pol-probe

目的

Proof of Life（PoL）プローブを定義し、説明します。これは、高コストな開発に取りかかる前に厳しい現実を明らかにするための、軽量で使い捨ての検証成果物です。本番品質のソフトウェアを作らずに、特定のリスクを取り除いたり、絞り込んだ仮説を検証したりする必要がある場合に使用します。PoL プローブは偵察ミッションであり、MVP ではありません。拡張するのではなく、削除することを前提としています。

このフレームワークは、プロトタイプ劇場（関係者を感心させるものの、何も学べない高コストなデモ）を防ぎ、検証方法を実際の学習目標に合わせることを徹底します。

入力

最適な入力： 検証したい仮説またはリスク。 あると役立つ情報： 考えを変える根拠、利用可能な時間やリソース、すでに検証したこと。

呼び出し時に渡された情報（スキル名の後のテキスト、貼り付けられたコンテキストのダンプ、または追記された ARGUMENTS: 行など）は、すでに提示された回答として扱います。その情報を使い、該当する内容は再度質問しないでください。

何も持たずに始めても大丈夫です。 このスキルでは、プローブを設計する前に、仮説とその中で最もリスクの高い前提を尋ねます。

呼び出し例： Define a PoL probe: we believe restaurant managers will photograph invoices daily if it auto-updates food costs.

主な概念

PoL プローブとは？

Proof of Life（PoL）プローブとは、できるだけ低コストかつ短時間で、特定の問いに答えるために意図的に設計された、使い捨ての検証実験です。製品でも、MVP でも、パイロットでもありません。真実を見極めるための、的を絞ったミッションです。

由来： Dean Peters（Productside）が提唱。Marty Cagan による 2014 年のプロトタイプの種類に関する研究と、Jeff Patton の原則に基づいています。「アイデアを検証する最も高コストな方法は、本番品質のソフトウェアを作ることです。」

---

5 つの必須特性

すべての PoL プローブは、次の基準を満たす必要があります。

特性	意味	重要な理由
軽量	リソースへの投資を最小限に抑える（数週間ではなく、数時間から数日）	高コストだと、データが中止を示していても中止を避けてしまいます
使い捨て	拡張ではなく、削除を明確に計画する	サンクコストの誤謬やスコープクリープを防ぎます
範囲を限定	1 つの具体的な仮説またはリスクを検証する	範囲の広い実験では、結果が曖昧になります
容赦なく正直	見栄えのよい指標ではなく、厳しい現実を明らかにする	耳当たりのよいデータは役に立ちません
小さく集中	偵察ミッションであり、MVP には決してしない	対象範囲が小さいほど、学習サイクルが速くなります

アンチパターン： 「プロトタイプ」が洗練されすぎて削除しにくいと感じるなら、それは PoL プローブではなく、プロトタイプ劇場です。

---

PoL プローブと MVP の違い

観点	PoL プローブ	MVP
目的	絞り込んだ仮説の検証を通じて意思決定のリスクを下げる	アイデアを正当化したり、ロードマップの方向性を擁護したりする
範囲	1 つの問い、1 つのリスク	出荷可能な最小限の製品の追加機能
寿命	数時間から数日で、その後削除	数週間から数か月で、その後改良
対象	社内チームと限定されたユーザーサンプル	本番環境の実際の顧客
忠実度	シグナルを捉えるのに必要なだけの錯覚	本番品質（またはそれに近い品質）
成果	うまくいかないことを学ぶ	うまくいくことを学び、それを出荷する

重要な違い： PoL プローブはMVP 前の偵察です。MVP を構築すべきかどうかを判断するためにプローブを実施するのであり、何かをリリースするために実施するのではありません。

---

5 種類のプロトタイプ

ツールの使い慣れ具合ではなく、仮説に合ったプローブの種類を選びましょう。

種類	主な問い	期間	ツール／手法	使用する場面
1. 実現可能性の確認	「これを構築できますか？」	1～2 日	GenAI のプロンプトチェーン、API テスト、データ整合性の一斉検査、スパイクアンドデリートのコード	技術的なリスクが不明で、サードパーティへの依存関係が不明確な場合
2. タスク重視のテスト	「ユーザーはスムーズにこの作業を完了できますか？」	2～5 日	Optimal Workshop、UsabilityHub、タスクフロー	重要な場面（フィールドラベル、意思決定ポイント、離脱ゾーン）の検証が必要な場合
3. ナラティブプロトタイプ	「このワークフローは関係者の賛同を得られますか？」	1～3 日	Loom のウォークスルー、Sora／Synthesia の動画、スライド資料のストーリーボード	「テスト」ではなく「語る」必要がある場合。ストーリーを共有し、関心度を測定します
4. 合成データシミュレーション	「本番環境のリスクなしでこれをモデル化できますか？」	2～4 日	Synthea（ユーザーシミュレーション）、DataStax LangFlow（プロンプトロジックのテスト）	エッジケースの探索、未知の未知の発見
5. Vibe-Coded PoL プローブ	「このソリューションは実際のユーザーとの接触に耐えられますか？」	2～3 日	ChatGPT Canvas + Replit + Airtable = 「Frankensoft」	ワークフロー／UX に関するユーザーフィードバックは必要だが、本番品質のコードは不要な場合

鉄則： 「最も厳しい真実を示してくれる、最も安価なプロトタイプを使いましょう。痛みを感じないなら、ただの見せ物かもしれません。」

---

PoL プローブを使用する場面

✅ 次の場合は PoL プローブを使用します：

• 検証する対象として、具体的で反証可能な仮説がある
• 特定のリスクが次の意思決定を妨げている（技術的な実現可能性、ユーザーのタスク完了、関係者の支持）
• 厳しい真実をすばやく（数週間ではなく数日以内に）知る必要がある
• 本番ソフトウェアの構築が時期尚早、または無駄になる
• 開始前に「失敗」がどのような状態かを説明できる

❌ 次の場合は PoL プローブを使用しません：

• 経営幹部に好印象を与えようとしている（それはプロトタイプの見せ物です）
• すでに答えが分かっていて、ただ確証を得たいだけである（それは確証バイアスです）
• 明確な仮説や廃棄計画を説明できない
• 学習目標の範囲が広すぎる（「顧客はこれを気に入るでしょうか？」）
• 難しい決断を避けるために使おうとしている

---

適用

全体の記入用テンプレートは template.md を使用してください。

PoL プローブのテンプレート

プローブを記録するには、この構成を使用してください：

# PoL Probe: [Descriptive Name]

## Hypothesis
[One-sentence statement of what you believe to be true]
Example: "If we reduce the onboarding form to 3 fields, completion rate will exceed 80%."

## Risk Being Eliminated
[What specific risk or unknown are you addressing?]
Example: "We don't know if users will abandon signup due to form length."

## Prototype Type
[Select one of the 5 flavors]
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [x] Vibe-Coded PoL Probe

## Target Users / Audience
[Who will interact with this probe?]
Example: "10 users from our early access waitlist, non-technical SMB owners."

## Success Criteria (Harsh Truth)
[What truth are you seeking? What would prove you wrong?]
- **Pass:** 8+ users complete signup in under 2 minutes
- **Fail:** <6 users complete, or average time exceeds 5 minutes
- **Learn:** Identify specific drop-off fields

## Tools / Stack
[What will you use to build this?]
Example: "ChatGPT Canvas for form UI, Airtable for data capture, Loom for post-session interviews."

## Timeline
- **Build:** 2 days
- **Test:** 1 day (10 user sessions)
- **Analyze:** 1 day
- **Disposal:** Day 5 (delete all code, keep learnings doc)

## Disposal Plan
[When and how will you delete this?]
Example: "After user sessions complete, archive recordings, delete Frankensoft code, document learnings in Notion."

## Owner
[Who is accountable for running and disposing of this probe?]

## Status
- [ ] Hypothesis defined
- [ ] Probe built
- [ ] Users recruited
- [ ] Testing complete
- [ ] Learnings documented
- [ ] Probe disposed

---

品質チェックリスト

PoL プローブを開始する前に、次の項目を確認してください：

• 軽量： これを 1～3 日で構築できますか？
• 使い捨て： 廃棄日を決めていますか？
• 範囲が狭い： 仮説を 1 つだけテストしますか？
• 容赦なく正直： 間違っていた場合、データは痛みを伴うものになりますか？
• 小規模で焦点が明確： MVP より小さいものですか？
• 反証可能： 「失敗」がどのような状態かを説明できますか？
• 担当者が明確： 実行と廃棄に責任を持つ人が 1 人いますか？

どれか 1 つでも「いいえ」であれば、プローブを見直すか、そもそも必要なのかを再検討してください。

---

例

PoL プローブの詳しい例は examples/sample.md を参照してください。

ミニ例の抜粋：

**Hypothesis:** Users can distinguish "archive" vs "delete"
**Probe Type:** Task-Focused Test
**Pass:** 80%+ correct interpretation

よくある落とし穴

• 反証可能な仮説を 1 つテストする代わりに、「ユーザーはこれを気に入るでしょうか？」という広範な実験を行う
• PoL プローブをプロトタイプ版 MVP として扱い、廃棄を拒む
• 居心地の悪い真実を避けるために、見栄えだけの指標を使う
• テスト開始前に失敗のしきい値を定義しない
• 仮説より先にツールを選ぶ

参考資料

関連スキル

• pol-probe-advisor（対話型）— 使用するプロトタイプの種類を選ぶための意思決定フレームワーク
• discovery-process（ワークフロー）— 検証フェーズで PoL プローブを使用します
• problem-statement（コンポーネント）— PoL プローブを作成する前に問題を定義します
• epic-hypothesis（コンポーネント）— PoL プローブでテストする前に仮説を組み立てます

外部フレームワーク

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

言及されているツール

• 実現可能性： GenAI（ChatGPT、Claude）、APIテストツール
• タスク重視： Optimal Workshop、UsabilityHub
• ナラティブ： Loom、Sora、Synthesia、Veo3（テキストから動画を生成）
• 合成データ： Synthea（患者シミュレーション）、DataStax LangFlow
• バイブコーディング： ChatGPT Canvas、Replit、Airtable、Carrd