R&D Interlock

R&D Interlock プロセスは、Product Management、User Experience、Engineering の各チームをロードマップ計画と実行調整の上で整合させるために使われます。インターロックは 3 つの主要な要素から構成されます：

• Resource Allocation Framework は、プロダクト主導およびエンジニアリング主導の取り組みを利用可能なエンジニアリングリソースにマッピングするための構造を提供します。
• Roadmap Structure は、整合に使われる計画成果物（ロードマップ）を説明し、それらのオーナーシップ、目的、対象読者を定義します。
• R&D Alignment Process は、次の実行四半期に向けて整合を作り出すためのプロセスとタイムラインを提供します。

整合プロセスは、プロダクト主導とエンジニアリング主導のイニシアチブを横断する共同アプローチを概説し、さまざまなステークホルダーとの明確なコミュニケーションチャネルを担保します。

注：FY26 の残り（2026 年 1 月まで）、チームは 2 か月ごとに 1 四半期を計画する加速計画に参加します。私たちの目標は、業界全体のトレンドと GitLab に類似した成熟しつつある SaaS 企業に整合した 4 四半期のロードマップを提供することです。1 月末にこれを達成したら、3 か月ごとに 1 四半期を計画する通常の計画ケイデンスに移行します。

Resource Allocation Framework

私たちは、カスタマーニーズ、品質基準、長期的なプロダクトの持続可能性を優先する、プロダクト主導とエンジニアリング主導のイニシアチブ間のバランスの取れたアプローチを確立しています。このバランスは、Product Management と Engineering チーム間の継続的な対話の基盤として機能し、各チームの特定のコンテキストに必要な比率を柔軟に調整できます。

イニシアチブは R&D Interlock Dashboard を通じて追跡されます。

• P1/P2/P3: プロダクト主導イニシアチブ

  • 優先順位レベル
    • P1: 完全なイニシアチブがコミット日に提供されることに 100% のエンジニアリング信頼度
    • P2: 完全なイニシアチブがコミット日に提供されることに 80% のエンジニアリング信頼度
    • P3: 50% のエンジニアリング信頼度。P1-2 または E1-2 がリスクにある場合、停止可能。
  • すべてではないが一部の P1/P2/P3 プロジェクトは、Public Roadmap（GTM 所有）に追加され、GTM ティア T1/T2/T3 でラベル付けされます（参考：GTM ティアの定義）。
    • T と P の優先順位が厳密に一致しない場合があります。たとえば、契約上のカスタマーコミットメントは Product にとって P1 でも、GTM にとっては T3 になることがあります。同様に、競合ギャップは Product にとって P2 でも、GTM にとっては T3 になることがあります。この優先順位の乖離は頻繁に発生することが想定されています。
    • GTM 優先順位 T1-3 は、Product 優先順位 P1-P3 より高くなることはありません（等しいか低いだけ）。そうしないと、優先順位の逆転が発生します。例外には PLT/ELT/MLT の承認が必要です。
    • T 優先順位は Public Roadmap を通じてステークホルダーに外部的に伝えられます
    • P 優先順位は Internal Roadmap を通じてステークホルダーに外部的に伝えられます

• E1/E2/E3: エンジニアリング主導イニシアチブ

  • 優先順位レベル：
    • E1: 完全なイニシアチブがコミット日に提供されることに 100% のエンジニアリング信頼度
    • E2: 完全なイニシアチブがコミット日に提供されることに 80% のエンジニアリング信頼度
    • E3: 50% のエンジニアリング信頼度。P1-2 または E1-2 がリスクにある場合、停止可能。
  • 内部可視性のみ
  • 外部には伝えられない
  • Engineering の外部に依存関係を持たない

各 Product または Engineering の VP の承認がない限り、エンジニア 20 人あたり最大 1 x（P1 または E1）と 2 x（P2 または E2）の制限があり、主要投資領域（SCM、CI、Security、Compliance、Planning、Duo など）ごとに最低 1 x P2 があります。

Product と Engineering の間にクリーンな整合（「インターロック」）を作るには、ユーザー要件と焦点を絞った品質改善および本質的な技術的取り組みを統合する、構造化された計画方法論が必要です。このフレームワークは、プロダクト主導イニシアチブ（P1/P2/P3）が明示的なリソース配分パラメータで動作するデュアルトラックシステムを確立します。P1 は計画されたスコープの 100% を 100% の確実性で提供するためのエンジニアリングキャパシティを受け取り、外部コミュニケーションでフルに可視化されます。P2 は計画されたスコープの 100% を 80% の確実性で提供するためのエンジニアリングリソースが配分され、両者には定義された受け入れ基準があります。P3 の取り組みは、キャパシティが許す場合に 50% の信頼度を目標として、反復的な開発サイクルを通じて実装されます。この体系的なアプローチは、コミットされた機能性と実行の間の追跡可能な関係を作りつつ、適切なリソース配分を担保します。

これらの要件主導の開発と並行して、フレームワークは技術的持続可能性トラック（E1/E2/E3）を実装します。これは同等のリソース配分メトリクスを持ちますが、外部依存関係およびリリースコミュニケーションから分離されています。この構造は、外部のスケジューリング制約なしに、適切な優先順位付けでクリティカルなリファクタリング、依存関係のアップグレード、テスト自動化の改善、インフラストラクチャ最適化を進めることを可能にします。

P-track と E-track の配分間の設定可能な比率は、システムコンポーネントやアーキテクチャレイヤーが異なる場合の実装の柔軟性を提供します。チームは技術的負債の蓄積、システムの安定性メトリクス、コンポーネントのライフサイクルフェーズに基づいてフレームワークを適応でき、最終的に機能要件を満たしつつアーキテクチャの完全性を維持するシステムを生み出します。

Roadmap Structure

R&D Execution Roadmap

• コンテンツ： すべての P1/P2/P3 および E1/E2/E3 イニシアチブ
• ケイデンス： 四半期ごとの更新、4 四半期ローリングウィンドウ
• 対象読者： Product および Engineering リーダーシップ
• オーナー： Product と整合した Eng VP
• 目的： 準備状況、実現可能性、実行計画
• 形式： セクションごとに 1 つのデッキ (テンプレート)、ステージごとにカスタマー主導およびエンジニアリング主導イニシアチブのための 1 つのロードマップ概要、各イニシアチブの個別整合スライド

R&D Investment Roadmap

• コンテンツ: P1/P2 および E1/E2 イニシアチブ（80%+ の信頼度）
• ケイデンス: 四半期ごとの更新、4 四半期ローリングウィンドウ
• 対象読者: ボードレベル
• オーナー: CPO と CTO 目的: 戦略的投資概要

Internal Roadmap

• コンテンツ: すべての P1/P2/P3 機能
• ケイデンス: 四半期ごとの更新、4 四半期ローリングウィンドウ
• 対象読者: 選ばれたカスタマー
• オーナー: Eng および UX と整合した PM VP
• 目的: プロダクトの進化と機能計画

Public Roadmap

• コンテンツ: P1/P2/P3 プロダクト主導機能のサブセットが GTM 用に T1/T2/T3 とラベル付けされます。注：GTM 優先順位 T1/T2 は、優先順位の逆転を避けるため、プロダクト優先順位より高くなることはありません。
• ケイデンス: 四半期ごとの更新、4 四半期ローリングウィンドウ
• 対象読者: カスタマー
• オーナー: Product と整合した GTM
• 目的: 外部コミットメントトラッキング

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    Execution_Roadmap("
        ⚙ **R&D Execution Roadmap**<br>
        *Purpose*: Readiness, Feasibility and Execution Planning<br>
        **P1/P2/P3 and E1/E2/E3 Initiatives**<br>
        *Audience*: PM, UX and Engineering Leadership
        *Owner*: Env VP in alignment with PM and UX
    ")

    Product_Roadmap("
        🧁 **Product Roadmap**<br>
        *Purpose*: Product Evolution and Features<br>
        **P1/P2/P3 Initiatives**<br>
        *Audience*: Select Customers
        *Owner*: PM VP in alignment with Eng and UX
    ")

    Investment_Roadmap("
        💰 **R&D Investment Roadmap**<br>
        *Purpose*: Strategic investment overview<br>
        **P1/P2 and E1/E2 Initiatives**<br>
        *Audience*: Board level
        *Owner*: CPO and CTO
    ")

    Public_Roadmap("
        📢 **Public Roadmap**<br>
        *Purpose*: Strategic investment overview<br>
        **P1/P2/P3 Initiatives**<br>
        *Audience*: Select Customers
        *Owner*: PM VP in alignment with Eng and UX
    ")

    Execution_Roadmap --> Product_Roadmap
    Execution_Roadmap --> Investment_Roadmap
    Product_Roadmap --> Public_Roadmap

R&D Alignment Process

R&D Alignment プロセスは、計画ウィンドウの 1 四半期前に、概ね合意された R&D Execution Roadmap（およびすべての派生ロードマップ）を作成します。Q_n から Q_n+3 までの計画を立てる場合、計画四半期は実行前であり、明確な計画タイムラインを提供するために Q_n-1 としてマークされます。整合プロセスは Q_n-1 の 7〜12 週目に実行されます。

---
config:
  look: handDrawn
  theme: neutral
---
gantt
    dateFormat YYYY-MM-DD
    axisFormat End of Week %W
    tickInterval 1week

    title Quarterly Planning Timeline

    Feature Alignment : 2025-02-16, 7d
    R&D Alignment     :             7d
    GTM Alignment     :             7d
    Commitment        :             7d
    Comms             :             7d
    Retrospective     :             7d

成功メトリクス

• 会社目標とのロードマップ整合
• 計画の効率（計画と整合に費やした時間、作業のサイジング、カスタマー／品質／持続可能性のバランス）
• 計画と実行の正確性（時間通りのコミットメント遂行）

Commitment Change Request

P1/E1 および P2/E2 の優先順位を持つコミット済み機能について、タイムライン、スコープ、コスト、優先順位、品質、リスクに関するあらゆる主要な変更は、それぞれの PLT および ELT メンバー、ならびに CPO と CTO に対して Commitment Change Request を通じて提起され、明示的な承認を得て、すべてのステークホルダーを把握させる必要があります：

1. プロジェクト DRI は、関連するインターロックエピックに新しいスレッドとして内部ノート（コメント）を追加し、そのコメントへのリンクを #r-and-d-roadmap-changes に投稿し、それぞれのステークホルダーをメンションします。意思決定者がすばやく対応／行動できるよう、エピックコメントは標準化された形式に従う必要があります：

   ### Proposing change to feature
   
   - Change Type: [select: Timeline / Scope / Cost / Priority / Quality / Risk]
   - What’s changing: <Priority from XX to YY>, <Delivery Milestone from YY.Y to ZZ.Z>, …
   - Background: [2-3 sentences describing the decision]
   - Impact: [optional, further detail on impact to customers / cost / list of projects that are dependent on this project + @ mentions of DRIs for those projects]
   - Proposed by: [Name of Product and Engineering DRI]
   - Approvers: [specific PLT, ELT members], CPO, CTO
   
   <more narrative / details of change, motivation, impact>
   
   /label ~"Interlock status::Change requested" ~"Interlock changed"
   

   注：変更リクエストがキャンセルされた場合は、変更リクエストテンプレートの一部として追加されたラベルを元に戻すか削除してください。

2. エピックコメント上でのスレッドとしての自由形式の議論、オプションでミーティング。

3. CPO および CTO からの変更コミットへの承認。

4. 承認されたら、変更リクエストを開始したチームメンバー（PM、EM など）が “Interlock status::VP approved” ラベルを追加すべきです。

期限の遅延、スコープの大幅な縮小、またはカスタマー期待を裏切るその他のあらゆる変更は、主要な変更と見なされます。疑わしい場合は、変更管理プロセスを経てください。

GitLab プロセス

一般的に、実装作業を公開可能な場所では、機密情報を扱う場合に 内部ノート を使ってメモを取ったり議論したりしてください。例：カスタマー名、ARR インパクト、その他公開すべきでない事業詳細など。

実装作業が gitlab-org/ グループにない場合、提供されたテンプレート を使用して別のインターロックエピックを作成すべきです。各インターロックエピックは、対応するワークストリームエピックにリンクされ、実際の実装作業へのナビゲーションとドリルダウンが容易になります。インターロックエピックは、インターロックプロセスに関連するあらゆる議論に使用され、その「ヘルス」と進捗のサマリーで定期的に更新されるべきです。

R&D Interlock 計画タイムライン

• FY27Q2 2025 年 9 月 1 日 - 2025 年 9 月 30 日
• FY27Q3 2025 年 10 月 15 日 - 2025 年 11 月 15 日
• FY27Q4 2025 年 12 月 8 日 - 2026 年 1 月 30 日

ベストプラクティス

1. エピックの量ではなく事業目標との整合に集中する R&D Interlock 項目は、投資テーマに直接結びつく必要があります。各投資テーマには最大 8 件の R&D Interlock 項目を持たせるべきです。事業目標および目標と最も整合しているものに集中してください。整合を確認するため、直接リーダーシップと協働してください。
2. インターロックキャパシティ インターロック項目は、最大でもチームのキャパシティの 70% をカバーするべきです。事業ニーズの変化、リソース、R&D 優先順位を完了するために追加の帯域を必要とする可能性のあるキャパシティの課題により、これより高くすることは推奨しません。チームに優先業務を遂行する余地があることを担保してください。
3. コミットメントを念頭に置く チームがインターロック項目にコミットするとき、これはチームがこの作業を優先し、他のイニシアチブの優先度を下げる意思があることを意味します。
4. クロスファンクショナルな優先順位の整合 他チームのプロダクトおよび／またはデリバリーでインターロックしている場合、GitLab の事業目標を達成するために、自分の責任を前進させ、他の作業の優先度を下げることにコミットしていることになります。
5. 早めに計画する 継続的計画プロセスを開始するにあたり、できるだけ早くチームと協働を始めることがクリティカルです。インターロック計画の中間に同期ミーティングを事前に予定し、適用可能なステークホルダーが整合のための専用時間を確保できるプレースホルダーを作ることが提案されています。

GitLab のプロダクトロードマップ R&D Interlock プロセス

R&D Interlock Process Review

次の 2 四半期にインターロックされたエピックについて、PM + EM は以下を行います：

• 項目をレビューし、デリバリーの信頼度を検証する 主要な依存関係またはリスクがある場合、管理してレビューと再スケジュールのためにリーダーに懸念を提示する
• 適切なデリバリーマイルストーンが割り当てられていることを担保する
• ヘルスステータスラベルが更新されており正確であることを担保する

このプロセスを使わない場合

すべての作業がこのインターロックプロセスを通る必要はありません。クロスファンクショナルな整合、重要なリソースのコミットメント、または市場参入の調整を必要としない通常の開発作業は、標準のワークストリームエピックと Issue を引き続き使えます。R&D Interlock プロセスは、GitLab プラットフォーム全体の投資領域ごとの高優先度の事業目標に専属するものです。

メリット

R&D Interlock プロセス経由で提案された作業は、以下のメリットを得られます：

• 役員レベルの可視性：このプロセスの項目は、組織の最高レベルで可視化されます
• 市場参入の調整：カスタマー対面の項目は、GTM tier に応じて GTM 計画に含まれることがあり、セールスおよびマーケティングの整合を可能にします
• リソースのコミットメント：指定された信頼度レベルでの正式なエンジニアリングコミットメント。これは、これらのチームがこれらの投資の提供にコミットし、引き換えに他の作業の優先度を下げることを意味します
• クロスファンクショナルな整合：Product、Engineering、GTM チームが優先順位について整合していることを担保します
• 外部コミュニケーション：選ばれた項目は、公開／カスタマー対面ロードマップに含まれる場合があります

提案の候補を作成する方法

1. 既存のエピックが gitlab-org の外部にある場合、Epic を作成する
   1. `gitlab-org グループ内で、新しいエピックを作成する（ドキュメント）
   2. 内部ノート にコピーする（既存の場合）、または選択する（新規の場合）、interlock_template という名前のエピックテンプレート
2. 必要な情報を完成させる
   1. テンプレートのすべてのセクションを埋める
   2. DRI を割り当てる（PM、EM、UXPD & PDM）
   3. 適切なラベルを適用する（ラベルガイド を参照）
      • 注：候補がコミットされない場合、すべてのインターロック専属ラベルは削除すべきです。
   4. 対象マイルストーンを適用する
3. プロセス全体でインターロックステータスを更新する
   1. 議論の進行に応じてインターロックステータスを更新する
   2. 四半期が始まったら、ヘルスステータスを毎週更新する
   3. リスクと依存関係を出てきた時点で文書化する

インターロックコミットメントを表示する

R&D Interlock Dashboard を活用して、四半期ごとにインターロックされたコミットメントを表示します。

グループ、ステージ、またはセクション用のカスタム GLQL ビュー作成にヘルプが必要な場合は、@amandarueda に連絡してください。

コミットメント後の変更

インターロックでコミットされた項目が変更された場合は、エピックに適切なラベル を保ってください。これには以下が含まれます：

1. インターロック項目を変更するには、commitment change request プロセスを使用します。
2. コミット済みインターロック項目をロードマップから削除するには、以下を行うべきです：
   1. なぜか説明する内部コメントを追加する（commitment change request テンプレートを使用している場合、変更ラベルを削除してください）。
   2. Interlock status Canceled ラベルを追加する。
   3. GTM ラベルを削除する。
   4. オプションで、investment ラベルを削除する。
   5. その他のすべてのインターロック関連ラベルは保持する。

ラベルガイド

将来の機能拡張

Plan ステージには、このインターロックプロセスを直接改善する多くの項目を含む素晴らしいプロダクトロードマップが今年あります。今後の機能を以下で確認し、追加の改善のアイデアがあればお知らせください！

• エピックマイルストーン - 四半期ラベルを適切なマイルストーン機能に置き換え、マイルストーンバーンダウンチャートを含めて、四半期の状況を一目で確認できるようにする
• カスタムフィールド - ラベルではなくフィールドを使用してラベルの過剰を減らす
• 強化されたボード機能 - 拡張されたスイムレーンオプション（水平グループ化）を使用して、フィルターと保存されたビューを減らす
• カスタマイズ可能なメタデータ表示 - 表示するフィールドを制御して役員ビューからノイズを除去する

FAQ

1. Q： なぜ Issue ではなくエピックを使っているのですか？

   • A： 将来のイテレーションでは、Plan 機能が成熟するにつれて、このプロセスをロードマップビューに入れることを目標としており、最終的には、ドリルダウンと進捗情報を可能にするためにワークストリームを戦略（plan）に接続することを目標としています。

2. Q： なぜ gitlab-org とは別のグループでこれらのエピックを作成しないのですか？

   • A： SRE チームが安全に保つ必要のある数百の内部グループがあることを学びました。それを積み重ねるのではなく、Boring Solution として主要な gitlab-org グループを使うことにしました。これがノイズや懸念を引き起こす場合は、決定を再検討できます。

3. Q： ラベルの代わりにネイティブヘルスステータスウィジェットを使えない理由はありますか？

   • A： エピックボードが ヘルスステータス 機能を活用できるようになるまで、ヘルスステータスにラベルを使用しています

4. Q： このプロセス用に独自のビューを保存できますか？

   • A： もちろんです。フィルター基準やラベルの使用について質問があればお知らせください。

5. Q： カスタマー情報を言及しているので、エピックを機密にする必要がありますか？

   • A： インターロック議論にはデフォルトで 内部ノート を使ってください。実装が非公開であるべき場合は、エピックを機密にする。

6. Q： EM と PM のどちらがインターロック計画用のエピック作成を担当しますか？

   • A： インターロックエピックの作成は PM が主要 DRI であり、P 優先順位については EM、E 優先順位ではその逆と協働します。

7. Q： インターロック後にタイムラインを調整する方法が明確ではありません。どうすればいいですか？ デリバリータイムラインを前倒しまたは後ろ倒しできますか？

   • A： チームは、必要な調整について 変更リクエスト を使うべきです。適切なリーダーシップの承認を得て、デリバリーを前倒しまたは後ろ倒しに更新できます。

8. Q： 現在、タイムラインの提供は困難です。チームとインターロックしていますが、インターロックする必要のあるチームに現在の曖昧さがあります - 明確さがなければインターロックすべきではないという意味ですか？

   • A： いいえ、チームは引き続き協働してインターロックすべきです。まだ定義する必要のあるプロセスの曖昧さがあります。チームは、開発の曖昧なエリアに関する追加の明確さが得られたら、パートナーシップと実行にコミットできます。今のところ、これらの日付に向けて作業を進めてください。100% の確実性がない可能性があり、さらなるインターロックには追加の情報が必要かもしれないという但し書き付きです。最終的に、期限は、各「フェーズ」が十分な時間を持てるようにプロセスをタイムリーに進めるためのガイドとなる目標ですが、将来の計画イテレーションのためにさらにレビューされます。

9. Q： 現在のプロセスに苦労していて、もっとガイダンスが必要です。どこにヘルプを求められますか？

   • A： インターロックプロセスに関する質問があれば、#r-and-d-planning-leads Slack チャンネル にメッセージを送ってください。また、計画期間中は毎週、計画期間外は月に一度、R&D Interlock オフィスがあります。参加して質問を持参し、インターロックの最新ステータスを得られます。ノートに事前に記入された質問がないセッションはキャンセルされます。

ページのソースコードを見る - ページの編集 - please contribute.