試作・PoCと本番開発— 契約の分割

1. 分割する理由

1-1. 業務範囲の明確化

PoCは「検証可能なプロトタイプの納品」、本番は「本番環境で運用可能な製品の納品」と、成果物の定義が異なります。
フェーズごとに発注書面（3条・4条）を分けると、検収基準と報酬が対応しやすくなります。

1-2. 投資判断と予算管理

PoCの結果を見て本番に進むか否かを社内決裁する場合、フェーズ単位の契約は予算・稟議と相性が良いです。
本番未着手の段階で、本番分の全額を発注書に書いてしまうと、未実施分の整理が難しくなります。

2. 契約設計の型

2-1. 基本契約＋フェーズ別個別発注

共通条項（秘密保持、再委託、IP）を基本契約に置き、PoC用・本番用の個別発注書で業務内容・報酬・納期を定めます。
基本と個別の関係は基本契約と個別発注を参照してください。

2-2. PoCから本番へのオプション条項

「PoC成功時に本番発注する場合の単価・期間の目安」を覚書に書くことは可能ですが、本番分は別途発注書を交付する運用が安全です。
口頭の「続きは同じ単価で」は、報酬・範囲の争いの元になります。

3. 検収・支払の切り分け

3-1. PoCの検収基準

デモ可能、特定シナリオが動作、性能指標の一次測定など、PoCならではの「検証完了」基準を列挙します。
本番品質（セキュリティ・負荷・運用監視）をPoCの検収に含めないよう注意します。

3-2. 60日起算はフェーズごと

PoCの検収完了と本番の検収完了では、支払期日の起算日が別々に走ります。
台帳でも案件IDを「PoC」「本番」で分け、受領日・期日を混同しないようにします。
起算の考え方は60日の起算を確認してください。

3-3. 着手金の扱い

PoCのみ着手金を設定し、本番は別発注で再設定するパターンが多いです。
未着手の本番分を前もって請求しないよう、発注書の範囲をフェーズに限定します。

4. 著作権・ソースコード

4-1. PoC成果物の帰属

PoCで作ったコードを本番で流用するか、捨てて作り直すかを契約で決めます。
帰属・譲渡タイミングは著作権・IP条項もあわせて整合させます。

4-2. 本番で新規開発する場合

PoCのリポジトリと本番リポジトリを分け、ライセンス・OSS混入の確認をフェーズごとに行います。
検収記録にも「PoC資産の流用有無」をメモします。

よくある質問

Q. 1契約にまとめても問題ありますか？

可能ですが、PoC中止時の精算・未実施本番分の扱いが複雑になります。分割の方が台帳運用は明確です。

Q. PoC失敗で終了するときの支払は？

PoCフェーズの検収済み分までが支払対象です。本番未発注なら本番分の請求は発生しません。

Q. 同じ受託者でも別案件IDにすべきですか？

台帳上はフェーズごとに分けることを推奨します。書面・検収・期日が追いやすくなります。

Q. アジャイル開発との関係は？

スプリント単位の段階納品はアジャイル開発委託も参照してください。PoCと本番の境界はスプリント0相当で切る例もあります。

Q. 継続委託に該当しますか？

PoCのみ短期なら単発、本番を長期継続するなら継続委託の判定が別途必要です。期間を台帳で管理します。

5. 台帳・稟議との連携

5-1. フェーズステータス

• PoC：発注済／検収済／中止
• 本番：未発注／発注済／検収中／完了
• 各フェーズの発注書番号・金額・期日

5-2. 社内決裁メモ

PoC結果レポートと本番GO/NO-GOの決裁記録を、契約フォルダに保管します。
後から「本番は発注していないのに請求された」争いを防ぐため、未発注ステータスを明示します。

5-3. トリカク（torikaku）の活用

トリカク（torikaku）では、フェーズ別の書面交付・受領日・期日を一覧管理できます。
発注コンプラの入口はチェックリスト記事も参照してください。

5-4. デリバラブル一覧の分離

PoCの納品物リスト（プロトタイプ、検証レポート）と本番の納品物リスト（本番コード、運用手順書）を別表にします。
同じ機能名でも品質水準が異なるため、検収チェック項目を表ごとに分け、混同を防ぎます。
表は発注書の添付資料として交付し、受託者の確認署名または返信メールを保管します。
本番用の別表は、PoC検収完了後に初めて共有する運用にすると、範囲の先走りを防げます。

6. GO/NO-GO判断の記録

6-1. 評価観点の例

• 技術的実現性（性能・セキュリティの一次評価）
• UX検証結果（ユーザーテストの所見）
• 本番開発の概算見積・期間の妥当性
• 社内リソース（PM・受入体制）の確保

6-2. NO-GO時のクロージング

PoCのみ検収し、本番発注書は発行しないことをメールで明示します。
PoC成果物の返却・削除・秘密情報の扱いを契約の終了条項どおりに処理し、台帳ステータスを「本番：未実施」でクローズします。
クロージングメールには、本番未発注であることと、今後の見積依頼手続を明記します。

7. 予算・稟議との整合

稟議書にPoC予算と本番予算を別欄で記載し、本番はPoC完了後の二次稟議とします。
稟議承認番号を台帳の発注行に紐づけると、後から「未承認発注」かどうかを説明しやすくなります。
承認前に受託者へ本番着手を依頼しないよう、キックオフ招待はPoC契約の担当範囲内に留めます。
本番キックオフは本番発注書交付後に別途設定し、参加者・議題を議事録として残します。
議事録には、PoCで作成した資産の流用有無と、本番スコープの確認結果を必ず記載します。

8. ステークホルダー調整

8-1. プロダクト・エンジニアリング

PoC成功後に本番へ移行する際、エンジニアが既に本番相当の実装をPoCブランチで進めている場合、範囲の食い違いが起きます。
ブランチポリシーで「PoC完了検収まで本番機能を混ぜない」ルールを共有します。

8-2. 調達・法務

本番発注はPoC評価レポートを添付した稟議を通してから契約締結し、評価前の口頭コミットを避けます。
稟議番号と本番発注書番号を台帳でリンクします。

8-3. 受託者との期待値調整

PoC段階で本番の規模感を口頭で伝えすぎると、PoC未契約の本番作業を求められることがあります。
本番の見積はPoC評価後の正式発注まで出さない方針を、キックオフ資料に明記します。
受託者への説明も書面で行い、「PoC契約の範囲外」と明確に区切ります。
本番見積依頼はPoC検収完了通知の後に正式に行い、その日付を台帳に記録します。

まとめ

• PoCと本番は成果物定義・検収基準が異なるため契約分割が望ましい
• 支払期日の起算・著作権・台帳IDをフェーズごとに分ける
• 本番は別途発注書を交付し、未発注分の請求を防ぐ
• GO/NO-GO決裁と稟議番号を台帳のフェーズ行に紐づける
• PoCと本番のデリバラブル一覧表を別管理する
• 本番キックオフ議事録に資産流用の確認結果を残す

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、法的助言ではありません。
個別の契約分割・IPの取扱いは弁護士等の専門家にご確認ください。