連載企画「実践！業態別契約書」の3回目は、前回に引き続き、IT系の制作物に関する業務委託契約書を取り上げます。前回はIT系制作物に関する業務委託契約の概要について解説しましたので、今回は契約書における重要なポイントについて触れていきます。
　IT系制作物に関する契約の代表は、新規のシステム開発委託契約です。新規でシステムを開発することはあまりないかもしれませんが、Web制作関連の契約にも共通するところは多いので、こちらを例にとって解説します。

1　システム開発委託の構造

　システム開発委託契約は、一つの契約のように見えて、開発事業者（一般に「ベンダー」といいます。）が行うべき業務は多岐にわたります。システム開発というとプログラマーが言語を使ってプログラムを書くイメージをお持ちの方もいらっしゃるでしょうし、それはそれで正しいのですが、それが全てではありません。
　システム開発は、大きく分けて「要件定義」→「設計」→「コーディング」→「テスト」→「リリース・納品」という工程で実施されます。プログラマーがプログラムを書くのは、この中の「コーディング」という工程です。これは家屋の建築において大工さんが資材を組んで家屋の形にする工程とある意味同じですが、システム開発でも建築でも、作業の前には必ず設計があります。その設計の前には「どんなモノを作りたいのか」という顧客（ユーザー）のニーズがあります。システム開発では、まず顧客のニーズ、すなわち顧客が何をするために新しいシステムを欲しいと考えているのか、既存のモノでは何が不足なのかという、根源的な目的を明らかにするところからスタートします。これを定義していく工程が「要件定義」です。
　次に、要件定義に従って、技術的にどのようなモノを作っていくか、最終的なプロダクトの出来上がりを意識した設計をします。設計には、外部設計と内部設計があり、外部設計はシステムの外観（UI＝ユーザインタフェース）や使い勝手などに関する設計、内部設計は外部設計をもとにしたプログラムの構造に関する設計です。ベンダーは、これら外部設計と内部設計を設計書の形で取りまとめます。
　設計ができたら、システムエンジニアやプログラマーが、特定のプログラム言語を使って、設計に書いてあることを実現するためのプログラムを書いていきます。これをコーディングといいます。
　コーディングを終えれば、システムは形になります。今度は出来上がったシステムが設計どおり動き、要件定義どおりに動作し、ユーザーのニーズを満たすものになっているかのテストを行います。通常、システムが一発で組み上がることはなく、多かれ少なかれバグが見つかりますので、これがなくなるまで（完全になくすことは現実的には不可能ですが）テストを繰り返し、最後にユーザーに納品されます。
　システム開発委託契約書は、このようなシステム開発の工程をトレースしたものになっている必要があります。

2　システム開発委託契約書における重要な規定

　以下、システム開発委託契約書で特に重要度が高い規定について解説していきます。

(1)　定義規定

　定義規定はシステム開発委託契約書に限らず設けられるものですが、システム開発委託契約書は条文や専門用語が多くなりやすいため、語義を明確にするため定義規定が設けられることが特に多い印象です。必須ではないものの、これを設けておくと全体がすっきりします。

(2)　協議会に関する規定

　企業向けのシステムは、企業で多数の人が使用することを前提に作られることがほとんどです。様々な部署の様々な用途のニーズを満たすためには、ユーザー側は各部署の意見を吸い上げ、ベンダーの各工程とこれを共有しなければなりません。これを効率的に実施するため、ユーザーとベンダーの実務担当者の間で協議会を立ち上げ、ここで情報や意見の共有をすることが多いです。

(3)　仕様の特定に関する規定

　システム開発委託契約書ではこれが最も重要と言って過言ではありません。

　上記のとおり、システムを開発するに当たっては、「どんなものを作るのか」の特定がスタートラインです。とはいえ契約時にはそれすら完全に特定されておらず、ベンダーの専門的技術的意見を加味して初めて「作るべきモノ」の全体像ができることがほとんどです。
　そこで、システム開発委託契約書では、「仕様そのもの」よりも、「仕様をどのようにして定めるか」に関する規定を置くことが多いと言えます。具体的には、どのようなプロセスで、どのような形式（書類等）で仕様を特定するかと、一度決まった仕様を変更するときのプロセスや、仕様を変更した場合における費用の取扱に関する規定です。
　システム開発の場面では、一度決まった仕様が途中で変更されることも少なくありません。そして、これは開発途中で仕様を満たすことが技術的に困難であることがわかったなどベンダー側の事情であることも、当初出ていなかった別の機能の追加を求めるなどユーザー側の事情であることも、両方あります。一度決まった仕様を変えるとその分工程が増え、工程が増えれば人件費が増えますので、増加する費用を誰が持つのかは、予め決めておいた方が紛争の予防に繋がります。また、テストや納品検査（検収）の際に参照すべき仕様を特定するためにも、仕様を変更したことは記録化しておく必要がありますので、記録化の方法なども定めます。

(4)　納品検査（検収）

　コーディングとテストを経て完成したシステムは、ユーザーの納品検査を経て検収となり、ここでベンダーの業務は一区切りとなります。ただ、システムの特殊なところは、物品の購入などと違い、「仕様に適合しているか」の検査基準を予め決めておかなければ検査自体ができないことがあることと、仕様に適合しているかどうかは、使ってみなければ完全にはわからないところがあることです。納品検査ではわからない部分は、契約不適合責任の規定に処理を譲ることになります。

(5)　知的財産権の処理

　成果物としてのシステムはプログラムの集合体であり、著作権による保護の対象となります。著作権は著作者＝ベンダーに第一次的に帰属しますので、これをユーザーが取得するならば、著作権の譲渡に関する規定が必須です。開発の対象となったシステムやベンダーの方針にもよりますが、一般に、オリジナルのシステムを開発したときには著作権はユーザーに譲渡されることが多く、Web制作など汎用の素材を用いる場合はベンダーに留保されることが多い傾向です。パッケージシステムの販売の場合は販売者が著作権を保有し、ユーザーにライセンス（利用許諾）を与えるという形式になります。

(6)　プロジェクトマネジメント

　システム開発の工程のうち上流にある要件定義は、専らユーザーの意向を固める作業です。ベンダーに丸投げでは全く前に進みません。でも納期が決まっていると、結局コーディングを突貫工事にするしかなくなってしまいます。これではベンダー側が大変なだけではなく、ユーザー側にとってもトラブル含みの成果物が上がってきてしまい、誰にとっても良いことはありません。
　このため、システム開発委託契約書では、プロジェクトマネジメントの責任と、ベンダー、ユーザー間の役割分担を明確化する規定を置きます。この規定により、誰が、どの段階で、何をしなければならないかが明確となります。

(7)　保守

　システムは開発・納品して終わりということはまずありません。どんなに完璧に作り込んだシステムでもどこかに必ず微細なバグが入り込んでいますし、特定のウイルスやサイバー攻撃への脆弱性が判明することもあります。そのような場合のアップデートのほか、使い方の問合せやトラブル対応など、システムはほとんど例外なく「保守」がセットとなります。保守契約はシステム開発委託契約書とは別に締結されることが多いですが、システム開発委託契約と関連して必要になることを知っておきましょう。

3　まとめ

　他にもシステム開発委託契約書で気をつけるべきことは沢山ありますが、共通していえることは、「仕様の特定」と「仕様の変更時の処理」を明確にすることで、システム開発委託契約にまつわるトラブルの大半は予防することができる、ということです。「何をやって、何をやらないか」の認識を共通化することは他の契約類型でも大事ではありますが、システム開発関係では特に曖昧になりがちですので、委託側も受託側も、この点に十分注意しましょう。