新しい機能を自社で開発するべきか、外部サービスを使うべきか。限られた人員を、既存システムの維持と新しい試みのどちらへ振り向けるか。議論を始めても、参加者ごとに前提が違い、好みや過去の成功体験で話が進んでしまうことはないでしょうか。
一般的な事業計画やシステム構成図は、何があるかを整理するには便利です。ただし、利用者から見た重要度と、技術や業務がどれほど成熟しているかを同時に表しにくいため、投資判断の背景が見えないことがあります。
ワードリーマッピング（Wardley Mapping）は、利用者のニーズを起点に価値連鎖を描き、各要素を進化段階へ配置する戦略フレームワークです。要素がどこにあり、今後どちらへ動くかを地図として共有することで、内製、購入、標準化、探索といった選択を議論しやすくします。
この記事では、地図の二つの軸、作成手順、地図から戦略的な選択肢を読み取る方法、チームで更新する際の注意点まで解説します。未来を正確に予言する図ではなく、前提を見える形にして対話する道具として使うことが大切です。
この記事を読むと次のことがわかります
ワードリーマップは価値連鎖と進化段階を一枚に重ねる
ワードリーマップは、縦方向に利用者から見た可視性、横方向に要素の進化を置きます。上側には利用者が直接認識するニーズやサービスがあり、それを支える要素を依存関係に沿って下へつなぎます。
同じ要素を横方向の進化段階へ配置すると、利用者に近いかどうかと、市場でどれほど成熟しているかを同時に見られます。単なる部品一覧や業務フローとは異なる視点です。
ワードリーマップでは、事業上の価値が高い要素を右上へ置くといった採点はしません。縦位置は利用者からどれほど見えるか、横位置は進化の状態です。重要度を表す二軸マトリクスと混同すると、依存関係と変化が読めなくなります。
進化段階は技術の性能ランキングでもありません。成熟した電力や通信は革新的でないように見えても、多くのサービスを支える重要な基盤です。右側にあるから軽視するのではなく、安定して利用できる形へ任せる発想を持ちます。
地図上の線は、価値を届けるための依存を表します。線が多く一点へ集中する要素は、障害時の影響や変更待ちが大きい可能性があります。進化位置だけでなく、依存の集中も戦略上の観察点になります。
SWOT分析が強みや機会を整理し、ビジネスモデルキャンバスが事業の構成要素を俯瞰するのに対し、ワードリーマップは依存関係と進化による動きを扱います。どれか一つで戦略全体を完結させず、問いに応じて組み合わせます。
地図の起点は自社の製品ではなく利用者のニーズに置く
最初に「誰が、何を必要としているか」を決めます。オンライン予約サービスなら、事業者の売上ではなく、利用者が希望日時に迷わず予約できることなど、具体的なニーズを起点にします。
自社が作りたい機能から始めると、その機能が必要だという前提を地図へ埋め込んでしまいます。利用者とニーズを固定することで、別の提供方法も比較できます。
縦方向は価値を届けるための依存関係を表す
利用者のニーズを満たすサービス、そのサービスに必要な機能、さらに機能を支えるデータや基盤を上から下へつなぎます。上の要素が下の要素に依存する関係です。
組織図の上下関係や処理の時系列ではありません。部門が違っても同じ価値連鎖にあれば接続し、同じ部門の仕事でも対象ニーズに関係しなければ最初の地図から外します。
横方向は要素が市場で進化する位置を示す
進化は、創生、特注、製品・レンタル、コモディティ・ユーティリティーの四段階で捉えます。左側ほど新しく不確実で、右側ほど標準化され、入手方法や比較基準が整っています。
時間がたてば多くの要素は左から右へ進みます。ただし、単に古い技術だから右、新しい技術だから左とは限りません。利用者の理解、市場の供給、競争のあり方から位置を考えます。
一枚の地図は特定の状況について立てた仮説である
同じ技術でも、業界や利用目的が違えば進化位置は変わる可能性があります。ある企業には一般的な製品でも、厳しい規制や特殊な性能が必要な企業には特注領域かもしれません。
そのため、地図を正解として配布するのではなく、配置理由を話せる仮説として扱います。意見が割れた要素は、無理に一点へ決めず、調査が必要な前提として記録します。
利用者のニーズから5つの手順で最初の地図を作る
最初の地図は、対象を小さくし、紙やホワイトボードで作るだけでも十分です。複雑な事業全体を一度に描くより、一つの利用者ニーズと一つの判断テーマへ絞ります。
例として、社内の営業担当者が外出先から最新の提案資料を安全に使える仕組みを考えます。地図を作る目的は、資料管理のどこを自社で改善し、どこを既製サービスへ任せるかを考えることです。
要素名は、担当部署や製品名ではなく能力で書くと比較しやすくなります。「情報システム部」ではなく「本人認証」、「A社製品」ではなく「文書保管」と置けば、別の実現方法を検討できます。
進化位置に迷うときは、普及率だけでなく、利用者が何を求めるか理解されているか、提供者を比較できるか、失敗の種類が予測できるかを確認します。予測可能性が高まり、価格競争や標準化が進むほど右寄りです。
オンライン会議で作る場合は、付箋一枚に要素名と配置理由を一つ書きます。参加者が同時に大量の要素を置くより、価値連鎖を先に合意し、その後に横位置を動かす方が議論を追いやすくなります。
手順1は利用者と満たしたいニーズを一文で定める
利用者を「社員」のように広くせず、「外出先で提案する営業担当者」まで具体化します。ニーズは「クラウドを導入する」ではなく、「承認済みの最新資料をすぐ提示できる」と表します。
技術名をニーズへ入れると、解決策を先に決めることになります。利用者が得たい結果へ言い換え、関係者が同じ場面を想像できるか確認します。
手順2はニーズを支える要素を依存順につなぐ
最新資料の提示には、資料検索、版管理、アクセス制御、認証、端末、通信などが必要です。まず5～10要素ほど挙げ、どの要素がなければ上の要素を提供できないかを線で結びます。
細部をすべて描くと地図が読めなくなります。今回の判断に影響しない一般的な部品はまとめ、投資や差別化を議論したい要素は分けます。
手順3は特徴を照らして各要素の進化位置を決める
創生は前例が少なく試行錯誤が必要な領域、特注は理解が進んだものの個別開発が多い領域です。製品・レンタルでは比較可能な製品やサービスがあり、コモディティー・ユーティリティーでは標準化され必要量を容易に利用できます。
営業資料固有の承認ルールは特注寄りでも、認証基盤やオンラインストレージは製品またはユーティリティー寄りかもしれません。知名度ではなく、その用途での供給と差別化余地を見ます。
手順4と5は移動方向を書き込み前提を言葉にする
市場の標準化、法規制、利用者の期待、価格低下などにより位置が動きそうな要素へ矢印を付けます。現在位置だけでなく、変化の方向を見ることで、今は内製していても将来は購入へ移す判断ができます。
最後に、配置理由と確信度を短く添えます。「競合各社が同機能を提供」「特殊要件のため既製品では不足」などです。根拠のない位置ほど、次に調べるべき論点になります。
地図から内製・購入・探索の選択肢を読み取る
地図が完成しても、左側をすべて内製し、右側をすべて外注すればよいわけではありません。利用者への価値、競争上の差、切り替えコスト、規制、能力を合わせて判断します。
地図の役割は結論を自動で出すことではなく、異なる性質の要素へ同じ管理方法を当てはめていないかを見つけることです。探索領域と安定運用領域では、予算や評価の考え方も変わります。
内製か購入かを判断するときは、現在の総費用だけでなく、変更速度と学習の蓄積も見ます。差別化領域を外部へ任せると、短期費用は下がっても利用者から得た知識が社内に残りにくい場合があります。
右側の要素では、標準から外れた独自要件を減らせないか検討します。過去の事情で残ったカスタマイズが製品更新を妨げているなら、業務側を標準へ合わせることも戦略的な選択です。
左側の実験が成功し、利用方法や要件が理解されてきたら、特定チームの職人技に留めず、再現可能な仕組みへ移します。文書化、インターフェース、運用責任を整えることで、進化に合わせた管理へ変えられます。
地図から複数の選択肢が出たら、費用だけで順位を決めず、前提が外れたときの損失も比べます。小さく戻せる実験と、移行後に戻しにくい基盤変更を分けると、意思決定の順番を組み立てやすくなります。
右側の成熟要素は共通化と購入の余地を探る
市場で標準化された要素を各チームが個別開発しているなら、既製サービスの利用や社内共通基盤への統合を検討できます。そこへ割いている人員を、利用者価値に近い課題へ移せるかもしれません。
ただし、料金、移行、停止時の影響、データ移転性を確認します。成熟していることは、特定ベンダーへ無条件に依存してよいという意味ではありません。
左側の不確実な要素は小さな探索として扱う
創生や特注の領域では、要件を最初に固定して大規模発注するより、仮説を小さく試す方が向いています。成功率だけでなく、利用者について何を学べたかを評価します。
探索対象を既存の安定運用と同じ納期・稼働率で管理すると、試行が難しくなります。実験の上限時間と予算、止める条件を決め、学習を早く得る設計にします。
価値に近く差別化できる要素へ能力を集める
利用者から見えやすく、競争上の違いを作れる要素は、外部へ任せる場合でも社内に判断能力を残したい領域です。顧客理解、優先順位、品質基準まで委託すると、改善の主導権を失う可能性があります。
一方、価値に近い要素でも市場で同質化しているなら、独自開発を続ける理由を問い直します。地図上の位置と事業上の重要性を別々に確認します。
要素の移動を見越して出口を準備する
現在は自社開発が必要でも、市場が成熟すれば既製品へ切り替えられることがあります。データ形式、インターフェース、責任範囲を分離しておくと、後の移行を進めやすくなります。
反対に、外部サービスが自社の差別化を制約し始めた場合は、代替手段や内製能力が必要です。現在の選択だけでなく、進化した後にどう動くかを地図上で話します。
地図を対話と検証の道具として更新する
ワードリーマップは、作成者の頭の中だけで完成させるより、異なる立場の人と議論することで価値が高まります。営業、開発、運用、調達などが持つ事実を重ねると、隠れていた依存や前提が見つかります。
一方で、精密な座標を決める会議にすると時間を消費します。意思決定に影響する違いへ集中し、配置の細かな誤差より、なぜそう考えたかを残します。
ワークショップでは、最初に地図から決めたいことを掲示します。参加者が別々の問題を解こうとすると、要素を増やす議論ばかりになり、どの配置差が結論を変えるのかわからなくなります。
役職の高い人が作った地図へ同意を求める形では、現場の事実が出にくくなります。最初に各自で位置を置き、違いを比べる方法なら、暗黙の前提を言葉にしやすくなります。
地図を社外へ共有する場合は、競争上の仮説やシステム依存が含まれる点に注意します。公開用には抽象度を上げ、社内版では根拠と行動を詳しく残すなど、利用範囲を分けます。
ファシリテーターは自分の地図へ誘導せず、「この要素がなくても上の価値を届けられるか」「代替手段は市場にあるか」と問いかけます。配置理由を参加者自身が説明することで、地図が共同の思考材料になります。
最初は一つの判断と10要素程度に範囲を絞る
「会社のデジタル戦略」のような広いテーマでは、要素が増えすぎます。「顧客問い合わせの初回回答を短くするため、どこへ投資するか」のように判断を限定します。
主要要素だけで粗い地図を作り、議論に必要になった部分を分解します。細かさは見栄えではなく、選択肢が変わるかどうかで決めます。
配置が割れた箇所を調査課題へ変える
ある機能を特注と見る人と製品化済みと見る人がいれば、市場調査や利用実績が不足しています。議論で勝敗を決めず、候補製品、価格、導入例、特殊要件を確認します。
意見の差は、部門ごとに見ている利用者や用途が違うことも示します。その場合は地図を分けるか、対象ニーズをより明確にします。
地図から選んだ行動と確認指標を結び付ける
購入候補を調べる、試作品を作る、共通基盤へ移すなど、次の行動を一つずつ担当と期限へ落とします。地図を描いて納得しただけでは、投資配分は変わりません。
行動後は、利用者の待ち時間、開発工数、切り替えコスト、得られた学びなどを確認します。予想と違えば、地図の位置や依存関係を更新します。
定期更新より前提が変わったときに描き直す
月例で全要素を動かす必要はありません。新規参入、価格変化、規制、利用者行動、新技術など、重要な前提が変わったときに見直します。
古い地図を残しておくと、当時の判断と変化を比べられます。地図の美しさより、どの仮説が外れ、次の意思決定へ何を反映したかを共有することが重要です。
地図にした前提から技術投資の会話を始めよう
ワードリーマッピングは、利用者のニーズから価値連鎖を描き、各要素を創生、特注、製品・レンタル、コモディティー・ユーティリティーの進化段階へ配置するフレームワークです。
地図を作るときは、一つの利用者ニーズと判断テーマへ絞り、依存要素をつなぎ、進化位置と移動方向を置きます。位置は事実ではなく仮説なので、配置理由と確信度を共有します。
成熟要素の共通化、不確実な要素の小さな探索、差別化領域への能力配分などを検討し、具体的な行動へつなげます。まず身近なサービスを10要素ほどで描き、意見が割れる場所を見つけるところから始めてみましょう。
今回のポイント
