前回は，契約書などの文書が存在しない場合，裁判所が企業間の契約成立の肯定に消極的であることを紹介しました。では，どのような状況であれば，契約の成立が肯定されるのでしょうか。今回はこの点を含めて，オーダーメイドのシステム開発における請負契約の問題点を明らかにします。その上で，問題点への対応策を検討してみたいと思います。
合意された内容が不明確な場合，請負契約の成立が否定されることも
オーダーメイドのシステム開発における請負契約では，その成立時期を判断する上で，参考となる裁判例が存在します。この裁判は，契約成立の時期について以下のように判示しています。
| 名古屋地裁平成16年1月28日判決 本件総合システムの導入に際して締結されるような，業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は，業者とユーザ間の仕様確認等の交渉を経て，業者から仕様書及び見積書などが提示され，これをユーザが承認して発注することにより相互の債権債務の内容が確定したところで成立するに至るのが通常であると考えられる。 |
ここでは「業者から仕様書及び見積書などが提示され，これをユーザが承認して発注することにより相互の債権債務の内容が確定したところで成立するに至る」と判断しています。名古屋地裁は，請負契約の要素を「仕事の内容（開発対象）と報酬」と見て，仕事の内容となるシステムの仕様（開発対象）が明確でなければ，請負契約が成立しないと考えたのではないでしょうか。
企業情報システムの開発は，通常，ウォーターフォール型と呼ばれる流れに沿って進められます（表）。このうち要件定義と外部設計は開発対象の仕様を確定する部分であり，内部設計以降は，要件定義，外部設計に基づいて実際にシステムを開発する工程となります。
工程の分類，名称，内容は企業や論者により異なる
| 順番 | 名称 | 作業内容 | 備考 |
| 1 | 要件定義 | ユーザーの要望を分析し，システムに実装する機能を設定する作業 | 開発の対象を明らかにする工程（開発対象を定める工程） |
| 2 | 外部設計 （基本設計） |
利用者から観察できる部分の設計（例えばシステムの画面やシステム構築等） | |
| 3 | 内部設計 （詳細設計） |
要件定義や外部設計書に基づいて，プログラムのアルゴリズム等を設計する作業 | 決定された開発の対象を実現する工程（開発対象とされたシステムを実現する工程） |
| 4 | プログラミング | プログラムのコーディング作業 | |
| 5 | 単体テスト | 単体のプログラムのテスト | |
| 6 | 結合テスト | 複数のプログラムを同時に実行させた場合のテスト | |
| 7 | 運用テスト | 発注者であるユーザの現場でのテスト |
ここで，外部設計までを「開発対象を特定する工程」であると考え，上記名古屋地裁が判示する請負契約は，「相互の債権債務の内容が確定したところで成立」するという立場を徹底すると，外部設計の内容が合意された段階で，請負契約が成立するという解釈も成立し得るでしょう。現実の裁判では，事案に応じた柔軟な解決が図られ，単純に外部設計相当の合意が存在していたかという基準で判断するということはしないかもしれません。
しかし，ベンダーのリスク管理という視点からすると，外部設計相当の内容について合意が得られているという点は，「仕事の内容が不明確であるから契約が成立していない」という結論を排斥できる可能性が高まるという意味で安心なのです。
他方，上記のように考えると，外部設計相当の内容について合意が得られていない場合（仕様が不明確であると判断された場合），請負契約の成立自体が否定され，作業をしていたにもかかわらず対価を支払ってもらえないリスクが生じ得ることになるわけです。
小規模なシステムの開発であればともかく，開発するシステムの規模が大きくなれば，上流工程にかかる費用も多額になります。ですから，上流工程の作業についても，作業が無駄にならないように，債権を回収しやすい仕組みを採用しておかなければ，リスク管理としては不十分でしょう。それでは，このような問題を回避するには，どのようにしたらよいのでしょうか。
