lean-ux-canvas

目的

プロダクトマネージャーが Jeff Gothelf の Lean UX Canvas（v2） を作成できるようにガイドします。これは、取り組みを 実装するソリューション ではなく、解決すべきビジネス上の課題 を中心に捉える、1ページのファシリテーションツールです。これを使って、部門横断チームの認識を主要な前提にそろえ、検証可能な仮説を立て、理解の不足（課題、ユーザー、価値、そしてソリューションが機能する理由）を明らかにすることで、スプリントごとに学びが得られるようにします。

これはロードマップでも機能リストでもありません。前提を実験に変え、本格的な開発に踏み切る前に確かめるための 「保険」 です。このキャンバスによって、会話の焦点が アウトプット から アウトカム へと移り、チームがただ正しく作るだけでなく、正しいものを作れるようになります。

入力

特に役立つもの： 取り組みの対象となるビジネス上の課題、または提示されたソリューション案。キャンバスを使って、課題として捉え直します。 あると便利なもの： 既知のユーザー、これまでに得られたエビデンス、チームがすでに信じていること（表面化させるべき前提）。

呼び出し時に渡された内容（スキル名の後に入力されたテキスト、貼り付けられたコンテキスト、追記された ARGUMENTS: 行）は、すでに回答済みの内容として扱います。それを使用し、該当する項目については再度質問しないでください。

何も用意できていなくても大丈夫です。 このスキルは Box 1 から始めます。解決しようとしているビジネス上の課題は何ですか？

呼び出し例： Fill a Lean UX canvas: leadership wants 'an AI chatbot' — underlying problem seems to be support ticket volume growing 3x faster than the team.

主要なコンセプト

Lean UX Canvas とは？

Lean UX Canvas（v2） は、チームがソリューションではなくビジネス上の課題を中心に取り組みを捉えられるよう設計された、構造化された1ページのテンプレートです。部門横断チームの認識を以下の点でそろえます。

• どのような課題が存在するのか（そして、なぜ今それが重要なのか）
• 成功を示す測定可能なアウトカムは何か
• 誰の課題を解決するのか
• どのような前提を置いているのか
• まず何を学ぶ必要があるのか
• それらの前提を検証する実験は何か

由来： 『Lean UX』（O'Reilly、2013年）の著者である Jeff Gothelf が作成しました。バージョン 2 は、ビジネス上のアウトカムとユーザーのアウトカムをより明確にするためにリリースされました。

重要なポイント： このキャンバスは 保険 のような役割を果たします。構築を始める前に理解の不足を明らかにし、間違ったものにスプリントを費やすことを防ぎます。

---

キャンバスの構成（8つのボックス）

レイアウト（3列 × 3行）：

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │              │ 2. Business Outcomes  │
│                     │              │                       │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users            │  (tall box   │ 4. User Outcomes      │
│                     │   spanning   │    & Benefits         │
├─────────────────────┤   rows 1-2)  ├───────────────────────┤
│ 6. Hypotheses       │──────────────┤ 8. Least Work /       │
│                     │ 7. Learn     │    Experiments        │
│                     │    First     │                       │
└─────────────────────┴──────────────┴───────────────────────┘

8つのボックス（以下の順に記入）：

1. ビジネス上の課題 — 解決する価値のある課題が生まれたのは、世の中で何が変化したからですか？
2. ビジネス上のアウトカム — 成功を示す、測定可能な行動の変化は何ですか？
3. ユーザー — まずどのペルソナに焦点を当てるべきですか？
4. ユーザーのアウトカムとメリット — ユーザーがこれを求める理由は何ですか？どのようなメリットが得られますか？
5. ソリューション — 課題を解決し、ユーザーのニーズを満たす可能性のある機能や取り組みは何ですか？
6. 仮説 — ボックス 2〜5 の内容を組み合わせた、検証可能な前提（If/Then 形式）
7. まず何を学ぶことが最も重要ですか？ — 現時点で最もリスクの高い前提を1つ
8. 次に学ぶための最小限の作業は何ですか？ — その前提を検証または反証するための、最小限の実験

---

これが有効な理由

ソリューションではなく、課題を起点にする： 「X を作るべきだ」ではなく、「世の中で何が変化したのか？」から始めます。これにより、ソリューションありきの思考を防ぎます。

前提に基づく： 構築する前に仮説を明確にします。各専門分野の担当者が、それぞれのリスク（技術的な実現可能性、ユーザー価値、ビジネスとしての実行可能性）を表面化させます。

実験を重視する： リソースを投入する前に前提を検証します。大きな賭けよりも、小さな実験を重ねるほうが効果的です。

部門横断で認識をそろえる： 共有されたキャンバスによって共通言語が生まれ、全員が同じ理解の不足を把握できます。

---

主な違い（混同を避けるために）

ボックス 2（ビジネス上の成果）とボックス 4（ユーザーの成果）：

• ボックス 2： 測定可能な行動の変化（継続率、サイト滞在時間、平均注文額）
• ボックス 4： 目標、メリット、感情、共感（お金を節約する、昇進する、家族と過ごす）

ボックス 2 は指標です。ボックス 4 は人間に関するものです。

解決策（ボックス 5）は確約ではなく、仮説です： 解決策の候補（機能、ポリシー、さらにはビジネスモデルの変更）を挙げます。すべてを開発すると確約するのではなく、解決策の可能性を探ります。

仮説（ボックス 6）は検証可能です： 次のテンプレートを使います：「[解決策]を使って[ユーザー]が[メリット]を得られれば、[ビジネス上の成果]を達成できると考えます。」各仮説では、1 つの解決策に焦点を当てます。

---

アンチパターン（これは何ではないか）

• 機能一覧ではありません： 解決策はテストするアイデアであり、バックログではありません
• プロジェクト計画ではありません： キャンバスは学習の枠組みであり、提供までのスケジュールではありません
• 戦略の代わりではありません： キャンバスは戦略を実行するものであり、戦略を作るものではありません
• 一度限りの演習ではありません： 学びに応じて見直し、前提を更新します

---

使用するタイミング

✅ 次の場合に使用します：

• 新しい製品イニシアチブや機能に着手するとき
• 既存のプロジェクトを再検討するとき（間違ったものを作っている可能性がある場合）
• 前提や実験について、部門横断チームの認識を合わせるとき
• ディスカバリースプリントや MVP を計画するとき
• ステークホルダーが解決策ありきで考えていて（「X を作る必要がある」）、前提を明らかにする必要があるとき

❌ 次の場合は使用しないでください：

• 課題と解決策の検証がすでに済んでいるとき（実行に進みます）
• 戦術的なバグ修正や技術的負債への対応（学習が不要な場合）
• ステークホルダーが根拠にかかわらず解決策に固執しているとき（まず認識合わせを行います）

---

ファシリテーションの基準となる情報源

このスキルの既定の対話プロトコルとして、workshop-facilitation を使用します。

次の内容を定義しています：

• セッション開始時の案内と参加モード（ガイド付き、コンテキストの提示、最善の推測）
• 平易な言葉によるプロンプトを使った、一度に 1 つの質問を行う進め方
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 中断への対応と一時停止・再開の動作
• 意思決定の場面での番号付き推奨事項
• 通常の質問での番号付きクイック選択肢（必要に応じて Other (specify) を含める）

このファイルでは、ドメイン固有の評価内容を定義しています。競合する場合は、このファイルのドメインロジックに従ってください。

適用方法

全項目を記入できる構成には template.md を使用します。

この対話型スキルでは、順番に適応型の質問を 8 つ（キャンバスの各ボックスにつき 1 つ）行います。各ステップで、エージェントがガイダンス、例、選択肢を提示し、ボックスを適切に記入できるよう支援します。

---

ステップ 0：コンテキストを集める

エージェントが質問します：

Lean UX Canvas を記入する前に、コンテキストを集めましょう。次の情報を共有してください。

ビジネスのコンテキスト：

• ステークホルダーからの依頼、製品概要、またはイニシアチブの説明
• ビジネス指標（収益、解約率、成長目標、KPI）
• 戦略目標（OKR、ロードマップの優先事項）

ユーザーのコンテキスト：

• 顧客調査、ペルソナ、JTBD のインサイト
• ユーザーからのフィードバック、サポートチケット、解約の理由
• 競合分析、市場動向

次の情報を貼り付けられます：

• PRD または製品概要
• ステークホルダー向けメモ
• ユーザー調査の要約
• イニシアチブについて簡単に説明する

---

質問 1：ビジネス上の課題（ボックス 1）

エージェントが尋ねます：

解決しようとしている、ビジネスが抱える課題は何ですか？

以下について説明してください。

• 現状： ビジネスは現在、どのように価値を提供していますか？
• 何が変わりましたか： 市場の変化、競争上の脅威、顧客行動の変化、新しい提供チャネル
• なぜ重要ですか： なぜ現状では期待に応えられていないのですか？

良い例：

• 「モバイルのトラフィックがデスクトップを上回った後、チェックアウトのコンバージョン率が 15％低下しました。チェックアウトのフローはモバイル向けに設計されておらず、競合他社はワンタップでチェックアウトできます。」
• 「オンボーディングに 3 週間以上の手動設定が必要なため、エンタープライズ顧客が 6 か月後に解約しています。競合他社はセルフサービスのオンボーディングを提供しています。」

悪い例（曖昧すぎる）：

• 「収益を増やす必要があります」（何が変わったのかの背景がありません）
• 「ユーザーはもっと機能を求めています」（ビジネス上の課題が示されていません）

エージェントが 3 つの選択肢を提示します：

1. ビジネス上の課題を説明する — ［説明を貼り付けるか、入力してください］
2. ビジネス上の課題を特定するのを手伝ってほしい — ［エージェントが追加の質問をします：何が変わりましたか？ どの指標に影響していますか？ 競合他社は何をしていますか？］
3. ビジネス上の課題が何かわからない — ［まず skills/problem-statement/SKILL.md または skills/problem-framing-canvas/SKILL.md から始めることをエージェントが提案します］

ユーザーの回答： ［選択肢または説明］

エージェントが検証します： 何が変わったのか、そしてそれがなぜ課題を引き起こすのかが説明されていますか？ そうでなければ、明確にするための質問をします。

---

質問 2：ビジネス成果（ボックス 2）

エージェントが尋ねます：

ビジネス上の課題を解決できたと、どのように判断しますか？ 何を測定しますか？

測定可能な行動変化に注目してください（先行指標でもかまいません）。次のように考えてください。「解決策が機能した場合、人々の行動はどのように変わりますか？」

ビジネス成果の例：

• モバイルのチェックアウトコンバージョン率を 45％から 60％に引き上げる
• エンタープライズのオンボーディング時間を 3 週間から 3 日に短縮する
• 平均注文額を 50 ドルから 75 ドルに引き上げる
• カスタマーサポートへの問い合わせ件数を 30％削減する
• 無料から有料へのコンバージョン率を 5％から 10％に引き上げる

重要： ここは**ボックス 2（行動変化）**であり、ボックス 4（ユーザーのメリット／共感）ではありません。指標はここに記載します。感情はボックス 4 に記載します。

エージェントが 3 つの選択肢を提示します：

1. 具体的な指標を考えてある — ［ビジネス成果を記述してください］
2. 測定可能な成果を定義するのを手伝ってほしい — ［ビジネス上の課題に基づいて、エージェントが指標を提案します］
3. 遅行指標（収益、利益）しかない — ［そうした成果を予測する先行指標の特定をエージェントが支援します］

ユーザーの回答： ［選択肢または説明］

エージェントが検証します： 測定可能ですか？ 観察可能ですか？ 行動の変化を示していますか（単に「収益を増やす」ではありませんか）？

---

質問 3：ユーザー（ボックス 3）

エージェントが尋ねます：

まず注力すべきユーザーと顧客のタイプ（つまりペルソナ）は何ですか？

以下を検討してください。

• 誰が購入しますか？
• 誰が使用しますか？
• 誰が設定しますか？
• 誰が管理しますか？

重要な理由： チームはここを簡略化しがちです（「全員」など）。キャンバスでは、ユーザーについての共通のビジョンが必要です。そして、それは常に「顧客」とは限りません。

例：

• 「プロフェッショナルサービス（コンサルタント、会計士、弁護士）を営む中小企業のオーナー（従業員 1～10 人）」
• 「500 人以上の従業員向けに SSO を設定するエンタープライズ IT 管理者」
• 「週に 3 回以上テイクアウトを注文する、モバイル中心のミレニアル世代（25～35 歳）」

エージェントが 3 つの選択肢を提示します：

1. すでにペルソナがある — [skills/proto-persona/SKILL.md を参照するか、ペルソナを貼り付けてください］
2. ターゲットユーザーの特定を手伝ってほしい — ［エージェントが質問します：ビジネス上の課題を最も強く経験しているのは誰ですか？ 採用する可能性が最も高いのは誰ですか？ 最も接触しやすいのは誰ですか？］
3. まずペルソナを作成する必要がある — ［コンポーネントスキル skills/proto-persona/SKILL.md を使用することをエージェントが提案します］

ユーザーの回答： ［選択肢または説明］

エージェントが検証します： 実在する人物を思い描けるほど具体的ですか？ それとも「すべてのユーザー」のように広すぎますか？

---

Question 4: ユーザーの成果とメリット（Box 4）

エージェントの質問：

ユーザーがあなたの製品やサービスを求めるのはなぜですか？ どのようなメリットが得られますか？ 目標を達成したことを示す、観察可能な行動の変化は何ですか？

指標（Box 2で扱います）ではなく、目標、メリット、感情、共感に焦点を当てます。

ユーザーの成果とメリットの例：

• 手作業でのデータ入力を週10時間削減する（家族と過ごす時間を増やす）
• プロジェクトをより早く納品して昇進する
• 友人の前で決済に失敗する気まずさを避ける
• サポートに電話せずにエンタープライズソフトウェアを設定できる自信を持つ

重要な理由： ここは共感のボックスです。単なる行動の変化ではなく、人間の動機に関するものです。

エージェントが提示する3つの選択肢：

1. ユーザーが達成したいことがわかっています — ［ユーザーのメリットを説明］
2. ユーザーのメリットを特定するのを手伝ってください — ［エージェントが質問します：ユーザーはこの製品にどんな仕事をしてもらうために選んでいますか？ どんな課題を避けようとしていますか？ どんなメリットを求めていますか？］
3. まず調査が必要です — ［エージェントが skills/jobs-to-be-done/SKILL.md または skills/discovery-interview-prep/SKILL.md を提案します］

ユーザーの回答： ［選択または説明］

エージェントによる検証： これは、ユーザーが何をするかだけでなく、ユーザーがなぜそれを重視するのかを説明していますか？

---

Question 5: ソリューション（Box 5）

エージェントの質問：

ビジネス上の課題を解決すると同時に、顧客のニーズも満たすために、何を作ることができますか？

有効と思われる機能、取り組み、ポリシー、システム、さらにはビジネスモデルの転換を列挙します。大規模なもの、小規模なもの、革新的なもの、「風変わりな」もの、技術を使わないものまで、幅広いソリューションを検討してください。

例：

• ワンタップのモバイル決済（Apple Pay、Google Pay）
• セルフサービスのオンボーディングウィザード（人による設定は不要）
• AI を活用したレコメンデーションエンジン
• コンシェルジュ型オンボーディング（手厚く手動で対応し、自動化する前にテストする）
• 価格モデルを変更する（定額制から従量制へ）

重要： これらは仮説であり、確約ではありません。あらゆるものを作ると決めるのではなく、選択肢を検討しています。

エージェントが提示する3つの選択肢：

1. ソリューションのアイデアがあります — ［候補となるソリューションを列挙］
2. ソリューションのブレインストーミングを手伝ってください — ［エージェントが課題、成果、ユーザーに基づいてソリューションを提案します］
3. ソリューションが1つしか思い浮かびません — ［エージェントが問いかけます：「ほかに何が解決策になり得ますか？ その解決策がうまくいかなかったらどうしますか？」］

ユーザーの回答： ［選択または説明］

エージェントによる検証： 候補となるソリューションが少なくとも3つありますか？ （選択肢が多いほど、後でより良い仮説を立てられます）

---

Question 6: 仮説（Box 6）

エージェントの質問：

Box 2〜5の前提を組み合わせて、検証可能な仮説を作成しましょう。

次のテンプレートを使います：

私たちは、［Box 2のビジネス成果］は、［Box 3のユーザー］が、［Box 5のソリューション］**によって［Box 4のメリット］を得れば、達成されると考えています。

ルール：

• 各仮説では、1つのソリューション（Box 5から）に焦点を当てます
• Box 2、3、4、5の前提を組み合わせます
• 検証可能でなければなりません（仮説を検証または反証する実験を設計できます）

例：

**私たちは、**モバイル決済のコンバージョン率を45％から60％に引き上げることは、モバイルを優先する25〜35歳のミレニアル世代が、ワンタップの Apple Pay 統合によって、より速く摩擦のない決済を実現すれば、達成されると考えています。

エージェントの提示内容：

入力内容に基づき、以下の仮説を提案します（Box 5のソリューションごとに1つ）。

1. ［生成された仮説1］
2. ［生成された仮説2］
3. ［生成された仮説3］

選択肢：

• これらの仮説を採用する — ［エージェントが記録します］
• 仮説を編集する — ［表現を修正］
• 自分で仮説を書く — ［テンプレートを使う］

ユーザーの回答： ［選択または説明］

エージェントによる検証： 各仮説は、ソリューションがうまくいった場合に何が起きると考えているのかを明確に示していますか？

---

質問 7：最初に学ぶべき最も重要なことは何ですか？（ボックス 7）

エージェントが質問します：

ボックス 6 の各仮説について、最もリスクの高い前提を特定します。そのうえで、現時点で最もリスクの高いものを判断します。

リスクの種類：

• 価値のリスク： ユーザーは実際に使ってくれるでしょうか？ それを重要だと感じるでしょうか？
• 使いやすさのリスク： ユーザーは使い方を理解できるでしょうか？
• 実現可能性のリスク： 技術的に構築できるでしょうか？
• 事業性のリスク： 事業上の成果につながるでしょうか？

ヒント： 初期段階では、たいていの場合、実現可能性よりも価値に関するリスクに重点を置きます。技術的に実現可能でも、ユーザーが望まないものは作らないでください。

エージェントが提示します：

仮説に基づいて、最もリスクの高い前提を以下に示します。

1. ［仮説 1 のリスク］ — 例：「ユーザーは、明細を確認せずにワンタップでチェックアウトすることを信頼する」
2. ［仮説 2 のリスク］ — 例：「セルフサービスでのオンボーディングにより、セットアップ時間が 3 日未満に短縮される」
3. ［仮説 3 のリスク］ — 例：「AI によるおすすめで平均注文額が 50% 増加する」

現時点で最もリスクが高いのはどれですか？

選択肢：

1. リスク 1 — ［選択し、その理由を説明する］
2. リスク 2 — ［選択し、その理由を説明する］
3. リスク 3 — ［選択し、その理由を説明する］
4. どれが最もリスクが高いかわかりません — ［エージェントが優先順位付けを支援します。間違っていた場合、取り組みを頓挫させる前提はどれですか？］

ユーザーの回答： ［選択内容］

エージェントが記録します： これが最初に検証する前提です。

---

質問 8：次に最も重要なことを学ぶために必要な作業を、どこまで最小限にできますか？（ボックス 8）

エージェントが質問します：

最もリスクの高い前提（ボックス 7）をできるだけ早く検証または否定する実験を設計します。

実験の種類の例：

• 顧客インタビュー — 価値に関する仮説を検証するため、5～10 件のインタビューを実施します
• ランディングページ — フェイクドアテストで関心度を測定します
• コンシェルジュ／手動プロトタイプ — 自動化する前に、手厚く手動で対応するバージョンを用意します
• ウィザード・オブ・オズ — 裏側で人が対応し、機能が存在するように見せかけます
• スモークテスト — 機能を告知し、登録数を測定します

注意： 実験の設計は技術というより技芸です。このキャンバスは実験を行うよう促すものです。実験の設計については、別途反復して改善することを想定してください。

エージェントが提示します：

最もリスクの高い前提に基づいて、実験の選択肢を以下に示します。

1. 顧客インタビュー — 10 人のユーザーに話を聞き、［ソリューション］を使うか尋ね、現在どのように対処しているかを観察します
2. ランディングページテスト — ［ソリューション］を説明するランディングページを作成し、登録率を測定します
3. コンシェルジュテスト — 5 人のユーザーに［便益］を手動で提供し、［成果］を達成できるか観察します
4. ウィザード・オブ・オズのプロトタイプ — 裏側で人が対応して［ソリューション］を実現し、ユーザーがワークフローを完了するか確認します
5. カスタム実験を設計する — ［実験の内容を説明する］

どの実験を実施しますか？

ユーザーの回答： ［1 つ選ぶか、カスタム実験を説明する］

エージェントが検証します： これは前提を検証または否定できる最小のテストですか？（2 週間を超える場合は規模が大きすぎます。さらに細分化してください。）

---

ステップ 9：キャンバスを確認してエクスポートする

エージェントが要約します：

完成した Lean UX Canvas（v2）は以下のとおりです。

┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2)                                         │
│ Initiative: [Title]                                         │
│ Date: [Today's date]                                        │
│ Iteration: 1                                                │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │              │ 2. Business Outcomes  │
│ [Your input]        │              │ [Your input]          │
│                     │              │                       │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users            │              │ 4. User Outcomes      │
│ [Your input]        │ [Your input] │    & Benefits         │
│                     │              │ [Your input]          │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. Hypotheses       │ 7. Learn     │ 8. Experiments        │
│ [Your input]        │    First     │ [Your input]          │
│                     │ [Your input] │                       │
└─────────────────────┴──────────────┴───────────────────────┘

次のステップ：

1. 実験を実施する（ボックス 8） — 期間を設定します（例：2 週間）
2. 学びを記録する — 何がわかりましたか？ 前提は検証されましたか、それとも否定されましたか？
3. キャンバスを更新する — 学びに基づいて仮説を見直し、次に最もリスクの高い前提を選びます
4. 反復する — 構築に十分な確信が得られるまで、ボックス 7 → ボックス 8 を繰り返します

エージェントが質問します：

次のことを行いますか？

1. このキャンバスをエクスポートする（Markdown ファイルとして）
2. 次に使う関連スキルを提案する（例：顧客インタビュー用の skills/discovery-interview-prep/SKILL.md）
3. 特定のボックスを見直す（不十分に感じる項目がある場合）

---

例

Lean UX Canvas の例全体については、examples/sample.md を参照してください。

短い例：

**Box 1:** Mobile checkout conversion is 15% lower than desktop
**Box 2:** Increase mobile conversion from 45% to 60%
**Box 8:** Wizard-of-Oz test with one-tap checkout

よくある落とし穴

1. 課題ではなく、解決策から始める

失敗パターン： ボックス 1 に、何が変わったかを説明せず、「X を構築する必要がある」と書いています。

結果： 課題が実在するかを検証せずに、誰かがすでに決めた解決策を構築することになります。

対策： 「世の中で何が変わったのか？ なぜ今、これが課題なのか（6 か月前ではなく）？」と問いかけます。

---

2. 事業成果が曖昧

失敗パターン： ボックス 2 に、「売上を伸ばす」や「ユーザーを満足させる」と書いています。

結果： 成功を測る方法がなく、実験がうまくいったかどうかを判断できません。

対策： 測定可能な行動の変化を定義します。「平均注文額を 50 ドルから 75 ドルに増やす」や「サポートチケットを 30％削減する」などです。

---

3. ユーザーセグメントの範囲が広すぎる

失敗パターン： ボックス 3 に、「すべてのユーザー」や「全員」と書いています。

結果： 対象を絞った実験を設計できず、導入しないペルソナに時間を浪費します。

対策： まずは 1 つのペルソナを選びます。後から対象を広げることができます。

---

4. ボックス 2 とボックス 4 の混同

失敗パターン： ボックス 2 に感情を、ボックス 4 に指標を記入しています（またはその逆です）。

結果： 仮説に一貫性がなく、成功基準が不明確になります。

対策： ボックス 2 ＝行動の変化（指標）。 ボックス 4 ＝目標、メリット、感情（共感）。

---

5. ボックス 5 の解決策が 1 つだけ

失敗パターン： ステークホルダーがすでに決定しているため、機能を 1 つだけ挙げています。

結果： 代替案を検討できず、どの解決策が最適かをテストできません。

対策： 解決策を 3 つ以上挙げるようにします。「この課題を解決できる方法はほかに何があるか？」と問いかけます。

---

6. 実験を省略する（ボックス 8）

失敗パターン： 「とりあえず構築して、どうなるか見てみます。」

結果： 間違ったものの構築に数週間から数か月を浪費します。

対策： まず最小の実験を設計します。思いつかない場合は、skills/pol-probe-advisor/SKILL.md を使って検証方法を選びます。

---

参考資料

関連スキル

• problem-statement（コンポーネント）— ボックス 1 を記入する前に課題を明確にする
• problem-framing-canvas（インタラクティブ）— キャンバスの前に MITRE の問題定義を行う
• proto-persona（コンポーネント）— ボックス 3 のペルソナを作成する
• jobs-to-be-done（コンポーネント）— ボックス 4 のユーザーメリットを特定する
• epic-hypothesis（コンポーネント）— 検証可能な仮説を作成する（ボックス 6）
• discovery-interview-prep（インタラクティブ）— ボックス 8 の顧客インタビューを設計する
• pol-probe-advisor（インタラクティブ）— ボックス 8 の実験タイプを選ぶ

外部フレームワーク

• Jeff Gothelf — Lean UX: Designing Great Products with Agile Teams（O'Reilly、2013 年、第 2 版 2016 年）
• Jeff Gothelf — Lean UX Canvas v2（公式ブログ記事）
• Lean UX Canvas PDF — v2 PDF をダウンロード

ツール

• Miro / Mural — キャンバスを共同で記入するためのデジタルホワイトボード
• Google Slides / PowerPoint — Jeff Gothelf のサイトからテンプレートを入手できます
• Notion / Coda — 複数のキャンバスを追跡するためのデータベースビュー