shepherding-an-initiative

イニシアチブの推進担当者向けの、Software Initiative Funnelの5つのフェーズすべて（Identification → Research → Proof of Concept → Scoping & Commitment → Implementation）を網羅するエンドツーエンドの包括的なプレイブックです。各フェーズの作業量、成果物、意思決定ゲートを整理し、推進担当者が作成するものとチームに引き継ぐものの境界を明確にします。開始条件／終了条件やテンプレートの詳細を確認する必要がある場合は、get_confluence_pageで正規のファネルページを取得してください。

所有権のルール（全期間を通じて守ること）

イニシアチブの責任はあなたが持ちます。各受け入れチームは、自分たちの担当部分をどのように実行するかについて責任を持ちます。

各フェーズで覚えておくべきことは一つです。チームのストーリーを書き始めた時点で、その作業の責任はチームにありません。チーム間の調整をやめた時点で、イニシアチブは方向性を見失います。どちらの失敗も、あなたが防ぐ必要があります。

同じ境界について、エージェントに依存しないチーム側の視点（テックリードが読むバージョン）を確認するには、bitwarden-delivery-toolsでSkill(navigating-the-initiative-funnel)を呼び出してください。両方の視点を読むことで、実際の境界線がどこにあるかを常に意識できます。

期間と作業量の目安

ファネルページには、次のベンチマークが定められています。これらは努力目標ではありません。リーダーシップから「これを推進するにはどれくらいのコストがかかるのか」と尋ねられた際に、キャパシティ計画の根拠となる数値です。

フェーズ	期間	推進担当者の作業量	意思決定者
1 — Identification	約1週間	4～8時間	エンジニアリング全体のリーダーシップ
2 — Research	3～5週間	40～80時間	エンジニアリングリーダーシップ＋Architecture Council
3 — Proof of Concept	2～4週間	40～80時間	エンジニアリングリーダーシップ＋Architecture Council
4 — Scoping & Commitment	2～4週間	30～50時間	エンジニアリングリーダーシップ（Director以上）
5 — Implementation	2～6か月	月あたり10～20時間	チームが実行し、推進担当者が調整

合計：中規模のイニシアチブでは、4～9か月にわたり推進担当者の作業時間が150～300時間必要です。これは1人分の時間のおよそ5～10％で、ResearchとPoCにより多くの時間が集中します。

フェーズごとの推進担当者の役割

フェーズ1 — Identification

目的： リソースを時期尚早に確保せずに、意味のある評価に必要なだけの背景情報をまとめます。

あなたが作成するもの：

• Bitwarden Company（BW）プロジェクト内のBW Initiative課題。タイプ：Initiative。担当者：あなた（提案された推進担当者）。報告者：問題を提起した人。優先度：仮の値（「TBD - Awaiting Research」またはMedium）。
• 上流のARCHアイデア（存在する場合）を、経営層が読める要約にまとめた説明文です。TSIテンプレート全体のコピーではありません。パターン、リンクの一覧、フィールドごとの記入ガイドはアイデアに基づくイニシアチブにあります。
• JPD内のARCHアイデアからBWイニシアチブへの作業項目リンクです。これは追跡可能性を確保するための基本となるリンクであり、アイデアに基づくすべてのイニシアチブに必要です。
• 初期の「Relates to」リンク：過去の取り組み、関連するSRE／BRE／TSD／PMチケット、ARCHアイデアの調査で見つかったものすべて。
• JPDでARCHアイデアのステータスを「1️⃣ Identification」に更新します。

意思決定ゲート： エンジニアリング全体のリーダーシップが、Proceed／Hold／Declineを決定します。

あなたがしないこと： 解決策のスコープを事前に定めないでください。調査はまだ行われていません。最初から答えを用意しようとするのは避けてください。

フェーズ 2 — 調査

目的： 方向性を決定する前に、問題領域を深く理解し、解決策の候補を検討します。

成果物：

• 3～5 件のステークホルダーへのインタビュー（影響を受けるチームのテックリードが対象者として適切です）。
• コードベース全体の既存の実装を調査した現状分析 — 不整合、回避策、技術的負債を明らかにし、可能な場合は影響を定量化します。
• トレードオフを明示した、2～4 件の文書化された解決策。
• ステークホルダーのレビューを経て改善された、Confluence の EN-space assessments フォルダーにある Architectural Assessment。
• 大規模な取り組みの場合は、Architecture Council での任意のプレビュー。
• ARCH アイデアのステータスを「2️⃣ 調査」に更新します。

決定ゲート： Architecture Council の意見を踏まえ、エンジニアリングリーダーシップが判断します。PoC に進む／調査を継続する／保留する／却下する。

詳細スキル： ステークホルダーインタビューの構成、現状分析、選択肢の作成、Architectural Assessment のテンプレートについては、Skill(running-an-architectural-assessment) を参照してください。

フェーズ 3 — 概念実証

目的： Bitwarden のコードベースで、推奨する解決策が実際に機能することを、全面的な実装に着手する前に検証します。実践的な実験を通じてリスクを低減します。

成果物：

• 担当チームのテックリードと調整して選定した PoC エリア — 代表的でありながら範囲を限定したもの（ファイル約 1～5 件、または 1 つのモジュール）。
• より広範な展開で再利用するフレームワークまたは基盤と、実運用品質のサンプル実装 1～3 件。
• 1 件以上の PR（マージの有無は問いません。未マージの場合はタイトルに「PoC」と記載します）。
• Architecture Council での説明 — 15～30 分。PoC の PR、得られた知見（うまくいったこと、うまくいかなかったこと、変更が必要な点）、提案する方向性を含めます。
• Bitwarden ADR template に沿った ADR のドラフト（ステータス：提案）。ADR は一元管理されている bitwarden/contributing-docs リポジトリの docs/architecture/adr/ に置きます。リポジトリごとの ADR ディレクトリはありません。
• フレームワークとサンプル実装の コードの近くに置くドキュメント（Documentation Patterns に従います） — フレームワークのコードと同じ場所にある README.md、サンプルの近くにあるフォルダーレベルの注記、新しいパターンを導入する場合の CLAUDE.md の更新です。各ドキュメントの配置場所（コードの近くと一元管理された contributing-docs）の役割については、詳細スキルで説明しています。
• ARCH アイデアのステータスを「3️⃣ 概念実証」に更新します。

決定ゲート： Architecture Council の推奨を踏まえ、エンジニアリングリーダーシップが判断します。スコープ策定に進む／PoC を修正する／調査に戻る／却下する。

詳細スキル： PoC エリアの選定、フレームワークの構築、Architecture Council に向けた準備、ADR のドラフト作成については、Skill(running-a-proof-of-concept) を参照してください。

フェーズ 4 — スコープ設定とコミットメント

目的： 検証済みの PoC を、工数見積もり、チームの割り当て、経営陣のコミットメントを含む具体的な実装計画に落とし込みます。

作成する成果物：

• Confluence の EN スペースにある計画フォルダーに作成するハイレベルアーキテクチャ計画：スコープ、アプローチ（段階分け、移行パス）、チーム間の調整、依存関係、リスク軽減、成功指標、ドキュメント計画。
• BW イニシアチブの子エピック。通常はチームごと、または主要モジュールごとに 1 つ作成します。各エピックには、コードベース内の対象領域、PoC PR の参照、期待される成果、成功基準を記載します。
• 各担当チームとの引き継ぎ会議をスケジュールします（チームごとに 1 時間、20／15／15／10 分の構成）：20 分で説明、15 分で質疑応答、15 分でチームが初期の作業分解について検討、10 分で作業分解の期限を確定。
• アーキテクチャ計画に記載する費用対効果分析。
• BW イニシアチブの優先度（Critical／High／Medium／Low）を更新。
• 明確な Go／No-Go の判断とキャパシティの確保を求める、経営陣向けプレゼンテーション。
• エンジニアリング部門のリーダーシップと運用上の優先順位付けを行います：開始目標日、四半期、チームの他のコミットメントと比べた相対的な優先度、スプリントのキャパシティ割り当て。
• ADR を最終化します（ステータス：Accepted）。タイムラインも記載します。
• ARCH アイデアのステータスを「4️⃣ スコープ設定とコミットメント」に更新します。

意思決定ゲート： VP of Engineering／CTO。実装／スコープ再設定／延期／見送りのいずれかに進みます。

重大なアンチパターン： あなたがチームのストーリーを書くことです。作業分解はチームが行います。あなたではありません。あなたはイニシアチブのビジョンとの一貫性を確認するために作業分解をレビューするのであって、ストーリーを書き直すためではありません。

詳細スキル： Skill(scoping-and-handing-off-to-teams)。フェーズ 4→5 の引き継ぎは、開始側から行う作業の移行です。このスキルでは、移行の進め方に関する bitwarden-delivery-tools の Skill(running-work-transitions) を組み合わせて使用します。

フェーズ 5 — 実装

目的： 複数のチームにまたがって実行します。あなたは調整、支援、一貫性の維持を行います。実装は行いません。

作成／維持する成果物：

• コミュニケーションチャネル：任意の #initiative-<name> Slack チャンネル（PoC PR／ADR／アーキテクチャ計画／Jira ダッシュボードをピン留め）、隔週のテックリード同期（30～45 分）、任意のオフィスアワー、月次のステークホルダー同期アップデート。
• 全チーム参加のキックオフ会議（1 時間）。課題、ソリューション、PoC の結果、依存関係、コミュニケーションチャネルを振り返ります。
• アプローチの支援：Slack での質問への回答、テキストだけでは不十分な場合の Meets への参加、PoC で網羅されていないエッジケースの明確化。
• 各チームの初期 PR に対する一貫性レビュー。詳細なコードレビューではありません。チームの PR レビューは、引き続きチーム内で行います。
• チーム間の一貫性の維持：早期の逸脱検知、正当な差異と一貫性を損なう逸脱の判断、繰り返し出る質問と解決策をまとめた FAQ の作成。
• 毎週の進捗追跡（ダッシュボード＋Slack チャンネル）、隔週のテックリード同期、月次の経営陣向けアップデート。
• 段階的に作成するドキュメント（40％の時点でドラフト、90％の時点で最終化）：技術ガイド、移行ガイド、ADR の最終更新、コントリビューションガイドの更新、必要に応じたランブック。
• 知識の移転：最終数週間のうちに、テックトークまたはブラウンバッグを実施します（45～60 分）。
• 完了から 2 週間以内に振り返りを行います（取りまとめ役と、影響を受けるすべてのチームのテックリードが参加、1.5 時間）。
• スコープ設定で定義した成功指標に照らし、3～6 か月後に影響を測定します。
• ARCH アイデアのステータスを「5️⃣ 実装」に更新し、完了時に最終ステータスへ更新します。

詳細スキル： Skill(coordinating-implementation-across-teams)。フェーズ 4→5 の移行の後半段階（開始側における Work Transition Playbook のフェーズ 3～6：およそ 30 日後の状況確認、およそ 90 日後の振り返り、クローズ）では、このスキルと bitwarden-delivery-tools の Skill(running-work-transitions) を組み合わせて使用します。

横断的な実践事項

これらはすべてのフェーズに適用されます。

• ARCH アイデアのステータスを同期させてください。 ファネルのフェーズステータス（1️⃣～5️⃣）は、JPD ビューでアーキテクチャ部門とエンジニアリング部門のリーダーが取り組みを把握するためのものです。BW イニシアチブだけを更新していると、ポートフォリオレベルの情報が古くなります。
• BW イニシアチブには積極的にリンクを追加してください。 「関連する」SRE／BRE／PM チケット、過去の試みのチケット、関連するイニシアチブ、発生した運用チケットをリンクします。リンクの一覧は、維持する成果物の中でも特に価値の高いものです。
• Jira のコメントを時系列記録として活用してください。 重要な決定、ステークホルダーからのフィードバック、途中での方針修正、チーム間の依存関係の解決などは、イニシアチブのコメントに記録します。振り返りの際や、同様の取り組みに直面する今後の担当者にとって、非常に貴重な情報となります。
• アプローチの進展に合わせてイニシアチブの説明を更新してください。 これは調査文書ではなく、常に更新される概要です。詳細な調査はアーキテクチャ評価に、実装の詳細はエピックとストーリーに、決定の根拠は ADR に記載します。

イニシアチブの規模がファネルの想定より小さい場合

このファネルは、複数のチームにまたがるイニシアチブを対象に設計されています。主に 1 つのチーム、または隣接する 1 つのチームの領域で完結するイニシアチブの場合、テックリードはこのプラグインではなく、bitwarden-tech-lead を通じて直接進行を担当できます。小規模なイニシアチブの担当者として進める場合は、簡略版を実施してください。アーキテクチャ評価を簡素化し、PoC の規模を縮小し、引き継ぎミーティングを 1 回にし、実装フェーズ中のチーム間調整をより簡素にします。フェーズはそのまま適用されますが、成果物の規模は小さくなります。

規模にかかわらず、最低限守るべきことは、問題を文書化すること、決定を文書化すること、実装開始前にキャパシティを明示的に確保すること、そして最後に振り返りを行うことです。

よくある間違い

• 解決策が明白に思えるからといって、すぐに PoC に進む。 アーキテクチャ評価は、チームの専門知識を引き出し、摩擦が生じる箇所を明らかにする場です。これを省略すると、採用段階で行き詰まる解決策につながります。
• スコーピング中にチームのストーリーを書く。 その場では速く進みますが、自分たちで作成していない作業をチームが主体的に担うことはありません。必ず引き継ぎとチームによる作業の分解を行ってください。
• 運用上の優先順位付けを行わずにフェーズ 5 へ進む。 経営陣のコミットメント（「はい、これを進めてください」）は必要ですが、それだけでは不十分です。対象となる四半期、キャパシティの割り当て、相対的な優先順位を付けたチームのバックログ上の位置付けがなければ、エピックは停滞します。
• すべての PR をレビューする。 あなたはチームのレビュアーではありません。初期の PR はアプローチの整合性を確認し、コード品質についてはチームを信頼してください。
• ARCH アイデアのステータスを古いままにする。 ポートフォリオビューはこの情報に依存しています。フェーズが変わるたびに更新してください。
• 振り返りを省略する。 ファネル自体を改善する唯一の仕組みです。各イニシアチブの教訓を必ずフィードバックするか、さもなければ同じ教訓を再び学ぶことになります。

参考資料

• ソフトウェアイニシアチブファネル — フェーズごとの正規ドキュメントです。テンプレート全体、開始・終了基準、またはタイムライン表の例が必要な場合は、get_confluence_page で取得してください。
• アイデアベースのイニシアチブ — BW イニシアチブの構成、説明テンプレート、リンクの規則、フェーズごとのイニシアチブの発展を示す正規ドキュメントです。
• 作業移行プレイブック — 6 つのフェーズからなる移行の正規リファレンスです。フェーズ 4→5 の引き継ぎは、発案側からの移行です。
• アーキテクチャ／エンジニアリング運用モデル — アーキテクチャのイニシアチブポートフォリオの伝達方法（Architecture Initiative Review、Architecture/Platform sync）について説明しています。
• 関連項目：Skill(running-an-architectural-assessment)、Skill(running-a-proof-of-concept)、Skill(scoping-and-handing-off-to-teams)、Skill(coordinating-implementation-across-teams)、Skill(curating-the-strategy-ideas-backlog)、bitwarden-delivery-tools の Skill(navigating-the-initiative-funnel)、Skill(running-work-transitions)。