優先事項トラッカーガイド

概要

優先事項トラッカー（社内用、GitLab チームメンバー限定）は、四半期ごとに 1 つ作成する、7 つのタブを持つスプレッドシートです。前の四半期のトラッカーをコピーして元のものを記録として残し、Read me タブの四半期設定を変更すると、すべてのタブが再計算されます。

このページはスプレッドシートのリファレンスです。各タブの内容、行の書き方、作業可能量の計算方法、計画確定前に各行が満たすべきチェック項目を説明します。レビューの頻度、入れ替えのルール、四半期の締め処理など、トラッカーが支えるプロセスは四半期計画ページを参照してください。

タブ

トラッカー内の規約: 黄色のセルに記入してください。青い文字は入力した数値、黒い文字は数式なので、数式は変更しないでください。灰色の斜体の行は上書きするための記入例です。ドロップダウンの使用は必須です。選択肢にない値が必要な場合は、制約を回避して入力するのではなく、トラッカーのオーナーに依頼してください。 行 ID は DRF-1 のようにチームコードと番号を組み合わせたもので、自動生成されます。

Two-pager

各チームは計画確定前に 1 つ作成します。印刷して 2 ページ以内に収めます。これは、レビューする人が一度に頭に入れておける分量の目安であり、それより長い計画は読まれない傾向があるためです。トラッカーのオーナーは、セクション 3、5、6、8 を最初に読みます。

行の構成

Priorities タブの各行には、4 つの列グループがあります。EM は確定前に計画の列を記入します。追跡の列はレビューサイクルごとに変更します。チェック列は数式で、締め処理の列は四半期末に 1 回だけ記入します。

Plan（計画）。 Team（チーム）、Rank（順位）、Org bet（組織の重点施策）、Outcome（成果）、Metric（指標）、Baseline（ベースライン）、Target（目標値）、Owner（オーナー）、Tier（区分）、Confidence（確信度）、Appetite（エンジニア週単位の投入上限）、Stop signal（中止判断のシグナル）、Check-by date（確認期限）、Depends on（依存先）、Dependency accepted by（依存事項を引き受けた人）、Epic link（エピックへのリンク）。

• 成果は「[日付] までに、[誰が] [何をする]」と記述します。指標、ベースライン、目標値によって検証可能にします。
• 中止判断のシグナルは「[こうなった] 場合、私たちは [こうする]」と記述します。確認期限は、それを確認する日です。期限を過ぎると、EM が新たな期限を設定して続行するか、入れ替えるか、優先順位を下げるかを決定するまで、行に警告が表示されます。
• 依存先には、計画内に存在する行 ID、Search and Data Platform 外のチームの場合は EXT: [team] — [what]、または None を記載します。提供側のチームが氏名と日付を記入して引き受けます。
• 確約項目の行には、実際の作業を追跡するエピックへのリンクを記載します。

Track（追跡）。 Current value（現在値）、Status（ステータス）、Last update（最終更新日）、日付付きの記録を新しい順に並べた Change log（変更ログ）。

Checks（チェック）。 OK またはその行が違反しているルールを表示する 1 つのセルです。確定するには、すべての行が OK でなければなりません。

Close（締め処理）。 Final value（最終値）、Result（結果: Hit は達成、Partial は一部達成、Miss は未達）、締めくくりの 3 行。

同じ行を、まずタスクとして、次に重点施策として書くと、次のようになります。

• タスクとして: 利用状況ダッシュボードのパブリックベータを 12 月 15 日までに提供する。 これでは日程しかわかりません。
• 重点施策として: 四半期末までに、デザインパートナー 10 アカウントの Engineering リーダー 25 人が、利用状況ダッシュボードを毎週再訪する。 指標: 毎週再訪するリーダー数、ベースライン 0、目標値 25。Committed（確約）、80%。投入上限: 26 エンジニア週。オーナー: 1 人の氏名。中止判断のシグナル: ベータ開始から 4 週間の時点で再訪するリーダーが 5 人未満なら、ビューの追加を止め、まずデータへの信頼を改善する。第 6 週末までに確認。DIP-1 に依存し、引き受けた人の氏名を記載。これなら、うまくいったかどうか、いつ止めるべきかがわかります。

作業可能量と確約分の上限

作業可能量は計算で求めます。Capacity タブは、四半期設定と各 EM が計画確定前に確認する数値を基に計算します。

• 標準作業可能量 = エンジニア数 ×（四半期の週数 − 休暇週数）− 既知の不在期間。単位はエンジニア週です。
• 確約分の上限 = 標準作業可能量 × 70%。
• 残りの 30% は予備枠です。行には一切記載しません。四半期末に各 EM が実際に使用した予備枠を記録し、上限を再調整できるようにします。

トラッカーのオーナーは、四半期ごとに Read me タブで休暇による控除を設定します。対象は全社的な休暇だけです。個人の PTO は Capacity タブの Absences 列に記載します。トラッカーで使用する目安は、1〜3 月と 4〜6 月の四半期が 0.5 週間、7〜9 月が 1.0 週間、10〜12 月が 2.0 週間です。最後の期間には Thanksgiving と 12 月 21〜31 日の休暇を織り込みます。10〜12 月の四半期に、エンジニア 4 人のチームで予定休暇が 2 エンジニア週ある場合、標準作業可能量は 4 × 11 − 2 = 42 エンジニア週、確約分の上限は約 29 です。確約項目の行は、この 29 エンジニア週以内に収めなければなりません。挑戦項目には、空いた作業可能量を使います。

Summary タブは、確約分の上限、計画された確約項目の投入上限、余力、上限を超えているチーム、エンジニア数が未入力のチームを組織全体で集計します。余力がマイナスなら、組織は上限内で提供できる量を超えて約束していることを意味し、上限を超えているすべてのチームは計画確定前に優先順位を見直します。

トラッカーが適用するチェック

Priorities タブの Checks 列は以下のルールを適用します。これらは判断を伴うものではなく機械的なチェックであり、1 つでも満たさない行は確定できません。

1. チーム内の順位は 1 から n までで、重複がないこと。
2. すべての行に成果、指標、ベースライン、目標値があること。
3. すべての行に 1 人のオーナーの氏名があり、組織の重点施策へのリンクまたは None が記載されていること。
4. 確約項目の行がチームの上限内に収まること。
5. すべての行に中止判断のシグナルと確認期限があること。確認期限を過ぎた行には、EM が決定するまで警告が表示されます。
6. すべての依存事項に、計画内に存在する行 ID または EXT: のチームが記載され、引き受けた人の氏名があること。
7. 確約項目の行にエピックへのリンクがあること。
8. 確信度が区分に合っていること。Committed（確約）は 80% または 90%、Aspirational（挑戦枠）は 50% です。
9. 更新期限（14 日間）内に更新されていない行には警告を表示し、順調な行より先に議論すること。
10. 依存先の項目には、それに依存する行のうち最も優先度の高い行と同等以上の組織優先度を持たせること。チーム間の優先順位付けを参照してください。

Priorities タブの記入例には、この列の動作を確認できるように、意図的に 2 つのチェックに失敗する行が含まれています。

防ぐことを目指すアンチパターン

このページの各ルールは、以下のいずれかがすでにどこかで起きたために存在します。見かけた場合は、レビューで取り上げてください。

よくある質問

「これはインターロックに別のプロセスを上乗せするものではありませんか？」 いいえ。インターロックは少数の大規模な部門横断の項目を対象とし、確約までを扱います。このページは、その下位とその後を扱います。チームが自分たちの行をどう選んで規模を決めるか、依存事項をどう調整するか、確約した作業をどう実行して締めくくるかです。インターロックにルールがある場合は、そのまま使用します。

「私のチームにはエンジニアが 4 人います。行数はいくつですか？」 優先順位を付けた 3〜5 行で、確約項目の行は上限内に収めます。インターロックのリソース配分フレームワークは、組織レベルで確約に上限を設けています。VP が例外を承認しない限り、エンジニア 20 人あたり P1 または E1 が最大 1 件、P2 または E2 が最大 2 件です。これを組織内のチームで分け合うと、通常、4 人のチームが同時に確約するチーム横断の行は最大 1 件になります。これは別のルールではなく、上限の結果であり、意図したものです。

「リーダーシップが確約を求める項目について、80% の確信が持てません。」 そのことを行の Change log に記載してください。その行を挑戦項目にするか、投入上限を増やすか、確信が持てるまでスコープを縮小します。50% で確約して 80% と呼ぶことは、その後のすべてを損ないます。トラッカー内の他のあらゆる数値は、その数値が正直であることを前提としているためです。

「四半期の途中で緊急の依頼が入りました。」 予備枠内に収まるなら実施し、1 行記録してください。確約分の作業可能量が必要なら、入れ替えルールに従って入れ替えを提案し、次のレビューで議論するよう印を付けるか、臨時のスレッドや同期ミーティングを設定して、組織全体、スコープ、コスト、時間の優先順位を調整して必要なリソースを確保してください。

「なぜ GitLab ではなくスプレッドシートなのですか？」 現時点で、順位、上限、依存事項の受諾、更新期限の警告、say/do のチェックを数式で適用しており、実際の作業はすでに GitLab のエピックにあるためです。GitLab の作業アイテムで同じチェックを適用できるようになれば、トラッカーを移行し、このページも変更します。

「エンジニアが実際にしなければならないことは何ですか？」 自分が所有する行の作成を手伝い（四半期に 1 回、1 時間未満）、エピックを最新に保ち、中止判断のシグナルが発生したら早めに伝えてください。このページのそれ以外の内容は、マネージャー向けです。

関連ページ

四半期計画、R&D Interlock、リリース前のプレモーテム。

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