curating-the-strategy-ideas-backlog

Bitwarden のTechnical Strategy Ideas（TSI）バックログ向けの、ピアレビュアー兼ポートフォリオキュレーターのプレイブックです。これは、Software Initiative Funnel の Identification にアイデアを送り込む、上流のアイデア創出段階のシステムです。他の人のアイデアに建設的な課題提起を行う役割、バックログの管理（毎週のトリアージ、毎月の RICE 更新、Now／Next／Later への配置）、エンジニアリングリーダーシップとの四半期ごとの優先順位付けレビュー、承認されたアイデアのファネルへの引き継ぎについて説明します。

アクティブな各アイデアに割り当てられる2つの役割

アクティブステータス（Research から Implementation まで）の各 TSI には、Architecture のメンバーが2名割り当てられます。TSI ページでは、次のように明示されています。

• Primary Owner。 パイプラインを通じてアイデアを推進します。問題の記述を作成し、調査を実施し、Architecture Council で発表し、ファネルへの移行を取りまとめます。進捗に責任を負います。Primary Owner 向けのプレイブックは Skill(championing-a-strategy-idea) です。
• Peer Reviewer。 サウンディングボードとして機能し、状況を把握したうえで、建設的な課題提起を行う役割を担う、2人目の Architecture エンジニアです。共同オーナーではありません。難しい質問を投げかけ、イニシアチブ間の競合を見つけ、ステークホルダーとの十分な連携を確保するのが役割です。このスキルを呼び出すときのあなたの役割です。このスキルの残りの部分で扱う、より広範なポートフォリオキュレーターとしての実践も併せて担います。

ピアレビューの進め方

TSI ページに基づくと、次のようになります。

• ピアレビュアーはアイデアごとに割り当てられます。アイデアがライフサイクルを進み、新たなアイデアが加わるにつれて、ペアを入れ替え、チームがポートフォリオ全体について幅広く知見を深められるようにします。
• Primary Owner は、進捗や意思決定のポイントを継続的に Peer Reviewer と共有します。隔週のアーキテクチャ作業セッションが主な場となります。緊急性の高い意思決定については、臨時の確認も想定されています。
• アイデアを Backlog から Research に進める前に、Primary Owner と Peer Reviewer がテンプレートの「Stakeholder & Engagement Map」セクションを共同で完成させます。これは必須のゲートです。
• アイデアが Architecture Council で発表される際、Peer Reviewer は状況を把握した協力者として出席し、質問への回答や議論の進行を支援します。
• **1人のエンジニアが同時に担当できるアクティブなレビューは、Primary と Peer のどちらの役割でも2件までです。**レビュー担当を過剰に割り当てると、その目的が損なわれます。

ゲートとしての Stakeholder & Engagement Map

このマップは、アイデアが Backlog から Research に進む前に通過しなければならないゲートです。5つの項目（Decision makers、Must consult、Must inform、Known friction points、Engagement approach）の詳細は、Primary Owner 側から見たマップの仕組みを網羅する正式な参照先である Skill(championing-a-strategy-idea) に記載されています。マップは Primary Owner と Peer Reviewer が共同で完成させます。マップがなければ、アイデアを Research に進めることはできません。

Peer Reviewer としての具体的な役割は、マップの内容を吟味することです。とりわけ、アイデアが軽視されがちな項目であり、「技術的に妥当な提案が導入段階で行き詰まる」要因として TSI ページでも明示されている Known friction points を重視します。Backlog から Research への移行に向けてアイデアをトリアージする際に問うべきなのは、マップが十分に埋められ、率直に書かれているかどうかです。摩擦要因が曖昧に扱われている場合、意思決定者が不明確な場合（権限が明記された具体的な役割ではなく「Vault チーム」とされているなど）、あるいはステークホルダーのコミュニケーションスタイルに合わない連携方法が記載されている場合は、異議を唱えてください。

RICE スコアリングの運用

各アイデアには RICE スコアが付与されます。リーチ × インパクト × 確信度 ÷ 労力です。TSI ページによると、スコアリングのガイダンスはアイデアの RICE スコアリングに記載されています。

キュレーターの実践事項：

• スコアは毎月更新します。 ピアレビュー、ステークホルダーとの会話、関連する取り組みの進展などを通じてアイデアについて分かってくることが増えるにつれ、スコアを見直します。
• 新しいアイデアのトリアージを毎週行い、バックログを最新の状態に保ちます。また、四半期半ばのバックログ管理で、現在のポートフォリオに照らしてスコアを見直します。
• スコアを不当に高くしないようにします。リーチは実際の値を反映させ、確信度は実際の知識の状態を反映させます。「確信度は低い」と示す正直な RICE スコアのほうが、PoC で検証できる疑問を隠す水増しされたスコアよりも価値があります。

テーマ、ロードマップへの配置、顧客セグメント

TSI ページによると、アイデアには RICE 以外にも、標準化された優先順位付けのフィールドがあります。

• テーマ。 アーキテクチャ／運用／SDLC／製品／アプリケーションセキュリティ。アイデアがどのポートフォリオビューに表示されるかを決定します。
• ロードマップへの配置。 Now / Next / Later。アーキテクチャ／エンジニアリング運用モデルによると、エンジニアリングリーダーに共有される Now/Next/Later ポートフォリオで使用される区分です。
• 顧客セグメント。 個人／チーム／企業／セルフホスト／社内。誰がメリットを得るかを記録します。

運用モデルでは、Now、Next、Later の違いが明確に示されています。特に、Later は方向性を示すものであり、確約ではありません。エンジニアリングリーダーとの会話では、この位置づけを維持してください。Later の段階で四半期単位の日付を確約すると、実態にそぐわない精密さが生じます。

四半期ごとの優先順位付けサイクル

TSI ページによると、次のとおりです。

活動	頻度	参加者
新しいアイデアのトリアージ	毎週	アーキテクチャ
スコアの更新	毎月	アーキテクチャ
バックログ管理	四半期半ば	アーキテクチャ + 関心のある Staff+ エンジニア
優先順位付けレビュー	四半期ごと	アーキテクチャ + エンジニアリングリーダーシップ
採用の振り返り	引き継ぎ時に取り組みごと	主担当者 + ピアレビュアー。作業セッションで共有

四半期ごとの優先順位付けレビューは、アーキテクチャが有力候補をエンジニアリングリーダーに提示し、ファネルへの追加承認を得る場です。運用モデルでは、これを四半期ごとの60分間の詳細レビューと説明しており、その合間にステークホルダーとの同期を通じて、毎月15〜20分の簡易アップデートを行います。

四半期レビューにおけるキュレーターの実践事項：

• Now / Next / Later のポートフォリオを確認します。前回のレビューから何が変わったのか、またその理由を明らかにします。
• 「Now」の項目を詳しく確認します。現在のファネル段階、関与している、または今後関与するチーム、各チームにアーキテクチャが求めること、関与の想定スケジュールを確認します。チームが自分たちに向かってくる作業を事前に把握する場です。
• 「Next」の項目について話し合います。順序や優先順位について意見を募ります。何を上げる、または下げるべきでしょうか。データには表れていない依存関係はありますか。パイプラインに加えるべき、チーム発のアイデアはありますか。
• エンジニアリングチームが話題を提起し、質問し、アーキテクチャの方針に関する懸念を伝えられるよう、自由に発言できる時間を設けます。

承認されたアイデアをファネルに移行する

リーダーシップがアイデアのファネルへの取り込みを承認すると（通常は四半期レビュー時）、そのアイデアはフェーズ 1「特定」の BW イニシアチブに移行します。TSI ページによると、次の手順を実施します。

• イニシアチブを作成する。 BW プロジェクトに新しい Jira イニシアチブを作成します。
• アイデアにリンクする。 BW イニシアチブから ARCH アイデア（JPD 内）への作業項目リンクを設定します。これがトレーサビリティの基盤となるリンクです。
• シェパードを割り当てる。 ファネルを通じてイニシアチブを主導する担当者として、Staff+ エンジニアを指名します。多くの場合はプライマリオーナーですが、適切なドメインの専門知識を持つ別の Staff+ エンジニアが担当する場合もあります。
• ピアレビュアーを割り当てる。 ファネル作業における相談役と検証役として、2 人目のアーキテクチャエンジニアを指名します（多くの場合、アイデアを担当したのと同じピアレビュアーですが、交代する場合もあります）。
• ステークホルダーとエンゲージメントのマップを完成させる。 まだ完成していない場合は、リサーチに入る前にシェパードとピアレビュアーが共同で仕上げます。
• 特定フェーズに入る。 イニシアチブはファネルのフェーズ 1 から開始します。
• ARCH アイデアのステータスを JPD で「1️⃣ 特定」に更新します。

ここからは、シェパードが Skill(shepherding-an-initiative) とフェーズごとの詳細なシェパードスキルを使用して、イニシアチブを推進します。ピアレビュアーは引き続き状況の共有を受け、検証役を務めます。

進行しないアイデア

TSI ページによると、却下の理由には次のものがあります。

• 戦略に沿っていない。
• 価値が不十分。 異なるアプローチを検討しても、コストがメリットを上回る。
• 別の場所で対応する方が適切。 チームレベルの作業、プロダクトプロセス、その他のチャネルなど。
• タイミング。 外部要因や依存関係により、今後しばらく実行が現実的でない。
• 関連するアイデアや既存のイニシアチブに取って代わられた。
• 別の手段（チームの作業、外部の変更）で解決済み。

却下されたアイデアは、理由を記録したうえで JPD に表示されたままになります。キュレーターとして徹底すべきことは、必ず理由を記録し、組織の記憶を必ず残すことです。理由が記録されていなければ、同じアイデアが 6 か月後に再び一から評価されることになります。

採用に関する振り返り（ファネルへの引き継ぎ時）

TSI ページによると、イニシアチブが実装フェーズに到達し、Work Transition Playbook に沿った引き継ぎを開始する際、プライマリオーナーとピアレビュアーが、影響力を効果的に発揮できたかどうかに焦点を当てた簡潔な振り返りを行います。効果的だったエンゲージメント、権限が不足していた場面、意見の相違が表面化するのが遅れた場面、次回に向けた改善点を振り返ります。

アイデアのピアレビュアーを務めている場合は、振り返りに参加してください。正式な振り返りのプレイブック（4 つの質問、注目すべき点、調査結果の共有先）は、プライマリオーナーのスキルである Skill(championing-a-strategy-idea) にあります。この振り返りはアーキテクチャチーム内（プライマリオーナーとピアレビュアー）で行い、アーキテクチャがどのように影響力を発揮したかに焦点を当てます。ファネルにおける実装終了時の振り返り（シェパードと受け入れ側のテックリードが実行に焦点を当てるもの）とは別のものです。

新しいアイデアをレビューする際のキュレーターの実践

テックリードまたはStaff以上のエンジニアが新しいアイデアを提出した場合、キュレーター側のトリアージでは通常、次の点を確認します。

• 問題は本当に複数チームにまたがるものですか？ 1つのチームのコードベース内にとどまる場合は、理由（「チーム内にとどまるため、提出しない場合については Skill(contributing-to-technical-strategy) を参照してください」）を添えて却下します。チームの範囲内の作業をArchitectureのポートフォリオに取り込まないでください。
• Problem / Opportunity Statementは具体的ですか？ 「エラー処理に一貫性がない」→「パターンの違いとその影響を具体的に示してください」と差し戻します。具体性に関するTSIページのガイダンスを参照してください。
• 摩擦点は明示されていますか？ Stakeholder & Engagement Mapがない場合、または「Known friction points」フィールドが曖昧な場合は、差し戻します。Researchへ進めるうえで、摩擦点を最初に明示することは必須です。
• すでに別のアイデアに置き換えられていませんか？ ARCHバックログを検索して、関連するアイデアや重複したアイデアを確認します。関連があれば明示的にリンクし、重複していれば置き換えます。
• Architecture Councilに持ち込むほどのアーキテクチャ上の重要性がありますか？ 新しいパターン、大規模な技術選定、複数領域にまたがるセキュリティなど、一部のアイデアは、ファネルに入る前にCouncilの意見を得る必要があります。

よくある間違い

• Stakeholder & Engagement Mapの確認をおろそかにする。 このゲートには理由があります。摩擦点を率直に明示しないままResearchに進んだアイデアは、採用の段階で行き詰まります。
• スコアを水増しする。 Confidenceの数値を作り上げたり、Reachの値を水増ししたりすると、実態を反映しないバックログになります。四半期レビューでは、スコアが正直であることが重要です。
• ピアレビューを割り当てすぎる。 Architectureのエンジニア1人あたりの同時進行中の割り当てが2件を超えると、異議を唱える役割が薄まります。TSIページの「2件以下」というルールは、確実に守る必要があります。
• 却下を失敗とみなす。 理由を記録したうえで却下したアイデアは、組織にとって貴重な知識です。問題なのは却下ではなく、何も言わずに取り下げることです。
• 引き継ぎ時の採用に関する振り返りを省略する。 Architectureの影響力の有効性は、その運用パターンを検証して初めて向上します。振り返りに参加してください。実施手順は Skill(championing-a-strategy-idea) に記載されています。
• Operating Modelから切り離してキュレーションする。 Now/Next/Laterのポートフォリオは、四半期レビューでエンジニアリングリーダーシップに、月次同期でPlatformに共有されます。その対象者を意識してキュレーションしてください。

参考資料

• Technical Strategy Ideas — TSIの正式なテンプレート、ピアレビューのモデル、優先順位付けのサイクル、ガバナンス。
• Architecture / Engineering Operating Model — Now/Next/Laterのポートフォリオ共有、Architecture Initiative Review、Architecture/Platformの同期。
• Idea-Based Initiatives — ARCHのアイデアがファネルに移行した際にどうなるか。
• Software Initiative Funnel — Phase 1 Identificationで承認済みのアイデアが進む先。
• Idea RICE Scoring — スコアリングのガイドライン。
• 関連項目：同じShepherding ModelにおけるPrimary Owner側（自身が説明責任を負う特定のアイデアを推進する役割）については Skill(championing-a-strategy-idea) を、提出におけるチームのテックリードとしての貢献については bitwarden-tech-lead の Skill(contributing-to-technical-strategy) を、アイデアが承認されてファネルに入った後については Skill(shepherding-an-initiative) を参照してください。