ゲーム開発・Unity委託の取適法— スプリント払いと検収

1. スプリント払いと検収の関係

1-1. スプリントごとに検収を切る

アジャイル型のゲーム開発では、2週間や4週間のスプリント終了時に成果物を受領し、その都度検収・支払を行う運用が一般的です。
このとき「スプリント完了＝検収完了」と書面で定めておかないと、最終リリースまで検収が宙ぶらりになり、60日起算の起点も曖昧になります。
発注全体の確認項目は発注コンプライアンスのチェックリストも参照してください。

1-2. 中間ビルドと最終納品の区別

プレイ可能なビルドの提出は、開発途中の確認用か、検収対象の給付かを契約で区別します。
確認用ビルドまで検収対象に含めると、バグ修正のたびに受領日が更新され、支払期日の管理が複雑になります。
受領日を台帳に記録する習慣が、期日管理の前提になります。

1-3. マイルストーン報酬の設計

企画確定・α版・β版・リリースなど、マイルストーンごとに報酬を分割する場合は、各マイルストーンの完了定義を添付資料に書きます。
「だいたい動く」ではなく、チェックリスト形式の完了条件にすると、検収の行き違いが減ります。
検収基準の考え方は支払60日ルールの起算点を参照してください。

2. 仕様変更と追加発注の記録

2-1. スコープクリープへの対応

ゲーム開発では、プレイテストの結果から仕様が膨らみやすく、当初見積もりを超える作業が発生しがちです。
口頭で「ついでに入れて」と依頼した機能は、後から追加発注として認識されないと、報酬未払い・減額トラブルの火種になります。
変更は都度、書面または記録可能なチャットで合意し、台帳に紐づけます。

2-2. 追加見積もりと発注書面

追加作業には別枠の発注書面を発行し、報酬・納期・検収条件を明記します。
記載事項の型は記載事項のテンプレートをベースにすると漏れが減ります。
元契約の「変更は書面合意」との条項と整合させておきます。

2-3. バグ修正と仕様変更の線引き

契約上の瑕疵対応（バグ修正）と、新機能追加は別物として扱います。
無償修正回数の上限を超える変更は、追加発注として扱う旨を契約に書いておくと、現場の判断がぶれにくくなります。

3. 複数職種への発注と台帳

3-1. プログラム・デザイン・アセットの分離

同じタイトル開発でも、プログラマー・デザイナー・サウンドクリエイターが別契約になることが多いです。
発注者側は取引先ごとに台帳を分け、受領日・支払期日を個別に管理します。
一括で「ゲーム開発費」として処理すると、どの給付の受領日か追えなくなります。

3-2. 再委託・孫請けの確認

受託者が外部にモデリングや翻訳を再委託する場合、契約で再委託の可否・届出を定めます。
孫請けの存在が後から判明すると、著作権・機密・支払条件の整理が難しくなります。

3-3. ソースコード・プロジェクトファイルの受領

ビルド成果物だけでなく、ソースの納品を求める場合は、納品物一覧に明記します。
リポジトリへの招待日を受領日とするか、タグ付きリリース日とするかを事前に決めます。

4. 支払期日とスプリント運用

4-1. スプリント終了日と受領日

スプリントレビューで成果を確認した日を受領日とするか、検収承認メールの日とするかを社内で統一します。
60日の数え方は発注コンプライアンスのチェックリストの整理が参考になります。
受領日が空欄のままだと、超過リスクを機械的に検知できません。

4-2. 着手金・前払いの扱い

開発着手前の前払いは、契約上の位置づけ（着手金か中間金か）を明確にします。
前払いだけ先行し、スプリント成果の検収が遅れると、資金と履行のずれが生じます。

4-3. 遅延時の連絡と記録

スプリント遅延が常態化する場合、一方的な納期短縮や減額要求は買いたたきに当たる可能性があります。
遅延の事実・原因・合意した対応を記録に残し、報酬改定は双方の合意で行います。

5. 実務シナリオとチェックリスト

5-1. スプリント3で仕様が膨らんだとき

例えばスプリント3の途中で、ボスキャラの AI 行動を追加する依頼が口頭で入ったとします。
見積もり工数が20時間増える見込みなら、着手前に変更依頼書を起票し、報酬と納期への影響を記載します。
承認後にチケットを起票し、台帳の発注番号と紐づけます。
承認なしに実装が進んでいる場合は、検収時に「当初スコープ外」と争点になるため、早めに書面化します。

5-2. 複数ベンダーが絡むリリース日

プログラム・デザイン・サウンドが別々の受領日を持つ場合、ストア申請に必要な素材が揃った日を社内で「統合受領日」と定義するか検討します。
統合日を設けない場合は、最も遅い受領日が実質的な完了日になり、支払期日もそれに追随します。
期日計算の基本は支払60日ルールの起算点を参照してください。

5-3. 発注前チェック（ゲーム開発向け）

取引開始前に、再委託の可否・ソースの帰属・スプリント単位の検収・修正回数上限・中間ビルドの位置づけを書面に含めるか確認します。
発注コンプライアンスのチェックリストに沿って、資本金・従業員数の適用判定も忘れず行います。
キックオフ議事録だけで終わらせず、合意内容が発注書面・別紙に反映されているかを法務・経理でクロスチェックします。

よくある質問

Q. スプリント途中で契約解除できますか

可能な場合もありますが、既に提供された役務の対価・解除予告は別途整理が必要です。
継続委託の解除は記載事項のテンプレートの観点も確認してください。

Q. β版の段階で全額支払うべきですか

契約どおりです。段階払いならβ版時点のマイルストーン分のみが対象になります。
最終リリース前に全額を払う設計なら、その旨を書面に明記しておきます。

Q. アセット商店の素材利用は発注書に書くべきですか

ライセンス条件・商用利用可否・帰属表示の要否は、成果物の権利関係として契約に触れておくと安全です。
受託者が購入した素材か、発注者提供かも区別して記録します。

Q. 海外のゲーム開発スタジオへの発注は取適法の対象ですか

取引の実態・当事者の位置づけによります。
国内向けの役務提供委託として整理される場合は、記載・支払期日等の遵守が求められます。

Q. QA業務だけ別委託にした場合の検収は

QAレポートの提出日・バグチケットのクローズ条件など、QA単体の完了定義を書面にします。
開発本体の検収とは別マイルストーンとして台帳を分けると管理しやすいです。

まとめ

• スプリントごとに検収・受領日を切り、60日起算の起点を明確にする
• 仕様変更は追加発注として書面化し、バグ修正との境界を契約に書く
• 職種別・取引先別に台帳を分け、再委託の有無を確認する
• 支払はマイルストーン設計と受領日記録をセットで運用する

6. ゲーム開発委託の発注前チェックリスト

• スプリント単位の検収・支払条件を発注書面に明記したか
• 中間ビルドと最終納品のどちらを受領日起算にするか決めたか
• 仕様変更・追加機能は変更依頼書で承認するフローがあるか
• プログラム・デザイン・アセットなど職種別に台帳を分けたか
• ソース・プロジェクトファイルの納品形式と帰属を合意したか
• 再委託・孫請けの可否と届出手順を契約に書いたか

キックオフ後に「口頭で足した機能」が増えていないか、スプリント終了ごとに台帳とバックログを突合します。
受領日が未入力の取引先があれば、支払期日の計算が止まるため最優先で埋めます。
複数ベンダーが絡む場合は、ストア申請に必要な素材が揃った日を社内で統合受領日と定義するか検討してください。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。