判断の出発点
プロトタイプは操作の理解を、技術検証は定めた条件で実現できるかを調べます。MVPは実際の利用者に、限定された使える結果を提供します。どれか一つで残りの検証まで済むわけではありません。
具体例で考える
納品書を読み取り在庫を更新する例では、試作品で数量訂正の操作を確認します。技術検証では正解を付けたサンプルで抽出結果を調べます。MVPでは受付、確認、権限のある在庫更新、失敗からの復旧までつなぎます。
成果物ごとに受入の方法を変える
試作品では数量を案内なしで訂正してもらい、次の操作への期待を聞きます。評価するのは褒め言葉でなく誤解です。技術検証では正解付き文書、項目、許せない誤りを先に決めます。MVPでは実際の権限で確認キューと更新失敗まで追います。別々の試験なので、一つの成功を全体の完成証明にしないでください。
省略した部分を引き継ぐ
試作品の固定値、一台のPCで動く実験、MVPの手作業は明示すれば合理的なことがあります。前提、未実装、環境、データ権限を残し、例示画面はそう表示します。コードを流用するなら、実験では不要だった認証、設定、エラー処理、監視、公開、保守を確認します。支えられる仕事を再利用し、見えない負担を本番へ運ばないことです。
結果から次の検証を選ぶ
訂正画面が理解されなければ抽出の追加実験では解決しません。必須書式の読み取りに失敗するなら画面の仕上げでは直りません。両方動いても必要な時に文書が手元にないなら運用を調べます。学び、残る疑問、次の変更を短く記してください。すべての案へ同じ順序を強制したり、全実験を公開したりする必要はありません。
選択肢とその負担
- 操作の不明点なら試作品、実現性なら実験、利用や業務価値ならMVPを選びます。複数必要でも、問いと終了条件を分けます。実験コードを本番へ転用するかも別の判断です。
見落としやすい点
見栄えのよい画面は抽出の成功を証明しません。動くスクリプトも権限や公開や支援体制を保証しません。省略した部分と試験条件を記録します。
依頼前に確認すること
何の判断が変わるか。入力は代表的か。失敗をどう定義するか。成果物と公開日を決める前に、開発パートナーと合意してください。