ゲームの開発を外部のスタジオに任せるとき、契約を「請負」にするか「準委任」にするかで、発注側と受注側の責任の置き方は変わります。本記事では、経済産業省が公開している「情報システム・モデル取引・契約書」の考え方を手がかりに、ゲーム開発を外注する法人の担当者が依頼の前に決めておきたい点を整理します。法的助言ではありません。実際の契約条件は、弁護士など専門家にご確認ください。
請負と準委任の基本的な違い
一般的な整理では、請負は「仕事の完成」を約束する契約、準委任は「業務を行うこと」を約束する契約です。ゲーム開発のように、最初は仕様が固まりきっていない案件で全工程を一つの契約にすると、「どこまでが成果物か」が曖昧になりやすくなります。
経産省のモデル契約書にみる考え方
経済産業省のモデル契約書（平成19年4月、第一版）は、情報システムの受託開発を対象に、工程ごとの契約の考え方を示しています。公開資料で確認できた範囲は次のとおりです。
- 企画段階は準委任とされています。業務要件が固まっていない段階では、受託側も成果物を特定できないためです。
- 開発段階は請負と準委任の両方があり得ます。内部設計以降のソフトウェア設計、プログラミング、テストは請負型が想定されています。
- 受入・導入支援や運用テストは準委任型とされています。
- 請負にすると発注側に「丸投げ」の意識が強まる懸念が指摘されています。準委任では、要件定義などで発注側が担うべき責任が明確になるという考え方が示されています。
この資料は情報システムを対象とした2007年のもので、ゲームやアニメの制作にそのまま当てはまるわけではありません。ただ、「仕様が固まっていない段階」と「固まった後の段階」で契約の性質を分ける発想は、ゲーム開発の外注を考える際の参考になります。
工程ごとに契約を分ける「多段階契約」
同じモデル契約書は、工程ごとに個別契約を結ぶ方式を例示しています。たとえば、コンサル（準委任）、要件定義（準委任）、外部設計（準委任または請負）、ソフトウェア開発（請負）といった分け方です。見積りも「試算、概算、確定」と精度を上げながら進め、各工程の開始時に再見積りができる仕組みとされています。あわせて、契約単位だけでなく、全体の工程と予算の管理が重要だと述べられています。
ゲーム開発の外注前に決めておきたい5つの点
以下は上記資料の考え方をもとにした一般的な整理です。個別の案件では条件が異なります。
1. どこまでを一つの契約にするか
企画やプロトタイプなど仕様が動く段階と、仕様確定後の制作段階を分けて契約するかどうかを、最初に検討します。
2. 受入の基準を事前に書面にする
モデル契約書には、発注側の検査の合否判断基準となる「検査仕様書」が登場します。ゲームでも、何をもって完了とするかを納品前に書面で共有しておくと、認識のずれを減らしやすくなります。
3. 仕様変更の手続を決める
外部設計の承認後に要件の追加や仕様変更が生じた場合は、変更管理の手続に従って委託料や納期を協議することが望ましい、とされています。変更の申し出方法と、費用・納期への反映方法を決めておきます。
4. 発注側が担う判断を整理する
モデル契約書では、業務要件とシステム要件を定める責任は発注側（ユーザ）にあり、機能要件に加えて非機能要件も明確にすることが重要とされています。ゲームでは、遊びの狙いや対象プラットフォームなど、発注側が決める事項を洗い出しておきます。
5. 権利・費用・体制は案件ごとに確認する
成果物の権利の帰属、費用、体制、不具合への対応などは、案件ごとに個別に定める必要があります。モデル契約書も、瑕疵担保の期間や損害賠償の上限額などは、個々のシステムの特性に応じて定めるとしています。
FounderBank について
ファウンダーバンク株式会社の公式サイトには、「IPプロデュース＆制作」として、アニメ、ゲーム、ライトノベルなどの新規IPを企画段階から作り、作品化と発信を支援すると記載されています。料金や契約条件、契約書の作成や法的判断を提供するという記載はサイトにありません。個別の相談内容や条件は、お問い合わせください。
Before Outsourcing Game Development: Contract Types, Acceptance and Change Control
When you entrust game development to an outside studio, whether the contract is a work-for-completion contract (ukeoi) or a quasi-mandate contract (jun-inin) changes how responsibilities are divided between client and contractor. This article uses the Japanese Ministry of Economy, Trade and Industry (METI) published Model Transaction and Contract Documents for Information Systems as a starting point and organizes what a corporate client should settle before commissioning a game project. This is not legal advice; please have actual contract terms reviewed by a qualified professional.
The basic difference
As a general rule, a ukeoi contract promises the completion of a piece of work, while a jun-inin contract promises the performance of services. In a game project whose specifications are not yet firm, putting every phase under a single contract can make it unclear what exactly counts as a deliverable.
What the METI model contract says
The METI model contract (April 2007, first edition) covers commissioned development of information systems and describes how to treat each phase. Within the published document, we could confirm the following.
- The planning phase is treated as jun-inin, because the contractor cannot specify deliverables while business requirements are still open.
- The development phase may use either type. From internal design onward, software design, programming and testing are assumed to be ukeoi.
- Acceptance and deployment support and operational testing are treated as jun-inin.
- The document notes a concern that ukeoi can encourage a hands-off attitude on the client side, and that jun-inin makes the client’s own responsibilities, such as requirements definition, clearer.
This document concerns information systems and dates from 2007, so it does not apply directly to game or anime production. Even so, the idea of separating the phase where specifications are still moving from the phase after they are fixed is a useful reference.
Multi-stage contracts
The same document gives an example of concluding a separate contract for each phase: for instance consulting (jun-inin), requirements definition (jun-inin), external design (jun-inin or ukeoi) and software development (ukeoi). Estimates are refined step by step, from a rough calculation to an approximate figure to a fixed figure, with a chance to re-estimate at the start of each phase. It also stresses managing the overall schedule and budget, not only individual contracts.
Five points to settle before outsourcing a game
The following is a general summary based on the above, and individual projects differ.
- 1. Decide how much goes into one contract, and whether to separate the planning or prototype phase from the production phase.
- 2. Put acceptance criteria in writing in advance. The model contract uses an inspection specification as the basis for the client’s pass or fail decision; for a game, agree in writing what counts as done before delivery.
- 3. Agree on a change procedure. After the external design is approved, additions or changes to requirements are best handled through change control, discussing fees and delivery dates.
- 4. Clarify what the client must decide. The model contract places responsibility for defining business and system requirements on the client and stresses clarifying non-functional requirements as well.
- 5. Confirm rights, costs and team structure case by case. The model contract itself says that defect-liability periods and caps on damages should be set according to the characteristics of each system.
About FounderBank
The FounderBank Inc. website describes IP production and development, supporting new IP in anime, games and light novels from the planning stage through to production and release. The website does not state fees, contract terms, contract drafting or legal judgment as part of its offering. Please contact us to discuss your specific project and conditions.
お問い合わせ / Contact
日本語・英語どちらでもご相談を受け付けています。お問い合わせページはこちら。
You can write to us in Japanese or English via the contact page.
この記事へのコメントはありません。