№1666 ソフトウェア開発モデルと契約
システム開発契約の難点は初期段階では製品のあり方が見えない点にあり，どうしてもあいまいな部分が残ることだ。こうした曖昧さをはらみつつ，ソフトウェア開発契約が締結されることになる。
東京地裁H26.10.30判決（判時2257号70頁）は，従前のシステムから新システムに乗り換えるシステム開発契約が問題になった。顧客（ユーザー）は「現行システムの機能を全て満たした上で」新たな要望を満たすという内容だったと主張し，多くの点が不具合であったから検収を拒み，さらには残代金の支払いを拒んだという事例だ。
この事件では既製品であるパッケージソフトウェアを利用することで合意し，それで足りない部分をカスタマイズするという方式であった。裁判所はパッケージソフトウェアを利用する場合には，原則として「パッケージソフトウェアの機能とユーザーが要望する機能との比較」を行い，「カスタマイズは最小限に留め，業務をパッケージソフトにあわせる」ものだとしている。
この比較検討あわせていく作業を「フィットギャップ分析」と呼ばれているが，裁判所はこの「フィットギャップ分析」の過程を検討して，「現行システムの機能を網羅することを合意していなかった」としている。
裁判所はパッケージソフトウェア利用する場合の開発における「不確定要素」部分について「フィットギャップ分析」が適正に行われていたかどうかをもって，契約として適正に確定されていったかどうかを検討しているようにも見える。
本件では顧客と相互に検討しながら内容を確認して納品し，いざ使ってみると，それまでの「打ち合わせ内容を覆して，現行システムとの仕様のちがいを指摘し始めた」と認定した。つまり，製品としては正式に納品されたものの，新しくなったシステムになじめなかった部分についてクレームが繰り返されたに過ぎないとした。
ソフトウェアの開発は一般にはウォーターフォール型開発が伝統的に利用されている。これは，あいまいなソフトウェア開発をいくつかの開発段階（フェーズ）に分け，ここまでやったら次の段階という具合に段階をもって成果を確認し，次に進む手法だ。
①要件定義（要求分析），②基本設計，③構築，④運用に分けられ，段階を経て商品が納品されていく。開発契約もこうした開発の実態をみつつ，それが反映した形で作られていくことになるだろう。
本件の場合，既製品，パッケージソフトウェアを利用する点でこのプロセスの労力が節約されることになる。それに伴い，契約も特殊になるが，もっともパッケージソフトウェアを利用する契約の場合，最も重要な内容は「業務をパッケージソフトウェアにあわせる」という内容を明確に契約内容に盛り込むことが必要となる。
