engineering-rapid-prototyper

ラピッドプロトタイピングガイド

概要

このガイドでは、迅速な概念実証の開発と MVP の作成について説明します。仮説を検証するプロトタイプの構築、A/B テストの設定、または本番環境向けの堅牢性よりもデプロイの速さを優先する迅速な開発スタックの選択に利用してください。

スタック選択ガイド

ツールの選び方

• 認証が必要な場合は、すぐに設定できる Clerk または NextAuth を使用してください。プロトタイプでカスタム認証を構築してはいけません。仮説の検証にユーザーアカウントが不要なら、認証自体を省略してください。
• データベースが必要な場合は、ホスティング、スキーマ管理、行レベルセキュリティをすぐに利用できる Prisma + Supabase を使用してください。テスト用に保存するデータが <100 件で済むプロトタイプなら、JSON ファイルまたは localStorage を使用し、データベースを設定しないでください。
• デプロイが必要な場合は、すぐにホスティングでき、すべての PR にプレビュー URL を用意できる Vercel を使用してください。プロジェクト開始から 2 時間以内に最初のデプロイを行ってください。
• 要件をノーコード／ローコードで満たせる場合は、それを使用してください。カスタムコードよりも検証までの速さが重要です。
• 開発では、まずコア機能を実装し、仕上げやエッジケースへの対応は後回しにしてください。ハッピーパスがエンドツーエンドで動く前にエラー処理を書いているなら、手を止めてください。

スコープの判断基準

• データベースのテーブル数は最大 5 つです。スキーマに 5 つを超えるテーブルが必要なら、作り込みすぎです。スコープを縮小するか、データモデルを簡素化してください。
• 機能数は最大 3～5 個です。機能リストが 5 個を超える場合は、仮説への影響度で順位を付け、優先度の低いものを削ってください。プロトタイプでは、5 つの仮説を中途半端に検証するのではなく、1 つの仮説をしっかり検証します。
• ページ／ルート数は最大 8 つです。それ以上必要なら、ビューを統合するか、機能を削ってください。
• カスタム UI コンポーネントはゼロにしてください。shadcn/ui、Radix などを使用してください。ライブラリにコンポーネントが存在しない場合は、既存のものに合わせてデザインを簡素化してください。
• CRUD と 1 つのビジネスルールを超えるカスタムバックエンドロジックは禁止です。プロトタイプに複雑なバックエンド処理（キュー、スケジュールされたジョブ、複数ステップのワークフロー）が必要なら、現実的なダミーデータを返すシンプルなエンドポイントで代用してください。
• 最適化はしないでください。キャッシュ、CDN の設定、データベースのインデックス、遅延読み込み、コード分割は不要です。これらは本番環境向けの課題です。プロトタイプはデモに十分な速さであればよく、それ以上は必要ありません。

中止基準

• セットアップ（プロジェクト初期化 → 初回デプロイ）に 3 時間を超える場合、スタックが複雑すぎます。よりシンプルな方法に切り替えてください。
• 2 日経ってもプロトタイプでコア仮説を検証できない場合は、仮説ではなくプロトタイプを設計し直してください。
• 1 つの機能の実装に 1 日を超える場合、その機能はプロトタイプには複雑すぎます。簡素化するか、静的データで代用してください。
• テストを書いているなら、プロトタイプモードから外れています。プロトタイプは使い捨てです。テストは、残すつもりのコードに対して書くものです。

推奨スタック

• フレームワーク: Next.js 14+ (App Router)
• UI: shadcn/ui + react-hook-form + Zod validation
• 状態管理: Zustand（クライアント側の状態が必要な場合のみ。サーバーコンポーネント + サーバーアクションを優先）
• データベース: Prisma + Supabase（仮説の検証に永続化が必要な場合のみ）
• 認証: Clerk または NextAuth（仮説にユーザーの識別が含まれる場合のみ）
• アニメーション: Framer Motion（デモに限る。内部テストのみなら省略）
• デプロイ: Vercel

完全な package.json と shadcn/ui のインストールコマンドについては、スタックのセットアップを参照してください。

ワークフロー

0～2 時間目：仮説とセットアップ

• 仮説を 1 文で書いてください。「[ユーザー] は [理由] により [行動] すると考え、[指標] で測定します。」この文を書けないなら、開発を始める準備ができていません。
• scripts/scaffold.sh または npx create-next-app でプロジェクトのひな形を作成します。shadcn/ui をインストールします。空の状態で Vercel にデプロイします。これを <2 時間で完了してください。
• 認証が必要なら Clerk を設定します（15 分）。データベースが必要なら Supabase プロジェクトを作成し、prisma db push を実行します（20 分）。仮説の検証にどちらも不要なら、両方省略してください。

Hour 2-8: コアフロー（1日目）

• 最も重要なユーザーフローを、入口 → コアアクション → 表示される結果まで一貫して構築します。追加機能、設定、エッジケースには手を出しません。
• データの取得にはサーバーコンポーネントとサーバーアクションを使用します。インタラクティブ性が必要な場合にのみ、クライアントコンポーネントを追加します。
• 仮説に関係しないものはすべてハードコードします。シードデータ、プレースホルダー画像、リアルなダミーコンテンツを使用します。機能に未設定の外部 API が必要な場合は、サーバーアクションからモックデータを返します。
• 1日目の終わりまでに Vercel にデプロイします。1日目に実際のユーザーが操作できるプロトタイプを用意します。

Hour 8-20: 補助機能（2〜3日目）

• 補助機能を2〜4個、1つずつ追加します。機能を追加するたびにデプロイします。機能によってデプロイに失敗した場合は、すぐに元に戻します。30分を超えてデバッグしないでください。
• フィードバックの仕組みを追加します。シンプルなフォーム（shadcn/ui の textarea と Supabase に書き込むサーバーアクション）または Hotjar/PostHog のスニペット（コード3行）のどちらかを使用します。
• A/B テストが必要な場合は、Vercel Edge Config またはシンプルな Cookie ベースの振り分けを使用します。本格的な実験プラットフォームは使用しません。

Hour 20-24: テストと判断（3〜4日目）

• 対象ユーザー5〜10人に共有します。24〜48時間、様子を観察するかフィードバックを集めます。
• 0時間目に定義した仮説の指標に照らして評価します。指標が良好なら、本番ビルドを計画します。悪ければ、仮説を転換するか、プロトタイプを終了するかを判断します。
• プロトタイプの改良を1週間以上続けないでください。1週間後には、本番品質で再構築するか、アーカイブするかを決めます。

フィードバックフォームコンポーネントと A/B テスト用フックについては、コード例を参照してください。

検証フィードバックループ

プロトタイプは問いに答えるためにあります。実際に答えを得られるよう、次の手順に従ってください。

• 構築前：仮説、指標、成功／失敗のしきい値を書き出します。例：「テストユーザーの30％超が、サポートなしでチェックアウトフローを完了できれば、UX の仮説が検証されたと判断する。」
• 構築中：機能を追加するたびにデプロイし、実際のユーザーがその機能をテストできるか確認します。最初から最後までクリックして操作できなければ、完成ではありません。
• 1日目のチェックポイント：デプロイ済みのプロトタイプを1人（自分またはチームメイト）に共有します。説明なしでコアフローを完了できますか？できない場合はフローに問題があります。機能を追加する前に修正します。
• 2〜3日目のチェックポイント：対象ユーザー5〜10人に共有します。様子を観察するか、フィードバックを集めます。ユーザーが同じステップで混乱するなら、そこが障害になっています。そのステップだけを修正し、機能を追加しないでください。
• 判断ポイント（3〜5日目）：仮説の指標を測定します。結果は次の3つです。
  • 指標達成：仮説が検証されました。学びを記録し、プロトタイプをアーカイブして、本番用スキルを使った本番計画を開始します。
  • 指標に近いが未達：1回だけ改善できます。最大の摩擦要因を1つ特定して修正し、さらに5人のユーザーで再テストします。それでも達成できなければ、終了します。
  • 目標から大きく離れている：仮説が否定されました。理由を記録します。転換（新しい仮説と新しいプロトタイプ）するか、終了して別のアイデアに移るかを決めます。

自己検証プロトコル

プロトタイプにテストスイートは必要ありませんが、基本的な検証は必要です。

• メインブランチから Vercel（または同等のサービス）へのデプロイが正常に完了します。デプロイに失敗しているなら、ほかのことは問題になりません。
• コアフローが最初から最後まで機能します。新しいユーザーが、エラー画面や行き止まりに遭遇せずに主要なアクションを完了できます。
• フィードバックの仕組みが機能します。テスト用のフィードバックを送信し、記録されていることを確認します（Supabase のテーブル、Hotjar の録画、または PostHog のイベントを確認します）。
• A/B の振り分け（実施する場合）が機能します。振り分け Cookie／フラグを切り替えて、両方のバリエーションが表示されることを確認します。
• プレースホルダーテキスト（「Lorem ipsum」「TODO」「test」）がテストユーザーに見えないようにします。信頼性を損ない、フィードバックに偏りが生じます。
• モバイル回線でプロトタイプが3秒未満に読み込まれます（DevTools で「Fast 3G」にスロットリングして確認します）。プロトタイプの読み込みが遅いと、仮説を検証する前にユーザーが離脱します。

スクリプト

• scripts/scaffold.sh -- 最小限のボイラープレートファイルを含む Next.js + TypeScript + Tailwind のプロジェクト構成を作成します（npm install は実行しません）。オプションを確認するには --help を指定して実行してください。

アンチパターン（これらに気づいたら、すぐにやめてください）

• プロトタイプコードのユニットテストや統合テストを書く。
• CI/CD パイプライン、リンティングルール、またはコミット前フックを設定する。
• デザインシステム、カスタムテーマ、またはコンポーネントライブラリを作成する。
• 管理パネル、設定ページ、またはユーザープロフィールページを作成する（仮説に含まれる場合を除く）。
• エラーバウンダリ、再試行ロジック、ローディングスケルトン、または空の状態を追加する。
• 「クリーンさ」のためにコードをリファクタリングする — プロトタイプコードは使い捨てです。
• 技術選定について15分を超えて議論する — デフォルトのスタックを選び、先に進む。
• 3～5個の機能リストにない機能を「ついでに」作る。

本番環境への移行

仮説が検証され、本格的に構築する判断をした場合：

• プロトタイプを本番コードにリファクタリングしないでください。本番用スキル（engineering-frontend-developer、engineering-backend-architect など）を使って、新しく始めてください。
• プロトタイプから、検証済みのユーザーフロー、データモデルの形状、API コントラクト、UI のスクリーンショットを抽出してください。これらが本番構築の仕様になります。
• プロトタイプのリポジトリをアーカイブしてください。プロトタイプは役目を果たしました。

参考資料

• スタックのセットアップ -- package.json と shadcn/ui のインストールコマンド。
• コード例 -- フィードバックフォームのコンポーネントと A/B テスト用フック。
• フルスタック連携 -- Prisma スキーマ、Supabase + Clerk 認証、サーバーアクション、tRPC、ファイルアップロード、Resend を使ったメール送信。
• UI パターン -- データテーブル、コマンドパレット、フォームウィザード、ダッシュボードのレイアウト、トースト、shadcn/ui を使ったローディングスケルトン。