prototyping-pretotyping

プロトタイピングとプレトタイピング

目次

1. ワークフロー
2. よくあるパターン
3. 忠実度の段階
4. ガードレール
5. クイックリファレンス

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Prototyping Progress:
- [ ] Step 1: Identify riskiest assumption to test
- [ ] Step 2: Choose pretotype/prototype approach
- [ ] Step 3: Design and build minimum test
- [ ] Step 4: Run experiment and collect data
- [ ] Step 5: Analyze results and decide (pivot/persevere/iterate)

ステップ 1：最もリスクの高い仮説を特定する

すべての仮説（需要、価格設定、実現可能性、ワークフロー）を列挙し、リスク（誤っている確率 × 誤っていた場合の影響）に基づいて順位を付けます。最もリスクの高い仮説から検証します。分野ごとの一般的な仮説については、よくあるパターンを参照してください。

ステップ 2：アプローチを選ぶ

検証方法を仮説と利用可能な時間・予算に合わせます。適切な忠実度の選び方については、忠実度の段階を参照してください。実験の設計にはresources/template.mdを使用してください。

ステップ 3：最小限のテストを設計して作成する

仮説を検証する最もシンプルな成果物（ランディングページ、紙のプロトタイプ、手作業によるサービス提供など）を作成します。具体的な手法（フェイクドア、コンシェルジュ、Wizard of Oz、ペーパープロトタイピング）については、resources/methodology.mdを参照してください。

ステップ 4：実験を実施する

テストを公開し、参加者を募り、定量データ（登録数、クリック数、支払い数）と定性フィードバック（インタビュー、観察）を収集します。最小限必要なデータ（定性調査では n=5～10、定量的な信頼性の確保では n=100 以上）を目指してください。

ステップ 5：分析して判断する

結果を成功基準（例：「コンバージョン率 10% で需要を検証」）と比較します。判断は、ピボット（仮説が誤っていたため方向転換）、継続（仮説が検証されたため構築）、または反復（結果が混在しているため改善して再テスト）です。

よくあるパターン

仮説の種類別：

需要に関する仮説（「人々はこれを求めている」）：

• テスト：フェイクドア（「今すぐ購入」から「近日公開」へ遷移するランディングページ）、先行予約、ウェイティングリストへの登録
• 成功基準：X% のコンバージョン、Z 日間で Y 件の登録
• 例：「2 週間で訪問者の 10% がウェイティングリストに登録」→ 需要を検証

価格設定に関する仮説（「人々は $X を支払う」）：

• テスト：ランディングページに価格を掲載する、複数の価格帯を提示する、価格の A/B テストを実施する
• 成功基準：目標価格で Z% のコンバージョン
• 例：「月額 $49 で 5% がコンバージョン」→ 価格設定を検証

ワークフローに関する仮説（「これはユーザーの課題を直感的な方法で解決する」）：

• テスト：紙のプロトタイプ、クリック可能なプロトタイプを使ったタスク完了テスト
• 成功基準：X% が助けを借りずにタスクを完了し、エラーが Y 件未満
• 例：「10 人中 8 人が、エラーなしで 2 分未満にチェックアウトを完了」→ ワークフローを検証

実現可能性に関する仮説（「これを構築・拡張できる」）：

• テスト：技術的なスパイク、実データを使った概念実証、まず手作業でコンシェルジュサービスを提供する
• 成功基準：パフォーマンスが目標を満たし、コストが予算内に収まる
• 例：「100 リクエスト/秒で API が 500 ミリ秒未満に応答」→ アーキテクチャを検証

価値提案に関する仮説（「顧客は代替案よりも当社のアプローチを好む」）：

• テスト：メッセージングの A/B テスト、異なる価値提案を使ったフェイクドア、競合比較
• 成功基準：X% が代替案よりも当社のアプローチを選ぶ
• 例：「手動のキュレーションより AI を活用した方法を 60% が選ぶ」→ 差別化を検証

忠実度の段階

質問に応じて適切な忠実度を選びましょう：

レベル 0 - プレトタイプ（数時間〜数日、$0-100）：

• 内容：実際に何かを作る前に、まずはそれらしく見せます
• 用途：需要、価格設定、価値提案に関する仮説を検証します
• 方法：サインアップ用のランディングページ、フェイクドアテスト、手動のコンシェルジュ対応、動画モックアップ
• 例：Dropboxは製品を作る前に動画で紹介しました（3〜4分の動画で、一夜にして登録者数が7万人から7万5千人に増加）
• 長所：最も速く、最も安価で、意見ではなく実際の行動を検証できます
• 短所：ワークフローやユーザビリティを詳しく検証できず、欺きすぎると倫理的な懸念が生じます

レベル 1 - ペーパープロトタイプ（数時間〜数日、$0-50）：

• 内容：手描きのスケッチ、印刷した画面、インデックスカード
• 用途：ワークフロー、情報アーキテクチャ、画面構成を検証します
• 方法：ユーザーが紙の上で「クリック」し、画面を入れ替えながら、混乱する箇所を観察します
• 例：銀行アプリ - 紙の画面を10枚用意し、ユーザーが小切手の入金をシミュレーションして、ワークフローの問題を3つ特定します
• 長所：非常に速く反復でき（数分で描き直せます）、見た目の仕上がりではなく構成に集中できます
• 短所：実際の操作（ジェスチャー、アニメーション）を検証できず、ユーザーには「偽物」に感じられます

レベル 2 - クリック可能なプロトタイプ（数日〜1週間、$100-500）：

• 内容：Figma、InVision、Adobe XDで作成するインタラクティブなモックアップ（実際のコードは使いません）
• 用途：ユーザーフロー、UIパターン、インタラクションデザインを検証します
• 方法：ユーザーにタスクを完了してもらい、成功率・所要時間・エラーを測定して、フィードバックを収集します
• 例：ECサイトのチェックアウト - 画面を8枚用意し、20人のユーザーをテストしたところ、配送方法の選択時に15％が離脱したため、コーディング前に修正します
• 長所：本物らしく見え、変更が簡単で、現実的なインタラクションを検証できます
• 短所：パフォーマンス、スケーラビリティ、バックエンドの複雑さは検証できません

レベル 3 - コード化されたプロトタイプ（数週間〜1か月、$1K-10K）：

• 内容：機能を限定し、データの一部と簡略化した実装を使った、動作するソフトウェアです
• 用途：技術的な実現可能性、パフォーマンス、統合の複雑さを検証します
• 方法：実際のユーザーに実際のタスクを実行してもらい、レイテンシやエラーを測定し、アーキテクチャを検証します
• 例：検索エンジン - 1,000万件ではなく1万件のドキュメントを使い、50人のユーザーで応答時間が1秒未満であることを確認し、アプローチを検証します
• 長所：実際の技術的制約を検証し、統合の問題を明らかにします
• 短所：より費用と時間がかかり、間違っていた場合に破棄しにくくなります

レベル 4 - 実用最小限の製品（数か月、$10K-100K+）：

• 内容：実際の顧客に中核的な価値を届ける、最もシンプルなバージョンです
• 用途：仮説の大部分が検証され、市場からのフィードバックを得る準備ができた段階です
• 方法：小規模なセグメントに公開し、継続率や収益を測定して、データに基づいて反復します
• 例：Instagram v1 - 写真フィルターのみ（動画、ストーリーズ、リールはなし）を、小規模なグループに公開しました
• 長所：実際の市場での検証、収益、学びが得られます
• 短所：費用がかかり、期間も長く、公開に伴う責任が生じます

ガードレール

品質を確保する：

1. 最もリスクの高い仮説を最初に検証する：確信していることはテストしません

   • ✓ 「顧客はXドルを支払うか？」（不確実性が高い）を、「ボタンを青くできるか？」（些細なこと）より先にテストします
   • ❌ 中核となる価値を検証する前に、細かな点をテストします

2. 問いに合わせて忠実度を調整する：目の前の問いに対して、作り込みすぎないようにします

   • ✓ ワークフローをテストするなら紙のプロトタイプ（数時間）、レイテンシをテストするならコード化したプロトタイプ（数週間）を使います
   • ❌ ユーザーが配色を気に入るかテストするために、コード化したプロトタイプを作ります（やりすぎです）

3. テスト前に成功基準を設定する：確証バイアスを避けます

   • ✓ 「コンバージョン率10％で需要ありと判断する」（テスト前に決めます）
   • ❌ 「コンバージョン率7％？かなりいいですね！」（テスト後に基準を変えます）

4. 実際のターゲットユーザーでテストする：友人や家族は代表的なユーザーではありません

   • ✓ ターゲット層から参加者を募集します（例：B2B SaaS なら企業の IT 購買担当者）
   • ❌ 参加できる人なら誰でもテストします（礼儀正しい創業者の友人など）

5. 意見ではなく行動を観察する：人の発言より、実際にしたことを重視します

   • ✓ 「50％が『今すぐ購入』をクリックしたが、支払いを完了した人は0％だった」（実際の行動 → 価格設定や購入時の摩擦の問題）
   • ❌ 「ユーザーは月額99ドルを払うと言っていた」（意見であり、信頼できる予測材料ではありません）

6. 偽装について透明性を保つ：倫理的なプレトタイピングを行います

   • ✓ 「先行アクセスに登録」や「近日公開」（正直な表現です）
   • ❌ 偽の製品でクレジットカードに課金する、作る予定のない機能を約束する（詐欺です）

7. プロトタイプは破棄する：プロトタイプのコードを本番環境に使わないようにします

   • ✓ 検証後、適切なアーキテクチャで作り直します
   • ❌ プロトタイプのコードをリリースします（技術的負債、セキュリティ問題、スケーラビリティの問題につながります）

8. すばやく反復する：高価なテストを1回行うより、低コストのテストを複数回行います

   • ✓ 1週間で紙のプロトタイプを5つ作ります（5つのアプローチをテストします）
   • ❌ 1か月かけてコード化したプロトタイプを1つ作ります（1つのアプローチに固定されます）

クイックリファレンス

リソース：

• クイックスタート：resources/template.md - プレトタイプ／プロトタイプ実験のテンプレート
• 高度な手法：resources/methodology.md - フェイクドア、コンシェルジュ、Wizard of Oz、ペーパープロトタイピング、A/B テスト
• 品質チェック：resources/evaluators/rubric_prototyping_pretotyping.json - 評価基準

成功基準：

• ✓ リスクで順位付けした、最もリスクの高い仮説を3～5個特定している（誤っている確率 × 誤っていた場合の影響）
• ✓ 必要最低限の忠実度で、最もリスクの高い仮説をテストしている
• ✓ テスト前に定量的な成功基準を設定している（例：「コンバージョン率10％」）
• ✓ 実際のターゲットユーザーを募集している（定性的調査では n=5～10、定量的調査では n=100 以上）
• ✓ 意見だけでなく、行動データ（クリック、コンバージョン、タスク完了）を収集している
• ✓ ピボット／継続／反復の判断を下せるほど、結果が明確になっている
• ✓ 学びを文書化し、チームと共有している

よくある間違い：

• ❌ リスクの高い仮説より先に、些細な仮説をテストする
• ❌ 作り込みすぎる（ランディングページで十分なのに、コード化したプロトタイプを作る）
• ❌ 成功基準がない（テスト後に基準を変える）
• ❌ 対象ユーザーを間違えてテストする（ターゲット層ではなく、友人や家族を使う）
• ❌ 行動ではなく、意見（「ユーザーは気に入ったと言っていた」）に頼る
• ❌ 分析麻痺に陥る（テスト前に完璧なプロトタイプを作ろうとする）
• ❌ プロトタイプのコードをリリースする（技術的負債の大惨事につながります）
• ❌ 低コストのテストを順次／並行して複数実施できるのに、1つだけテストする

代替手法を使う場合：

• A/B テスト：既存の製品やトラフィックがあり、複数のバリエーションを比較したい場合
• アンケート：大規模に定量的な意見を集めたい場合（ただし、意見 ≠ 行動であることを忘れないでください）
• 顧客インタビュー：ソリューションのテストではなく、問題や状況を理解したい場合
• ベータテスト：製品がほぼ完成しており、仕上がりやバグについてフィードバックが必要な場合
• スモークテスト：構築前に関心を測定するもので、プレトタイプと同じです