プランニングで止まらないリリースの周期の作り方
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
金曜日の午後4時30分です。カレンダーを開き、青くなっているミーティングのブロックを数えて合計します。今週9時間。月曜日のsprint planning。水曜日のmid-sprintリファインメント。木曜日のretroが別のプランニングセッションに変わったもの。チケットの「準備ができていなかった」ためにスケジュールした3つの見積もり会議。そしてチームは機能を1つshipしました。
それは計画していた機能ですらありませんでした。チームのシニアICが水曜日の朝に明らかに何かが壊れているのに気づき、昼食前にPRを開き、木曜日のstandup前にmergeしました。誰も担当範囲を決めず、見積もりをせず、ボードに載せなかったもの。
あなたは考えます。チームはプランニングにもかかわらずshipした、プランニングのおかげではなく。
この光景に心当たりがあれば、このガイドはあなたのためです。私はEMたちをこのまったく同じパターンに対してコーチングしてきました。解決策は「より良いプランニング」ではありません。解決策は「より少ないプランニングを、異なる構造で、1つの本物のシグナルを実際に見ながら行う」ことです。
プランニングが一週間を食い、何も改善しない理由
計算してみましょう。エンジニア6人、2週間ごとに2時間のplanning、さらに1時間のmid-sprintリファインメント、1時間のretro。それだけで1sprint当たり24エンジニア時間が正式なプランニングに消えます。EMの準備時間(通常1sprint当たり3〜4時間)、tech leadの準備時間(2時間)、Slackスレッドでの非同期チケットグルーミング(計算不可)を加えると、シニアエンジニア1人分の1週間相当を、2週間ごとにプランニングに費やしています。
それで何が得られますか? 私が見てきた多くのチームでは、3〜4倍外れる見積もり、どうせ毎週再優先順位付けされるbacklog、水曜日には誰も担当を引き受けていないretroのアクションアイテムが得られます。
本当の問いは「どうすればより良くプランニングできるか?」ではありません。「プランニングは実際に何のためにあるのか?」です。削ぎ落としてみましょう。プランニングはチームに必要な3つのことを生み出します。次に何をするかの短いリスト、名前のあるオーナー、リスクがある箇所についての共通認識。それ以外はすべて形式です。
落とし穴は、プランニングのセレモニーが生産的に感じられることです。部屋を出るときにsprintボードが埋まっています。仕事が進んだように見えます。しかし埋まったsprintボードはコードをshipしません。PRを書いているICがコードをshipします。エンジニアをプランニングミーティングに1時間拘束するたびに、問題を形にするかPRを開く機会を1時間奪っています。
セレモニーではなくスパイクとしてのプランニング
考え方を変えましょう。プランニングはスパイクです。明確なインプットとアウトプットを持つ、短く集中した調査。定期的なセレモニーではなく。憂鬱なカレンダーブロックでもなく。
1時間。週1回。チーム全員の参加は任意、EMとtech leadは必須。
私が3つの異なるチームで使ったサンプルアジェンダ。
- 0〜10分、何がshipされ、何がされなかったか。 先週のボードを確認する。責任追及なし。ただ状況を確認。shipされなかったものがあれば、理由を一文で：「レビューでブロックされた」「担当範囲が想定より大きかった」「インシデントで割り込まれた」。それだけ。
- 10〜25分、何がブロックされているか。 48時間以上動きがないもの。tech leadとEMが判断する：今すぐブロックを解除する、削除する、またはエスカレーションする。議論ではなく意思決定。
- 25〜50分、次の5〜7チケット。 sprint全体ではなく。次の5〜7つのもの。各チケットについて：オーナー、おおよその作業量(小/中/大)、爆発するかもしれない一つのリスク。story pointsなし。フィボナッチなし。プランニングポーカーなし。
- 50〜60分、オープンクエスチョン。 上記に収まらなかった、誰かが気にしていること。10分以内に解決できなければ、書面に残してオフラインに持ち越す。
以上です。40人規模のエンジニア組織のチームが、これに近い方法でプランニングを週8時間から1時間に削減しました。スループットは最初の月に下がらず、上がりました。
最も難しいのは、1時間で部屋を出る規律です。オープンクエスチョンがある? 書き留めて、オフラインに持ち出し、非同期で決める。ミーティングを延長しない。毎回1時間で終わる、さもなければ全体がセレモニーに逆戻りします。
6週間のShape Up vs 2週間のsprintの議論
エンジニアリングマネジメントには長年の議論があります。2週間のsprint(Scrum寄り)vs 6週間のShape Upサイクル(BasecampのShape Upモデル)。宗教的な論争は省略します。
機能を中心とした仕事のときは6週間サイクルを使う。 3〜6週間分の意味のある、明確に定義された担当範囲があります。チームは一つの大きな賭けにコミットし、意図を持って取り組み、実質的なものをshipできます。Shape Upはここで輝きます。なぜなら、作業時間の上限(担当範囲を削減する前に費やす最大時間)がモデルに組み込まれているからです。
仕事が対応型のときは2週間のsprintを使う。 顧客エスカレーション、インフラインシデント、サポートエンジニアリング、計画するよりも速くリクエストが来るプラットフォーム作業。2週間のsprintはより短いフィードバックループを提供し、戦略の方向転換のように感じさせずに再優先順位付けを可能にします。
正直なテスト：事前準備なしでこの質問をチームにしてみてください。「6週間で一つの大きな賭けにコミットするか、2週間で5つの小さな賭けにコミットするか、どちらが好ましいですか?」異なるチームが異なる答えを出します。どちらも有効です。間違った答えは混在させることです。6週間の仕事量を持ちながら2週間のsprintを回すと、毎sprintが失敗のように感じられます。対応型の仕事に6週間サイクルを使うと、毎回2週目に顧客インシデントがサイクルを吹き飛ばします。
一つ選ぶ。1四半期コミットする。再評価する。
チケットからPRまでの時間：本物のシグナル
開発速度のpointは忘れましょう。「担当範囲を追加し続けるため実際にはburn-upチャートになっているburn-downチャート」も忘れましょう。リリースの周期が機能しているかを示す数字は一つです。チケットからPRまでの時間です。
定義：チケットがエンジニアにアサインされてから、そのエンジニアが最初のPRを開くまでの経過時間。
以上です。story pointsなし。見積もりなし。2つのタイムスタンプだけ。
5日のチケットと見積もったものでその数字が4日以上なら、プランニングが機能していません。エンジニアが遅いからではありません。チケットが着手できる状態に整っていないからです。1日目、2日目、3日目はチケットが実際に何を意味するのか、担当範囲に何が含まれ何が含まれないのか、避けられないラビットホールに入ったときに何をすべきかを把握することに費やされます。それはプランニングが実行段階に漏れ出しているのです。
良い状態とはどういうものか。チケットからPRまでの時間の中央値が24時間以内。p75が48時間以内。p90が5日以内。分布にロングテールがある場合(10日以上滞っているチケットがいくつかある)、それがsprintを食っているチケットであり、調査すべきものです。
使っているツールで一度チャートを作ってください。Linear、Jira、ShortcutはいずれもAPIを通じてこのデータを公開しています。週次で引き出す。中央値を見る。上昇すれば、プランニングが劣化しています。下降すれば、何かが機能しています。
「3日の見積もりが11日かかった」パターン
すべてのEMがこれを経験しています。3日で見積もったチケット。11日後もまだレビュー中。エンジニアが怠けていたわけではありません。チケットが十分に整っていなかったのです。
これは見積もりの問題ではありません。より良い見積もりでは解決しません。仕事自体がsprintに入った時点で曖昧であり、「曖昧なものを進めながら考える」が3日のチケットを11日にします。
解決策は、チケットがsprintに入る前の30分のシェイピングセッションです。tech leadまたはシニアICが主導する。アウトプットは4つの事項をカバーする短いシェイピングドキュメント。
- 担当範囲内。 構築する具体的な動作や機能。抽象的ではなく、具体的に。
- 担当範囲外。 関連するように見えるが明示的に行わない2〜3つのこと。これが最も重要なセクションです。これがなければ、担当範囲は毎回膨らみます。
- ラビットホール。 既知のリスク：「これはauth serviceに触れる必要があるかもしれず、そうなれば止まって再担当範囲を決める」。事前に名指しすることで、エンジニアが1週間かけて潜り込まずに済みます。
- 作業時間の上限。 担当範囲を削減またはエスカレーションする前に費やす最大時間。見積もりではなく、予算です。
30分。1つのドキュメント。シェイピングを経たチケットは、経ていないチケットに比べて4〜5倍、作業時間の上限に近い形でshipされます。6人のチームでも60人のチームでも、これが成り立つことを確認しています。時間投資に対する計算は明らかです。
技術的負債の予算配分：20%ルール
sprint全体の20%を技術的負債に割り当てます。「時間があれば」ではなく。「来四半期にやる」でもなく。コミット済みの、名前のある、予算項目としての配分です。
これをスキップすると、負債が積み重なります。3四半期目には開発速度が半分になり、誰もその理由をうまく説明できません。3回リトライしないと通らないflaky test。18ヶ月前に一時的なはずだったマイグレーション。まもなく育児休暇を取るエンジニア1人しかdeployの方法を知らないサービス。
20%は魔法の数字ではありません。それを下回ると負債が返済より速く積み上がる下限です。補填期間中は30%必要なチームもあります。コードベースが本当に若ければ15%で運営できるチームもあります。15%を下回ると、翌四半期の開発速度から借り入れていることになり、それを実感することになります。
どの負債を先に返すか、優先順位の順に。
- 顧客向けの問題。 チームが回避策を取ってきたが顧客はまだ直面しているバグ。サポートチケットに現れるパフォーマンスの問題。常に最優先。
- 開発者向けの問題。 遅いテスト、壊れたローカル開発環境、deployの地雷。週1時間以上のコストをチームにかけるもの。
- 理論的なクリーンアップ。 気分は良くなるが強制力のないリファクタリング。最後の優先度。これらがそもそもsprintに入るべきかについて正直になること。
20%をボード上で見えるようにしてください。チケットに「tech-debt」とタグを付ける。週次のプランニングスパイクでその割合を報告する。3週間連続でsprintが20%を下回ったら、それは警告フラグです。
ブロック解除のパターン：PRレビューSLAと意思決定カレンダー
プランニングのどの変更よりも実際に効果のある2つの具体的なメカニズム。
PRレビューSLA。 業務時間中に4時間以内に最初のレビューを行う。ガイドラインではなく。ブロッキングコミットメントとして。PRが4時間以上レビューされない状態にあれば、アサインされたレビュアーが担当作業を中断してレビューします。厳しく聞こえます。機能します。
これを採用したチームが以前の2〜3倍shipしている理由は明確です。PRが2〜3日レビュー待ちになると、エンジニアは別の作業にコンテキストを切り替え、レビューが来たら切り替えて戻り、フィードバックに対応するためにまた切り替えます。切り替えのたびに30〜60分の実際の生産時間が失われます。4時間のSLAはそのループを解消します。
チームの業務合意書に書く言葉、そのまま使えます。
業務時間中に4時間以内に最初のレビューを行う。ただし事前に通知された集中作業ブロック中のエンジニアを除く。レビューはレビュアー自身のアクティブなチケットを含む他の作業をブロックする。コメントのみのレビューでも有効。期待するのはフィードバックであり、承認ではない。
意思決定カレンダー。 週1回30分のスロットで、EMとtech leadが待ち状態になっているすべてのことを決定します。アーキテクチャの判断。ベンダーの選択。「ライブラリAかライブラリBか?」という意思決定。48時間以上Slackスレッドに滞留しているあらゆる質問。
これがなければ、意思決定は何週間も伸びます。エンジニアが一度聞き、「考えてみます」という返答をもらい、質問はスレッドで消えます。意思決定カレンダーは公開コミットメントを作ります。金曜日午前11時までに、その質問はyes、no、または「さらに30分確認が必要」のいずれかになります。「後で返答します」のループはなし。
どちらのメカニズムも機械的なものです。文化の変革や同意を得るための説明行脚は不要です。月曜日にコミットして火曜日から始めます。
いつエスカレーションするか(そして「エスカレーション」が実際に意味すること)
多くのEMは「エスカレーション」を誤って使います。何かが火事のときに上司のところへ行くことだと思っています。それはエスカレーションではありません。余分なステップを踏んだステータスアップデートです。
エスカレーションとは、適切な見えていない意思決定を可視化することです。
本物のエスカレーションの3つのトリガー。
- 担当範囲が作業時間の上限を超えた。 1週間の上限でチケットを整えました。エンジニアが今、3週間の問題だと伝えています。意思決定(まだやるか、担当範囲を削るか、来四半期に回すか)はチームの外にあります。エスカレーション。
- 別チームへの依存関係が2日以上ブロックしている。 聞きました。フォローアップしました。何も動いていません。別チームのEMに、具体的な要求と具体的な期限を持ってエスカレーション。「手伝ってもらえますか?」ではなく「auth teamが木曜日のEODまでにこれを優先できるかどうか、yes/noで教えてください」。
- アーキテクチャの意思決定があなたのチームを超えて影響する。 新しいデータベースを導入しようとしています。新しいauthパターン。新しいdeployアプローチ。影響範囲があなたのチームより大きければ、意思決定が適切なレベルで所有されるよう上にエスカレーション。
Slackまたはメールでそのまましいいるエスカレーションの3行テンプレート。
必要な意思決定：[具体的な質問、yes/noまたは選択肢の一つとして枠組み]
なぜ今：[何がブロックされているか、誰が影響を受けているか、待つコストは何か]
期限：[具体的な日時で、返答が必要なタイミング]
これが全テンプレートです。3行。背景説明の段落なし。受け取る側が文脈を必要とすれば、聞いてきます。明確さ自体がブロックの解除です。
この新しい周期の最初の30日間
これをすべて月曜日に展開しないでください。チームの信頼を失う最も確実な方法は、新しい運営モデルを発表し、何も機能するところを見せないうちに従うよう求めることです。
定着する30日間の展開計画。
1週目：定期ミーティングを1つ廃止する。 誰も好きでないものを選ぶ。おそらくmid-sprintリファインメント。キャンセルする。何が壊れるか観察する。たいていは何も壊れません。もし何かが壊れれば、そのミーティングが実際に何をしていたかが分かりました。
2週目：新しい1時間のプランニングスパイクを実施する。 一度実施する。チームに新しいフォーマットが何でなぜかを説明する短い注記を送る。1時間やり通す。時間を守る。
3週目：チケットからPRまでの時間を計測する。 ツールからデータを引き出す。チャートを作る。まだ共有しない。自分の分布が実際にどのような形かを理解するために1週間自分だけで見る。
4週目：データをチームと見直して調整する。 チャートを持ち込む。「何が見えますか? 何が驚きですか? 変えるとしたら一つ何ですか?」と聞く。チームの意見を聞く。彼らの言葉に基づいて周期を調整する。
30日後には、6時間以上のプランニングを1時間に置き換え、唯一重要なシグナルを計測し、チームが誇りを持って守れる周期を確立しています。時間も取り戻せます。それをEMが本当に担うべき仕事に使ってください。問題を整え、人のブロックを解除し、エンジニアを成長させること。
この記事の冒頭の金曜日午後の光景は? 60日後には見覚えがないものになります。カレンダーにはプランニングブロックが1つ、意思決定カレンダーブロックが1つ、そして空白が多く並んでいます。チームはより多くをshipしています。そして以前はプロセスにもかかわらずshipしていたシニアICは、プロセスのおかげでshipするようになります。
関連記事
