contributing-to-technical-strategy

Bitwarden の技術戦略は縦の構造になっています。最上位にはアイデア、中間にはイニシアチブ、最下位にはチームレベルのエピックとストーリーがあります。テックリードはこの縦の構造全体に関わる役割です。最下位にある、最上位に引き上げるべきパターンを見つけ、最上位の取り組みをチームがリリースするストーリーへと落とし込みます。

このスキルでは、この縦の構造全体を扱います。

• 記録する価値のあるアイデアを見極める。
• アーキテクチャチームが評価できるよう、十分に明確な形にする。
• 承認されたアイデアがどのように BW イニシアチブになるかを理解する。
• イニシアチブからエピックレベルおよびストーリーレベルの作業を定義する。

正式な参照先は、Technical Strategy Ideas と Idea-Based Initiatives です。完全なテンプレートや各フィールドの詳細な定義が必要な場合は、get_confluence_page を使って取得してください。

ファネルの最上位：技術戦略アイデア

技術戦略アイデア（TSI）は、Bitwarden のアイデアバックログです。Architecture が Jira Product Discovery の ARCH プロジェクトで管理する、技術的な改善機会の精選された一覧です。アイデアは RICE スコアで評価され、テーマ別に分類され、Now／Next／Later のロードマップに配置されます。優先順位が決まったアイデアは、Identification からソフトウェアイニシアチブのファネルに入ります。

記録する価値のあるアイデアを見極める

次のようなパターンが見られた場合は、TSI を作成します。

• 複数のチームにまたがる課題のパターン。 5 つのチームが、それぞれ異なる方法で同じエラー処理の問題に対処しています。これはチームレベルの問題が 5 つあるのではなく、チーム横断のアイデアが 1 つあるということです。
• 広範囲に影響するアーキテクチャ上の不足や技術的負債。 共有コードに負債がある、またはその不足によって他のチームの作業が妨げられています。
• 開発者エクスペリエンスや運用の信頼性を改善する機会で、単一のチームでは担えないレベルのもの。
• Bitwarden が評価すべき技術トレンド。 「新しい技術だから GraphQL を使うべき」ではなく、「この箇所では REST の往復コストを定量化でき、代替手段を評価する価値があります」というものです。
• 複数のシステムにまたがるセキュリティ改善。

次の場合はチーム内で対応し、何も作成しません。

• 問題が単一チームのコードベース内に収まっており、そのチームが通常の作業で解決できる場合。
• 問題が緊急で、直ちに対応する必要がある場合。このプロセスは経由せず、リーダーシップに直接相談してください。
• プロダクト主導の機能リクエストの場合。これはプロダクトのバックログで扱うものであり、TSI には含めません。

TSI の主な提案者は Staff 以上のエンジニアですが、テックリードもチームの経験から得たアイデアを積極的に提案できますし、そうすべきです。スプリントを通じて浮かび上がるパターンは、Architecture が直接把握できないことも多い重要な兆候です。

アイデアを適切にまとめる

TSI に完全なアーキテクチャ提案は必要ありません。ただし、アーキテクチャチームが調査に値するかどうかを評価できるだけの背景情報は必要です。TSI テンプレートには複数のセクションがあります。特に重要なのは次の項目です。

• 問題／機会の説明。 現状、課題、解決した場合の機会を具体的に記載します。「エラー処理に一貫性がない」では曖昧です。「クライアント全体で5種類の異なるエラー処理パターンが使われており、デバッグが難しく、ユーザーが混乱している」なら、実行可能な内容です。可能であれば数値で示します。「これに関連するバグが四半期ごとに約3件」や「これによりスプリントごとに約4時間が失われている」といった記述があれば、影響が具体的になります。
• 戦略との整合性。 どの OKR、戦略テーマ、アーキテクチャ原則を支援しますか？ 依存する、または実現を可能にする他の取り組みはありますか？
• 対象ユーザー／ステークホルダー。 利益を得るチーム、ユーザー、システム、その他影響を受ける人々、専門知識を求めるチームを記載します。
• ステークホルダーとエンゲージメントのマップ。 ここは、適切に作成しないとアイデアが停滞しやすい項目です。意思決定者をチーム名だけでなく、名前または役割で特定します。必ず相談すべきステークホルダー、必ず情報共有すべきステークホルダー、そして――少し気が重い項目ですが――既知の摩擦点も明らかにします。意見の相違や抵抗はどこから、なぜ生じるでしょうか？ 摩擦点を事前に明らかにすることで、技術的には妥当な提案が導入段階で停滞するのを防げます。摩擦点を認識しているアイデアは、メリットだけを示すアイデアよりも信頼を得られます。
• 提案する方向性。 概要レベルにとどめ、ソリューションを設計しないでください。それはファネルの調査段階で行います。大まかな概念的アプローチ、検討に値するテクノロジー、構築・購入・統合に関する考え方を記載します。
• 運用と品質に関する考慮事項。 重要なメトリクスまたは SLI、パフォーマンス上の制約、テスト容易性への影響、セルフホストとクラウドそれぞれへの影響、コンプライアンスに関わる事項（SOC 2、ISO 27001）を記載します。
• 検証アプローチ。 最小限の概念実証をどのようなものにするか、どのような兆候があれば追求する価値があると判断できるか、どのような前提を検証する必要があるかを記載します。
• 大まかな見積もり。 Tシャツサイズ、想定期間、複雑さの要因を記載します。
• 優先順位付けのための RICE スコアに加えて、顧客セグメントとテーマを記載します。

最初に記入する際、すべての項目を完璧に埋める必要はありません。特に「ステークホルダーとエンゲージメントのマップ」は、アイデアがバックログから調査に進む前に、主担当者とピアレビュアーが協力して完成させます。チームからアイデアが提出された場合、アーキテクチャグループが提出者とレビュアーをペアにします。そうすることで、マップの内容をさらに明確にできます。

提出後の流れ

アーキテクチャチームは毎週新しいアイデアをトリアージし、毎月 RICE スコアを更新し、四半期半ばにバックログを管理し、エンジニアリングリーダーシップとともに四半期ごとの優先順位付けレビューを実施します。追求が承認されたアイデアは、識別フェーズでソフトウェアイニシアチブファネルに移行します。

追求されないアイデアは、判断理由を記録したうえで「却下」に移されます。却下されたアイデアはすべて、組織の記憶として参照できるように残されるため、背景情報がないまま同じアイデアが再評価されることはありません。

ファネルの中盤：アイデアからイニシアチブへ

ARCH アイデアがファネルに進むことを承認されると、別の成果物として、Jira の Bitwarden Company プロジェクトに BW イニシアチブの課題が作成されます。これらは、異なる目的を持つ別々の2つのレコードです（アイデアベースのイニシアチブを参照してください）。

• ARCH アイデアは Jira Product Discovery に残ります。RICE、テーマ、ロードマップ上の位置づけ、TSI テンプレート全体、そして何より重要なファネルフェーズのステータス（1️⃣ Identification から 5️⃣ Implementation まで）を引き続き保持します。
• BW イニシアチブは実行レベルのレコードです。戦略の概要、担当者としてのシェパード、各チームの子エピック、プロジェクトをまたぐ関連作業への課題リンク、意思決定や調整イベントを記録した Jira コメントが含まれます。

両者は 作業項目リンクでつながっており、BW イニシアチブが ARCH アイデアを「実装」します。このリンクにより、JPD では実行状況をたどることができ、Jira では戦略的な根拠にさかのぼることができます。

テックリードが BW イニシアチブを作成することは通常ありません。Identification 中に作成するのはシェパードの役割です。ただし、イニシアチブは頻繁に参照されます。チームに影響するものが現れたとき、シェパードが特定のアプローチを提案する理由を理解したいとき、隣接するチームに関連作業がないか確認するときなどです。適切にリンクされたイニシアチブなら、次の3つの質問にひと目で答えられます。

1. これはどこから来たのか？ ARCH アイデアへのリンクから、戦略的な根拠を確認できます。
2. どのような作業が行われているのか？ 子エピックから、チームをまたぐ現在の実行状況を確認できます。
3. ほかに何が関連しているのか？ 「Relates to」リンクから、過去の試み、依存関係、運用上のチケット、プロジェクト間の調整を確認できます。

イニシアチブからエピックを受け取ったら、5分かけて親の BW イニシアチブを読み、リンクをたどって ARCH アイデアを確認してください。その背景を知ることには、ほとんどの場合、時間をかける価値があります。

ファネルの下部：トレースをチームの作業につなげる

テックリードに特有の作業は、ここで行われます。Scoping & Commitment 中に、シェパードは BW イニシアチブの下に子エピックを作成します。通常、チームごと、または主要モジュールごとに1つです。その後、チームのエピックを分解するのはチームの役割です。

その分解の進め方、つまりストーリーの品質ルール、含める内容、避ける内容、シェパードへの共有方法については、Skill(navigating-the-initiative-funnel)で説明しています。このスキルが、分解の実践に関する正式な参照先です。このスキルで重要なのは、分解を元のアイデアへと上流につなぎ続けるトレーサビリティです。

• チームの分解セッションを行う前に、リンクを上流へたどってください。BW イニシアチブの説明を読み、続けて作業項目リンクから ARCH アイデアを確認します。TSI には、戦略的な根拠、ステークホルダーマップ、既知の摩擦点が記載されています。これらはすべて、チームがエピックをどう解釈するかに反映すべき情報です。ここで5分読むだけで、後からスコープを誤ったストーリーに何時間も費やさずに済みます。
• 分解中に、TSI やイニシアチブの説明にない曖昧さが見つかった場合、選択肢は2つです。曖昧さがチームのスコープ内なら、チームで判断して進めます。チームをまたぐ影響があるなら、やり直しを始めずに解決できるだけの背景情報を添えてシェパードに伝えます。TSI の「Stakeholder & Engagement Map」セクションを見れば、どちらに該当するか分かることがよくあります。
• 実装中に、TSI の「Known Friction Points」セクションで予測されていた摩擦点に直面した場合は、その記載を示してシェパードに伝えてください。これは、予測されていた場所に摩擦が生じたという合図です。新たな問題ではなく、積極的な対応が必要な、想定済みの問題です。

追跡情報を維持する

作業が進むにつれて、BW Initiative に積極的にリンクします。

• この作業に関係する SRE／BRE／TSD／PM のチケットを「関連」に設定します。
• 実装中に見つかった過去の試行に関するチケット。
• この取り組みと相互に作用する隣接イニシアチブ。
• 展開中に発生した運用チケット。

イニシアチブのリンク一覧は、イニシアチブが提供する価値の中でも特に重要なものです。すべてのプロジェクトにまたがる、この取り組みに関連する作業の全体像を示します。迷ったらリンクしましょう。あるチームの分解によって、他のチームにも影響する曖昧さが明らかになった場合は、独断で解決せず、シェパードに相談してください。

よくある間違い

• アイデアを起票するのは手間だと感じ、チーム横断のパターンをチーム内の問題のままにしてしまう。 手間がかかるのは事実ですが、5 つのチームが同じギャップをそれぞれ独自に回避するコストも現実にあります。
• 摩擦の内容を明確にせずにアイデアを起票する。 アーキテクチャチームは意見の不一致の解消を支援できますが、摩擦が発生している場所でそれが明確にされている必要があります。
• ARCH アイデアと BW Initiative を混同する。 これは対象とする読者が異なる 2 つの成果物であり、リンクされていますが別々のものです。イニシアチブの進展に合わせて、両方の情報を最新に保ちます。
• リンク一覧の確認を省略する。 「関連」リンクのないイニシアチブでは、似たことが次に起きたときに、誰もが背景情報を再発見することになります。
• TSI を読まずにチームの分解を進める。 アイデアには、イニシアチブの説明では要約されて省かれる背景、つまり戦略的な根拠、ステークホルダーの構成、既知の摩擦が含まれています。上流の内容を 5 分読むことで、下流の作業にかかる時間を何時間も節約できます。

参考資料

• Technical Strategy Ideas — TSI の正式なテンプレートとバックログモデルです。
• Idea-Based Initiatives — BW Initiative の正式な構成と、フェーズごとの進化を説明しています。
• 関連資料：アイデアがファネルに入った後のフェーズの仕組みについては Skill(navigating-the-initiative-funnel)、アイデアの枠組みづくりとチームの分解の両方に活かすアーキテクチャ上の判断については bitwarden-delivery-tools の Skill(architecting-solutions)、この分解がつながる Phase 4→5 の引き継ぎについては、移行のどちら側でも Skill(running-work-transitions) を参照してください。