specsfy-specialist-prototyping

プロトタイピング

使用するタイミング

• 技術、操作性、または視覚に関する具体的な疑問があり、ドキュメントではなく実行可能な成果物だけが確かな答えを出せる場合に実施します。
• コストのかかる、取り消しが難しい決定を下す前に、具体的な選択肢を2つ以上比較する場合にも実施します。
• 一次資料にすでに答えが記載されている場合は実施しません。その場合は $specsfy-specialist-technical-research のほうが、何かを構築するコストをかけずに、より早く解決できます。
• プロトタイプのコードをそのまま本番環境に昇格させないでください。プロトタイプの忠実度を下げる（テストカバレッジなし、エラー処理なし、セキュリティ対策なし）ことは、破棄を前提とする間だけ有効な、意図的な選択です。

フロー

1. コードを書く前に、1つの疑問と、その答えを決める基準を定めます。これを定めないと、プロトタイプは終わりのない探索になってしまいます。
2. 何を実際に動かす必要があるか（テスト対象の仕組み）と、何をシミュレーションまたはモック化できるか（疑問への回答に影響しないすべてのもの）を決めます。
3. 必要最低限の忠実度、明確な時間制限、そしてリポジトリ内またはリポジトリ外の、明確に破棄可能な場所を選びます。
4. 1つの選択肢を期待値と照らし合わせてテストするより、選択肢を直接比較するほうが情報量が多い場合は、複数の選択肢を構築します。
5. 計画したシナリオを実行し、観察可能な証拠を収集します。「動いているように見える」という主観的な印象に頼らないでください。
6. 元の疑問への答えを明示的に示し（採用、却下、またはまだ結論が出ていない）、テストした内容の制約を記録します。
7. プロトタイプを破棄するか、本番用ではないことを明記してアーカイブします。プロトタイプを参照するランタイム依存関係は一切残さないでください。

パターン

• 説得力のあるデモと、妥当なアーキテクチャを混同しないでください。「デモでは動く」プロトタイプでも、意図的に検証していない並行処理、スケーラビリティ、エラー、セキュリティについては、何も証明していません。
• 疑問への回答に実システムでのテストが必要な場合（その場合も、範囲と許可を明示する必要があります）を除き、実データ、本番環境の認証情報、実際の統合はプロトタイプに持ち込まないでください。
• UI のプロトタイプでは、「lorem ipsum」ではなく現実的なコンテンツを使い、極端な状態（非常に長いテキスト、空のリスト、エラー）も含めます。UI に関する疑問は、ハッピーパスだけを対象としていることはほとんどありません。
• ロジックや状態のプロトタイプでは、疑問に不要な完全な UI の背後に隠すのではなく、最小限のインターフェース（CLI、実行可能なテスト）で遷移と不変条件を見えるようにします。
• 疑問への回答に必要な範囲を超えて、抽象化、テストカバレッジ、視覚的な仕上げに時間をかけないでください。それはプロトタイプの目的に反します。
• 本番コードが誤ってインポートできないよう、コードに破棄可能であることを示します（分離されたディレクトリ、誤解の余地がない名前、公開エクスポートなし）。
• 関連する学びはすべて、適切な管理先（spec、ADR、バックログ）の要件、記録済みの決定、またはテストに反映します。破棄した後、プロトタイプ自体は信頼できる情報源ではありません。

アンチパターン

• 「動いたから」という理由で、「一時的な」プロトタイプを本番環境で動かし続けること。プロトタイプが意図的に省略した検証（セキュリティ、エラー、スケーラビリティ）をすべて完了していない限り、本番環境に目に見えないリスクを持ち込みます。
• 同じプロトタイプで複数の疑問を同時にテストすること。結果が曖昧になると、どの変数が何を引き起こしたのか判断できません。
• 仕組みの技術的な実現可能性だけが問題なのに、見た目を磨いたり、「念のため」アーキテクチャを作り込んだりすること。
• プロトタイプの負債をひそかに引き継ぐこと。プロトタイプのファイルを、本来の品質基準に従って書き直さずに、本番コードの土台として再利用しないでください。

検証

• 判断基準は実行前に定義されており、同じシナリオを実行した別の人も結果を再現できます。
• 元の質問に明確な答えがあります。仮説が支持されたか、棄却されたか、あるいはまだ結論が出ていないか（その場合、判断に何が足りないか）が示されています。
• プロトタイプの制約と、本番環境で求められるものとの違いが明記されています。
• プロトタイプの成果物が最終的なランタイムに接続されたままになっていないことを、思い込みではなく確認済みです。
• プロトタイプだけを根拠に、アプローチを「本番環境で実現可能」と宣言しません。これには、プロジェクト標準に記載された実装と完全な検証が必要です。

関連するスキル

• 何も構築せずに一次情報源から答えられる質問の場合は、$specsfy-specialist-technical-research。
• プロトタイプによって、まだモデル化されていないドメイン概念が明らかになった場合は、$specsfy-specialist-domain-modeling。得られた知見は、破棄されるコードに閉じ込めず、モデルに反映します。
• プロトタイプがインターフェースで、個別の質問を超えたフローや視覚的な階層の厳密さが必要な場合は、$specsfy-specialist-ux-design または $specsfy-specialist-ui-design。

質問の種類ごとの忠実度レベル、出力形式、公式情報源については、references/standards.md をお読みください。