navigating-the-initiative-funnel

Bitwarden は、部門横断的な技術作業を Software Initiative Funnel を通じて進めます。シニアエンジニア（チーム横断の取り組みでは通常 Staff 以上、主に単一チームの領域内で完結する小規模な作業ではテックリードの場合もあります）が、各取り組みを「特定」「調査」「概念実証」「スコープ設定とコミットメント」「実装」の5つのフェーズを通して推進します。テックリードは全フェーズに参加しますが、特に「スコープ設定とコミットメント」と「実装」で深く関与します。このスキルは、別の推進担当者と連携するテックリードの視点で、その関与に関する実務ガイドをまとめたものです。テックリード自身が取り組みの推進も担う場合は、両方の役割についてフェーズの説明を確認し、両方の役割を果たしてください。正式なリファレンスが必要な場合は、get_confluence_page MCP ツールを使ってファネルのページを取得してください。このドキュメントは実務向けの要約です。

所有権のルール

各フェーズで覚えておくべきことは、ひとつの文にまとめられます。推進担当者は取り組みに責任を持ち、テックリードは自分のチームがその一部をどのように実行するかに責任を持ちます。この境界が曖昧になると、次のどちらかの問題が起こります。推進担当者がチームのストーリーを書き始めてチームが作業を自分ごととして捉えなくなるか、テックリードが自分の権限外のチーム横断的な決定を始めて取り組みが迷走します。

フェーズごとの役割

フェーズ1 — 特定

推進担当者は BW Initiative issue を作成し、問題を記録して、エンジニアリングリーダーから実施可否の判断を得ます。

この段階でのテックリードの役割は限定的です。 チームの領域が影響を受けるため推進担当者から連絡があった場合は、背景情報、既知の経緯、関係者を共有してください。過去の取り組みがあれば伝えてください。まだ調査が行われていないため、事前にスコープを決めないでください。

フェーズ2 — 調査

推進担当者は関係者（テックリードが該当する可能性もあります）にヒアリングし、コードベースを調査して、2～4個の解決策を提示する Architectural Assessment を作成します。

テックリードの役割： ヒアリングに適切に対応してください。チームの問題点、回避策、推進担当者が外部からは把握できない制約を共有してください。可能であれば数値化してください（「これにより、スプリントごとに約3件のバグが発生します」など）。推進担当者が提案する方向性がチームのロードマップ上の作業と衝突する場合は、コミットメントの後ではなく、この段階で明らかにしてください。

フェーズ3 — 概念実証

推進担当者は PoC の対象領域（チームのコードベースが対象になる場合もあります）を選び、フレームワークまたはサンプルを構築し、Architecture Council に提示して、ADR の草案を作成します。

PoC がチームのコードベースで行われる場合のテックリードの役割： チームから窓口となる担当者を割り当て、推進担当者とペアを組むか、PR をレビューしてもらってください。門番ではなく、協力者になってください。PoC は実際のコードで実現可能性を検証するためのものです。手抜きがある場合は、それを明らかにすべき兆候として扱いますが、PoC の PR を本番コードのレビューと同じように扱わないでください。アプローチに関する懸念は推進担当者に直接伝え、回避策を黙って実装しないでください。

フェーズ 4 — 範囲設定とコミットメント

テックリードの参加が最も重要になるフェーズです。シェパードは BW イニシアチブの下に子エピックを作成し（通常、チームまたは主要なモジュールごとに 1 つ）、エピックの説明を記述して、引き継ぎミーティングを設定します。その後、作業の細分化はチームが担います。

シェパードは引き継ぎの際に、PoC の調査結果、チームに関連するアーキテクチャ計画のセクション、成功基準、および質疑応答の時間を用意します。テックリードは、質問、既存のチームロードマップにどう組み込めるかについての現実的な見通し、そして作業の細分化自体を完了する期日を用意します。

引き継ぎの後、チームで作業の細分化セッションを実施します。ストーリーを作成するのはシェパードではなく、チームです。次のファネルのストーリー品質ルールを適用してください。

• 具体的に記述します。「エラー処理を更新する」よりも、「user-service のエラー処理を新しいパターンに移行する」のほうが適切です。
• 完了条件を定義する受け入れ条件を記述します。技術的なアプローチについては、PoC の PR またはアーキテクチャ計画を参照します。
• 依存関係を記録します。特にチームをまたぐ依存関係は重要です。調整のため、シェパードに共有します。
• 個人ではなく、チームに割り当てます。 個人への割り当てはスプリント計画で行います。
• フィルタリング用のラベルを付けます（例：initiative-typescript-migration）。これにより、シェパードのダッシュボードで進捗を追跡できます。
• チームの通常のプロセスで見積もります。 イニシアチブの作業のために、新しい見積もり方法を考案しないでください。

作業の細分化が完了したら、シェパードに共有します。シェパードはイニシアチブのビジョンとの一貫性を確認しますが、ストーリーを書き直したり、細かく管理したりはしません。「よさそうですが、PoC の async/await パターンではなくコールバックを使っています。これは意図的ですか？」といった質問を想定してください。これがシェパードの役割です。テックリードの役割は、適切な回答を用意することです。

Tech Breakdown Template は、このフェーズの標準となる成果物です。 ファネルはチームにエピックを渡し、チームはそれを基に Tech Breakdown を作成します。Breakdown は bitwarden/tech-breakdowns リポジトリに保存します。このリポジトリのトップレベルの README.md には、チームごとのフォルダー規約が記載されています。テンプレートファイルは templates/breakdown.md と、その補助ファイルである templates/tasks.md の 2 つです。これらを取得するには、既存のローカルチェックアウトから読み込むか（パスが明らかでない場合は、人間に保存場所を確認してください）、リポジトリをクローンします。

git clone https://github.com/bitwarden/tech-breakdowns.git

クローンに失敗した場合（リポジトリはプライベートなので、認証なしでクローンすると 404 になります）、人間に認証情報を使ってクローンしてもらい、ローカルパスを共有してもらってください。リポジトリの README に記載されている規約に従って、2 つのテンプレートファイルをチームのフォルダーにコピーし、テンプレートで定義されているセクションを記入します。前述の「共有」の段階で、シェパードはこの breakdown を確認します。

イニシアチブが実装フェーズに進む前に、エンジニアリングリーダーシップはキャパシティを明示的にコミットする必要があります。つまり、具体的なスプリントに対する具体的な割り当てが必要です。そのコミットメントなしに、エピックをバックログに受け入れてはいけません。 運用上の優先順位付けを伴わない経営陣のコミットメントは、エピックがバックログに置かれたまま、スプリントに取り込まれないという失敗につながります。

フェーズ 5 — 実装

チームが実行に移ります。シェパードは各チーム間を調整し、アプローチに関する質問に答え、初期の PR を 1～2 件レビューして方向性の一致を確認し（詳細なコードレビューではありません）、進捗をリーダーシップに報告します。

テックリードが継続して担う責任：

• シェパードやその他の関係チームとの隔週のテックリード同期。進捗、ブロッカー、チーム間の依存関係、新たに生じた疑問について順番に共有します。30～45 分です。
• チーム内での方向性のずれに注意します。 エンジニアが PR ごとにパターンを異なる形で解釈している場合は、シェパードが気づくのを待たずにガイダンスを明確にします。
• 新たに生じた問題を報告します。 PoC では本番環境における問題の実態をカバーできていなかったことを示す問題にチームが直面した場合は、報告します。シェパードは Architecture Council にエスカレーションし、一時停止や方針転換を調整できます。最悪の結果は、3 つのチームがそれぞれ異なる回避策をひそかに実装することです。
• FAQ ドキュメントを活用します。 シェパードが管理する #initiative-foo という Slack チャンネルや FAQ の Confluence ページがある場合、チームが見つけた答えを投稿します。他のチームも同じ疑問に直面するからです。
• コードレビューを止めないでください。 シェパードはチームの PR のレビュアーではありません。チーム内での詳細なコードレビューは、引き続きチーム内で行います。

チームのエピックが完了したら、完了としてマークし、シェパードが実施するレトロスペクティブに参加して、チームの通常の進行ペースに戻します。

押さえておくべき 2 つのリスト

テックリードが担当し、シェパードは担当しないこと：

• ストーリーの分割、受け入れ条件、見積もり。
• チーム内での詳細なコードレビュー。
• チームの PR マージの進行ペース。
• スプリント計画と個人への割り当て。
• チームのコードベースの範囲内だけで完結する判断。

シェパードが担当し、テックリードは担当しないこと：

• イニシアチブの ADR とアーキテクチャ計画。
• チーム間の一貫性と、一時停止または方針転換の判断。
• Architecture Council での代表。
• リーダーシップに向けた進捗の説明。
• 共有依存関係について、他チームのリードとコミュニケーションを取ること。

どちらのリストにも当てはまらない場合は、通常、チーム間の依存関係です。その場合、シェパードが範囲と背景情報を添えてチームに引き渡すまでは、シェパードの担当です。

エスカレーションの経路

• キャパシティの競合（提案されたスケジュールではチームがエピックを受け入れられない）：チームの EM とシェパードにエスカレーションします。ファネルのスコーピングとコミットメントのフェーズは、キャパシティを交渉する場として明確に位置づけられています。実装の途中ではなく、そこが適切な場です。
• PoC のアプローチがチームの状況に合わない： シェパードに報告します。根本的な問題であれば、シェパードが Architecture Council に持ち込みます。
• 別のチームがパターンから逸脱しており、それがチームの作業に悪影響を及ぼす： シェパードに報告します。チーム間の一貫性はシェパードの仕事です。テックリードが他チームの実装について直接交渉することはありません。
• シェパードが不在または応答しない： ファネルでは、シェパードは長期不在に備えてバックアップを指名するよう明記されています。バックアップがいない場合は、ひそかに穴を埋めるのではなく、エンジニアリングリーダーシップにエスカレーションします。

よくある間違い

• シェパードが作成したストーリーを、そのまま受け入れる。 チームが分割セッションを実施していないなら、その作業はチーム自身のものになっていません。重複作業に感じられても、もう一度実施します。
• 引き継ぎを形式的なものとして扱う。 引き継ぎのミーティングは、聞きにくい質問をする機会です。PoC のパターンに問題があるように思える場合、引き継ぎの時点なら修正コストは低く、マージ後は高くなります。
• ずれを積み重ねてしまう。 小さな違いは増えていきます。最後の 10 件ではなく、最初の 1～2 件の PR で見つけます。
• キャパシティを確保する前に作業を始める。 明確なスプリント割り当てなしにバックログに追加されたエピックは、そのまま放置されます。これはリーダーシップとの話し合いであり、英雄的な頑張りで解決する話ではありません。
• シェパードに頼りすぎる。 シェパードは 5 つ以上のチームを調整しています。チーム内の詳細なコード品質、スプリントの規律、チーム内での判断は、引き続きチーム自身が担います。

参考資料

• ソフトウェアイニシアチブのファネル — フェーズごとの標準ドキュメントです。完全なテンプレート、Go／No-Go の基準、またはタイムラインの例の表が必要な場合は、get_confluence_page で取得してください。
• 関連資料：チームがフェーズ 4 から作成するブレークダウンの草案に使用する Tech Breakdown テンプレートについては bitwarden/tech-breakdowns を参照してください（活用方法については上記のフェーズ 4 を参照）。引き継ぎの双方におけるフェーズ 4→5 の移行手順については Skill(running-work-transitions) を参照してください。ブレークダウンに盛り込むアーキテクチャ上の判断については Skill(architecting-solutions) を参照してください。