プロトタイプからスクラッチ開発へ移行するタイミング

プロトタイピングで業務フローを確認できたら、次は本番システムの開発です。移行のタイミングと、スクラッチ開発に向けて整えておくべきことを整理します。

プロトタイプの役割が終わる条件

プロトタイプは「確認のための先出し」であり、本番で使い続けるシステムではありません。以下の条件が揃ったとき、スクラッチ開発への移行タイミングです。

業務フローの確認が完了している：プロトタイプを使った業務シミュレーションを通じて、「このフローで実際の業務が回る」という確認が取れていること。発注者・現場担当者・開発者の間で認識が揃っていることが条件です。

変更点が出尽くしている：「ここはこう変えたい」というフィードバックが一巡し、大きな変更要望が出なくなっていること。プロトタイプへのフィードバックを本番開発に反映するためには、フィードバックが収束している状態が必要です。

ユーザーの運用確認が完了している：テスト運用を実施し実際の稼働シミュレーションが完了していること。完成したのに誰も使ってない状態を避けるためには、現場の業務に合っているか、機能に不足はないか、UI/UXは使いやすいものになっているかの確認も必要です。

仕様が文書化されている：プロトタイプで確認した業務フロー・画面仕様・データ構造が、開発のインプットとして整理されていること。プロトタイプという「動くもの」があっても、仕様書として言語化しておくことで開発の精度が上がります。

プロトタイプは業務確認を目的として作られるため、本番システムとは設計の優先順位が異なります。

プロトタイプで「動いていた」ことと、本番システムとして「正しく設計されている」ことは別です。プロトタイプのコードをそのまま本番に転用することは基本的に推奨されません。

開発会社・体制の確保：スクラッチ開発を担う開発会社や開発体制を、移行前に決めておきます。プロトタイプを作った会社がそのまま本開発を担当する場合も、担当しない場合も、プロジェクトの引き継ぎが必要になります。

予算・スケジュールの確定：プロトタイプで仕様が固まった状態であれば、本開発の見積もり精度が上がります。プロトタイピング後のタイミングで改めて複数社に見積もりを取ることで、適切な費用感を把握できます。

プロトタイプフェーズで得た知見の整理：プロトタイプのフィードバックや変更経緯をまとめておくことで、本開発の仕様定義に活かせます。「なぜこの仕様になったか」の背景が残っていると、開発中の判断がスムーズになります。