recommendation-canvas

目的

ビジネス成果、顧客成果、課題の定義、ソリューション仮説、ポジショニング、リスク、価値の根拠を評価する、構造化されたキャンバスを使って、AI プロダクトのソリューションを評価し、提案します。これを活用して、関係者や意思決定者に向けた、包括的で根拠のある提案を作成します。特に、不確実性とリスクが高い AI 搭載機能やプロダクトを提案する場合に有効です。

これは機能仕様書ではありません。AI ソリューションを構築する価値がある「理由」、検証が必要な「前提」、成功を測定する「方法」を明確にする、戦略的な提案です。

入力

特に役立つもの： 評価対象の AI プロダクトまたは機能のアイデア。 あると便利なもの： 対象顧客、期待されるビジネス成果、既知のリスク、提案の説得相手。

呼び出し時に渡された内容（スキル名の後のテキスト、貼り付けられたコンテキストのダンプ、追加された ARGUMENTS: 行など）は、すでに得られた回答として扱います。その内容を利用し、記載済みの項目については質問を省略します。

何も決まっていなくても大丈夫です。 このスキルでは、まずアイデアと意思決定者を尋ね、その後キャンバスの各項目を一緒に検討します。

呼び出し例： Recommendation canvas: AI-suggested reorder quantities for warehouse managers — VP Ops wants a go/no-go next month.

主な概念

Recommendation Canvas フレームワーク

Dean Peters の Productside「AI Innovation for Product Managers」クラス向けに作成されたこのキャンバスは、複数の PM フレームワークを統合し、1 つの戦略的な視点を提供します。

主な構成要素：

1. ビジネス成果： ビジネスにとってどのような価値がありますか？
2. プロダクト成果： 顧客にとってどのような価値がありますか？
3. 課題の定義： ペルソナを中心とした課題の定義
4. ソリューション仮説： 実験を伴う「もし〜なら、〜になる」という仮説
5. ポジショニングステートメント： 価値提案と差別化
6. 前提と不明点： 何がこの提案を無効にする可能性がありますか？
7. PESTEL リスク： 政治、経済、社会、技術、環境、法律
8. 価値の根拠： なぜこれを実施する価値があるのですか？
9. 成功指標： 影響を測定する SMART 指標
10. 次のステップ： 戦略的な次のアクション

効果がある理由

• 成果重視： ビジネスと顧客の価値を明確にします
• 仮説重視： ソリューションを確定事項ではなく、検証する価値のある賭けとして扱います
• リスクを明示： 前提とリスクを早い段階で可視化します
• 経営陣向け： 包括的でありながら、C レベルのレビューに適した構成です
• AI に適している： 特に不確実性の高い AI 機能に有用です

アンチパターン（このスキルに当てはまらないもの）

• PRD ではありません： 詳細な要件ではなく、戦略的な枠組みです
• 事業計画書ではありません（まだ）： 事業計画書の作成に役立ちますが、まず検証が必要です
• 機能リストではありません： 機能ではなく成果に重点を置きます

使用する場面

• AI 搭載の新しいプロダクトや機能を提案するとき
• 経営陣に提案するとき、または予算や支援を確保するとき
• AI ソリューションを推進する価値があるか評価するとき
• 部門横断の関係者（プロダクト、エンジニアリング、データサイエンス、ビジネス）の認識を合わせるとき
• 初期のディスカバリーを終えた後（作成にはコンテキストが必要です）

使用しない場面

• ささいな機能の場合（小さな変更を過度に複雑にしないでください）
• ディスカバリーを始める前（まずユーザー調査と課題の検証が必要です）
• 実験の代わりとして（キャンバスは実験の参考にするものであり、その逆ではありません）

---

適用

全項目を記入するための構成には、template.md を使用してください。

ステップ 1：コンテキストを収集する

キャンバスを記入する前に、次の情報がそろっていることを確認してください。

• 課題の理解： ユーザー調査、悩み（skills/problem-statement/SKILL.md を参照）
• ペルソナの明確化： 誰が課題を経験しますか？（skills/proto-persona/SKILL.md を参照）
• 市場の状況： 競合環境、カテゴリ内でのポジショニング
• ビジネス上の制約： 予算、スケジュール、戦略上の優先事項

コンテキストが不足している場合： まずディスカバリーを行ってください。このキャンバスは知見を統合するものであり、知見を生み出すものではありません。

---

ステップ 2：成果を定義する

ビジネス成果

ビジネスにとってのメリットは何ですか？次の形式を使用します。

• [方向性] [指標] [成果] [状況] [受け入れ基準]

## Business Outcome
- [e.g., "Reduce by 25% the churn of existing customers using our existing product"]

例：

• 「12 か月以内に、エンタープライズ顧客からの月間経常収益を 15％増加させる」

品質チェック：

• 測定可能： この指標を追跡できますか？
• 期限が明確： どの期間内に達成しますか？
• 野心的でありながら現実的： 「1 か月で収益を 10 倍にする」ではありません

---

プロダクト成果

顧客にとってのメリットは何ですか？次の形式を使用します。

• [方向性] [指標] [成果] [ペルソナ視点での状況] [受け入れ基準]

## Product Outcome
- [e.g., "Increase the speed of finding patients when I know the inclusion and exclusion criteria"]

例：

• 「小規模事業のオーナーが請求書を手作業で処理する時間を 60％削減する」

品質チェック：

• 顧客中心： ユーザーの視点（「私」であり、「私たち」ではない）で書かれています
• 機能ではなく成果： 「AI による自動化を使う」ではなく「費やす時間を削減する」

---

ステップ 3：問題を明確にする

skills/problem-statement/SKILL.md の問題定義のナラティブを使用します。

## The Problem Statement

### Problem Statement Narrative
- [Persona description: 2-3 sentences telling the persona's story from their POV]
- [Example: "Sarah is a freelance designer managing 10 clients. She spends 8 hours/month manually tracking invoices and chasing late payments. By the time she follows up, some clients have already moved to other designers, costing her revenue and damaging relationships."]

品質チェック：

• 共感的： ユーザーの声のように聞こえますか？
• 具体的： 「ユーザーはより良いツールを求めている」ではなく、「Sarah は月に 8 時間を費やしている」
• 検証済み： 仮定ではなく、実際のユーザー調査に基づいています

---

ステップ 4：ソリューション仮説を定義する

仮説の記述

skills/epic-hypothesis/SKILL.md のエピック仮説の形式を使用します。

## Solution Hypothesis

### Hypothesis Statement
**If we** [action or solution on behalf of target persona]
**for** [target persona]
**Then we will** [attain or achieve desirable outcome]

例：

• 「フリーランスのデザイナー向けに、最適なタイミングで自動送信する AI 搭載の請求書リマインダーを提供すれば、支払いのフォローアップにかかる時間を 70％削減できます」

---

小さな発見の取り組み

仮説を検証するための手軽な実験を定義します。

### Tiny Acts of Discovery
**We will test our assumption by:**
- [Experiment 1: Prototype AI reminder system and test with 5 freelancers]
- [Experiment 2: A/B test manual vs. AI-timed reminders for 20 users]
- [Experiment 3: Survey users on perceived value after 2 weeks]

品質チェック：

• 迅速： 数日または数週間で実施でき、数か月はかかりません
• 低コスト： プロトタイプやコンシェルジュテストを使い、本格的な開発は行いません
• 反証可能： 仮説が誤りだと証明できる可能性があります

---

実現可能性の確認

検証方法を定義します。

### Proof-of-Life
**We know our hypothesis is valid if within** [timeframe]
**we observe:**
- [Quantitative outcome: e.g., "80% of users send reminders via the AI system"]
- [Qualitative outcome: e.g., "8 out of 10 users report saving 5+ hours/month"]

---

ステップ 5：ポジショニングを定義する

skills/positioning-statement/SKILL.md のポジショニングステートメントの形式を使用します。

## Positioning Statement

### Value Proposition
**For** [target customer/user persona]
**that need** [statement of underserved need]
[product name]
**is a** [product category]
**that** [statement of benefit, focusing on outcomes]

### Differentiation Statement
**Unlike** [primary competitor or competitive arena]
[product name]
**provides** [unique differentiation, focusing on outcomes]

---

ステップ 6：前提と不明点を記録する

## Assumptions & Unknowns
- **[Assumption 1]** - [Description, e.g., "We assume users will trust AI-generated reminders"]
- **[Assumption 2]** - [Description, e.g., "We assume payment timing optimization increases response rates"]
- **[Unknown 1]** - [Description, e.g., "We don't know if users prefer email or SMS reminders"]

品質チェック：

• 明示的： 隠れた前提を明らかにします
• 検証可能： 各前提を実験で検証できます

---

ステップ 7：PESTEL リスクを特定する

調査が必要なリスク（優先度：高）

## Issues/Risks to Investigate
- **Political:** [e.g., "Regulatory changes to AI-generated communications"]
- **Economic:** [e.g., "Economic downturn reduces willingness to pay for premium features"]
- **Social:** [e.g., "Users may perceive AI reminders as impersonal or pushy"]
- **Technological:** [e.g., "AI model accuracy may degrade over time without retraining"]
- **Environmental:** [e.g., "Energy costs of AI processing"]
- **Legal:** [e.g., "GDPR compliance for storing customer email patterns"]

---

監視するリスク（優先度：低）

## Issues/Risks to Monitor
- **Political:** [e.g., "Potential AI regulation in EU markets"]
- **Economic:** [e.g., "Exchange rate fluctuations affecting international customers"]
- **Social:** [e.g., "Changing norms around automated communication"]
- **Technological:** [e.g., "Emerging AI competitors with better models"]
- **Environmental:** [e.g., "Carbon footprint concerns from stakeholders"]
- **Legal:** [e.g., "Future data privacy laws"]

---

ステップ 8：価値を正当化する

## Value Justification

### Is this Valuable?
- [Absolutely yes / Yes with caveats / No with suggested alternatives / Absolutely NO!]

### Solution Justification

We think this is a valuable idea. Here's why:
1. **[Justification 1]** - [Description, e.g., "Addresses the #1 pain point for our target segment"]
2. **[Justification 2]** - [Description, e.g., "Differentiates us from competitors who only offer manual reminders"]
3. **[Justification 3]** - [Description, e.g., "Low technical risk—leverages existing AI infrastructure"]

---

ステップ 9：成功指標を定義する

SMART 指標（具体的、測定可能、達成可能、関連性が高い、期限が明確）を使用します。

## Success Metrics
1. **[Metric 1]** - [e.g., "80% of active users adopt AI reminders within 3 months"]
2. **[Metric 2]** - [e.g., "Average time spent on payment follow-ups decreases by 50% within 6 months"]
3. **[Metric 3]** - [e.g., "Net Promoter Score for invoicing feature increases from 6 to 8 within 6 months"]

---

ステップ 10：次のステップを定義する

## What's Next
1. **[Next step 1]** - [e.g., "Run 2-week prototype test with 10 beta users"]
2. **[Next step 2]** - [e.g., "Build lightweight AI model for reminder timing optimization"]
3. **[Next step 3]** - [e.g., "Conduct legal review of GDPR implications"]
4. **[Next step 4]** - [e.g., "Present findings to exec team for go/no-go decision"]
5. **[Next step 5]** - [e.g., "If validated, add to Q2 roadmap"]

---

例

推奨キャンバスの全体例については、examples/sample.md を参照してください。

ミニ例の抜粋：

### Business Outcome
- Increase by 20% MRR from freelance users within 12 months

### Solution Hypothesis
**If we** provide AI-powered invoice reminders
**for** freelance designers
**Then we will** reduce time spent on follow-ups by 70%

よくある落とし穴

落とし穴 1：成果が曖昧

兆候： 「ビジネス成果：収益を増加させる。プロダクト成果：UX を改善する。」

結果： 測定も責任の明確化もできません。

対策： 成果の公式を使用します：[方向性] [指標] [成果] [状況] [受け入れ基準]。具体的に記述してください。

---

落とし穴 2：ソリューションから考え始める

兆候： 問題の記述が「AI 搭載の X が必要だ」になっています

結果： 問題を検証せずに、解決策へ飛びついています。

対策： ユーザーの視点から問題を定義します。検証済みの課題からソリューション仮説を導き出します。

---

落とし穴 3：小さな発見の取り組みを省略する

兆候： 仮説から実験を行わず、そのままロードマップへ進んでいます

結果： 間違ったものを構築するリスクが高まります。

対策： 手軽な実験を 2～3 件定義します。エンジニアリングリソースを投入する前にテストしてください。

---

落とし穴 4：一般的すぎる PESTEL リスク

兆候： 「政治：規制が変わる可能性がある」

結果： リスク分析が形だけのものになり、実行可能な対策につながりません。

対策： 具体的に記述します：「クライアントのメール送信タイミングデータを保存するには、GDPR への準拠について法務レビューが必要です。」

---

落とし穴 5：価値の根拠が弱い

症状：「顧客に喜んでもらえるので、これは価値があります」

**結果：**経営幹部を納得させられません。

**対処法：**データを使います。「ユーザー調査によると、最大の課題に対応しています。解約率を 20% 削減すると、ARR が 50 万ドル増加します。技術的なリスクは低いです」

---

参考資料

関連スキル

• skills/problem-statement/SKILL.md — 問題の説明に役立ちます
• skills/epic-hypothesis/SKILL.md — ソリューション仮説の構成に役立ちます
• skills/positioning-statement/SKILL.md — ポジショニングのセクションに役立ちます
• skills/proto-persona/SKILL.md — ターゲットペルソナを定義します
• skills/jobs-to-be-done/SKILL.md — 顧客が得る成果に役立ちます

外部フレームワーク

• Osterwalder のバリュープロポジションキャンバス — 問題とソリューションの枠組みに影響を与えます
• PESTEL 分析 — リスク評価フレームワーク
• SMART 目標 — 成功指標の構成

Dean の取り組み

• AI レコメンデーションキャンバステンプレート（Productside の「AI Innovation for Product Managers」クラス向けに作成）

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリ内の prompts/recommendation-canvas-template.md を基にしています。

---

**スキルタイプ：**コンポーネント 推奨ファイル名： recommendation-canvas.md 推奨配置場所： /skills/components/ 依存関係： skills/problem-statement/SKILL.md、skills/epic-hypothesis/SKILL.md、skills/positioning-statement/SKILL.md、skills/proto-persona/SKILL.md、skills/jobs-to-be-done/SKILL.md を参照します