プロトタイプはコストや時間がかかるという誤解

「プロトタイプを作ってから、それとは別に本番システムを作る」という二度手間のイメージから、プロトタイプ開発はコストや期間が余計にかかると思われがちです。実際にはこのイメージ自体がすれ違っており、正しく運用すればコストは増えるどころか、手戻りが減る分だけ総コストは下がります。

誤解の正体:「作り直す」ことを前提にしている

この誤解は、プロトタイプを「見た目だけ動く使い捨てのモックを作り、それを参考にして本番システムをもう一度ゼロから作る」というプロセスだと捉えていることから生まれます。これが正しければ、確かに実装は二重に発生し、コストは膨らみます。

しかし実際のプロトタイピングでは、今、認識合わせが必要な範囲——たとえば「承認フローのステータス遷移」や「特定の帳票の入力項目」だけに、本番と同等の実装を絞り込んで作ります。ここで作った実装は使い捨てのモックではなく、本番と同等のロジックを持つ「完全型プロトタイプ」の一部です。後から別物として本番システムを作り直すのではなく、この実装をそのまま拡張していく前提のため、二重に実装が発生することはありません。実装コストは「システム全体の再実装」ではなく、この絞り込まれた範囲に比例し、範囲を絞りながら本番相当の実装を積み上げていくこと自体が、この手法の中心にある技術です。

本当のコストは「手戻りの回数 × 1回あたりの手戻りコスト」

仕様書ベースの開発でも、要件を文章にまとめる作業には当然時間がかかっています。つまり「プロトタイプを作る時間」と「仕様書を書く時間」は、どちらもゼロではなく比較の対象になります。違いが出るのは、その後です。

仕様書は「読み手が正しく解釈できたか」を実装が始まるまで検証できません。解釈のズレは、実装がある程度進んだ段階——結合テストやユーザー受け入れテストのタイミング——で初めて表面化します。この時点での手戻りは、該当箇所の再設計・再実装・再テストが必要になり、コストが大きくなります。

対してプロトタイプは、実装に着手した直後——早ければ数日以内——にステークホルダーの目の前で解釈のズレを検出できます。手戻りが発生する回数自体は仕様書ベースの開発と大きくは変わらないかもしれませんが、1回あたりの手戻りコストが「実装後の手戻り」から「プロトタイプの微修正」に変わるため、総コストは下がる方向に働きます。

手戻り以外にも、実装コストそのものを下げる要素がある

ここまでは「手戻りコストが小さくなる」という間接的な効果でしたが、開発者視点では実装コストそのものを直接下げる要素もあります。

1つは、プロトタイプ実装の中で行った技術検証のソースをそのまま流用できることです。外部APIとの連携方法や、特定の計算ロジックの実装方法など、プロトタイプの段階で「動くことを確認したコード」は、後工程で書き直す必要がなく、そのまま本体の実装に組み込めます。

もう1つは、プロトタイプを実装する過程で、業務ルールや例外パターンの洗い出しが自然に進むことです。仕様書の段階では「基本的にはこう」としか書かれていなかった業務ルールも、実際にコードとして動かそうとすると、条件分岐や例外処理としてすべて具体化しなければ動きません。この過程は、実質的に設計を清書・詳細化する作業を兼ねています。プロトタイプが完成した時点で、本開発で使える詳細設計に近いものが既に手元にあることになり、本開発側で改めて詳細設計を作り直すコストが減ります。

誤解が現実になるケース:範囲がズルズル広がったとき

ここまでの話には1つ条件があります。「実装範囲を絞り込む」という前提が崩れ、確認したい論点と関係のない部分までプロトタイプに作り込んでしまうと、当然コストは膨らみます。これは一般に「スコープクリープ（要件爆発）」と呼ばれる現象です。「せっかく動くから」と不要な機能まで拡張して作り込んだり、確認が終わった論点の作り込みを続けてしまったりすると、二度手間だという誤解の方が現実になってしまいます。プロトタイピングでコストを抑えられるかどうかは、手法そのものよりも「今、何を確認するために作っているか」をマネージャーが見失わないかにもかかっています。

まとめ

プロトタイプ開発が高くつくという誤解は、「本番システムを二度作る」という誤った前提に基づいています。実際には確認したい論点に実装範囲を絞り込むため、コストはその範囲に比例します。仕様書ベースの開発と比べても、要件のズレを検出するタイミングが実装直後と早いため、手戻りコストが小さく済み、総コストはむしろ下がる方向に働きます。ただしこれは範囲を絞り込むという運用が保たれている場合の話であり、確認目的を離れて作り込みが広がれば、誤解の方が現実になってしまう点には注意が必要です。