№1667　システム開発契約のあり方

　どんな契約書でもそうだが，当事者双方の取引の実態を正確に整理して反映していく。不確定要素は「リスク」と呼ばれ，リスクに対して紛争解決の方式を定めておく。このリスクからくる責任をどちらがどれだけ負担するかという点で，企業法務上の攻防が繰り広げられると言って良い。

　無防備な企業，あるいは力関係で弱い企業はリスクをどんどん引き受けることになって，いざトラブルとなると大きな損失を被ることになる。

　システム開発の場合，通常はウォーターフォール方式によって開発される。①要件定義（要求分析），②基本設計，③構築，④運用と4段階に分かれて理解される。この方式では各段階を確定させた上で次の段階に進むので後戻りのない方式というのが原則である。

　当然，契約上もこれを反映させることになる。

　たとえば，①要件定義，②基本設計と契約の段階も，それ応じて作り上げていく方式もけっこうある。

「要件定義サービス個別契約」という名称を使うこともある。これは要件の確定を行い，原告は，要件確定後，内容をとりまとめたシステム確認書を提出する。システム確認書が受領されるとサービスが終了し，代金が支払われる。

　次の段階が「設計サービス確認契約」ということになる。こうして，各段階ごとに納期を決め，納期ごとに代金を支払う方式はウォーターフォール方式で開発する場合に対応した契約方式ということになる。

　契約書を作成する場合，こうした各段階の特性の応じた契約内容を作り上げて行くことになる。

　たとえば，要件定義の場合，顧客からの要求を拾い上げて要件定義書を作り上げていくことになる。要求を拾い上げる作業はユーザーの積極的な協力無くしてあり得ない。

　ユーザーは専門家であるベンダーの援助を受けつつ，実現したい目的を整理してもらうことになる。そうなると，ここでの契約上の問題は，ユーザーの協力義務を明示する必要がある。また，最終的には「定義書」とような完成品が納品されることになるがその場合の「検収」のあり方と代金の支払い方法について定めておく必要がある。

ベンダーの側から言えば，最初から何もかも分かるものではないということになろう。その場合，進行に応じて「要件定義」の変更がありうる事が契約書委明示される必要があるだろう。この場合の追加料金についても定めなども必要と思われるが，難しい問題をはらんでいる。

　これは，何もないところから開発する場合の一般的プロセスを示しているに過ぎない。通常は開発の手間や費用を節約するためにパッケージソフトウェアを利用する。この場合にはパッケージソフトウェアを利用する事を前提に，ユーザーの業務をそれにあわせてもらうという契約となる。