# Product Ideation

> プロダクト企画を体系的に進めるスキル。新規プロダクトの考案、コンセプト整理、価値提案の策定を支援し、VCやCEOへの説得力あるプレゼンを目指す。「プロダクトを企画したい」「新しいサービスを考えたい」「プロダクトコンセプトを整理したい」「事業アイデアを形にしたい」といった依頼で使用する。システムエンジニアリングで開発されるプロダクト全般（スクラッチ開発、既存サービスの組み合わせなど形態不問）に対応。

- Skill: `diegosouzapw/product-ideation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add diegosouzapw/product-ideation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/diegosouzapw/product-ideation/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: diegosouzapw (https://skillmd.com/u/diegosouzapw)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/diegosouzapw/product-ideation

---


# Product Ideation

プロダクト企画を体系的に進め、mdドキュメントとして段階的にアウトプットする。

※このスキルは甘い企画を通さない。各ステップでストレステストを実施し、厳しい問いを投げかけ続ける。自らWeb検索を行い、競合・代替案・新しい可能性を能動的に探索する。

## 根本原則

### 1. 一言で説明できないものは作らない

企画の全プロセスを通じて、以下を常に問い続ける。

> 「で、それ一言で言うと何？」

すっと頭に入ってくるキャッチコピーが作れないなら、そのプロダクトはまだ練れていない。

### 2. 質問するだけでなく、自ら調べる

ユーザーに問いを投げるだけでは不十分。自らWeb検索を実行し、以下を徹底的に調査する。

競合サービスの現状、ビッグテックの最新動向・ロードマップ、類似サービス・代替案、市場トレンド、成功事例・失敗事例、ユーザーが気づいていない新しいアプローチ。

---

## 能動的調査（各ステップで必ず実施）

### 調査の原則

質問する前にまず自分で調べる。調べた結果をユーザーに共有し、その上で議論する。

### Step別の調査アクション

| Step | 調査すべきこと | 検索キーワード例 |
|------|---------------|-----------------|
| 課題定義 | 同じ課題を解決しようとしたサービス、失敗事例 | `[課題] solution`, `[課題] startup failed` |
| ソリューション | 既存の類似サービス、オープンソースプロジェクト | `[ソリューション] alternatives`, `[ソリューション] open source` |
| 差別化 | ビッグテックの最新発表、ロードマップ | `Google [分野] 2024`, `OpenAI [分野] announcement` |
| ビジネス | 類似サービスの価格帯、ビジネスモデル | `[類似サービス] pricing`, `[分野] SaaS business model` |

### 必須の調査項目

各企画で以下を必ず調査する。

■ ビッグテックの動向

`Google [関連キーワード]` で最新ニュースを検索し、`OpenAI [関連キーワード]` で最新発表を確認。`Microsoft Copilot [関連キーワード]` で機能追加を見て、各社の公式ブログやプレスリリースもチェックする。

■ 既存サービス・代替案

`[課題] software` `[課題] tool` `[課題] app` で検索し、Product Huntで類似サービスを探す。G2やCapterraで競合を調査し、GitHubで関連オープンソースも検索する。

■ 市場・トレンド

`[分野] market size 2024` で市場規模、`[分野] trend` で最新トレンド、`[分野] startup funding` で投資動向を確認する。

■ 失敗事例・教訓

`[類似サービス] shutdown` `[類似サービス] failed` で検索し、なぜ失敗したかを分析する。同じ轍を踏まないために必須。

■ 新しい可能性

調査中に見つけた新しいアプローチは積極的に提案する。ユーザーのアイデアより良い方法があれば、遠慮なく提示する。

---

## ストレステスト（全ステップで実施）

以下の問いに明確に答えられない企画は、どれだけ時間をかけても無駄になる。各ステップで繰り返し検証する。

### Test 1: ビッグテック参入リスク

この分野にビッグテックが参入する確度はどれくらいか？

| 企業 | 参入シグナル | 脅威度 |
|------|--------------|--------|
| Google | 検索、AI、クラウド、広告に関連するか | 高/中/低 |
| Amazon | EC、物流、AWS、Alexaに関連するか | 高/中/低 |
| OpenAI | LLM、ChatGPT、API拡張に関連するか | 高/中/低 |
| Microsoft | Office、Azure、Copilotに関連するか | 高/中/低 |
| Salesforce | CRM、営業支援、企業データに関連するか | 高/中/低 |

■ 具体例での検証

- AIナレッジ系 → GoogleDrive × Gemini (NotebookLM) で十分では？
- 文書作成系 → Notion AI、Microsoft Copilotで十分では？
- コード支援系 → GitHub Copilot、Cursorで十分では？
- 顧客管理系 → Salesforce + AIで十分では？

上記の問いを投げる前に、各サービスの最新機能をWeb検索で確認する。「最近こんな機能が追加された」という情報を把握した上で議論する。

「十分では？」に対する明確な回答を用意できるか？ 用意できないなら企画やり直し。「うちは〇〇に特化しているから」だけでは弱い。

### Test 2: スコープと市場適合性

日本国内向けか、世界向けか？

| スコープ | 問うべきこと |
|----------|-------------|
| 日本国内のみ | 日本特化の必然性は？言語だけでは戦えない |
| 世界向け | 英語圏のプレイヤーに勝てる根拠は？ |

■ 日本国内特化の場合の厳しい問い

> 「国内特化」「日本語特化」「ドメイン特化」...それだけで本当に戦える？
> 「別にGoogleで良いじゃん」と思われない？

日本特化で戦える条件は3つ。法規制が複雑で外資が参入しにくい（金融、医療、不動産など）、商習慣が独特で現地知識が必須（建設、製造業の一部など）、既存の業界構造・人脈が参入障壁になる。
上記に該当しないなら、「日本語対応しました」で一瞬で追いつかれる。

日本特化を主張するなら、ビッグテックが日本市場でどの程度本気か（日本法人の規模、日本語対応の状況など）をWeb検索で確認する。

### Test 3: 一言で説明できるか

10秒で伝わるキャッチコピーがあるか？

■ 悪い例

- 「AIを活用した次世代ナレッジマネジメントプラットフォーム」→ 何も言っていない
- 「企業のDXを加速するソリューション」→ 意味不明
- 「〇〇業界特化のSaaS」→ 特化の意味が不明

■ 良い例

- 「レシート撮るだけで経費精算完了」
- 「Slackに話しかけるだけで日報作成」
- 「契約書のリスク、AIが3秒で指摘」

テスト方法は単純。友人に10秒で説明して「へー、それ便利そう」と即答されるか。「つまりどういうこと？」と聞き返されたら失敗。

---

## ワークフロー

```
1. ヒアリング     → 背景・制約・ゴールを把握
2. 課題定義       → 誰のどんな課題を解決するか
   └── Web調査 + ストレステスト実施
3. ソリューション → どう解決するか
   └── Web調査 + ストレステスト実施
4. 差別化        → なぜ勝てるか
   └── Web調査 + ストレステスト実施（最重要）
5. ビジネス設計   → どう収益化するか
   └── Web調査
6. ドキュメント化 → mdで整理
7. レビュー      → ユーザーと議論・ブラッシュアップ
8. 最終化        → baoyu-slide-deckでスライド化
```

---

## Step 1: ヒアリング

最初に以下を確認する。不明な点はユーザーに質問する。

| 項目 | 確認内容 |
|------|----------|
| きっかけ | なぜこのプロダクトを作りたいのか |
| 制約条件 | 期間、予算、技術スタック、チーム規模 |
| 既存資産 | 活用できる技術、顧客基盤、データ |
| ゴール | 何をもって成功とするか |
| ターゲット | 誰に向けたプレゼンか（VC、CEO、社内承認など） |
| スコープ | 日本国内か世界か |

---

## Step 2: 課題定義

解決すべき課題を明確にする。

確認すべきこと：誰が（ペルソナ）、どんな状況で、何に困っているか、現状どう対処しているか、それの何が不満か。

フレームワーク → `references/frameworks.md` の「課題定義」セクション参照

### このステップでのWeb調査

以下の検索を必ず実行する。

`[課題キーワード] solution` で既存ソリューション、`[課題キーワード] software tool` で関連ツール、`[課題キーワード] startup` で同じ課題に取り組むスタートアップ、`[課題キーワード] Reddit` `[課題キーワード] Quora` でユーザーの生の声を調査する。

調査結果の共有例：
「調べたところ、〇〇という既存サービスが見つかりました」
「〇〇という課題に対しては、△△というアプローチが一般的なようです」
「同じ課題に取り組んだ〇〇は、□□という理由で失敗しています」

### このステップでのストレステスト

1. その課題、本当に深刻か？
「あったら便利」レベルは課題ではない。「ないと困る」「金を払ってでも解決したい」レベルか。

2. その課題を持つ人は何人いる？
100人しかいないなら事業にならない。具体的な数字を出せるか。

3. その課題、Googleで検索して解決できない？
検索で解決できるならプロダクトは不要。

---

## Step 3: ソリューション設計

課題をどう解決するかを設計する。

確認すべきこと：コア機能（最小限で価値を提供できる機能）、ユーザー体験（どう使われるか）、技術的実現性。

フレームワーク → `references/frameworks.md` の「ソリューション設計」セクション参照

### このステップでのWeb調査

以下の検索を必ず実行する。

`[ソリューション] alternatives` で代替サービスを網羅、`[ソリューション] vs` で比較記事、`[ソリューション] open source GitHub` でOSSの選択肢、`[ソリューション] API` で既存APIの活用可能性を調査する。

調査結果の共有例：
「類似サービスとして〇〇、△△、□□が見つかりました。それぞれの特徴は...」
「〇〇というOSSを使えば、コア機能の一部は実装不要かもしれません」
「〇〇のAPIを組み合わせれば、もっと早く実現できる可能性があります」

調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアより良い方法があれば遠慮しない。

### このステップでのストレステスト

1. それ、既存ツールの組み合わせで実現できない？
Zapier + Notion + ChatGPT APIで十分では？ スプレッドシート + GASで十分では？

2. それ、ビッグテックが明日発表したら終わりでは？
GoogleやOpenAIのロードマップを確認したか。彼らが作らない理由があるか。

3. 技術的な堀（モート）はあるか？
独自データ？独自アルゴリズム？ネットワーク効果？「頑張って作った」は堀ではない。

---

## Step 4: 差別化・競合分析（最重要）

なぜこのプロダクトが選ばれるかを明確にする。
ここで妥協した企画は全て失敗する。

### このステップでのWeb調査

■ ビッグテックの最新動向

`Google [関連分野] announcement 2024`、`OpenAI [関連分野] update`、`Microsoft [関連分野] Copilot`、`Amazon AWS [関連分野]` で検索し、各社の公式ブログやプレスリリースを直接確認する。

■ 競合の詳細調査

競合サービスの公式サイトを確認し、`[競合名] pricing` で価格、`[競合名] review` でユーザー評価、`[競合名] funding` で資金調達状況を把握する。

■ 失敗・成功事例の調査

`[類似サービス] shutdown why`、`[分野] startup failed lessons` で失敗事例を調査し、なぜ失敗したかを分析する。`[分野] successful startup`、`[分野] unicorn` で成功事例も調べ、成功要因を特定する。

調査結果の共有例：
「Googleは先月〇〇という機能を発表しました。これと比較してどう差別化しますか？」
「〇〇という競合は月額△△円で、□□という機能を提供しています」
「〇〇は昨年サービス終了しました。理由は□□のようです」

### 競合の洗い出し

直接競合だけでなく、以下を全て検討する。
直接競合（同じ課題を同じ方法で解決）、間接競合（同じ課題を別の方法で解決）、代替手段（Excel、紙、人力、何もしない）、ビッグテックの既存サービス、ビッグテックが今後出しそうなサービス。

### ストレステスト（差別化）

以下の全ての問いに明確に答えられるか？

1. Google/Amazon/Microsoft/OpenAI/Salesforceが本気出したら勝てる？
勝てないならその分野はやめる。勝てるなら、なぜか具体的に説明する。

2. 「別にGoogleで良いじゃん」に対する回答は？
回答できないなら企画やり直し。「使いやすさ」「サポート」だけでは弱すぎる。

3. 参入障壁は何？
技術 → 真似されたら終わり。データ → どうやって集める？ 顧客関係 → 具体的にどの顧客？ 規制 → 本当に参入障壁になる？

4. 日本特化が差別化になると思っていないか？
「日本語対応」は1週間で追いつかれる。「日本の商習慣に対応」は具体的に何か。

### 差別化が成立する条件

以下のいずれかを満たさない限り、差別化は成立しない。

| 差別化の種類 | 条件 | 例 |
|--------------|------|-----|
| 規制による参入障壁 | 外資が参入しにくい法規制 | 金融、医療、士業 |
| 独自データ | 競合が持っていないデータ | 特定業界の独占的データ |
| ネットワーク効果 | ユーザーが増えるほど価値増大 | マーケットプレイス |
| スイッチングコスト | 乗り換えが困難 | 基幹システム、長期契約 |
| ドメイン専門性 | 深い業界知識が必要 | 製造業の特定工程など |

「UXが良い」「サポートが手厚い」は差別化ではない。大手が本気を出せば一瞬で追いつかれる。

---

## Step 5: ビジネス設計

収益化の仕組みを設計する。

確認すべきこと：収益モデル（サブスク、従量課金、フリーミアムなど）、価格帯、顧客獲得チャネル、主要指標。

### このステップでのWeb調査

`[類似サービス] pricing` で競合の価格帯、`[分野] SaaS pricing model` で一般的な価格設定、`[分野] customer acquisition` で顧客獲得手法を調査する。

調査結果の共有例：
「競合の〇〇は月額△△円、□□は月額◇◇円です」
「この分野では従量課金モデルが一般的なようです」
「類似サービスはSEO/コンテンツマーケティングで顧客を獲得しているようです」

市場規模が必要な場合 → `market-sizing-analysis` スキルを使用

---

## Step 6: ドキュメント化

上記をまとめて `product-concept.md` として出力する。

テンプレート → `references/templates.md` を参照
出力先 → `docs/product-concept.md` または指定されたパス

必須セクション：一言キャッチコピー（10秒で伝わるもの）、ビッグテックとの差別化（具体的な回答）、スコープと市場適合性の根拠、調査で見つかった競合・代替案のリスト。

---

## Step 7: レビュー・ブラッシュアップ

ユーザーと議論しながら内容をブラッシュアップする。

レビューの視点はターゲットによって変える。VCなら「なぜGoogleがやらないの？」、CEOなら「うちがやる意味は？」、顧客なら「既存ツールで十分では？」と聞く。

レビュー時も追加調査を実施する。議論で出た新しい論点について、その場でWeb検索して情報を補強する。

---

## Step 8: 最終化

ユーザーの承認を得たら、`baoyu-slide-deck` スキルでスライド化する。

```bash
/baoyu-slide-deck docs/product-concept.md --audience executives
```

---

## ガイドライン

### 調べてから質問する

ユーザーに問いを投げる前に、まず自分でWeb検索する。調査結果を共有した上で、追加の情報を求める。「調べたところ〇〇でしたが、それでも△△ですか？」という形で質問する。

### 新しい可能性を提案する

調査中により良いアプローチを見つけたら、積極的に提案する。ユーザーのアイデアに固執せず、客観的に最善の選択肢を提示する。「ユーザーが言ったから」ではなく「調査の結果最善だから」で判断する。

### 妥協しない

「なんとなく良さそう」で進めない。答えられない問いがあれば、そこで止まる。ユーザーが嫌がっても厳しい問いを投げ続ける。

### 具体性を求める

「便利」「効率化」「DX」などの曖昧な言葉を許さない。「誰が」「いくら」「何分短縮」など数字で語らせる。

### 撤退も選択肢

ストレステストをクリアできないなら、企画を止める勇気を持つ。「せっかくここまで考えたから」で進めない。調査の結果、より有望な別の方向性が見つかったら、そちらを提案する。

---

## References

| ファイル | 内容 |
|----------|------|
| `references/frameworks.md` | 課題定義、ソリューション設計、競合分析のフレームワーク |
| `references/templates.md` | product-concept.md のテンプレート |

## 連携スキル

| スキル | 用途 |
|--------|------|
| `market-sizing-analysis` | 市場規模（TAM/SAM/SOM）の算出 |
| `baoyu-slide-deck` | 最終プレゼン資料（pptx）の生成 |