公式スキル · 経営戦略

ワードリーマップ

v1.0.1・2026年11月4日更新

利用者のニーズを起点に、要素を見えやすさと進化の段階で地図に置き、どこを作り、買い、借り、外注するかの打ち手を決める。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• 何を自社で作り、何を買う、借りる、外注するかを決めるとき
• どこで差をつけ、どこで解決済みの問題に力を使っているかを見つけるとき
• 戦略やロードマップを、市場と技術の進化と照らし合わせるとき

AI に渡すもの

• 範囲: 事業、商品、サービス
• 利用者とそのニーズ
• 要素
• 進化の根拠

できあがるもの

要素の表、テキストで描いた地図、地図からわかること、担当と最初の一歩つきの打ち手、確かめる前提。

手順

1. 起点を決める 利用者（1つか少数の種類）と、そのニーズを利用者の言葉で書き、いちばん上に置く。「売上を伸ばす」のような会社の目標は、利用者のニーズではない。
2. バリューチェーンを書き出す ニーズを満たすのに必要な要素を並べ、次にそれぞれが頼っている要素を、土台のインフラにたどり着くまで書く。見えやすさの順に並べる。利用者が直接目にするものは上に、まったく目にしないものは下に。頼る関係は「A には B が要る」と書く。
3. 各要素を進化の軸に置く 4つの段階を使う。誕生（新しく、珍しく、先が読めず、すぐ変わる）、特注（わかっている人が少なく、1件ごとに作る）、製品（レンタルを含む。競合する製品がいくつもあり、形が定まってきた）、コモディティ（ユーティリティを含む。標準化され、どこでも手に入り、ユーティリティとして、または大量に買う）。置いた根拠を1行ずつ書く。同じ要素でも市場によって段階が違うことがある。この市場のいまの姿で置く。
4. 動きと慣性を書き込む 要素ごとに、根拠から、右へ動いているか、どれくらいの速さかを書く。慣性も書く。会社、仕入れ先、顧客が、要素の動きに抵抗しているところ（契約、技能、過去の投資、習慣）。
5. 地図を描く 要素の表と、テキストで描いた地図を出す。進化の段階を左から右への列に、見えやすさを上から下への行にし、頼る関係を矢印で、予想される動きを「>」で示す。チャットの画面で読める大きさにする。正しいのは表のほう。
6. やり方のずれを読み取る 要素ごとに、いまの扱い方と照らし合わせる。コモディティなのに自社で作っている、誕生の段階なのに外注したり細かく決めすぎたりしている、製品の段階なのに標準がないまま進めている。ワードリーのドクトリンには「ユーザーのニーズに集中する」「場に合った方法を使う」があり、この手順はその2つを当てはめる。
7. 打ち手を選ぶ 要素ごとに打ち手を1つ。作って探る（誕生）、作るか特注で頼む（特注）、買うか借りる（製品）、ユーティリティとして使う（コモディティ）。役に立つなら、公開する、提携する、見守る。そのうえで、戦略の打ち手を2〜4つ選ぶ。どこで差をつけるか、何を工業化するか仕入れ先に任せるか、どの変化に備えるか、どの慣性を取り除くか。どの打ち手にも担当と最初の一歩をつける。
8. 前提と、その確かめ方を並べる 「[要確認: ...]」と書いた置き場所と、予想した動きは、すべて問いにし、だれが答えるかを書く。地図は議論のためのもの。置き場所について、チームに異論を出してもらう。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: wardley-map
description: 事業や商品のワードリーマップ（Wardley Map）をつくる。起点は利用者とそのニーズ。その下に、利用者からの見えやすさの順に要素のバリューチェーンを並べ、各要素を進化の軸（誕生、特注、製品・レンタル、コモディティ・ユーティリティ）に根拠つきで置き、動きと慣性を書き、そこから導かれる打ち手（作る、買う、借りる、外注する、公開する、見守る）を決める。出力は要素の表、テキストで描いた地図、担当つきの打ち手の一覧。ワードリーマップ、バリューチェーンのマッピング、システム全体での内製か購入か、どこで差をつけるか、何を外注するか、市場や技術がどう進化するかを頼まれたときに使う。
license: CC BY-SA 4.0. The method is Simon Wardley's (Wardley Maps, CC BY-SA 4.0).
---

# ワードリーマップ

ワードリーマップは、事業が何でできていて、それぞれの部分がどこまで成熟しているかを示す。チームは、どこを作り、どこを買うか、何が変わろうとしているかを見られる。方法を考えたのはサイモン・ワードリーで、著書『Wardley Maps』にまとめ、Medium でクリエイティブ・コモンズ 表示・継承 4.0 国際ライセンス（CC BY-SA 4.0）のもとで公開している。地図は利用者とそのニーズから始まる。そのニーズを満たす要素を、見えるものから見えないものへ鎖のように並べ（縦軸）、各要素を、誕生から特注、製品を経てコモディティへと進む進化の軸に置く（横軸）。要素は、需要と供給の競争によって時間とともに右へ動く。このスキルは、事業の担当者と一緒に作業する AI のために、この方法を手順にまとめた私たちの要約で、要素の表、テキストの地図、打ち手を出す。もとの方法と同じく CC BY-SA 4.0 で公開している。LICENSE.txt を参照。

## 使う場面

- 商品や業務の全体を見て、何を自社で作り、何を買う、借りる、外注するかを決めるとき。
- 会社がどこで差をつけるべきか、どこで解決済みの問題に力を使っているかを見つけるとき。
- 戦略やロードマップを、市場と技術の進化と照らし合わせるとき。
- 込み入ったシステムを、技術に詳しくない決裁者に1枚で説明するとき。
- 業界の利益の水準を見るときには使わない（five-forces-analysis を使う）。社内の活動をコストで並べるときにも使わない（value-chain-analysis を使う）。戦略の方法そのものを選ぶなら strategy-approach-picker を使う。

## 用意するもの

- 範囲: どの事業、商品、サービスか、だれのためか。
- 利用者とそのニーズ。はっきりしなければ一度だけ聞く。地図の起点は利用者で、会社の目標ではない。
- 要素: ニーズを満たすために会社がしていること、動かしているもの、買っているもの（活動、やり方、データ、知識、技術）。ふつうは依頼した人のチームが知っている。AI が一覧の案を出して確かめる。
- 進化の根拠: 供給する会社がいくつあるか、製品として売られているか、従量のユーティリティとして売られているか、どれだけ標準化されているか、どれだけ速く変わっているか。推測を事実のように扱って要素を置かない。「[要確認: 根拠]」と書く。
- あれば、地図で判断したい決定。

## 手順

1. **起点を決める。** 利用者（1つか少数の種類）と、そのニーズを利用者の言葉で書き、いちばん上に置く。「売上を伸ばす」のような会社の目標は、利用者のニーズではない。
2. **バリューチェーンを書き出す。** ニーズを満たすのに必要な要素を並べ、次にそれぞれが頼っている要素を、土台のインフラにたどり着くまで書く。見えやすさの順に並べる。利用者が直接目にするものは上に、まったく目にしないものは下に。頼る関係は「A には B が要る」と書く。
3. **各要素を進化の軸に置く。** 4つの段階を使う。誕生（新しく、珍しく、先が読めず、すぐ変わる）、特注（わかっている人が少なく、1件ごとに作る）、製品（レンタルを含む。競合する製品がいくつもあり、形が定まってきた）、コモディティ（ユーティリティを含む。標準化され、どこでも手に入り、ユーティリティとして、または大量に買う）。置いた根拠を1行ずつ書く。同じ要素でも市場によって段階が違うことがある。この市場のいまの姿で置く。
4. **動きと慣性を書き込む。** 要素ごとに、根拠から、右へ動いているか、どれくらいの速さかを書く。慣性も書く。会社、仕入れ先、顧客が、要素の動きに抵抗しているところ（契約、技能、過去の投資、習慣）。
5. **地図を描く。** 要素の表と、テキストで描いた地図を出す。進化の段階を左から右への列に、見えやすさを上から下への行にし、頼る関係を矢印で、予想される動きを「>」で示す。チャットの画面で読める大きさにする。正しいのは表のほう。
6. **やり方のずれを読み取る。** 要素ごとに、いまの扱い方と照らし合わせる。コモディティなのに自社で作っている、誕生の段階なのに外注したり細かく決めすぎたりしている、製品の段階なのに標準がないまま進めている。ワードリーのドクトリンには「ユーザーのニーズに集中する」「場に合った方法を使う」があり、この手順はその2つを当てはめる。
7. **打ち手を選ぶ。** 要素ごとに打ち手を1つ。作って探る（誕生）、作るか特注で頼む（特注）、買うか借りる（製品）、ユーティリティとして使う（コモディティ）。役に立つなら、公開する、提携する、見守る。そのうえで、戦略の打ち手を2〜4つ選ぶ。どこで差をつけるか、何を工業化するか仕入れ先に任せるか、どの変化に備えるか、どの慣性を取り除くか。どの打ち手にも担当と最初の一歩をつける。
8. **前提と、その確かめ方を並べる。** 「[要確認: ...]」と書いた置き場所と、予想した動きは、すべて問いにし、だれが答えるかを書く。地図は議論のためのもの。置き場所について、チームに異論を出してもらう。

## 出力の形式

````markdown
# ワードリーマップ: [範囲] · [日付]
**利用者:** [利用者] · **ニーズ:** [ニーズ] · **判断したい決定:** [決定]

## 要素
| 要素 | 見えやすさ（1 = いちばん上） | 頼っているもの | 進化の段階 | 根拠 | 動き / 慣性 |
|---|---|---|---|---|---|

## 地図
```text
            誕生        特注        製品（＋レンタル）   コモディティ（＋ユーティリティ）
見える    [利用者のニーズ]
   |      ...
見えない  ...
```

## 地図からわかること
- [やり方のずれ、差をつけているところ、脅威]

## 打ち手
| 要素か領域 | 打ち手 | 理由（地図から） | 担当 | 最初の一歩 |
|---|---|---|---|---|

## 確かめる前提
- [要確認: 置き場所か動き] — 答える人: [名前]
````

## 例

**入力:** 「うちの事業を地図にしてください。国内の高校生向けに、オンラインの数学の個別指導をしています。利用者は、お金を払う保護者と、授業を受ける生徒。保護者のニーズは、子どもが学年末の数学の試験に通ること。生徒と講師の組み合わせは自社のルールで決めていて（去年、社内で作った）、授業の予約は市販の予約サービスを使い、授業は分単位で払うビデオ通話サービスで行い、カード決済は決済代行会社を通し、サーバーはクラウドを使っている。講師は自社の面接と試験で選んでいて、保護者がレビューでよく触れてくれる。保護者には毎週、講師が手で書いた学習レポートを送っている。これをやっている競合は少なく、形式はいまも毎月変えている。3年前に自社でホワイトボードのツールを作り、エンジニア2人が保守している。いまはホワイトボードの製品がいくつもある。一部の競合が、AI の練習用チューターを試し始めた。決めたいのは、来年4人のエンジニアをどこに使うか。」

**出力:**

````markdown
# ワードリーマップ: オンラインの数学の個別指導 · 来年のエンジニアの計画
**利用者:** 保護者（払う）、生徒（受ける） · **ニーズ:** 子どもが学年末の数学の試験に通る · **判断したい決定:** 来年、4人のエンジニアをどこに使うか

## 要素
| 要素 | 見えやすさ（1 = いちばん上） | 頼っているもの | 進化の段階 | 根拠 | 動き / 慣性 |
|---|---|---|---|---|---|
| 毎週の学習レポート | 1 | 講師のメモ | 特注（初期） | 出している競合は少ない。形式はいまも毎月変わる | [要確認: 動き] |
| 講師の選考 | 2 | 面接と試験 | 特注 | 自社の手順。保護者がレビューで触れている | [要確認: 動き] |
| 講師との組み合わせ | 2 | [要確認: 頼っているもの] | 特注 | 自社のルール、去年作った | [要確認: 組み合わせの製品はあるか] |
| 授業の予約 | 3 | [要確認: 頼っているもの] | 製品 | 市販のものを買っている | [要確認: 動き] |
| ホワイトボード | 3 | [要確認: 頼っているもの] | 製品 | ホワイトボードの製品がいくつもある | 慣性: 自社製で、エンジニア2人が保守している |
| ビデオ通話 | 4 | ビデオ通話サービス | コモディティ（＋ユーティリティ） | 分単位で払っている | [要確認: 動き] |
| カード決済 | 4 | 決済代行会社 | コモディティ（＋ユーティリティ） | 決済代行会社から買っている | [要確認: 動き] |
| クラウドのサーバー | 5 | クラウド事業者 | コモディティ（＋ユーティリティ） | クラウド事業者から買っている | [要確認: 動き] |
| AI の練習用チューター | 2 | [要確認] | 誕生 | 競合が試している段階で、定着していない | 右へ動いている [要確認: 速さ] |

## 地図
```text
            誕生          特注                製品（＋レンタル）   コモディティ（＋ユーティリティ）
見える    保護者: 子どもが試験に通る
   |                      学習レポート
   |      AI チューター >  選考  組み合わせ
   |                                          予約  ホワイトボード*
   |                                                               ビデオ通話  決済
見えない                                                           クラウドのサーバー
* 製品の段階にある要素を自社で作っている
```

## 地図からわかること
- 保護者に見えている差は、特注の段階にある。選考と学習レポート。
- ホワイトボードは製品の段階の要素なのに、社内で作って保守している。4人のエンジニアのうち2人が、解決済みの問題に張りついている。
- AI の練習用チューターは誕生の段階にある。右へ動けば、学習レポートが応えているのと同じニーズに触れる。

## 打ち手
| 要素か領域 | 打ち手 | 理由（地図から） | 担当 | 最初の一歩 |
|---|---|---|---|---|
| ホワイトボード | 製品に替える | 製品の段階。エンジニア2人が空く | [担当: 要確認] | ホワイトボードの製品2つを、講師6人で30日試す |
| 学習レポート | 投資する: 作り込み、標準化する | 見えている差で、まだ特注 | [担当: 要確認] | 形式を1つに決め、保護者の継続率を測る [要確認: 継続のデータ] |
| AI の練習用チューター | 安く探り、見守る | 誕生の段階で、先が読めない | [担当: 要確認] | 少数の生徒で小さな実験をする |
| 講師の選考 | 社内に残す | 保護者が触れている差 | [担当: 要確認] | 手順を書き残す |

## 確かめる前提
- 個別指導向けの組み合わせの製品があるか — 答える人: [名前]
- 競合の間で、AI の練習用チューターがどれくらいの速さで広がっているか — 答える人: [名前]
- 自社製のホワイトボードをやめたとき、いまの授業で失うものは何か — 答える人: [名前]
````

## 送る前のチェック

- [ ] 起点は会社の目標ではなく、利用者とそのニーズで、利用者の言葉で書いた。
- [ ] どの要素にも、見えやすさの位置、頼っているもの、進化の段階、1行の根拠か「[要確認: ...]」がある。
- [ ] 進化の段階に、4つの名前を使った: 誕生、特注、製品（＋レンタル）、コモディティ（＋ユーティリティ）。
- [ ] 入力が裏づけるところに、動きと慣性を書いた。
- [ ] 打ち手は、持ち込んだ施策の一覧からではなく、地図（段階と見えやすさ）から導いた。
- [ ] どの打ち手にも担当と最初の一歩がある。
- [ ] スキルを共有したり変えたりするときも、サイモン・ワードリーの名前と CC BY-SA 4.0 のライセンスを残す。

## よくある失敗

- 組織図や業務フローを描く。地図に置くのは、見えやすさと進化で並べた要素。
- 大事に感じるかどうかで要素を置く。置き場所は、その要素の市場がどこまで進化しているかで決める。
- 地図をできあがったものとして扱う。値打ちは置き場所をめぐる議論にあるので、チームと描き直す。
- すべてに同じ打ち手を当てる（「自社のプラットフォームを作る」）。段階が違えば、合うやり方も違う。
- 慣性を見落とす。会社自身の慣性も含めて。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.1 · 2026年11月4日 · Example: the last assumption asks what current lessons would lose without the in-house whiteboard, instead of presuming lesson recordings the input never mentions.
• v1.0.0 · 2026年11月4日 · First release.