championing-a-strategy-idea

Technical Strategy Idea（TSI）を、Architecture のファネル前評価に通すための、Primary Owner 向けガイドです。ARCH アイデアの登録、ピアレビュアーとのペアリング、ステークホルダー＆エンゲージメントマップ（既知の摩擦点を含む）の完成、Architecture Council での発表、四半期ごとの優先順位付けへの対応、Implementation への引き継ぎ時の Adoption Retrospective の実施までを扱います。期間は四半期ごとのレビュー周期に沿って進み、固定の期間はありません。

Peer Reviewer／ポートフォリオキュレーター側の役割については Skill(curating-the-strategy-ideas-backlog) を、チームのテックリードがコントリビューターとして取り組む場合（適切に登録し、Staff+ のオーナーへ各段階を進めてもらうこと）については、bitwarden-tech-lead の Skill(contributing-to-technical-strategy) を使用してください。

推進モデル

TSI のページによると、アクティブなステータスにあるすべてのアイデアには、Architecture 側の担当者が 2 名割り当てられます。

• Primary Owner。 パイプライン全体を通じてアイデアを推進します。問題ステートメントを作成し、調査を実施し、Architecture Council で発表し、ファネルへの移行を進めます。進捗に対して責任を負います。このスキルを呼び出したあなたがこの役割を担います。
• Peer Reviewer。 相談相手となり、アイデアの進捗を把握し、建設的な異議を提示する 2 人目の Architecture エンジニアです。共同オーナーではありません。重要な質問を投げかけ、取り組み間の競合を見つけ、ステークホルダーへの十分な働きかけを確実にすることが役目です。

このペアリングは重要です。TSI のページには、「1 人のエンジニアが、Primary と Peer を問わず、同時に 2 件を超えるアクティブなレビュアー担当を持つべきではありません」と明記されています。Primary Owner を引き受ける時点ですでに 2 件を担当している場合は、その状況を伝えてください。過負荷なレビューは本来の目的を損ない、名目上は引き受けていても実際には推進できないアイデアを停滞させます。

構想からファネルへのインテークまで

おおまかな流れは次のとおりです。

1. 登録。 問題／機会ステートメント、戦略との整合性、おおまかな RICE、テーマ、顧客セグメント、ロードマップ上の配置を含む、簡潔な初稿で ARCH アイデアを登録します。
2. ペアリング。 ピアレビュアーを割り当ててもらいます。隔週のアーキテクチャ作業セッションで、そのレビュアーと進捗の共有を始めます。
3. ピアレビューで具体化。 アイデアを Backlog から Research に移す前に、共同でステークホルダー＆エンゲージメントマップを完成させます。これが移行の条件です。
4. 調査。 問題ステートメントをブラッシュアップし、合意したエンゲージメント手法を使ってステークホルダーとの対話を行い、得られた知見をまとめます。
5. Architecture Council で発表。 ピアレビュアーは、状況を把握した協力者として出席します。
6. 四半期ごとの優先順位付けでインテークを獲得。 このアイデアをファネルに入れるかどうか、またロードマップ上でいつ扱うかを、エンジニアリングリーダーシップが決定します。
7. ファネルへ移行。 BW Initiative を作成し、ARCH アイデアにリンクし、ステータスを更新したうえで、ファネルの流れについて Skill(shepherding-an-initiative) に引き継ぎます。

ファネル側で実装が完了した後、あなたとピアレビュアーは、影響力を発揮するうえでの有効性に焦点を当てたAdoption Retrospectiveを実施します。これはファネル関連のスキルではなく、このスキルに戻って扱います。詳しくはこのスキルの末尾を参照してください。

アイデアを提案する（キャプチャ）

TSI テンプレートは、ARCH プロジェクト内の JPD にあります。主担当者にとって特に重要なセクションは次のとおりです。

• 問題／機会の説明。 現状、課題、機会を具体的に記述します。TSI ページに記載されている例の基準は、「クライアント間に5種類の異なるエラー処理パターンが存在し、デバッグが困難になり、ユーザーが混乱している」です。「エラー処理に一貫性がない」ではありません。可能な限り定量化してください。
• 戦略との整合性。 どの OKR、テーマ、アーキテクチャ原則を支援しますか？ どの取り組みに依存し、あるいはどの取り組みを可能にしますか？
• 提案する方向性。 概念的なアプローチのみを記述します。解決策の設計はしないでください。これはファネルのリサーチで行います。構築、購入、統合のどれにするかを大まかに検討します。
• 運用および品質に関する考慮事項。 主要なメトリクス／SLI、パフォーマンス上の制約、テスト可能性、セルフホストとクラウドのどちらにするか、コンプライアンス上の留意点。
• 検証方法。 最小限の PoC の概要、成功を示す兆候、検証する前提条件。
• 概算規模。 Tシャツサイズ、想定期間、複雑さの要因。
• RICE。 正直に評価します。確信度はありのままで構いません。水増しすると、実態を反映しないバックログになります。TSI ページの RICE スコアリングページに評価基準が記載されています。

テンプレートの使い方を確認するため、bitwarden-tech-lead の Skill(contributing-to-technical-strategy) を参考にして提出できます。このスキルは投稿者側の視点を扱うものです。提出後のすべての作業、つまりペアリング、マッピング、ブラッシュアップ、プレゼンテーション、優先順位付けは、このスキルの範囲です。

ステークホルダーとエンゲージメントのマップ（リサーチゲート）

このスキルが最も大きな効果を発揮するのは、この部分です。TSI ページによると、主担当者とピアレビュアーが共同でマップを完成させない限り、アイデアはバックログからリサーチへ進みません。マップには5つの項目があります。

• 意思決定者。 チーム名だけでなく、具体的な個人または役割と、それぞれが決定権を持つ領域を記載します。「リソース配分はエンジニアリング担当 VP、運用上の責任は SRE リード。」
• 必ず相談する相手。 専門知識や背景知識が、方向性に 実質的な影響を及ぼす 人々です。リサーチ中に意見を求め、後回しにはしません。「必ず相談する相手」と「必ず情報共有する相手」を区別することが、アイデアが閉じた環境で形作られるのを防ぎます。
• 必ず情報共有する相手。 結果の影響を受け、状況を把握しておく必要がある人々です。取り組みが自分たちに及んだときに、驚かせてはいけません。
• 把握している摩擦点。 意見の相違、抵抗、優先事項の競合がどこから生じるかを記載します。正直に、具体的に。リサーチを始める 前に 明らかにします。TSI ページでは、「摩擦を事前に明らかにすることで、良いアイデアが技術的には妥当でも導入段階で行き詰まる提案になるのを防げます」と明言しています。主担当者が最も表現を和らげたくなる項目です。率直に記載してください。
• エンゲージメントの進め方。 各グループとどのように関わるかを記載します。TSI ページには、1対1の会話、RFC 形式の Confluence レビュー、アーキテクチャ評議会でのプレゼンテーション、チームのスプリントレビューへの参加、非同期の Confluence レビューが挙げられています。ステークホルダーのコミュニケーションスタイルとトピックのセンシティブさに合わせて方法を選びます。

ピアレビュアーが確認すべき、そしてまず自分自身で確認すべき質問が2つあります。

• すでに把握している摩擦点を明記していますか？ 「Y が理由で Team X からの抵抗が予想されます」と記載したアイデアのほうが、メリットだけを示すものより信頼できます。
• エンゲージメントの進め方に、実際の影響力が正直に反映されていますか？ マップに「Platform チーム向けの RFC」と記載していても、RFC がレビューされる可能性を高めるために事前に Platform のテックリードと1対1で話す必要があるなら、そのことも明記してください。

マップは更新し続ける文書でもあります。リサーチを進める中で新たなステークホルダーや摩擦点が明らかになったら、更新してください。この一連の取り組みの最後に行う導入の振り返りでは、マップが正確だったかどうかが問われます。後で検証できるように記述してください。

リサーチによるブラッシュアップ（ファネル前）

TSI のリサーチフェーズは、ファネルのリサーチフェーズよりも軽いものです。まだアーキテクチャ評価を作成する段階ではありません。アイデアを提示して優先順位を付けられる状態にするために、理解を深めます。

• 問題／機会の説明をブラッシュアップします。 根拠が集まるにつれて更新します。アーキテクチャ評議会に提出するバージョンは、提出時のものより明確になっているべきです。
• 合意したエンゲージメントのアプローチを実施します。 1 対 1 の面談、RFC のレビュー、チームのスプリントレビューへの参加などです。それぞれの会話で、通常はマップが予測していなかったことが明らかになります。マップを更新しましょう。
• 隔週のアーキテクチャ作業セッションで、ピアレビュアーに進捗を共有します。 ここでのピアレビュアーの役割は、自分では尋ねなくなっていた質問を投げかけることです。
• RICE を更新します。 確信度が明確になるにつれて、スコアも変わるはずです。確信度が正直に下がる場合、「コミットする前に PoC が必要」というサインであることがよくあります。それで問題ありません。リサーチと、その後の PoC はそのためにあるのです。

アーキテクチャ評議会での発表

マップが完成し、問題の説明が明確になり、摩擦が認識され、初期の会話を通じてエンゲージメントのアプローチが検証されたら、アイデアをアーキテクチャ評議会に持ち込みます。

• ピアレビュアーは、事情を把握した協力者として参加します。 質問への対応や議論のサポートをしてくれます。TSI ページには「アーキテクチャグループは、隔週の作業セッションを通じてセッション前に内部調整を行う」とあります。それを活用しましょう。
• 主張を軸に発表を構成します。 提案するソリューションではなく、問題と戦略との整合性から始めます。評議会の役割は、このアイデアにリソースを割く価値があるかを検証することであり、設計することではありません。
• 摩擦も含めて臨みます。 評議会は必ず尋ねます。質問で引き出されるよりも、率直な説明を先に提示するほうがよいでしょう。
• 意見を真剣に受け止めます。 評議会から、取り組みをまたぐ対立や、マップに含めていなかったステークホルダーが明らかになった場合は、それをマップに反映します。

この段階でアーキテクチャ評議会が提供するもの：取り組みをまたぐ状況の把握、戦略との整合性の検証、タイミングや対立に関する懸念の提示、場合によってはエンゲージメントのアプローチに関する推奨。

提供しないもの：その後に行われるエンジニアリングリーダーシップによる優先順位付けとは独立したゴーサインです。評議会が推奨し、リーダーシップが優先順位を付けます。どちらも、そのアイデアがファネルへの取り込みに値するかどうかの判断材料となります。

四半期優先順位付けにおけるアイデアのファネルへの取り込み

Architecture / Engineering Operating Modelに従い、Architecture は優先順位付けしたアイデアを四半期ごとにエンジニアリングリーダーシップに提示し（60 分、詳細レビュー）、その間に毎月、簡易的なアップデート（15～20 分）を行います。

四半期レビューに向けて担当すること：

• アイデアが議題に含まれていることを確認します。 提示するアイデアは Architecture が決定します。隔週のワーキングセッションで Architecture グループリードと調整してください。
• Now / Next / Later に沿った提案を準備します。 Operating Model ではこれらの区分を使用します。このアイデアはどこに該当すると考えますか？その理由は何ですか？四半期先送りになった場合、何が変わりますか？
• 必要なリソースを率直に伝えます。 承認された場合、誰が主導しますか（あなた、または別の人）？どのチームに影響する可能性がありますか？大まかなスケジュールはどのようになりますか？
• 障壁を事前に示します。 意見の相違が生じる箇所を明示したアイデアのほうが、それを伏せたものより、リーダーシップが承認しやすくなります。

承認されると、アイデアはフェーズ 1「特定」でファネルに移行します。TSI ページおよびアイデアベースの取り組みに従い、次の作業を行います。

• Jira の BW プロジェクトに新しい BW Initiative を作成します。
• BW イニシアチブから ARCH アイデアへ 作業項目リンクを設定します。これは、追跡可能性を確保するための基盤となるリンクです。
• シェパードを割り当てます（多くの場合はあなたですが、適切なドメインの専門知識を持つ別の Staff 以上のエンジニアが担当することもあります。希望は伝えますが、決めつけないでください）。
• ファネル全体を通して ピアレビュアーを割り当てます（同じピアレビュアーが担当することが多いですが、視野を広げるために交代することもあります）。
• ステークホルダーおよびエンゲージメントマップが未完成の場合は、完成させます。
• JPD で ARCH アイデアのステータスを「1️⃣ 特定」に更新します。

ここからは、ファネル全体のプレイブックとしてSkill(shepherding-an-initiative)に引き継ぎます。今進めた流れが、その作業の上流コンテキストになります。

アイデアが却下または保留された場合

TSI ページに従い、却下理由を明示的に記録します。

• 戦略との整合性がない。
• 価値が不十分（異なるアプローチを検討しても、コストがメリットを上回る）。
• 別の場所で対応するほうが適切（チームレベルの作業、プロダクトのプロセス、その他のチャネル）。
• タイミングが適切でない（外部要因、依存関係）。
• 関連するアイデアまたは既存のイニシアチブによって置き換えられた。
• 他の手段で解決された。

却下に移す前に、JPD のアイデアに判断理由を記録してください。組織の知見を残すことは重要です。半年後に誰かが同じパターンを見つけたとき、どのような結論に至ったかを知ることで役立つ可能性があります。

保留と却下は異なります。タイミングが適切でなくても、仮説が有効であれば、却下ではなく「Later」を提案し、次回の四半期レビューで再検討してください。

採用の振り返り（実装への引き継ぎ後）

これは推進の一連の取り組みの結びであり、ファネルのスキルではなく、ここに記載します。TSI ページによると、取り組みが実装段階に進み、Work Transition Playbook に沿った引き継ぎを開始したら、主担当者とピアレビュアーが、納品の進め方ではなく、影響力の有効性に焦点を当てた短い振り返りを行います。

この方針を実現するために、アーキテクチャがどのように影響力を活用したかを振り返る、4 つの質問です。

• 採用を促すうえで、どのようなエンゲージメントの方法が効果的でしたか？ どの 1 対 1 のミーティングが立場を変えましたか？ どの RFC レビューが実際に作業を前進させましたか？ どの Council でのプレゼンテーションが合意を得ましたか？
• どこで権限が不足しており、どのように対処しましたか？ アーキテクチャにはチームに作業を割り当てる権限はありません。エンゲージメントの方法によって、権限の不足を影響力で補います。その代替がうまく機能した場合と、しなかった場合の両方が、次のアイデアに役立ちます。
• 早く明らかにすべきだった意見の相違を、どこで遅れて発見しましたか？ これは、ステークホルダーとエンゲージメントのマップにある「既知の摩擦点」欄の事後検証です。早い段階で明らかにした摩擦は、対処できた摩擦です。実装中に発見した摩擦は、マップで見落としていた摩擦です。
• 次の取り組みでは、何を変えますか？ 実践的で、他の取り組みにも応用できる教訓を確認します。

TSI ページでは、調査結果を「アーキテクチャの作業セッションで共有し、組織の記録として元のアイデアにコメントとして記録する」よう定めています。どちらの場も重要です。作業セッションはアーキテクチャ全体の実践を改善し、コメントはこのアイデアを後から見つけた人が振り返りの内容を把握できるようにします。

これは、Skill(coordinating-implementation-across-teams) にあるファネルの実装終了時の振り返りとは異なります。そちらは進行役と受け入れ側のテックリードが、実行に焦点を当てて行います。採用の振り返りは、アーキテクチャ内部で（主担当者とピアレビュアーが）、影響力に焦点を当てて行います。

よくある間違い

• アイデアを登録した後、放置する。 登録は推進ではありません。主担当者としての役割を真剣に受け止め、ペアを組み、マップを作成し、発表し、優先順位を付けましょう。そうしないと、アイデアはバックログで停滞します。
• 既知の摩擦点を控えめに扱う。 マップによって、アイデアの信頼性が高まるか、理論上のものにとどまるかが決まります。ピアレビュアーはこの点を厳しく問いかける役割を担います。その指摘を和らげようとしていることに気付いたら、それは注意すべきサインです。
• アーキテクチャ Council を通過すべき関門として扱う。 Council は意見を得る場です。売り込みではなく、実際の疑問を持ち込みましょう。有望なアイデアの多くは、形を変えて Council から出てきます。
• 採用の振り返りを省略する。 ファネルの振り返りは納品を扱い、こちらは影響力を扱います。この振り返りがなければ、アーキテクチャ全体の実践は、最も得意になる必要のあることについて改善されません。
• ピアレビュアーに負荷をかけすぎる。 TSI ページのルールでは、アーキテクチャのエンジニア 1 人につき、アクティブなレビュアーの担当は 2 件までです。レビュアーに過度な負荷がかかると、課題を指摘する機能が弱まります。その状況を明らかにしましょう。
• 推進中にスコープを事前に決める。 提案する方向性は概念的なものです。詳細なソリューション設計はファネルの調査の役割であり、まだあなたの役割ではありません。早すぎる段階でスコープを決めると、Council が広げていた可能性を閉ざしてしまいます。

参考資料

• 技術戦略のアイデア — 標準の TSI テンプレート、シェパーディングモデル（主担当／ピアレビュアー）、ステークホルダーとエンゲージメントのマップ、導入の振り返り。
• アイデアに基づくイニシアチブ — 承認された ARCH アイデアが、ファネルのフェーズ 1 で BW イニシアチブになるまでの流れ。
• アーキテクチャ／エンジニアリング運営モデル — 四半期ごとの優先順位付けレビューと、どのアイデアをファネルに進めるかを決定する Now／Next／Later ポートフォリオ。
• ソフトウェアイニシアチブファネル — 承認されたアイデアが進む先（Identification 以降）。
• アーキテクチャ評議会 — 推進活動中、およびファネルの Research／PoC の段階で発表する場。
• 関連項目：同じシェパーディングモデルのピアレビュアー／ポートフォリオキュレーター側については Skill(curating-the-strategy-ideas-backlog) を参照してください。アイデアがファネルに取り込まれた後の流れについては Skill(shepherding-an-initiative) を参照してください。提案を提出するチームテックリードの役割については、bitwarden-tech-lead の Skill(contributing-to-technical-strategy) を参照してください。