pol-probe-advisor

目的

プロダクトマネージャーが、仮説、リスク、利用可能なリソースに基づいて、適切な Proof of Life（PoL）プローブの種類（5つのタイプ）を選べるように支援します。特定のリスクを排除したい場合や、限定的な仮説を検証したいものの、どの検証方法を使えばよいかわからないときに活用してください。このインタラクティブなスキルを使うと、自分が最も作り慣れているプロトタイプではなく、最も厳しい真実を明らかにできる、最も低コストのプロトタイプを選べます。

これは、検証すべきかどうかを判断するためのツールではありません（検証はすべきです）。最も効果的な検証方法を選ぶための意思決定フレームワークです。

入力

最も効果的な入力： 検証したい仮説、または排除したいリスク。 あると役立つ情報： 利用可能なリソース（時間、予算、エンジニアリングへのアクセス）、対象ユーザーへのアクセス方法、失敗した場合の損失。

呼び出し時に入力された内容（スキル名の後に続くテキスト、貼り付けたコンテキスト、追加された ARGUMENTS: 行）は、すでに回答された内容として扱います。それを使用し、該当する質問は繰り返しません。

何も入力せずに始めても大丈夫です。 アドバイザーが、何を知りたいのかをまず尋ねてから、5つのプローブタイプの中から最適なものを選びます。

呼び出し例： どのプローブが適していますか？ 仮説：中堅企業の人事チームは、AIが作成した求人票を信頼して公開する。期間は2週間、エンジニアの支援なし。

主な概念

中心的な課題：手法と仮説のミスマッチ

よくある失敗パターン： PMが学習目標ではなく、使い慣れたツールを基準に検証方法を選んでしまいます（「Figmaを使えるから、プロトタイプをデザインしよう」）。その結果、誤ったことを検証し、本当のリスクを見落とします。

解決策： 仮説から逆算します。「排除したい具体的なリスクは何か？ 最も低コストで厳しい真実を知るには、どのような方法があるか？」と問いかけます。

---

5つのPoLプローブタイプ（クイックリファレンス）

種類	中心となる問い	最適な用途	期間
実現可能性チェック	「これを構築できるか？」	技術的な不確実性、APIへの依存、データの完全性	1-2日
タスク重視テスト	「ユーザーは手間なくこのタスクを完了できるか？」	重要なUIの場面、フィールドラベル、意思決定ポイント	2-5日
ナラティブプロトタイプ	「このワークフローで関係者の賛同を得られるか？」	ストーリーテリング、複雑なフローの説明、認識合わせ	1-3日
合成データシミュレーション	「本番環境のリスクなしで、これをモデル化できるか？」	エッジケース、未知の未知、統計モデリング	2-4日
バイブコーディングPoLプローブ	「このソリューションは実際のユーザーとのやり取りに耐えられるか？」	実際のインタラクションを伴うワークフロー／UXの検証	2-3日

黄金律： 「最も厳しい真実を明らかにする、最も低コストのプロトタイプを使う。」

---

アンチパターン（このスキルで扱わないこと）

• 「作り慣れたプロトタイプを作る」ことではありません： スキルセットではなく、仮説に合わせて手法を選びます
• 「関係者の好みに基づいて選ぶ」ことではありません： 社内政治ではなく、学びを重視します
• 「最も印象的な選択肢を選ぶ」ことではありません： 印象的であることと、有益であることは別です
• 「まずコードを書く」ことではありません： コードを書くのは最後の手段であり、最初に取る方法ではありません

---

このスキルを使う場面

✅ 次のような場合に使います：

• 仮説は明確ですが、どの検証方法を使えばよいかわからない
• コードを作るか、動画を作るか、シミュレーションを実行するか判断できない
• 特定のリスクを数日以内にすばやく排除したい
• プロトタイプを作ること自体が目的になるのを避けたい

❌ 次のような場合は使わないでください：

• まだ仮説がない（まず problem-statement.md または problem-framing-canvas.md を使ってください）
• 経営陣に好印象を与えようとしている（それは検証ではありません）
• すでに答えがわかっている（確証バイアス）
• MVPをリリースする必要がある（これはMVP以前の事前調査向けです）

---

ファシリテーションの信頼できる情報源

このスキルでは、既定の対話プロトコルとしてworkshop-facilitationを使用してください。

このプロトコルでは、次の内容を定義します。

• セッション開始時の案内と開始モード（ガイド付き、コンテキストの一括入力、最善の推測）
• 平易な表現のプロンプトを使った、1ターンにつき1つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 意思決定ポイントで番号付きの推奨事項を提示
• 通常の質問に対する番号付きのクイック選択式回答オプション（有用な場合はOther (specify)を含める）

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

適用

この対話型スキルでは、コンテキストに基づいた適応型の質問を行い、適切な PoL プローブタイプを推奨します。

---

ステップ 0：コンテキストを把握する

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

検証のニーズに適した PoL プローブタイプを見つけましょう。まず、いくつか状況を教えてください。

1. どのような仮説を検証していますか？ （1文で説明するか、「[ペルソナ]に[X]を行うと、[結果]が得られる」という形式を使ってください）

2. 解消しようとしている具体的なリスクは何ですか？ 例：

• 技術的な実現可能性（「当社の API でリアルタイムデータを処理できるか？」）
• ユーザーのタスク完了（「ユーザーは『エクスポート』ボタンを見つけられるか？」）
• ステークホルダー間の合意（「経営陣はこの方針を承認するか？」）
• エッジケースでの動作（「システムは重複するエントリーをどのように処理するか？」）
• ワークフローの検証（「ユーザーは3ステップのオンボーディングを完了するか？」）

3. どのくらいの時間がありますか？

• 数時間（当日中の検証）
• 1～2日（短期間の試作）
• 3～5日（中程度の作業）
• 1週間以上（長すぎます。小さなプローブに分割することを検討してください）

4. 利用できるリソースは何ですか？ 例：

• エンジニアリングの対応力（開発者1人で1日）
• デザインツール（Figma、Loom、Sora）
• AI／ノーコードツール（ChatGPT Canvas、Replit、Airtable）
• ユーザーへのアクセス（ウェイトリストから10人、ベータ版の顧客5人など）
• 予算（UsabilityHub、Optimal Workshop などに使用）

---

ステップ 1：中心となる問いを特定する

エージェントがユーザーの入力をまとめて尋ねます：

仮説とリスクに基づくと、次のうち、本当に答えを得ようとしている中心的な問いはどれですか？

プローブタイプに対応した5つの選択肢を提示します：

1. 「これを構築できますか？」 — 技術的な実現可能性、API 統合、データの入手可能性、またはサードパーティへの依存に不確実性があります
2. 「ユーザーは煩わしさなくこの作業を完了できますか？」 — 重要な UI 上の操作、フィールドラベル、ナビゲーション、または意思決定ポイントを検証します
3. 「このワークフローでステークホルダーの賛同を得られますか？」 — 複雑なフローを説明したり、経営陣の認識を一致させたり、ストーリーを「説明する」のではなく「テストする」必要があります
4. 「本番環境のリスクなしに、これをモデル化できますか？」 — エッジケースを検討したり、ユーザーの行動をシミュレーションしたり、プロンプトのロジックを安全にテストしたりする必要があります
5. 「このソリューションは、実際のユーザーとの接触に耐えられますか？」 — UX／ワークフローの問題を見つけるために、半機能的なワークフローをユーザーに操作してもらう必要があります

ユーザーの回答： [番号を1つ選ぶか、該当するものがなければ説明してください]

---

ステップ 2：PoL プローブタイプを推奨する

ユーザーの選択に基づき、エージェントが該当するプローブタイプを推奨します：

---

オプション 1 を選択：「これを構築できるでしょうか？」

→ 推奨する検証方法：実現可能性チェック

概要： 技術的リスクを明らかにするための、1～2 日間の試作と破棄を前提としたテストです。誰かを感心させるためではなく、障害となる要因をすばやく見つけることが目的です。

方法：

• 生成 AI のプロンプトチェーン（AI がユースケースに対応できるかをテスト）
• API の簡易テスト（サードパーティとの連携が機能するかを確認）
• データ整合性の確認（データが機能をサポートできるかをチェック）
• サードパーティ製ツールの評価（Zapier／Stripe／Twilio が想定どおりに機能するかをテスト）

期間： 1～2 日

ツール：

• ChatGPT／Claude（プロンプトのテスト）
• Postman／Insomnia（API のテスト）
• Jupyter notebooks（データの調査）
• 概念実証用スクリプト（使い捨てコード）

成功基準の例：

• 合格： API が期待するデータ形式で 200ms 未満に応答する
• 不合格： API がタイムアウトする、またはデータ構造が当社のスキーマと互換性がない
• 学び： 具体的な技術的障害を特定する

破棄計画： 調査結果を記録した後、試作コードをすべて削除します。

次のステップ： この実現可能性チェックを記録する pol-probe アーティファクトを生成しますか？

---

オプション 2 を選択：「ユーザーはストレスなくこの作業を完了できるでしょうか？」

→ 推奨する検証方法：タスクに焦点を当てたテスト

概要： 専門的なテストツールを使い、フィールドラベル、判断ポイント、ナビゲーション、離脱しやすい箇所など、重要な場面を検証します。意見ではなく、観察可能なタスクの完了に焦点を当てます。

方法：

• Optimal Workshop（ツリーテスト、カードソーティング）
• UsabilityHub（5 秒テスト、クリックテスト、選好テスト）
• Maze（ヒートマップを使ったプロトタイプテスト）
• Loom で録画したタスクのウォークスルー（ユーザーに「考えていることを声に出してもらう」）

期間： 2～5 日

ツール：

• Optimal Workshop（月額 200 ドル）
• UsabilityHub（月額 100～300 ドル）
• Maze（無料プランあり）
• Loom（基本機能は無料）

成功基準の例：

• 合格： 80％以上のユーザーが 2 分未満でタスクを完了する
• 不合格： 完了率が 60％未満、または 3 人以上のユーザーが同じ手順で行き詰まる
• 学び： 正確な障害箇所（特定のフィールド、ボタンなど）を特定する

破棄計画： セッションの録画をアーカイブし、学びを記録した後、テスト用プロトタイプを削除します。

次のステップ： このタスクに焦点を当てたテストを記録する pol-probe アーティファクトを生成しますか？

---

オプション 3 を選択：「このワークフローはステークホルダーの賛同を得られるでしょうか？」

→ 推奨する検証方法：ナラティブプロトタイプ

概要： インターフェースをテストするのではなく、ストーリーを伝えます。動画のウォークスルーやスライド資料のストーリーボードを使ってワークフローを説明し、関心度を測定します。これは「説明するか、テストするか」のうちの「説明する」方法であり、検証するのは UI ではなくナラティブです。

方法：

• Loom のウォークスルー（ナレーション付きの画面録画）
• Sora／Synthesia／Veo3（AI で生成する解説動画）
• スライド資料のストーリーボード（イラストを使った PowerPoint／Keynote）
• ストーリーボードのスケッチ（storyboard.md コンポーネントスキルを使用）

期間： 1～3 日

ツール：

• Loom（無料、すばやく作成可能）
• Sora／Synthesia（テキストから動画を生成、有料）
• PowerPoint／Keynote（スライド資料のアニメーション）
• Figma（静的なストーリーボードのフレーム）

成功基準の例：

• 合格： 10 人中 8 人のステークホルダーが「これを使いたい」または「これは問題を解決できる」と答える
• 不合格： ステークホルダーが「なぜこれを使うのでしょうか？」と尋ねる、または別のアプローチを提案する
• 学び： ナラティブのどの部分が響くのか（または響かないのか）を特定する

破棄計画： 動画をアーカイブし、フィードバックを記録した後、関連ファイルを削除します。

次のステップ： このナラティブプロトタイプを記録する pol-probe アーティファクトを生成しますか？

---

選択肢 4 を選択：「本番環境のリスクなしで、これをモデル化できますか？」

→ 推奨プローブ：合成データシミュレーション

概要： シミュレートしたユーザー、合成データ、またはプロンプトロジックのテストを使い、本番環境に触れることなく、エッジケースや未知の未知を探ります。「事後検証より低コストの風洞実験」と考えてください。

方法：

• Synthea（合成患者データの生成）
• DataStax LangFlow（実ユーザーなしでプロンプトロジックをテスト）
• モンテカルロシミュレーション（確率的な結果をモデル化）
• 合成ユーザー行動スクリプト（クリックパターンのシミュレーション、負荷テスト）

期間： 2〜4 日

ツール：

• Synthea（オープンソース、医療分野）
• DataStax LangFlow（プロンプトチェーンのテスト）
• Python + Faker ライブラリ（合成データの生成）
• Locust/k6（合成ユーザーによる負荷テスト）

成功基準の例：

• 合格： システムが 10,000 人の合成ユーザーを 1％未満のエラー率で処理する
• 不合格： エッジケースによってクラッシュや誤った出力が発生する
• 学び： システムを壊すエッジケースを特定する

破棄計画： 合成データを削除し、調査結果をアーカイブして、エッジケースを文書化します。

次のステップ： この合成データシミュレーションを記録する pol-probe 成果物を生成しますか？

---

選択肢 5 を選択：「このソリューションは実際のユーザーとの接触に耐えられますか？」

→ 推奨プローブ：バイブコーディングによる PoL プローブ

概要： Frankensoft スタック（ChatGPT Canvas + Replit + Airtable）を使い、ユーザーが半機能的なワークフローを操作できる程度の仕掛けを作ります。本番環境向けではなく、48 時間以内に UX／ワークフローに関する兆候をつかむために必要な分だけ作ります。

⚠️ 警告： これは最もリスクの高いプローブタイプです。実物らしく見えるため、勢いを成熟度と取り違えるおそれがあります。実際のユーザーとの接触が必要で、ほかの方法では不十分な場合にのみ使用してください。

方法：

• ChatGPT Canvas（迅速な UI 生成）
• Replit（使い捨てコードのホスティング）
• Airtable（偽のデータベース）
• Carrd/Webflow（ランディングページとワークフローのモックアップ）

期間： 2〜3 日

スタックの例：

• ChatGPT Canvas：フォーム UI を生成
• Replit：シンプルな Flask/Node アプリをホスト
• Airtable：フォームの送信内容を保存
• Loom：ユーザーセッションを記録し、事後検証に使用

成功基準の例：

• 合格： ユーザー 10 人中 8 人がワークフローを完了し、重大な混乱が一度も発生しない
• 不合格： ユーザーが行き詰まる、「これは壊れているのですか？」と尋ねる、または途中で離脱する
• 学び： ユーザーが信頼を失う正確なステップを特定する

破棄計画： ユーザーセッション後にすべてのコードを削除し、Loom の録画をアーカイブして、学びを文書化します。

次のステップ： このバイブコーディングによるプローブを記録する pol-probe 成果物を生成しますか？

---

ステップ 3：コンポーネントスキルを適用する

エージェントの提案：

あなたの仮説には ［選択したプローブタイプ］ の使用をおすすめします。次のどれを希望しますか？

1. 完全な pol-probe 成果物を生成する（pol-probe.md テンプレートを使用）。仮説、成功基準、期間、破棄計画を含めます。
2. このプローブタイプの実行手順を確認する（ツール、方法、ユーザー募集）。
3. 先に仮説を練り直す（範囲が広すぎる、または曖昧に見える場合）。

ユーザーが選択肢を選び、エージェントがそれに応じて実行します。

---

ステップ 4：練り直す、または反復する（任意）

ユーザーが確信を持てない場合、または仮説の範囲が広すぎる場合：

エージェントの質問：

仮説の範囲が広いか、一度に複数のことをテストしているようです。PoL プローブは、範囲が狭く、反証可能な場合に最も効果を発揮します。いくつか確認させてください。

確認の質問：

1. 最初にテストできる最小の要素は何ですか？（変数を 1 つに絞ります）
2. 「失敗」とはどのような状態ですか？（失敗を説明できなければ、成功を測定できません）
3. これはユーザーの行動、技術的な実現可能性、利害関係者間の合意のどれをテストしますか？（焦点を 1 つ選びます）

その後、エージェントは練り直した仮説に基づいて、プローブタイプを再度提案します。

---

例

例 1: タスク重視型テストの選択

ユーザーコンテキスト:

• 仮説: 「ユーザーは 3 分以内に当社のチェックアウトフローを完了できる」
• リスク: モバイルでの高いカート放棄率
• タイムライン: 3 日
• リソース: UsabilityHub アカウント、ウェイトリストからのユーザー 20 名

エージェントの推論:

• 核心的な問い: 「ユーザーはこのジョブを摩擦なく完了できるか？」
• リスクはタスク完了（観察可能な行動）であり、技術的な実現可能性ではない
• タイムラインはタスク重視型テスト（2〜5 日）に適合する

推奨: UsabilityHub を使用したタスク重視型テスト

• 手法: モバイルユーザーを対象とした Maze プロトタイプテスト
• 成功基準: 80% 以上が 3 分未満でチェックアウトを完了
• 廃棄: ヒートマップを分析した後、プロトタイプを削除する

---

例 2: 実現可能性チェックの選択

ユーザーコンテキスト:

• 仮説: 「GPT-4 を使用してサポートチケットを 5% 未満のエラー率で自動タグ付けできる」
• リスク: AI が業界固有の専門用語を扱えるか不明
• タイムライン: 1 日
• リソース: 過去のサポートチケット 100 件、ChatGPT API へのアクセス

エージェントの推論:

• 核心的な問い: 「これは構築できるか？」
• リスクは技術的な実現可能性（AI の能力）であり、ユーザー行動ではない
• タイムラインは短い（1 日 = スパイクの領域）

推奨: プロンプトエンジニアリングスパイクを使用した実現可能性チェック

• 手法: 100 件のチケットを GPT-4 プロンプトチェーンに通し、エラー率を測定する
• 成功基準: 誤分類されたチケットが 5% 未満
• 廃棄: 調査結果を文書化した後、スパイクコードを削除する

結果: エラー率は 18% でした。機能を構築しないことを決定しました。6 週間の開発を節約しました。

---

例 3: ナラティブプロトタイプの選択（Vibe-Coded ではない）

ユーザーコンテキスト:

• 仮説: 「エンタープライズのバイヤーは当社のマルチテナントセキュリティモデルを理解するだろう」
• リスク: 複雑な技術的概念には説明が必要
• タイムライン: 2 日
• リソース: Loom、エンタープライズ見込み客 5 名

エージェントの推論:

• 核心的な問い: 「このワークフローはステークホルダーの賛同を得られるか？」
• リスクは理解・合意であり、タスク完了ではない
• 機能するプロトタイプを構築するのは過剰投資になる（2 日 = 説明するだけで十分）

推奨: Loom ウォークスルーを使用したナラティブプロトタイプ

• 手法: 図を用いてセキュリティモデルを説明する 5 分間の Loom
• 成功基準: 見込み客 5 名中 4 名が追加の質問なしに「理解できた」と言う
• 廃棄: 5 回のセッション後に動画をアーカイブする

なぜ Vibe-Coded プローブではないのか: ユーザーにセキュリティ設定を操作してもらう必要はなく、その概念を理解してもらう必要があります。ナラティブの方が安価で迅速です。

---

例 4: プロトタイプシアターの回避

ユーザーコンテキスト:

• 仮説: 「洗練されたデモを見せれば幹部は予算を承認するだろう」
• リスク: 社内政治
• タイムライン: 3 週間
• リソース: デザインチーム全員

エージェントの回答:

⚠️ これはプロトタイプシアターであり、PoL プローブではありません。

あなたはユーザー行動や技術的な実現可能性ではなく、社内政治をテストしています。PoL プローブはプロダクトのリスクを排除するものであり、組織のリスクではありません。

推奨: プロトタイプを完全にスキップしてください。代わりに:

1. ナラティブプロトタイプ（1 日で作成する Loom ウォークスルー）を使用して概念を説明する
2. ターゲットユーザー 5 名（幹部ではなく）でテストして仮説を検証する
3. 幹部には洗練されたデモではなく、ユーザーのフィードバックを提示する

幹部がデモを必要とする場合は、実際のユーザーで仮説を検証した後に構築してください。

---

よくある落とし穴

1. ツールの使いやすさに基づく選択

失敗モード: 「私は Figma を使い慣れているので、UI プロトタイプをデザインしよう」（たとえデザインがリスクでなくても）。

結果: 間違ったものを検証し、実際のリスクを見逃す。

修正: まず核心的な問いに答え、それから手法を選ぶ。実現可能性チェックが必要なのにデザインツールしか知らない場合は、エンジニアと 1 日ペアを組む。

---

2. コードへのデフォルト

失敗モード: 「とりあえず構築して、どうなるか見てみよう。」

結果: 間違った仮説を検証していたことに気づく前に 2 週間の開発。

修正: 問いかける: 「最も厳しい真実を教えてくれる、最も安価なプロトタイプは何か？」通常それはコードではありません。

---

3. バイブコーディングで作ったプローブをMVPと混同する

失敗パターン： バイブコーディングで作ったプローブが「本物らしく見える」ため、チームが本番コードのように扱ってしまいます。

結果： スコープクリープ、技術的負債、廃棄への抵抗が生じます。

対策： 作り始める前に廃棄日を設定します。バイブコーディングで作ったプローブは、設計上 フランケンソフト です。粗削りな状態を楽しみ、学びを得たら削除しましょう。

---

4. 複数のことを一度にテストする

失敗パターン： 「ワークフロー、価格設定、UIを1つのプローブでテストしましょう。」

結果： 結果が曖昧になり、どの変数が失敗の原因だったのかわからなくなります。

対策： 1つのプローブにつき、仮説は1つです。仮説が3つあるなら、プローブを3つ実行します。

---

5. 成功基準を省略する

失敗パターン： 「見ればわかります。」

結果： 厳しい真実ではなく、意見や見栄えだけの指標に終わります。

対策： 作り始める前に成功基準を書きます。「合格」「不合格」「学び」のしきい値を定義します。

---

参考資料

関連スキル

• pol-probe（コンポーネント）— PoLプローブを文書化するためのテンプレート
• problem-statement（コンポーネント）— 検証方法を選ぶ前に問題を定義します
• problem-framing-canvas（インタラクティブ）— 検証前にMITREの問題定義を行います
• discovery-process（ワークフロー）— 検証フェーズでPoLプローブを使用します
• epic-hypothesis（コンポーネント）— エピックを検証可能な仮説に変換します

外部フレームワーク

• Jeff Patton — User Story Mapping（リーンな検証の原則）
• Marty Cagan — Inspired（2014年のプロトタイプの種類に関するフレームワーク）
• Dean Peters — Vibe First, Validate Fast, Verify Fit（Dean PetersのSubstack、2025年）

プローブの種類別ツール

• 実現可能性： ChatGPT/Claude、Postman、Jupyter
• タスク重視： Optimal Workshop、UsabilityHub、Maze
• ナラティブ： Loom、Sora、Synthesia、PowerPoint
• 合成データ： Synthea、DataStax LangFlow、Faker
• バイブコーディング： ChatGPT Canvas、Replit、Airtable、Carrd