フレームワーク活用ガイドひとことで言うと#
ユーザーに価値を届けるまでの構成要素（バリューチェーン）を、見える度合い（Visibility） と 進化の段階（Evolution） の2軸で地図に描き、どこに投資し何を捨てるかを判断するフレームワーク。Simon Wardley氏がAmazonの戦略を分析する中で体系化した。
押さえておきたい用語#
- バリューチェーン（Value Chain）
- ユーザーに価値が届くまでに必要な活動や構成要素の連鎖のこと。上流ほどユーザーから見えにくく、下流ほど見えやすい。
- Evolution（エボリューション）
- 構成要素が時間とともにたどる進化の4段階を指す。Genesis → Custom Built → Product → Commodity の順に成熟していく。
- アンカー（Anchor）
- マップの最上部に置くユーザーのニーズそのもののこと。すべての構成要素はこのアンカーから下に連なる。
- コモディティ化（Commoditisation）
- かつて差別化の源泉だった技術や機能が標準化・汎用化して競争優位を失う過程である。クラウドインフラやメール配信などが典型例。
- 慣性（Inertia）
- 組織が既存のやり方に固執し、進化に対して抵抗する力を指す。マップ上で慣性を可視化することで、変革の障壁を事前に特定できる。
ワードリーマッピングの全体像#
こんな悩みに効く#
- 自社のどの技術に投資すべきか、判断の軸がない
- 内製すべきか外注すべきか、いつも議論が平行線になる
- 競合が次に何を仕掛けてくるか予測したい
- 新技術に飛びつくべきか、様子を見るべきか迷っている
基本の使い方#
マップの最上部に「誰の、どんなニーズに応えるのか」を置く。ここがすべての起点になる。
- ユーザーは誰か: 顧客、社内ユーザー、エンドユーザーなど
- 何を求めているか: 機能ではなく「達成したいこと」で書く
- 例: 「中小企業の経理担当が月次決算を3日以内に完了させたい」
アンカーから下に向かって「それを実現するには何が必要か？」を繰り返し、構成要素を洗い出す。
- ユーザーに近いもの（UI、サービス）から遠いもの（インフラ、電力）まで
- 粒度は揃える: 「AI機能」と「サーバー電源」が同じ粒度だと使いにくい
- 要素間の依存関係を線でつなぐ
各構成要素を横軸の4段階のどこに位置するか判断してプロットする。
| 段階 | 特徴 | 例 |
|---|---|---|
| Genesis | 新しく、不確実 | 自社独自のAIモデル |
| Custom Built | 目的特化で作り込み | 業務特化の管理画面 |
| Product | 市場に複数の選択肢 | CRMツール、BIダッシュボード |
| Commodity | 誰でも安価に使える | クラウドサーバー、メール配信 |
すべての要素は右（Commodity方向）に進化する。その速度と、組織の抵抗を可視化する。
- 矢印: 要素が今後どの方向に動くかを示す
- 慣性マーク: 「本当は外注すべきだが社内チームが手放さない」などの抵抗ポイント
- この動きを読むことで「次に何が起きるか」の仮説が立つ
完成したマップを見て、投資・撤退・外注の判断を下す。
- Genesis領域: 探索と実験に投資。ここが将来の差別化の源泉
- Commodity領域: 自前でやる意味がない。SaaSやアウトソースに切り替える
- 進化の方向: 今はCustom Builtでも、2年後にProductになるなら自社開発をやめる判断もある
具体例#
従業員120名のフードデリバリースタートアップが、限られた開発リソース（エンジニア18名）でどこに集中投資すべきかを整理した。
アンカー: 「注文から30分以内に温かい料理を届けてほしい」
マップに配置した主な構成要素:
| 構成要素 | 進化段階 | 現状 |
|---|---|---|
| 配達ルート最適化AI | Genesis | 自社開発、精度72% |
| 注文管理システム | Custom Built | 自社開発、保守にエンジニア4名 |
| 決済機能 | Commodity | 自社実装、PCI DSS対応に年間800万円 |
| クラウドインフラ | Commodity | AWS利用済み |
| 店舗向けタブレットUI | Product | 自社開発 |
マップを描いた瞬間、決済機能に年間800万円とエンジニア2名を費やしている異常さが見えた。Stripe連携に切り替え、浮いたリソースを配達ルート最適化AIに振り向けた結果、配達時間の中央値が38分から26分に短縮。注文単価も平均120円上がった。
総資産2.8兆円の地方銀行が、DX推進室の設立にあたり「何を内製し、何をベンダーに任せるか」で経営会議が紛糾していた。
ワードリーマップで勘定系・情報系・チャネル系を可視化すると、議論の焦点が絞られた。
- Genesis: 地域企業の財務データを活用した融資審査AIモデル（他行にない強み）
- Custom Built: 法人向けポータルの顧客体験設計
- Product → Commodity移行中: コールセンターシステム（クラウド型CTIに移行可能）
- Commodity: メール配信、帳票印刷、データセンター運用
特に帳票印刷の内製にこだわる部門の慣性が強く、年間1.2億円を社内で費やしていた。マップを見せることで「ここは差別化にならない」という共通認識が生まれ、外部BPOへの移行が決まった。
浮いた予算の約半分を融資審査AIの開発に充て、審査期間を14営業日から5営業日に短縮する計画が走り出している。
創業95年・客室28室の温泉旅館。コロナ後の回復期に「とりあえずDX」と言われ、予約管理・顧客管理・SNS運用・館内IoTを同時に進めようとして、どれも中途半端になっていた。
女将がワードリーマップを描いてみた（付箋とホワイトボードで十分できる）。
- Genesis: 常連客の好みを記憶した「おもてなしデータベース」（旅館の競争力の源泉）
- Custom Built: 季節ごとの料理プラン設計
- Product: 予約管理 → じゃらん・楽天トラベルのシステムで十分
- Commodity: SNS投稿のスケジューリング → 月額5,000円のツールで自動化
「全部やる」から「おもてなしデータベースだけは自分たちで作り込む」に方針転換。予約管理の自社開発を止めて年間180万円を節約し、そのうち60万円を常連客管理のNotion+スプレッドシート運用に回した。リピート率が前年の**34%から47%**に上がったのは、投資先を絞れたからこそだろう。
やりがちな失敗パターン#
- 最初から完璧なマップを描こうとする — ワードリーマップは「だいたい合っている」で十分価値がある。完璧を目指して議論が止まるより、30分で粗いマップを描いてから修正するほうがはるかに生産的
- 進化段階の判断を1人で行う — 「これはまだGenesisだ」「いやもうProductだろう」という認識のズレこそが戦略議論の本丸。複数人で議論しながら配置することでチーム内の前提が揃う
- マップを描いて終わりにする — 地図は移動するために使うもの。「この要素は右に動くから、2年後には外注に切り替える」のような時間軸を伴うアクションまで落とさないと壁に貼ったポスターになる
- すべての構成要素を同じ粒度で並べる — 「AIモデル」と「電気」を同列に並べても判断には使えない。意思決定に影響する粒度に揃えること
まとめ#
ワードリーマッピングは、バリューチェーンの構成要素をVisibility（見える度合い） と Evolution（進化段階） の2軸でプロットし、投資判断の根拠を「地図」として可視化する手法。Genesis領域には探索投資を、Commodity領域には標準化・外注を、という判断が地図から自然に導かれる。技術投資で迷ったら、まず付箋とホワイトボードで30分。粗くてもマップがあるのとないのとでは、議論の質がまるで変わる。