あおい
「予約システムは内製すべきか、購入すべきか？」は、一つの判断に聞こえます。しかし予約サービスは、顧客体験、予約枠のルール、カレンダー情報、通知、インフラなど、異なる要素で成り立っています。全体を一つの部品として扱うと、必要以上に内製したり、サービスの強みとなる部分に対応できない製品を選んだりしかねません。
Wardley Map（ワードリーマップ）は、これらの要素を分け、相互の関係の中に配置します。この記事では、架空の設備修理サービスを例に、どこで試行錯誤し、どこで既存製品を比較し、選択前に何を調べる必要があるのかを考えます。
二つの軸を正しく読む
Simon Wardleyが考案したWardley Mappingは、利用者のニーズと、それを支える機能や能力をつなげる手法です。縦方向には価値連鎖と、各要素が利用者からどれだけ見えるかを表します。横方向には進化の段階を表し、一般にGenesis、Custom、Product、Commodityというラベルを使います。Learn Wardley Mappingの解説では、配置と依存関係によってマップを作る方法が説明されています。
進化の軸は、開発の予定表ではありません。要素を右へ動かしても、来月完成するという意味にはなりません。また、縦軸の下にあるからといって重要でないわけでもありません。インフラが停止すれば、サービス全体が動かなくなることもあります。
戦略目標を整理する戦略マップ（英語）とも異なります。ここで考えるのは、サービスを構成する機能が利用者のニーズとどう結び付き、その環境でどれほど確立したものになっているかです。
修理を依頼する顧客のニーズから始める
例として、業務用厨房設備の訪問修理を手配するサービスを考えます。利用者は、都合のよい時間に適切な技術者に来てもらいたい飲食店の運営者です。直接のニーズは「当社の予約プラットフォームを使うこと」ではなく、不具合に実際に対応できる訪問修理を手配することです。
そのニーズをボードの上部に書きます。下には、それを満たすために必要なものを並べます。予約の利用体験、設備や不具合の情報、作業内容と技術者の能力を照合する方法、空いている訪問枠、運営者が理解できる確認通知です。
次に、それぞれが何に依存するかを考えます。空き枠を知るにはカレンダー情報が必要です。作業の割り当てには設備の種類と技術者のスキルが必要です。確認には通知サービスが必要です。デジタルサービスを動かす計算基盤も必要ですが、顧客は通常それに直接触れません。
一つの機能が別の機能を必要とするときだけ線を引きます。同じ部署が担当しているだけでは、依存関係にはなりません。データベースやAPIを一つずつ議論し始めたら、今回の問いに戻りましょう。予約サービスのどの部分を開発し、どの部分を外部から調達するかが検討の範囲です。
慣れではなく根拠に基づいて要素を置く
この例では、予約枠管理には確立した製品がいくつか見つかっている一方、特殊な設備故障を適切な担当者へ振り分ける方法は試行中だとします。これは説明のために置いた前提であり、実在する製品の市場調査ではありません。
| 要素 | 例での配置 | その位置に置く理由 | 実際のチームが必要とする根拠 |
|---|---|---|---|
| 試行中の故障振り分け方法 | Genesis（発生） | 提案した方法は新しく、有用性がまだ分からない | 既存の代替手段と、方法が機能するかを確かめる試験 |
| 修理業務に特化した予約体験 | Custom（特注） | この例では特殊な依頼に合わせた流れが必要 | 実際の顧客の行動と、利用可能な業務フローとの比較 |
| 予約枠管理 | Product（製品） | 特徴を比較できる、確立した製品があるという前提 | 現在の製品機能、制約、連携に必要な条件 |
| 顧客への通知 | Product（製品） | 基本的なニーズを満たす設定可能なサービスがあるという前提 | 配信の動作、アクセシビリティ、運用との適合性、提供条件 |
| 基本的な計算資源 | CommodityまたはUtility（コモディティ・標準化されたサービス型） | この例では標準化された基盤機能として扱う | サービス要件、利用可能な提供形態、利用上の制約 |
予約体験は顧客に近いので比較的上に置き、それを支える機能を下に置いて依存関係を結びます。表の五つの行を、ばらばらの点にするだけでは不十分です。要素間の関係があるからこそ、調達について具体的に話せます。
「自分たちで開発した」ことは、Customに属する根拠にはなりません。広く製品や標準化されたサービス型で提供されている機能を、独自実装で維持していることもあります。逆に、専門的な作業を外注していても、その機能が標準化された製品になるわけではありません。
配置に合意できない場合は、それぞれの理由を添えます。「予約エンジン」を通常の枠の割り当てと特殊案件の振り分けに分けると、食い違いが理解できるかもしれません。大まかなラベル一つの中に、性質の違う要素が隠れている場合があります。
内製か購入か、という問いを具体化する
最初の案は、予約システム全体を内製することでした。マップを使うと、より絞った検討ができます。通常の予約枠管理は外部から調達しつつ、修理特有の顧客体験を作り、未知の振り分け方法を試す余地を残せないか、という問いです。
これは検証する問いであり、自動的に導かれる推奨案ではありません。予約製品の流れが変更しにくかったり、顧客が答えられない情報を要求したり、重要な機能の変更を難しくしたりする可能性があります。マップ上の位置だけでは、適合性、運用費、契約、セキュリティ要件、切り替えに必要な作業の確認は省けません。
Simon Wardleyの初期のマップについての記述も、業務システムを一塊として扱わず、進化段階の異なる要素に分けて考える価値を示しています。修理サービスのチームは、その過去の事例の結論をそのまま借りずに、ものの見方を取り入れられます。
二つの具体案を比べる
案Aは、予約体験、予約枠管理、通知をまとめて開発する方法です。チームはそれらのつながりを制御できますが、他から調達できるかもしれない機能も、複数維持する責任を持ちます。
案Bは、予約枠管理の製品を使い、その周りに必要最小限の顧客向けの部分を作る方法です。保守する範囲を減らせる可能性があります。ただし、その製品が必要な予約ルールを扱え、顧客体験に必要な情報を取り出せることが条件です。
案Bは、都合のよいデモではなく難しい予約で試します。不具合がはっきりしない飲食店、対応できる設備が限られる技術者、追加情報によって変更が必要になる訪問予約を使いましょう。調達した機能でその流れを扱えないなら、設定の問題なのか、接続手段の不足なのか、根本的に合わないのかを見極めます。
Boardmixでサービスのマップを描く
Boardmixを開き、空白のボードを作成します。横軸に「進化」と書き、Genesis、Custom、Product、Commodityの四段階に分けます。縦には「利用者からの見えやすさ」と書き、上ほど見えやすい配置にします。
- 「適切な訪問修理の手配」というニーズの上に「飲食店運営者」を置きます。機能を追加しても、この起点が見えるようにします。
- ニーズの下に「修理予約体験」を置き、「故障の振り分け」と「予約枠管理」につなげます。
- 例に挙げた五つの要素を仮の位置に配置します。色がなくても分かるように、点には短いラベルを添えます。
- このサービスでは訪問の確認も含むので、予約体験から通知へ線を引きます。計算資源への依存関係は、マップの下部に示します。
- 故障の振り分けの横に「試行中の方法—既存の代替手段と比較」と書きます。二つの調達案は、機能の一部と誤解されないよう、マップの外側に置きます。
現状と提案を分けておきます。予約枠管理の外部調達を検討するなら、該当する作図領域を複製し、二つ目は案であると明記します。元のマップの点を説明なしに動かすと、提案がすでに実現している事実に見えてしまいます。
マップだけでは決められないことを理解する
マップは、最適な提供元を計算したり、投資収益率を証明したり、機能がいつコモディティ化するかを予測したりするものではありません。分析らしく見せるためだけに、細かい座標や予測日を加えるのは避けます。根拠のない小数点より、理由を説明できる大まかな位置の方が役立ちます。
修理サービスにとって目の前の問いは、顧客体験を損なわずに、通常の予約枠管理と特殊案件の判断ロジックを分けられるかです。小さな連携実験で分かる部分もあれば、顧客の行動を観察して分かる部分もあります。マップは、それらを組み合わせて調べる理由を見えるようにします。
予約製品が適合すれば、まだ不確かな修理体験の部分に、より多くの力を使えます。合わなかった場合も、「購入に失敗したから全部内製する」と議論を戻すのではなく、どの依存関係に問題があるのかを示せます。
