開発の進め方

ソフトウェア開発は、作ってみて初めて分かることが多い仕事です。最初から完璧な計画は作れないので、小さく区切って計画し、定期的に見直すことを前提にします。

どちらか一方を厳密に守る必要はありません。機能開発はスプリント、運用は WIP 制限つきのカンバン、のように組み合わせるチームも多いです。どちらでも、ふりかえり（何がよく、何を変えるか）は欠かさないようにします。

ふりかえりの進め方

作る前の見積もりは、当たらないことを前提に扱います。始めたばかりは分からないことが多く、進むほど幅が狭くなります（不確実性のコーン）。

よくある失敗は、見積もりを約束として扱い、外れた人を責めることです。次から大きめに言われ、予測の役に立たなくなります。ベロシティをチーム間で比べたり、目標にしたりするのも、ポイントの水増しを招きます。

ロードマップは、日付の約束の表ではなく「何を、どの順で、なぜやるか」の共有です。「今（Now）・次（Next）・その後（Later）」に分け、近いものほど具体的に、遠いものほどぼんやり書くと、確度の差が伝わります。

日付を出すときは「確度 80% で11月、早ければ10月」のように確度を添え、月1回など定期的に更新します。機能の名前より「解きたい問題」で書いておくと、途中でよりよい解決策が見つかったときに変えやすくなります。

やりたいことは、いつもチームの力より多くあります。優先順位は、価値（何がどれだけよくなるか）とコスト（どれだけかかるか）で並べるのが基本です。

EM は機能の優先順位そのものは PdM と一緒に決め、技術の仕事（負債・信頼性・運用）の枠を確保する役を担います。「やらない」と決めたものも理由を書いて共有すると、同じ議論のくり返しが減ります。

遅れは分かった時点で、すぐに伝えます。期日の直前に伝えると、選べる手がほとんど残っていません。伝えるときは、選択肢と、それぞれで何が起きるかを並べて、関係者と一緒に決めます。

「人を足す」については、『人月の神話』で知られるブルックスの法則（遅れているソフトウェアのプロジェクトに人を足すと、さらに遅れる）が有名です。新しい人が慣れるまでの時間と、やりとりの手間が増えるためです。足すなら、切り離しやすい作業を任せられる場合に限ります。

見積もりの方法

障害・問い合わせ・他チームからの依頼などの割り込みは、計画に入れていなくても必ず来ます。過去の実績から割り込みの割合を見て、先に差し引いて計画します。

割り込みの当番は、オンコールの当番と同じ人にすると、障害対応と問い合わせ対応を1人で抱えて回らなくなることがあります。チームの大きさに合わせて分けるかを決めます。

チームの会議は、目的・長さ・決めることがはっきりしていれば少なくて済みます。目的のない定例は、集中の時間を細切れにします。

• 集中の時間をまもるため、会議は午前か午後のどちらかに寄せる、会議のない曜日を作る、などの工夫をする。
• 非同期（文章）で済むものは会議にしない。進捗はチケットやチャットで共有できる。
• 四半期に1回、すべての定例について「まだ必要か」を見直す。

コードレビューは、品質を上げ、知識をチームに広げる場です。一方で、レビュー待ちは開発の待ち時間のうちで大きな割合を占めがちです。ルールをチームで決めておきます。

EM はレビューの待ち時間を数字で見て、偏りがあれば割り当てを直します。シニアのメンバーばかりがレビューしているなら、他の人にも任せることが育成にもなります。

CI/CD とボトルネック

速く出すことと安全に出すことは、小さく・段階的に・すぐ戻せるようにすれば両立できます。

機能フラグは便利ですが、増えすぎると設定の組み合わせが複雑になります。使い終わったフラグを消す作業も計画に入れます。

ふりかえりは、チームが自分たちの進め方を自分たちで直す場です。出た意見を並べて終わりにせず、次に変えることを1〜3個に絞って決めます。

• 決めたことには担当をつけ、次回の最初に「やってみてどうだったか」を確かめる。
• EM が話しすぎない。ファシリテーターをメンバーで回すのもよい。
• 同じ型が続いて飽きてきたら、型を変える。