scoping-and-handing-off-to-teams

イニシアチブを導くシェパード向け、フェーズ 4（スコープ設定とコミットメント）の詳細プレイブックです。大規模なリソース配分を行う前の最終判断ゲートです。シェパードは、作業を主導する立場から、実行するチームを支援する立場へと移行します。成果物は、高レベルアーキテクチャ計画、子エピック、チームごとの引き継ぎミーティング、費用対効果分析、リーダーシップ向け Go／No-Go プレゼンテーション、運用上の優先順位付け、キャパシティ配分、確定版 ADR です。期間の目安は 2〜4 週間で、シェパードの作業時間は 30〜50 時間です。Work Transition Playbook の、発案側における Preparation フェーズと Transition Sessions フェーズでは、bitwarden-delivery-tools の Skill(running-work-transitions) を組み合わせて使用します。

まず避けるべきアンチパターン

何よりも先に、作業の細分化を担うのはチームであり、シェパードではありません。 このフェーズで最も大きな失敗につながるのは、シェパードがチームのストーリーを書くことです。

ファネルのドキュメントには明確に記されています。「引き継ぎ後に、チームで作業を細分化するセッションを実施します。ストーリーを作成するのはチームであり、シェパードではありません。」チームが書いていないストーリーを、チームが自分たちのものとして捉えることはありません。そうなると、その後の失敗は「ストーリーがチームの実際の働き方に合っていないため、スケジュールに遅れています」という形で表面化し、確実な立て直しはできません。

この原則を守ってください。あなたの役割は、各チームが作業を適切に細分化できるよう、十分な背景情報、スコープ、パターンを提供することです。チームに代わって細分化することではありません。

作成するもの

フェーズ 4 では、概ね次の順序で 8 つの成果物を作成します。高レベルアーキテクチャ計画、Jira の子エピック、チームごとの引き継ぎミーティング、費用対効果分析、割り当てられたイニシアチブの優先度、Go／No-Go を判断するためのリーダーシップ向けプレゼンテーション、キャパシティ配分を含む運用上の優先順位付け、確定版 ADR です。それぞれについて、以下のセクションで説明します。

高レベルアーキテクチャ計画

EN スペースのアーキテクチャ計画フォルダーに配置する Confluence ページです。「High-Level Architecture Planning」テンプレートに従います。ファネルのドキュメントでは、以下の内容が指定されています。

• スコープ。 変更対象となるリポジトリ、モジュール、ファイルです。具体的に記述してください。この段階でスコープが曖昧だと、実装中にスコープを再設定することになります。
• アプローチ。 変更をどのように展開するかを記述します。段階的な展開、移行経路、移行中および移行後に古いパターンをどう扱うかを含めます。
• チームの連携。 各チームが担当する範囲を記述します。可能であれば、エピックごとに担当チームを 1 つ割り当てます。
• 依存関係。 先に実施する必要がある作業、並行して進められる作業、チーム間で作業が妨げられる箇所を記述します。
• リスク軽減。 失敗の形態、ロールバック計画、一時停止や方針転換の判断につながる指標を記述します。
• 成功指標。 イニシアチブの成功をどのように判断するかを記述します。これらの指標は今定義してください。実装完了から 3〜6 か月後に影響を測定する際の基準となります。
• ドキュメントの必要事項。 展開の進行に合わせて作成または更新するものを記述します（技術ガイド、移行ガイド、ADR の更新、貢献ガイドの変更、ランブック）。

アーキテクチャ計画は、各チームのテックリードが引き継ぎミーティングの前に読むドキュメントです。その読者を想定して作成してください。

Jira の子エピック

BW イニシアチブの下にエピックを作成します。通常は、チームまたは主要なモジュールごとに 1 つ作成します。各エピックには次の内容を含めます。

• 概要。 短く具体的にします（例：「ブラウザー拡張機能を新しいエラーパターンに移行」）。
• チームの割り当て。 個人ではなく、チームに割り当てます。
• 説明。 影響を受けるコードベースの領域、採用するパターン（PoC PR へのリンク）、このエピックで期待される成果、成功基準、チームが把握しておく必要のあるチーム間の依存関係を記載します。
• 絞り込み用のラベル／コンポーネント（例：initiative-typescript-migration）。これにより、後で全員のダッシュボードに進捗を集約できます。

ファネル文書にあるエピックの例：

エピック： ブラウザー拡張機能を新しいエラーパターンに移行 チーム： ブラウザー拡張機能チーム 説明：

• PoC で実証されたエラーミドルウェアパターンを採用する（PR #1234）
• バックグラウンドスクリプト、コンテンツスクリプト、ポップアップに適用する
• Sentry への既存のエラー報告を維持する
• 成功基準： 拡張機能のすべてのエラー処理が新しいパターンに従い、リグレッションがゼロであること

エピックに含めないものは、実装ストーリーです。これらはチーム独自のブレークダウンセッションで作成します。

チームごとの引き継ぎミーティング

チームごとに 1 時間の引き継ぎミーティングを設定します。ファネル文書にある進行内容は次のとおりです。

時間	内容
20 分	シェパードが説明：PoC の調査結果、このチーム向けのアーキテクチャ計画のセクション
15 分	質疑応答 — チームがアプローチについて不明点を確認
15 分	チームで議論：ブレークダウンの進め方についての初期検討
10 分	次のステップ — チームがブレークダウン完了の具体的な期日を約束

これは、開始側から見た Work Transition Playbook のフェーズ 2 でもあります。ファネル文書では Playbook が明示的に参照されており、どちらの立場からも適用されます。

ミーティングの前：

• アーキテクチャ計画と PoC PR のリンクを、数営業日前までに送ります。事前に資料を読んだチームは、より的確な質問を持ってきます。
• チームのテックリードと EM が出席することを確認します。

ミーティング中：

• 何をするか（アーキテクチャ計画のセクション）より先に、なぜそれをするのか（問題と PoC の調査結果）から説明します。チームは仕様よりも背景を理解したほうが、よりよい反応を示します。
• 特にロードマップとの衝突が明らかになる質問には、真摯に対応します。そうした話し合いには引き継ぎが適切な場であり、実装中に行うのは適切ではありません。
• ブレークダウンの確約期日を決めずにミーティングを終えないでください。「そのうちやります」では、エピックはバックログで形骸化していきます。

ミーティングの後：

• チームが独自にブレークダウンセッションを実施します（あなたは参加しません）。
• チームのテックリードが、完了したブレークダウンをあなたに共有します。
• イニシアチブのビジョンとの一貫性を確認します。ストーリーを書き直したり、細かく口を出したりするためではありません。ファネル文書にある質問の例は、「よさそうですが、PoC の async/await パターンではなくコールバックを使っています。これは意図的ですか？」です。

コスト／便益分析

アーキテクチャ計画に記載します。ファネル文書では次のように整理されています。

• コスト： チーム全体で必要となる作業の規模（各チームの見積もりの合計に加え、あなたのシェパードとしての時間と Architecture Council の時間）。
• 便益：
  • 定量的： バグの削減、時間の節約、パフォーマンスの向上、オンコールの通知の削減。
  • 定性的： 開発者エクスペリエンス、保守性、一貫性、セキュリティ態勢、将来的な柔軟性。
• 比較。 率直に記載します。定性的な便益が大きい場合は、そのように述べます。リーダーシップがそれを踏まえて判断できます。定量的な根拠がないのにあるように見せると、次のイニシアチブの信頼性を損ないます。

イニシアチブの優先度

ファネルのドキュメントに従い、エンジニアリング部門のリーダーと連携して、他のイニシアチブやArchitecture / Engineering Operating Modelポートフォリオと比較した優先度を設定します。

• Critical： 主要な製品開発を妨げる、または重大なリスクを生じさせる場合 — 直ちに着手します。
• High： 品質向上に大きく寄与する、またはリスクを大幅に低減する場合 — 四半期内に予定します。
• Medium： 意義のある改善で、柔軟に予定を組める場合 — 2四半期以内に実施します。
• Low： あれば望ましいもので、余力ができたら実施する場合 — 空き状況に応じて予定します。

JiraでBWイニシアチブの優先度を更新します。

リーダーシップ向けプレゼンテーション

ステークホルダーとの同期ミーティングで、エンジニアリング部門のリーダーに計画を提示します。ファネルのドキュメントに従い、以下を含めます。

• 問題の概要と解決アプローチ。
• PoCの検証結果。
• 工数見積もりとスケジュール（各チームの内訳を集約したもの）。
• コストと便益の分析。
• リスク評価。
• イニシアチブの優先度。
• 必要なリソース — 対象チーム、必要なキャパシティ、期間。

明確な実施可否の決定を求めます。経営陣のコミットメントとは、「はい、このイニシアチブを完了するためにリソースを割り当てます」ということです。

運用上の優先順位付け

これは、ファネルのドキュメントで経営陣のコミットメントと明確に区別されているステップです。経営陣のコミットメントは「いずれ実施する」という意思を示します。運用上の優先順位付けは、「この日程で、このキャパシティを使って着手する」ということです。

エンジニアリング部門のリーダーと連携して、以下を調整します。

• 目標開始日。 イニシアチブの優先度と、他のチームのコミットメントに基づいて決定します。
• 実施する四半期。
• 各エピックの相対的な優先度（製品ロードマップの機能、他のイニシアチブ、バグ、技術的負債など、チームの他の作業と比較）。

エンジニアリング部門のリーダーは、チームリーダーやEMと連携して、以下を行います。

• イニシアチブの重要性とスケジュールを周知します。
• キャパシティを割り当てます（例：「今後3スプリントのスプリントキャパシティの15％」）。
• チームのロードマップを調整します。
• チームが過剰なコミットメントを抱えている場合、競合を解消します。
• 適切な優先度を設定して、各チームのバックログにエピックを登録します。

このステップの成果物（ファネルのドキュメントに準拠）：

• 明確なスケジュール（例：「実装は2026年第2四半期に開始し、2026年第3四半期の完了を予定」）。
• 関係する各チームが、キャパシティを割り当てる必要があることを把握している。
• 各チームのバックログにおいて、Jiraでエピックの優先度が設定されている。
• 各チームが、この作業が自チームのロードマップに含まれることを了承している。

ファネルのドキュメントでは、「経営陣のコミットメントはあるが運用上の優先順位付けがないイニシアチブは、バックログで無期限に停滞する」と、この失敗パターンを明示しています。運用上の優先順位付けが完了するまで、実装に進まないでください。

ADRを確定する

• まだの場合は、ADRのステータスを「Accepted」に更新します。
• 実装スケジュールと最終的なスコープを追加します。
• 開始日と完了予定日を記載します。

BWイニシアチブの更新

スコーピング中（Idea-Based Initiativesを参照）：

• 優先度フィールド： リーダーシップが最終的に割り当てた優先度を設定します。
• 子エピック： チームまたはモジュールごとに1つ作成し、イニシアチブのJira子課題として登録します。
• コメント： 経営陣のコミットメントを記録します — 誰が承認したか、どの程度のキャパシティが割り当てられたか、どのようなスケジュールで合意したか。この記録は、コミットメントの監査可能な証跡になります。
• 説明： High-Level Architecture Planへのリンクを、説明またはコメントに記載します。
• ARCHアイデアのステータス： 「4️⃣ Scoping & Commitment」に更新します。

終了基準

ファネルのドキュメントによると：

• 成果物： 高レベルアーキテクチャ計画、明確なスコープとアプローチを定めたエピックの作成、各チームによるストーリーの分解と見積もりの完了、チームの見積もりを集約した全体のスケジュールと工数、イニシアチブの優先度の設定、費用対効果分析の完了、経営陣のコミットメントの確保、明確なスケジュールとキャパシティの割り当てを伴う、各チームのバックログでのエピックの優先順位付け。
• 意思決定者： ステークホルダーとの合意を得た VP of Engineering／CTO。
• 考えられる決定： 実装に進む／スコープを再設定する（スコープを縮小して再見積もりする）／延期する（時期が合わない場合は将来の四半期に予定する）／却下する。

ファネルのドキュメントに記載されている、成功の鍵となる5つの要素：

1. エンジニアリング部門のリーダーが「はい、これを実行します」と明確に表明すること。
2. 各チームのキャパシティが、明確な開始日と終了日とともに割り当てられていること。
3. キャパシティと依存関係を考慮した現実的なスケジュールであること。
4. 各チームのバックログでエピックが優先順位付けされ、チームがいつストーリーをスプリントに取り込むか把握できること。
5. 各チームが自らのストーリー分解に責任を持つこと。

このフェーズからフェーズ5に引き継ぐ内容

Implementation に進むと（Skill(coordinating-implementation-across-teams) を使用）、Work Transition Playbook のサポート期間フェーズが始まります。発案側のガイダンス（何をあなたに依頼し、何を依頼しないか）は Skill(running-work-transitions) にあります。Implementation の開始前に目を通してください。これは、受け入れ側のチームが読んでいるものと同じプレイブックです。

よくある間違い

• チームのストーリーを書く。 すでに挙げましたが、よくある失敗パターンなので再度取り上げています。
• 経営陣のコミットメントをスコープ設定の終わりと見なす。 運用上の優先順位付けがなければ、経営陣のコミットメントは理論上のものにすぎません。
• 途中で切り上げられる引き継ぎ会議を受け入れる。 引き継ぎは、聞きにくい質問をする場です。1時間未満で終わる場合、何かが話されずに残っています。
• 費用対効果の説明を誇張する。 エンジニアリング部門のリーダーには見抜かれ、次のイニシアチブが信頼の失墜を代償として負うことになります。
• アーキテクチャ計画の「ドキュメント作成のニーズ」セクションを省略する。 そうすると、パターンがすでに乖離した後の終盤になってからドキュメントを作成することになります。
• チームの合意を得ずに見積もりを集約する。 チームが見積もりを提示した時点でそれを信頼していなければ、その見積もりどおりに成果を出すこともありません。

参考資料

• ソフトウェアイニシアチブファネル §4 — 各フェーズの正式な説明、引き継ぎ会議の構成、運用上の優先順位付け。
• Work Transition Playbook — 引き継ぎプロセスの正式な手順。このフェーズは、フェーズ1～2における発案側にあたります。
• Idea-Based Initiatives — スコープ設定を通じて BW Initiative を更新する方法。
• Architecture / Engineering Operating Model — イニシアチブのポートフォリオを、他の Architecture の作業と照らし合わせて優先順位付けする方法。
• 関連項目：全体のプレイブックは Skill(shepherding-an-initiative)、発案側の引き継ぎ手順は bitwarden-delivery-tools 内の Skill(running-work-transitions)、スコープ設定から引き継がれる内容は Skill(coordinating-implementation-across-teams) を参照してください。