プロトタイプ開発を外注する前に。安く速く作るには捨て方を決める

見積書に「プロトタイプ一式」と書かれていて、完成画面の枚数だけが並んでいます。経営会議では早くデモを見せたい一方で、何を確かめるための画面なのかは決まっていません。

僕なら、プロトタイプ開発を外注するときは、完成品ではなく、次へ進むか止めるかを決める材料を買います。安く速く作りたい案件ほど、本開発へ流用できるという期待をいったん外し、検証後に捨てる範囲を発注前に決めます。

画面が動くことと、顧客が使うサービスを運用できることは別です。再利用を前提にしないコードまで本番品質で作らせると、確認したい仮説へ届く前に予算を使います。反対に、本番へ持ち込む予定のコードをデモ品質で受け取ると、後から安全性や運用機能を足す費用が見えません。

プロトタイプ開発の外注は、捨てる条件から決めます

最初に決めるのは、作る機能ではなく、今回の試作で答える問いです。利用者が申し込みを最後まで進められるか、手元のデータで予測に必要な結果が出るか、外部サービスと接続できるかでは、必要な試作品が変わります。一つの発注で三つを同時に確かめようとすると、画面もデータも接続先も増えます。

プロトタイプは、画面の流れや操作方法を利用者に触ってもらう用途に向きます。PoCは、技術やデータが想定した条件で使えるかを確かめる用途に向きます。実際の顧客へ提供する最小版は、利用規約、認証、問い合わせ対応、監視、障害時の復旧まで必要になるため、試作と同じ見積もりでは扱えません。

たとえば予約サービスの操作を試すだけなら、予約枠を固定データにして、通知を担当者が手で送っても検証できます。ただし、固定データと手作業をデモ画面の裏へ隠してはいけません。外注先には、省いた処理、代わりに人が行った作業、本開発で追加する機能を報告書へ書いてもらいます。

開始前に、試す人、使うデータ、操作してもらう場面、観察する行動、合格と中止の条件を決めます。「評判がよければ続ける」では足りません。どの操作で迷ったら画面を直すのか、外部接続が何度失敗したら別案を調べるのか、責任者が説明できる言葉にします。

英国政府のプロトタイプ作成に関するサービスマニュアルは、行政サービスの設計チームを対象に、案を試して合わない試作品を捨てる進め方を示しています。比較試験や費用調査ではなく、開発費や短縮日数の測定値は載せていません。同資料は、コード試作品が本番と同じ安全性や大量アクセスへの対応を備えない場合があり、そのまま本番へ写さないよう注意しています。

試作へ入る前の範囲整理は、作らない機能を先に決める要件定義と同じです。本開発ほど細かな仕様書は要りませんが、対象外とした業務、見送った理由、再検討する条件は残します。捨てると決めた機能を、途中の思いつきで戻さないためです。

PoC開発の費用は、検証単位で区切ります

PoC開発の費用に、案件を問わず使える相場は置けません。同じ一画面でも、固定データを表示する試作と、社内データを整えて外部APIへ接続する検証では、準備する作業が違います。総額だけを比べると、安い見積書からデータ整備や検証の実施が抜けている場合があります。

見積書は、検証設計、試作、検証の実施、結果の整理、本開発への引き継ぎに分けてもらいます。外部サービスの利用料、端末の準備、利用者への聞き取り、修正回数も、含む範囲と含まない範囲を分けます。発注側がテスト参加者やサンプルデータを用意するなら、担当者と用意する日を見積もりの前提へ入れます。

費用を抑えるときは、試す問いと関係の薄い機能から外します。ログイン画面を作り込む必要がない検証もあります。

反対に、認証方法そのものを確かめたい案件でログインを省くと、安くなっても答えを得られません。機能数ではなく、検証に必要かどうかで削ります。

修正を無制限に頼める発注も避けます。最初の試作を見た後に直す回数、追加の案を試す条件、予算上限へ達したときに止める人を決めます。直すたびに問いが変わるなら、同じPoCの改善ではなく、新しい検証として見積もりを分けます。

本開発の見積もりは、PoCの総額へ含めず、検証結果を受け取った後の別資料にします。ただし、認証、データ移行、監視、保守など、本開発で増える作業は発注前に概算項目まで出してもらいます。試作が安くても、本開発の対象範囲が空欄なら投資全体を比べられません。

外注先へ渡すのは、仕様書より検証台本です

外注先へ渡す一枚には、利用者、開始する画面、入力するサンプル、操作の順番、期待する結果、観察者、記録方法を書きます。利用者へ説明してよい内容も決めます。操作方法を横から教えすぎると、画面だけで使えるかを確かめられません。

サンプルは、見栄えのよい一件だけでなく、空欄、長い文字、重複、想定外の順番を含めます。実データを渡せない場合は、項目と難しさを保った架空データを発注側で用意し、実データとの違いを記録します。外注先の担当者へ本番環境の管理者アカウントを渡さず、検証用の環境と期限付きのアカウントを使います。

候補会社のデモでは、完成画面より「作っていない場所」を説明してもらいます。固定値になっている箇所、手作業へ戻す箇所、失敗時に表示されない情報、本開発で書き直す予定の箇所を画面上で指してもらいます。省略を率直に説明できる会社なら、速さの理由を発注側も確認できます。

AI機能のPoCを頼む場合は、成功した入力だけで委託先を決めません。RFPで候補会社の評価条件をそろえる方法と同じく、評価に使わなかった入力、失敗の内訳、人が確認へ戻す条件を見ます。正解率だけではなく、評価データの範囲と再現手順を受け取ります。

検証日に参加する社内担当者も先に確保します。外注先が画面を用意しても、利用者が集まらず、事業責任者が結果を読めなければ次へ進めません。現場担当者は操作中の発言を記録し、外注先は動作と不具合を記録し、事業責任者は合格条件と照合します。

プロトタイプ開発から本開発へ引き継ぐ成果物

捨てる前提でも、残す資料はあります。検証した問い、採用した案、見送った案、参加者の範囲、使ったサンプル、操作の記録、発生した不具合、未確認の条件を受け取ります。画面録画だけでなく、なぜ画面を変えたかも文章にします。

コードを捨てる場合は、本開発の会社へコードを読ませる必要がない場合もあります。画面遷移、データ項目、外部接続で判明した制約、利用者が迷った箇所を渡したほうが、設計へ使いやすくなります。試作専用の近道は「未実装」と明記し、本開発の完成扱いにしません。

コードを再利用する予定なら、発注時点で基準を変えます。ソースコードの保管場所、起動手順、使用した外部部品、テスト、設定項目を成果物へ含めます。誰が成果物を保管し、次の委託先へどの範囲を渡せるかは、契約書へ書き、締結前に契約担当者や専門家へ確認します。

再利用を選んでも、本番投入を自動で認めてはいけません。利用者ごとのアクセス制御、秘密情報の保管、異常時の表示、操作ログ、バックアップ、監視、負荷への対応を本開発の見積書へ追加します。試作コードを残す費用と、検証結果から書き直す費用を同じ条件で比べます。

引き継ぎ会では、外注先が自分の端末で動かすだけでは足りません。発注側または本開発の担当者が、新しい環境で起動し、検証台本を再実行します。

再現できなかった箇所を追加資料にします。委託先が変わる可能性があるなら、開発会社を替えても止めない引き継ぎ手順も発注前に確認してください。

見積もりを頼む前に三枚の資料を開きます

明日は、最初に検証票を一枚作ってください。試す問いを一文にし、対象者、使うデータ、操作する場面、合格条件、中止条件、結果を決める日を書きます。一文に問いが二つ入ったら、発注を分けます。

次に、見積比較の表を開きます。検証設計、試作、実施、報告、引き継ぎの金額と、対象外、修正回数、発注側が用意する物を各社へ同じ欄で書いてもらいます。総額が低い会社ではなく、検証票へ答える作業が欠けていない会社を残します。

最後に、引き継ぎ票へ、残す資料、捨てるコード、再利用を検討する部品、アカウントの管理者、検証環境を閉じる日を書きます。本開発へ進む場合は、試作で省いた安全性と運用機能を別見積もりへ移します。止める場合も、検証結果と見送った理由を社内の保管場所へ残します。

三枚の内容を候補会社が同じ言葉で説明できるなら、小さな外注へ進めます。完成画面だけを約束し、合格条件と捨てる範囲を説明できないなら、実装の発注は止めます。まず検証票を埋める作業だけを頼むほうが、安いデモを作り直すより次の選択肢を残せます。