アウトカムマッピング

英語名 Outcome Mapping
読み方 アウトカム マッピング
難易度
所要時間 2〜3時間(ワークショップ)
提唱者 IDRC(国際開発研究センター)
目次

ひとことで言うと
#

「何を作るか」ではなく「ユーザーの行動がどう変わるか」を起点にプロダクトの成功を設計する手法。アウトプット(機能、画面)を定義する前に、狙うべきアウトカム(行動変容)を明確にし、そこから逆算して施策を決める。

押さえておきたい用語
#

押さえておきたい用語
アウトカム(Outcome)
プロダクトの利用によって生まれるユーザーの行動変容や習慣の変化のこと。「ダッシュボードを使う」ではなく「データを見て施策を変える」がアウトカム。
アウトプット(Output)
チームが作って届ける具体的な成果物のこと。機能、画面、コンテンツなど。アウトカムを実現するための手段。
境界パートナー(Boundary Partner)
プロダクトが直接影響を与えられるステークホルダーのこと。エンドユーザー、管理者、チームリーダーなどが該当する。
プログレスマーカー(Progress Marker)
アウトカムの達成度を段階的に測る行動指標のこと。Expect / Like / Love の3段階で設計する。

アウトカムマッピングの全体像
#

アウトカムマッピング:ビジョンから逆算して行動変容を設計する
ビジョン(インパクト)プロダクトが実現したい大きな変化(直接コントロール不可)境界パートナーAExpect: ログインするLike: 週次で確認するLove: 文化が定着する境界パートナーBExpect: 情報を確認するLike: 自ら共有するLove: 行動が変わる境界パートナーCExpect: 利用を開始するLike: サポートを提供Love: 組織に浸透させるアウトプット(施策)行動変容を促す機能・コンテンツ・サポートを逆算「何を作るか」ではなく「行動をどう変えるか」が起点逆算
アウトカムマッピングの進め方フロー
1
ビジョン定義
プロダクトが実現したい大きな変化を言語化
2
アウトカム設定
境界パートナーの行動変容を定義
3
マーカー設計
Expect / Like / Loveの3段階で進捗を設計
アウトプット逆算
行動変容を促す施策を導き出す

こんな悩みに効く
#

  • 機能はたくさん作ったのに、ビジネス成果につながらない
  • 「ダッシュボードを作ってほしい」と言われて作ったが、誰も見ていない
  • チームが「何を作るか」ばかり議論して「なぜ作るか」を考えていない

基本の使い方
#

ステップ1: ビジョン(最終的なインパクト)を定義する

プロダクトが実現したい大きな変化を言語化する。

  • ビジョンの例: 「中小企業の経営者が、データに基づいて迅速に意思決定できる世界」
  • 具体的で測定可能にする: 「DX」「イノベーション」のような曖昧な言葉は避ける

ビジョンは直接コントロールできない。コントロールできるのは、ビジョンに向けたアウトカムとアウトプット。

ステップ2: 境界パートナーとアウトカムを特定する

プロダクトが直接影響を与えられる人々(境界パートナー)と、その行動変容(アウトカム)を定義する。

  • 境界パートナー: エンドユーザー、管理者、チームリーダーなど
  • アウトカム: その人々の行動がどう変わればビジョンに近づくか

アウトカムの書き方:

  • NG: 「ダッシュボードを使う」(これはアウトプットの利用であってアウトカムではない)
  • OK: 「経営者が週次で売上データを確認し、翌週の施策を調整するようになる」

行動の変化として書くのがポイント。

ステップ3: プログレスマーカーを設計する

アウトカムの達成度を段階的に測る指標を設定する。

3段階のプログレスマーカー:

  • Expect to see(期待される変化): 最低限の行動変化。例: 「経営者がダッシュボードにログインする」
  • Like to see(望ましい変化): より深い行動変化。例: 「経営者が週1回、データを見て施策を変更する」
  • Love to see(理想的な変化): 最高の行動変化。例: 「経営者がチーム全員にデータを共有し、データドリブンな文化が定着する」

段階的に追うことで、途中経過を可視化できる

ステップ4: アウトカムから逆算してアウトプットを決める

アウトカムを実現するために必要なアウトプット(機能、コンテンツ、サポート)を逆算する。

  • 各アウトカムに対して「この行動変容を促すために何が必要か?」を問う
  • 機能だけでなく、オンボーディング、教育コンテンツ、CSの対応も含める
  • 複数のアウトプット候補を出し、最もインパクトが大きいものから着手

アウトプットは手段であってゴールではない: 「ダッシュボードを作る」ことが目的ではなく、「経営者がデータを見て行動を変える」ことが目的。

具体例
#

例1:人事SaaSの1on1機能をアウトカムマッピングで設計する

ビジョン: 「マネージャーとメンバーの対話を通じて、組織のエンゲージメントが向上する」

境界パートナーとアウトカム:

境界パートナーアウトカム
マネージャーメンバーの状態を事前に把握した上で1on1に臨むようになる
メンバー1on1で自分のキャリアや悩みを率直に話すようになる
人事部組織全体の1on1の質を把握し、必要なサポートを提供するようになる

マネージャーのプログレスマーカー:

  • Expect: 1on1の前にメンバーの情報(前回の議事録、最近の業務状況)を確認する
  • Like: 1on1で出たアクションアイテムを次回までにフォローアップする
  • Love: メンバーの成長を四半期ごとに振り返り、育成計画を調整する

逆算したアウトプット:

  • 1on1テンプレート(事前準備を促す構造化された質問)
  • メンバーのコンディション履歴表示(事前把握を支援)
  • アクションアイテムのリマインド機能(フォローアップを促進)
  • 1on1実施状況レポート(人事部向け)

「1on1ツールを作る」ではなく「マネージャーの行動を変える」が起点。導入6ヶ月後、1on1実施率が42%から88%に向上し、エンゲージメントスコアが平均0.8ポイント改善。

例2:物流スタートアップの配送最適化アプリを再設計する

ビジョン: 「ラストワンマイル配送のコストと環境負荷を同時に削減する」

境界パートナーとアウトカム:

境界パートナーアウトカム
配送ドライバーAIルート提案を信頼し、手動ルート変更をしなくなる
配送センター管理者当日の配送件数と所要時間を朝の時点で正確に予測できるようになる
EC事業者(荷主)配送状況をリアルタイムで確認し、顧客問い合わせに即答できるようになる

配送ドライバーのプログレスマーカー:

  • Expect: アプリでルート確認を開始する(紙の地図を使わなくなる)
  • Like: AI提案ルートを80%以上の配送で採用する
  • Love: 渋滞・天候情報を踏まえたルート変更をドライバー自身が提案するようになる

逆算したアウトプット:

  • リアルタイム渋滞反映のルート最適化エンジン
  • ドライバー向け音声ナビ(運転中でも安全に使える)
  • 「AIルート vs 実際ルート」の比較レポート(信頼構築用)
  • 荷主向けリアルタイム追跡ダッシュボード

当初「ルート最適化アルゴリズムの精度向上」に投資していたが、ドライバーがAI提案を信頼していないことが本質的な課題だった。信頼構築のための比較レポートを追加した結果、AI採用率が35%から82%に向上し、配送効率が平均18%改善。

例3:地方自治体の防災アプリをアウトカムマッピングで改善する

ビジョン: 「災害時に住民が正しい情報に基づいて迅速に避難行動を取れる」

境界パートナーとアウトカム:

境界パートナーアウトカム
住民(65歳以上)避難指示が出たら10分以内に避難を開始するようになる
自治会長担当地区の要支援者の所在を常時把握し、避難時に声がけできるようになる
市の防災担当避難状況をリアルタイムで把握し、救助の優先順位を判断できるようになる

住民(65歳以上)のプログレスマーカー:

  • Expect: 防災アプリをインストールし、プッシュ通知を有効にする
  • Like: 避難訓練時にアプリの避難経路案内を実際に使う
  • Love: 平常時にハザードマップを確認し、自宅周辺のリスクを家族と共有する

逆算したアウトプット:

  • 大きな文字・シンプルUIの避難ナビ(高齢者向けUX)
  • 「いま避難しています」ワンタップ通知(自治会長に安否が伝わる)
  • 防災訓練モード(実際の災害でなくても操作を練習できる)
  • 避難完了の集計ダッシュボード(防災担当向け)

従来のアプリは「情報を正確に伝える」ことに注力していたが、住民が実際に避難行動を起こすかどうかが本質的な課題だった。防災訓練での実利用率が12%から67%に向上し、実際の台風時の避難開始時間が平均23分短縮された。

やりがちな失敗パターン
#

  1. アウトプットとアウトカムを混同する — 「レポート機能を使ってもらう」はアウトプットの利用。「経営者がレポートを見て施策を変える」がアウトカム。常に「それでユーザーの行動はどう変わるの?」と問う
  2. すべての境界パートナーを同時に狙う — 優先順位をつける。最もインパクトの大きい境界パートナーから着手する
  3. プログレスマーカーを定性的にしすぎる — 「満足度が上がる」では追えない。行動の変化として測定可能な形で書く
  4. アウトプットを先に決めてからアウトカムを後付けする — 「この機能を作りたい」が先にあって、それに合うアウトカムを探すのは本末転倒。必ずアウトカムから逆算する

まとめ
#

アウトカムマッピングは「機能を作る」から「行動を変える」にチームの思考を転換するフレームワーク。ビジョン→アウトカム→プログレスマーカー→アウトプットの順で考えることで、「作ったけど使われない」を防ぎ、本当にインパクトのあるプロダクト開発ができる。次の機能を企画するとき、「これでユーザーの何の行動が変わるか」から考え始めてみよう。