ベネフィット実現計画（ベネフィット・マップ）のテンプレート
プログラム憲章で成果を決め、ベネフィット定義書で測り方を決めたら、次は「その成果は、何がどうなって生まれるのか」をつなぐ番です。ここが抜けていると、構成プロジェクトが全部完了しても指標が動かない、ということが起こります。
この記事では、そのつながりを1枚に描くベネフィット・マップと、いつ効き始めていつ測るかを示すベネフィット実現スケジュールのテンプレートを紹介します。記入例は、ミライアパレル（架空）の「OMO変革プログラム」です。
■ 1. 背景・よくある課題
よくある状態 | 何が起きるか |
|---|---|
成果物と指標の間がつながっていない | システムは完成したのに、指標が動かない |
「システムを入れれば業務が変わる」と思っている | 業務手順と権限を変えていないため、誰も使い方を変えない |
稼働日＝成果が出る日だと思っている | 稼働直後に測って「効果なし」と判断してしまう |
どの指標にも効かない成果物が含まれている | 投資の一部が、説明できないまま消える |
どの成果物にも支えられていない指標がある | 目標だけ掲げて、達成手段が無い状態になる |
副作用が計画に入っていない | 物流コストの上昇などが「想定外」として扱われる |
■ 2. テンプレート作成の目的
目的 | 具体的にどうなることか |
|---|---|
成果物から指標までを線でつなぐ | 「なぜこれを作るのか」を、指標まで遡って説明できる |
抜けている作業を見つける | 業務手順の変更や研修など、システム以外の作業が見える |
余計なものを見つける | どの指標にも効かない成果物を、範囲外に出せる |
効き始める時期を決める | 稼働日ではなく、定着後の測定時期を計画に入れる |
副作用が先に出ることを見込む | 悪化する期間を、あらかじめ運営委員会と合意しておく |
■ 3. ベネフィット・マップの5つの層
マップは左から右へ、5つの層で並べます。
層 | 呼び方 | 書くもの | 誰が責任を持つか |
|---|---|---|---|
① | アウトプット（成果物） | 構成プロジェクトが作るもの。システム、設備、手順書 | 各プロジェクトのPM |
② | ケイパビリティ（できるようになること） | 成果物が揃うと、組織として何ができるようになるか | 各プロジェクトのPM |
③ | アウトカム（業務・行動の変化） | 現場の人が、実際に違うやり方をしている状態 | 業務部門（＋PgM） |
④ | ベネフィット（測る指標） | ベネフィット定義書の指標 | PgM |
⑤ | 戦略目標 | 会社としての到達点 | 経営 |
境目でいちばん大事なのが②と③の間です。②は「できる」、③は「実際にやっている」。ここに研修・手順の改定・評価制度の見直しといった、システム以外の作業が必要になります。この区別が無いと、プログラムは「システムを作るだけ」になります。
線は「効く」関係を表します。1つの成果物が複数のベネフィットに効き、1つのベネフィットは複数の変化に支えられます。マップを描くと、次の2つがすぐ見つかります。
見つかるもの | 意味 | 対応 |
|---|---|---|
線が1本も出ていない成果物 | どの指標にも効かない | プログラムの範囲外に出すか、効く指標を追加する |
線が1本も入っていないベネフィット | 達成する手段が無い | プロジェクトを足すか、目標を取り下げる |
ミライアパレルでは、当初案にあった「店舗レイアウト改装」から線が1本も引けないことが分かり、プログラムの範囲外に移しました。マップを描く目的の半分は、この「引き算」にあります。
■ 4. ベネフィット実現スケジュール
マップが「何が何に効くか」なら、スケジュールは「それがいつ効くか」です。
ここでいちばん伝えたいのは、稼働日と、ベネフィットが出はじめる日は違うということです。P1は2025年3月に稼働しますが、B-01（欠品損失）が測れるのは定着後の2025年8月です。この「ずれ」を計画に書いておかないと、稼働直後に「効果が出ていない」と判断され、続けるべき施策が止められます。
行 | 書く内容 | 書き方のコツ |
|---|---|---|
構成プロジェクトの稼働 | ★印で各プロジェクトの稼働日 | ベネフィットの帯より上に置く。ずれが視覚的に分かる |
ベネフィットの帯 | その指標が改善しはじめる期間 | 稼働日ではなく、定着期間（3〜6か月）を足した日から |
測定ポイント（◆） | 定義書の④で決めた測定日 | 最初の測定は、定着期間が終わった後に置く |
悪化する期間 | 副作用が先に出る指標の、赤い帯 | 運営委員会と事前に合意しておく |
B-05（物流コスト率）の赤い帯が、この表の要点です。取り寄せや店舗間移動が増えれば、物流コストは先に悪化します。良くなるのは、P4（物流拠点再編）が稼働してからです。このことを計画に書き、運営委員会と合意しておかないと、途中の報告で「コストが上がっている」と指摘されて施策が止まります。
■ 5. テンプレートの全体像
ベネフィット実現計画は、3つの部品でできています。
部品 | 形式 | 役割 | 更新の頻度 |
|---|---|---|---|
① ベネフィット・マップ | A3で1枚の図 | 成果物からベネフィットまでのつながりを見せる | 構成プロジェクトの増減時 |
② 実現スケジュール | 四半期刻みの帯 | いつ効き始め、いつ測るかを示す | 四半期ごと |
③ 実現責任表 | 1ベネフィット1行の表 | 誰が実現に責任を持つかを決める | 体制変更時 |
③ 実現責任表は見落とされやすい部品です。プロジェクトのPMは「作る」責任を持ちますが、「使われる状態にする」責任は業務部門にあります。ここを書き分けておきます。
ベネフィット | 作る責任（アウトプット） | 使われる状態にする責任（アウトカム） | 測る責任 |
|---|---|---|---|
B-01 欠品損失 | P1のPM | 店舗運営部長（取り寄せ運用の定着） | 経営企画部 |
B-02 値引き率 | P2のPM | 商品部長（在庫移動の判断基準の運用） | 経営企画部 |
B-03 EC売上比率 | P3のPM | EC事業部長（統合会員向けの施策実行） | EC事業部 |
B-04 在庫問い合わせ | P1・P5のPM | 店舗運営部長（端末の利用定着） | 店舗運営部 |
B-05 物流コスト率 | P4のPM | 物流部長（新拠点への業務移管） | 物流部 |
B-06 クロスチャネル率 | P3・P5のPM | EC事業部長・店舗運営部長（接客手順の改定） | EC事業部 |
■ 6. 作り方の手順
手順 | やること | 所要の目安 |
|---|---|---|
1 | 右端（④ベネフィット）を並べる。定義書の指標をそのまま置く | 30分 |
2 | 左端（①アウトプット）を並べる。構成プロジェクトの成果物 | 30分 |
3 | ②ケイパビリティを、①から埋める。「〜できる」で書く | 60分 |
4 | ③アウトカムを、④から逆算する。「〜している」で書く | 60分 |
5 | 線を引く。引けないものを洗い出す | 60分 |
6 | 引けなかった箇所を、追加・削除・目標変更のどれかで処理する | 運営委員会で決定 |
③を④から逆算するのがコツです。①から順に右へ進めると、「作ったものでできること」の延長でしか考えられません。④から左へ戻ると、「この指標を動かすには、現場が何をしている必要があるか」という問いになります。
■ 7. 運用ルール
ルール | 内容 | 理由 |
|---|---|---|
A3で1枚に収める | 階層は5つまで、項目は各層6つまで | 大きくなると誰も読まない |
構成プロジェクトが増減したら描き直す | マップの更新を、憲章の改定とセットにする | 古いマップは判断を誤らせる |
キックオフで全員に見せる | 各プロジェクトのメンバーに、自分の位置を示す | 自分の作業が何に効くかが分かると、判断が変わる |
四半期のレビューで実績を重ねる | スケジュールの◆に、実績値を書き込んでいく | 計画と実績の差が、次の打ち手の材料になる |
②と③の間の作業を、誰かのWBSに入れる | 研修・手順改定・評価制度の見直しを宙に浮かせない | ここが抜けると、システムだけができあがる |
■ 8. 活用シーン
場面 | 使い方 |
|---|---|
プログラムの立ち上げ | 憲章と同時に作り、構成プロジェクトの妥当性を確認する |
プロジェクト追加の判断 | マップに線が引けるかどうかで、入れるかを決める |
予算の削減を求められたとき | どの線が切れるか、どの指標が落ちるかで説明する |
四半期のベネフィットレビュー | スケジュールの◆で実績を確認し、帯を引き直す |
効果が出ていないとき | ②③のどこで止まっているかを、線をたどって特定する |
プログラムの終結判定 | ④がすべて測定済みになった時点が、終わりの目安 |
■ 9. よくある失敗と直し方
失敗 | 起きること | 直し方 |
|---|---|---|
②と③を区別していない | システムは入ったが、誰も使い方を変えない | ②は「できる」、③は「している」で書き分ける |
マップが50項目を超えている | 誰も読まず、図としての役割を果たさない | 各層6項目までに集約。細目は別紙へ |
稼働日を測定日にしている | 定着前の数字で「効果なし」と判断する | 定着期間3〜6か月を足した日を初回測定にする |
副作用の帯を描いていない | 途中の悪化が「想定外」として扱われる | 赤い帯として描き、運営委員会と事前に合意する |
作ったきり更新していない | プロジェクトが入れ替わり、実態と合わなくなる | 憲章の改定とセットで更新する |
③の作業が誰のWBSにも無い | 研修や手順改定が宙に浮く | 業務部門のリーダーを、③の責任者として明記する |
■ 10. 導入効果
観点 | マップが無いとき | マップを描いたとき |
|---|---|---|
プロジェクトの取捨 | 声の大きさで決まる | 線が引けるかどうかで決まる（店舗改装を範囲外へ） |
システム以外の作業 | 見落とされる | ②③の間の作業として、業務部門のWBSに入る |
測定の時期 | 稼働直後に測ってしまう | 定着後に測る。P1稼働3月→初回測定8月 |
副作用 | 途中で指摘されて施策が止まる | 悪化する期間を事前に合意している |
予算削減の議論 | 一律○%カットになる | 「この線を切ると、この指標が落ちる」と説明できる |
■ まとめ
ベネフィット・マップは、作るものと、測る数字のあいだを埋める図です。埋めてみると、たいてい2つのことが分かります。システム以外にやるべき作業があること、そして、やらなくてよい作業が混じっていること。
最初に描くときは、完璧を目指さなくて構いません。右端の指標と左端の成果物を並べて、線を引いてみる。引けない箇所が見つかった時点で、この図は仕事をしています。