先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を

この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。 スクラム導入のキモ まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えが

最近エンジニアの異動について軽く議論することがありました。自分はチームの安定性の側面からやや否定的な立場だったのですが、その議論で刺激を受けて周辺領域も含めて考え直したところ、組織の成長という軸で色々な知識がつながって面白かったのでまとめてみます。 議論の前提 異動も含めてエンジニア組織について考える時、まずは外せない前提がひとつあると思います。それは、安定したチームないしバリューストリームを維持することです。「チームトポロジー」の3章では以下の言葉を引用し、複雑なシステムの開発にはチームの効果的なパフォーマンスが欠かせないことを論じています。 ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ。 現代のソフトウェア開発の変化速度や複雑性に対処するには個人では限界があり、チームとしての活動が欠かせません。チームメンバー間で強い信頼関

ピープルマネジメントの文脈でエンジニア同士のメンタリング制度を設置しているIT企業は多いと思います。自分が勤める会社も例に漏れず、1on1によるメンタリング制度があります。エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ でも整理したように、ピープルマネジメントの領域にも取り組んでいきたいと考えていたわけですが、9月ごろからメンティー2人を持つ機会に恵まれました。1on1やコーチングの経験はほとんどなく、同僚のキャリアに関わる責任の重さを思うと、なんらか知識や型を整えて臨むのが適切だろうと考えました。この記事では、はじめてのエンジニア1on1メンターをやっていくために学んだことや実践の様子をまとめてみようと思います。 座学編 スクラムマスターの文脈でコーチングは多少関わりがあるものの、やはり1on1によるメンタリングは初めての経験です。何はともあれ本を1冊読む

企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン

ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き

最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。 エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいも