仮説行動
以下のフェーズの移り変わりの考え方は、以下の「仮説行動」という本の思想が参考になります。
この書籍には、仮説マップという、抽象から具体までの仮説要素からなるロジックツリーの考え方があります。
もちろん、超優秀なスクラムマスターとかなら、暗黙的にこのあたりの
「今回のスプリントでは、どの仮説ブロックを検証すべきか？」というのが、
図解でチームに浸透させることができ、学びが最大化されるように運用できるでしょう。
（私は会ったことないけど、、、）
作業仮説とクレーム仮説
その各「仮説」には、それぞれの不確実さがあり、作業仮説～クレーム仮説までグラデーションがあります。
仮説自体がまだ検証がほぼされておらず、不確実さが高い時には【作業仮説】。
検証が十分されており、確実さを帯びてくると【クレーム仮説】へと変化します。
（リトマス紙のpHのようなもんです。）
このクレーム仮説が、限りなく一番右に近ずくほど、それは世間でいうところの
【エビデンス】と言われるものへと変化していくんです。
なので、図のように同じ抽象度の仮説ブロックでも、そのブロックの内在している不確実さは変動します。
リスクの高いものから手を付ける
反復型開発やRUPで、「リスクの高いものから着手せよ」という原則があるのは、恐らくですが、この発想から来ていると思われます。
クレーム仮説に限りなく近いユースケースなどは、確実性が高いので、これをプロダクトバックログアイテム（PBI）の優先順位を高にしてしまうと、ハイリスクな作業仮説となるものに着手する際の予算が枯渇しているリスクがあるからです。
代表例
ハイリスクなユースケースの代表例としては、以下のようなものが挙げられます。
そのユースケースが、どの程度顧客にとっての価値に紐づくのか不明。
そのユースケースが、どの程度アーキテクチャを決定づける要因となるのか不明。
これらはいきなり定量評価できるものではないです。
他の同じ抽象度のユースケースと比較してみて、初めてわかるものです。
1. フェーズの移り変わり 🚶➡️🏃➡️🚀
PoC、プロトタイピング、MVP、これらのフェーズの移り変わりは、どのようなタイミングで行われるべきでしょうか？
PoC (概念実証) → プロトタイピング
PoCの目的
特定の技術やアイデアが技術的に実現可能かを検証することです (Can we build it？)。
移行タイミング
中核となる技術的リスク（例：「このアルゴリズムは必要な精度を出せるか？」）が解消され、「作れる」と分かったら、次の「どう作るか？」の段階へ移行します。
プロトタイピング → MVP (Minimum Viable Product)
プロトタイプの目的
製品の見た目や操作感（UI/UX）を探り、ユーザーフローを検証することです（How should it work / look？)。
ここには、紙芝居、画面遷移図、モックアップなども含まれます。
移行タイミング
主要なユーザーインターフェースやインタラクションが、「これでいけそうだ」と検証され、実際にユーザーに価値を提供できる最小限の「動く製品」 を作る段階へ移行します。
2. プロトタイプからMVPへの再利用
プロトタイプまでは「捨ててまた一から作る前提」のマインドで素早く雑に作ってフィードバックをもらうのが最優先されます。
基本は「捨てる前提」
プロトタイプは学習が最優先です。
そのため、
コードの品質やアーキテクチャは二の次で、「素早く作って、壊して、学ぶ」
ことが重視されます。
そして多くの場合、MVP開発時にはゼロから書き直すのが最も効率的です。
一部再利用の可能性
ただし、以下のようなものは、MVPに再利用できる可能性があります。
・検証済みのUIコンポーネント
デザインシステムとして管理されていれば。
・明確なアルゴリズム
プロトタイプで検証された計算ロジック自体。
・設定ファイルなど
環境設定の一部。
注意点
プロトタイプのコードをそのままMVPに流用すると、初期段階から技術的負債を抱え込むリスクが非常に高いです。
ここで無理に、MVPに再利用しようとするから、後になって取り返しのつかないことになっているケースはたくさんあります。
MVPは「Viable（実行可能）」である必要があり、テスト、セキュリティ、スケーラビリティといった非機能要件も最低限考慮する必要がありますが、プロトタイプには通常これらが欠けています。
というか、意図的にプロトタイピングまでは、テストを書かないというのも戦略として大事です。
ここの結論
プロトタイプは学習のためのツールであり、基本的には使い捨てと考え、MVPは本番品質のコードで作るべきです。
ただし、プロトタイピングの過程で得られた
「学び」や明確になった「仕様」、そして一部の「部品」 は、MVP開発の貴重なインプットとなります。
2. どんな時にPoCとプロトタイピングを同時に行うか
ところで、PoCとプロトタイピングを同時に行うケースもあります。
それは「新しい技術」とその「新しいユーザー体験（UX）」が密接不可分で、両方を同時に検証しないと製品の価値が成立するか判断できない場合です。
つまり、
「技術的に作れるか？（PoC）」と
「ユーザーはその技術をうまく使えるか？（プロトタイプ）」
の両方に大きな不確実性があり、片方だけ検証しても意味がないケースです。
暗黙的に、PoCとプロトタイプ工程に、ECRSのC（結合）が使われています。
具体的なシナリオ 🤔💡
・全く新しいインターフェース
例として、ジェスチャー操作、音声認識、AR（拡張現実）を使ったインターフェースなど。
検証
その技術（ジェスチャー認識エンジン）が実現可能か（PoC）と、
ユーザーがそのジェスチャーを直感的に操作できるか（プロトタイプ）を同時に検証しないと、製品として成り立つか分かりません。
・複雑なリアルタイムデータとUI
例として、金融のリアルタイムトレーディング画面、複雑なシミュレーション結果の可視化など。
検証
バックエンドが必要なデータをリアルタイムで処理・生成できるか（PoC）と、
フロントエンドがその大量のデータをユーザーに分かりやすく、かつインタラクティブに表示できるか（プロトタイプ）を同時に試す必要があります。
・AIによる提案機能
例として、AIがユーザーの行動に基づいて次のおすすめ商品を提案する機能。
検証
AIモデルが適切な提案を生成できるか（PoC）と、その提案をどのようなUIでユーザーに提示すれば効果的か（プロトタイプ）を組み合わせて検証しないと、機能全体の価値は判断できません。
MVPへの移行タイミング 🚀
この同時検証フェーズからMVPへ移行するのは、以下の両方が満たされたと判断できたタイミングです。
①. 中核となる技術的なリスク（PoCで検証）が十分に低減された。
②. 主要なユーザーインタラクション（プロトタイプで検証）が「これでいける」と確信できた。
つまり、「作れる」と「使える」の両方に目処が立ち、
最小限の価値を提供できる「動く製品」 を作る準備が整ったと判断した時です。
3. モデリングにかけるコスト感
プロトタイピング段階では、詳細な脅威モデリングやドメインモデリングに費やす時間は最小限に抑えるべきです。
ここで時間をかけてモデリングを行いまくったとしても、その分素早くフィードバックは得られないし、作りこんだ分「捨てたら勿体ない」マインドが発生しやすくなります。
なぜ最小限にすべきか
プロトタイプの主な目的は、アイデアの検証と素早い学習です。
この段階で重視されるのはスピードであり、「完璧さ」ではありません。
詳細なドメインモデリング
コアドメインの内部構造（集約、エンティティなど）を深く掘り下げるのは、UI/UXや基本的なユーザーフローを検証する段階では過剰な投資です。
プロトタイプの内部ロジックは、しばしばモックされたり、大幅に簡略化されたりします。
詳細な脅威モデリング
STRIDE分析などを詳細に行うには、比較的安定した設計が必要です。
しかし、プロトタイプは頻繁に変更・破棄されるため、その都度詳細な脅威分析を行うのはとても非効率です。
なぜ「マクロなコンテキストマップ＋脅威分析」は有効か
しかし一方で、
「マクロなコンテキストマップ」と、その「境界に対する基本的な脅威分析」
は非常に有効です。
コンテキストマップの価値
プロトタイプが
「何と連携するのか」（外部API、他のシステム、ユーザー）というシステムの境界
を明確にします。これにより、設計の初期段階で大きな見落としを防ぎます。
境界に対する脅威分析の価値
コンテキストマップで明らかになった 境界（インターフェース） に焦点を当てて、
「ここでのやり取りには、どのような明らかなリスクがあるか？」を考えます。
例①
「外部の決済APIと連携するなら、認証情報（APIキー）の扱いには注意が必要だ（たとえプロトタイプではモックするとしても）」
例②
「ユーザーからの入力（名前、住所）を受け付けるなら、基本的な入力検証（サニタイズ）は考慮すべきだ」
バランス
このレベルの分析では、詳細なモデリングほど時間をかけずに、アーキテクチャ上の根本的な欠陥（例：セキュリティを全く考慮していない設計）に陥るリスクを低減します。
結論
プロトタイピングでは、スピードを最優先し、詳細なモデリングは避けるべきです。
しかし、
システムの「外枠」（コンテキストマップ）と、
その「境界における明らかなリスク」だけは最低限考慮
しておくことで、後工程での手戻りを減らし、よりスムーズにMVP開発へと移行できます。