＜事案＞
Ｘは，化学薬品の研究等を行う株式会社である。Ｙは，システム開発等を行う株式会社である。ＸとＹは，Ｘの経営情報システム「○○ｖｅｒ７」（以下「本件システム」という。）の開発について請負契約（以下，「本件請負契約」といいます。）を締結し，ＸはＹに対して請負代金のうち，一部を支払った。しかし，Ｙが本件システムを完成させなかったとして，ＸはＹに対して，主位的に，債務不履行に基づく損害賠償請求を，予備的に，本件請負契約の解除に基づく原状回復として，上記既払額及び遅延損害金の支払を求めた。
＜争点＞
①本件請負契約において完成させるべき仕事は何か。
種々の争点がありますが，この点に絞ってみていきましょう。ここでは，裁判所がどのような点に着目をしているのかを見てもらえれば良いです。要するに，こういう観点からみているので，その点に注意して仕事をしていきましょうという教訓にしていただければ幸いです。
＜結論＞
①について
検討されたのは以下の点である。
前提として，本件請負契約において，当初，原告が基本設計書を提供し，詳細設計以降の下流工程を被告が担当することとされていたことには争いがないことが確認されている。そして，結論をだすに当たり議論をされたのは以下の点です。
①本件原告提供資料が基本設計書として本来備えるべき内容を備えていたか
②基本設計書の作成責任者が原告から被告に変わったか
③本件仕様書と本件仕事の範囲との関係はどのようなものか
まず，①については，以下のとおりである。
・本件原告提供資料は，
A：ドキュメント相互で用語の統一が図られていないこと，
B:画面設計書では画面イメージは表示されているものの各画面ごとの入力項目毎の属性，すなわち，当該画面において，どのようなデータが，どのように用いられるのかについて何ら説明されていないこと，
C：本件ＲＦＰによるならば，ＤＡＭを提供することによってテーブル毎の正規化が完了した基本設計書が渡されるはずであったのに，ＥＲ図（１対１又は１対多といったテーブル間の関係を示した図）などの図面やこれに代わる説明もなかったこと，
D：ＤＡＭについては，平成１９年１月１９日の段階でも全般的な見直しが必要とされていたこと
が認められる。
・詳細設計以降の下流工程では，実際にプログラミングを行うものであるから，用語の定義は厳格かつ一義的に行われなければならないことは当然であるところ，ドキュメント相互で用語の統一が図られていない状態では，機能毎の連携をとることは不可能といってよい。
・本件システム開発はＳＱＬによるプログラミングが予定されていたこと，「正規化」という単語が本件ＲＦＰ①に用いられていることからも，リレーショナルデータベース管理システムによるシステム開発が予定されていたことが認められるところ，リレーショナルデータベース管理システムによるシステム開発においては，テーブル間の関係が１対１又は１対多であるかの指定は極めて重要である。そして，１対１又は１対多の関係は，ユーザーの業務分析の結果，決定されるべきものであるから，基本設計書において決定されるべき問題であるし，実際に本件外部設計書には，テーブル相互の関係を示すＥＲ図が添付されている。
⇒本件原告提供資料は，詳細設計の前提となる情報が十分に記載されたものではないのであるから，基本設計書としての内容を備えていたものとは認めることはできない。この点，原告は，被告が，原告の旧システムを参照したり，△△理論に関する補足資料を参照するなどすれば本件原告提供資料の内容を理解することは可能であると主張し，Ｂもそのように証言する。しかし，そもそもウォーターフォールモデルにおける開発とは，上流工程に問題がないことを前提としているものであるところ，基本設計書は，基本設計過程ないしはそれよりも上流工程に行われる業務分析の結果を反映させて作成させるものであり，ベンダーが旧システムの運用などから逆算してその内容を推察するような性質のものではない。
次に，②について，ａ社が本件システム開発から脱退する頃，基本設計書の作成責任者が原告から被告に変わったか
・ａ社脱退に至る経緯について
前記認定事実(3)及び(9)によると，原告は，ａ社から被告の開発姿勢には問題があるとの指摘を受けていながらも，△△理論に基づく設計は困難であるとして，被告ではなくａ社との契約を打ち切ることを決断したことが認められる。
この点，Ｂ及びＣは，被告担当者のＪから，原告が，ａ社の手法に疑問を感じ，ａ社との契約を打ち切るとの文書を出すように求めたと証言するが，被告は，平成１９年２月２１日付けの被告から原告へ送られたメール（甲１１）においても，ａ社脱退後の平成１９年３月１６日付けの文書（乙１５）においても一貫してａ社の関与を希望しているし，基本設計に一定の関与をすることになった被告が，原告の業務分析を担当したことのあるａ社を排除する理由はないのであるから，Ｂ及びＣの前記証言は採用できない。
このことからすると，ａ社脱退は，原告が，ａ社の開発手法に問題を感じた結果，原告自らａ社との契約を打ち切った結果生じたものであると認められる。
・平成１９年２月２１日以降の開発計画見直しの結果について
アのとおり，ａ社脱退に至る経緯は，専ら原告の判断によるものであるところ，被告は，前記認定事実(9)ないし(11)のとおり，平成１９年２月２１日，原告に対し，被告が基本設計を担当することの承諾を求めたが，原告はこれを承諾しなかったことが認められる。
したがって，基本設計書の作成責任者が原告から被告に変わったとは認められない。
・この点，原告は，被告が作成した同月２０付け及び２２日付けの各システム移行修正計画表（案）（甲１１，乙７）によれば「基本設計見直し」が被告の担当とされていることから，被告が基本設計書の作成責任者となったと主張する。しかし，同表はあくまでも「基本設計書作成」はａ社となっており，ａ社が関与することを前提とした上で，被告もまた一定の関与を行うものとなっているのであって，これをもって被告が基本設計書の作成責任者となったものと直ちにいうことはできない。
よって原告の主張は採用できない。
最後に，③本件仕様書と本件仕事の範囲との関係について
・ 原告と被告は，ａ社脱退後，仕様の確定以前の問題として，仕様確定の時期を明らかにした上で，その時期までに仕様とした部分を，本件請負契約における開発対象とし，その余は第２次開発の対象とすることに合意したこと，平成１９年１０月１２日から平成２０年１月２９日にかけて，被告がドキュメントを提供し，原告が確認した上で，最終的に，Ｂが承認する形で本件仕様書が作成されていったことが認められる。そうすると，本件仕事の範囲は本件仕様書で定められたものであると認められる。そして，本件Ａ区分契約は，本件仕様書が完成した後に，新たに開発対象とした部分であるから，本来は本件仕事とは別の第２次開発の範囲に含められるべきものであるが，優先順位が高いものとして本件受入テストまでに納品をすることとされたものと認められる。
なお，本件では，基本設計書が具体的にどの文書をいうのかについて後記のとおり争いがあるが，以下では，原告が被告に提供した文書（甲１９）を「本件原告提供資料」，被告が本件システムの開発における基本設計書を含むものであると主張する文書（乙８）を「本件仕様書」，被告が後記本件受入テストの際に納品した，「機能設計書」と題するファイル群（乙２０のＣＤ－Ｒ中の「機能設計書」フォルダに含まれるファイル全体をいう。
以上のようにシステム開発に係る契約は，請負契約として締結される場合，その仕事の範囲は果たしてどこからどこまでなのかが議論になることは多々あります。基本的には，要求仕様書や情報システムのプロジェクト計画書などによってその範囲を特定していくことになるでしょう。RFP（Request for Informaiton）も参考とされます。ですので，システム開発に取り掛かる前にきちんと何をどこまで，いくらでやるのかなどを詳細にまで取り決めておく必要があります。手間のかかることですが，最後に取りっぱぐれたり，過大な請求をされたりすることを防ぐためには，重要なことです。
なお，上記では取り上げていませんが，当裁判例は，本件における仕事の範囲はどこからどこまでかを議論した後に，では仕事が完成したと言えるのかを議論しています。
