構成プロジェクト一覧（コンポーネント登録簿）のテンプレート
プログラムを1年も続けていると、「これもプログラムに入れてほしい」という話が必ず来ます。断る理由も入れる理由もその場で作ると、1年後には最初とまったく違う中身になっています。
この記事では、それを防ぐための構成プロジェクト一覧（コンポーネント登録簿）のテンプレートを紹介します。ポイントは、案件を構成・関連・範囲外の3つに分けて登録することです。記入例は、ミライアパレル（架空）の「OMO変革プログラム」です。
■ 1. 背景・よくある課題
よくある状態 | 何が起きるか |
|---|---|
入れる・入れないの基準が無い | 声の大きい部署の案件が入り、プログラムが膨らむ |
関係のあるものを、すべて中に入れている | PgMが動かせない案件まで抱え、責任だけが増える |
一覧がプロジェクト名と期間だけ | 各プロジェクトが何に効くのかが分からない |
範囲外にしたものが記録されていない | 半年後に同じ議論を繰り返す |
1つのプロジェクトが大きすぎる | 2年かかるプロジェクトが1本あり、途中で止められない |
プロジェクトを細かく切りすぎている | 15本を超え、管理そのものが仕事になる |
■ 2. テンプレート作成の目的
目的 | 具体的にどうなることか |
|---|---|
入れる・入れないの基準を先に決める | 3つの問いで機械的に判定できるようにする |
動かせるものだけを中に入れる | PgMが資源と優先順位を決められる範囲に絞る |
外したものも記録する | 同じ議論を繰り返さない |
各プロジェクトが何に効くかを紐づける | 予算削減の議論で、何が落ちるかを説明できる |
切り方の粒度をそろえる | 期間6〜12か月、5〜10本を目安にする |
■ 3. 3つの分類と、その判定
案件は、次の3つのどれかに分類します。
分類 | 意味 | PgMがすること | 一覧への記載 |
|---|---|---|---|
構成プロジェクト | プログラムの成果に直接効き、資源をPgMが配分できる | 優先順位の決定、ゲート判定、月次報告の受領 | する（本体） |
関連プロジェクト | 依存関係はあるが、予算も人もプログラムの外にある | 依存関係の管理と、定期的な情報交換のみ | する（別枠） |
範囲外 | どのベネフィットにも効かない | 何もしない。憲章の「範囲外」に明記する | する（記録用） |
判定は、次の3つの問いで行います。
とくにQ2が大事です。「関係があるから中に入れる」をやると、PgMは動かせないものの責任まで負うことになります。予算も人も決められないなら、それは関連プロジェクトとして依存関係だけを管理するのが正しい扱いです。
ミライアパレルでは、この判定を使って当初案から2件を外しました。「店舗レイアウト改装」はQ1で範囲外に、「グループ会社の基幹システム更新」はQ2で関連プロジェクトになっています。
■ 4. 各項目の説明
構成プロジェクト一覧の列構成です。1プロジェクト1行で書きます。
列 | 記入する内容 | 書き方のコツ |
|---|---|---|
ID／名称 | P1、P2… と、短い呼び名 | 番号は途中で入れ替えない。追加はP6以降 |
分類 | 構成／関連／範囲外 | 判定の3つの問いの結果をそのまま書く |
効くベネフィット | B-01（主）、B-04（従） のように | 主従を分ける。主が無いプロジェクトは要再検討 |
主な成果物 | 何ができあがるか | システム名だけでなく、手順書や研修も書く |
期間 | 開始と稼働（または完了）の年月 | 6〜12か月が目安。超えるなら分割を検討 |
計画額 | 金額（万円） | プログラム予備費とは別に管理する |
PM | 個人名 | 部署名で書かない |
依存 | 前提となるプロジェクトのID | 詳細は依存関係マップへ。ここは概要だけ |
状態 | 計画中／実行中／完了／保留／中止 | ゲート判定の結果を反映する |
直近のゲート | 通過したゲートと日付 | ゲート定義書と対応させる |
登録日／変更履歴 | いつ追加・変更したか | プログラムの中身がいつ変わったかを残す |
「効くベネフィット」の列が、この一覧の中心です。ここが空欄のプロジェクトは、そもそもプログラムに入れる理由がありません。
■ 5. 記入例（架空企業：ミライアパレル）
構成プロジェクト（5本）
ID | 名称 | 効くベネフィット | 期間 | 計画額 | PM | 状態 |
|---|---|---|---|---|---|---|
P1 | 在庫一元化（UNITE） | B-01（主）／B-04（主） | 2024/4〜2025/3 | 2億2,680万円 | 村瀬 | 完了 |
P2 | 店舗間移動最適化 | B-02（主）／B-01（従） | 2025/4〜2025/12 | 1億1,500万円 | 佐々木 | 実行中 |
P3 | 会員・ポイント統合 | B-03（主）／B-06（主） | 2025/1〜2026/3 | 2億4,000万円 | 岡田 | 実行中 |
P4 | 物流拠点再編 | B-05（主）／B-01（従） | 2025/7〜2026/9 | 2億8,000万円 | 中井 | 計画中 |
P5 | 店舗業務デジタル化 | B-04（主）／B-06（従） | 2026/1〜2026/12 | 1億1,000万円 | 未定 | 計画中 |
― | 小計 | ― | ― | 9億7,180万円 | ― | ― |
関連プロジェクト（2本）
ID | 名称 | 所管 | プログラムとの関係 | 情報交換の頻度 |
|---|---|---|---|---|
R1 | グループ会社の基幹システム更新 | グループIT本部 | 商品マスタの連携仕様が、P1・P3の前提になる | 月1回（PMOが出席） |
R2 | ECサイトのデザインリニューアル | EC事業部 | P3の会員画面と、リリース時期が重なる | 四半期に1回 |
範囲外にしたもの（記録）
名称 | 外した理由 | 判定日 | その後の扱い |
|---|---|---|---|
店舗レイアウト改装 | どのベネフィットにも線が引けない（Q1で不可） | 2024/3/12 | 店舗運営部の年度予算で単独実施 |
基幹会計システムの刷新 | ベネフィットに効かず、別の投資枠で承認済み | 2024/3/12 | 経理部が別プログラムとして推進 |
海外EC展開 | この3年の範囲外。国内の基盤が整ってから | 2024/3/12 | 2027年度以降に再検討 |
範囲外の表を残しておくと、「あれはなぜやらないのか」と聞かれたときに、理由と判定日を示せます。半年ごとに同じ議論を繰り返さずに済むのが、この表のいちばんの効き目です。
■ 6. 切り方の目安
観点 | 目安 | 外れているときの直し方 |
|---|---|---|
1本の期間 | 6〜12か月 | 18か月を超えるなら、稼働を分けて2本にする |
本数 | 5〜10本 | 15本を超えるなら、似たものをまとめる |
1本の金額 | プログラム総額の10〜30% | 50%を超える1本があるなら、それは分割を検討する |
効くベネフィット | 主が1つ以上 | 従しか無いなら、他のプロジェクトに統合する |
PMの担当 | 1人1本 | 1人で2本以上を持つなら、実質1本に統合する |
「1本の期間を6〜12か月にする」のには理由があります。プログラムの途中で方向を変えられる単位にしておくためです。2年かかるプロジェクトが1本あると、その2年間は何も調整できません。
■ 7. 運用ルール
ルール | 内容 | 理由 |
|---|---|---|
追加・削除は憲章の改定として扱う | 3つの問いで判定し、運営委員会で承認する | いつのまにか中身が変わるのを防ぐ |
効くベネフィットが空欄なら登録しない | 主が1つも無いものは差し戻す | 説明できない投資を作らない |
範囲外にしたものも記録に残す | 理由と判定日をセットで書く | 同じ議論を繰り返さない |
IDは再利用しない | 中止したP3の番号を、別の案件に使わない | 過去の記録がたどれなくなる |
状態はゲート判定で更新する | PgMの感覚ではなく、ゲートの結果で変える | 状態の意味が人によってぶれない |
四半期に1回、全件を見直す | 関連プロジェクトの状況も確認する | 外の変化が、依存関係を通じて効いてくる |
■ 8. 活用シーン
場面 | 使い方 |
|---|---|
新しい案件を入れたいと言われたとき | 3つの問いで判定し、結果を一覧に記録する |
予算削減を求められたとき | 計画額と効くベネフィットの対応から、何が落ちるかを示す |
ステージゲートの判定 | 状態と直近ゲートの列を更新する |
月次の運営委員会 | 状態が変わった行だけを報告する |
要員配分の検討 | 期間の重なりから、どの時期に人が必要かを見る |
PgMの交代時 | この一覧と憲章の2つで、引き継ぎの骨格になる |
■ 9. よくある失敗と直し方
失敗 | 起きること | 直し方 |
|---|---|---|
関係のあるものを全部中に入れる | 動かせない案件の責任まで負う | Q2で分け、関連プロジェクトとして扱う |
効くベネフィットが空欄のまま | 投資の説明ができない | 主を1つ以上書く。書けないなら範囲外へ |
2年かかる1本が含まれている | その2年、方向を変えられない | 稼働を分けて2本にする |
本数が20本を超えている | 管理そのものが仕事になる | 似たものをまとめ、10本以内にする |
範囲外の記録が無い | 半年後に同じ議論を繰り返す | 理由と判定日を記録し、いつでも示せるようにする |
IDを再利用している | 過去の判断がたどれなくなる | 欠番のまま運用する |
■ 10. 導入効果
観点 | 一覧が無い／薄いとき | 3分類で登録したとき |
|---|---|---|
案件の追加 | 声の大きさで決まる | 3つの問いで機械的に判定できる |
PgMの負担 | 動かせない案件まで抱える | 構成5本に集中し、関連2本は依存関係だけ見る |
断ったときの説明 | 「今回は見送りで」 | 「Q1でベネフィットに線が引けないため」 |
予算削減の議論 | 一律カットになる | プロジェクト単位で、落ちるベネフィットを示せる |
同じ議論の繰り返し | 半年ごとに蒸し返される | 範囲外の記録で、理由と判定日を示せる |
■ まとめ
構成プロジェクト一覧は、プログラムの輪郭を決める文書です。中に入れるものを決めるのと同じくらい、外に出したものを記録しておくことに価値があります。
いま運用している一覧に「効くベネフィット」の列が無ければ、まずその1列を足してみてください。埋まらない行が出てきたら、それがプログラムを整理する最初の手がかりになります。