システム開発においては、システム（プログラム）そのものを納入することが重要で、ドキュメント（設計書等）は軽視されがちです。ベンダーにとって、ドキュメントを作成するにも工数がかかります。
しかし、プログラムそのものを見ても、ユーザーが求めるものであるかどうかは簡単にはわかりませんし、現在、多くのシステムは、クラウド型であり、ベンダーが用意したサーバーに、ユーザーが、ID、パスワードなどを用いてアクセスして利用するものとなっており、納入といっても、モノがユーザーの手元に来るというものでもありません。
そのため、システム開発においては多くのドキュメントが作成され、ベンダー、ユーザー相互で内容が確認されます。もしドキュメントが無い場合は、ベンダーとユーザーの認識に齟齬が生じるおそれがあり、トラブルとなる可能性が高くなります。システムが完成したかどうかすら争いとなりかねません。
この点で、参考となる裁判例があります。
東京地判平成２６年９月１０日は、
「システムの開発が完了したといえるためには、これが被告又は被告の顧客が使用する端末機器等において支障なく動作し、被告が商品先物取引受託業務を行うに当たり十分な性能を有するものである必要があると解されるところ、原告は、画面のイメージ（甲１８から２５まで）を提出するにとどまり、プログラム本体はもとより、要件定義書、基本設計書、テスト結果報告書などを提出しておらず、原告が開発したというシステムがどのような性質を有しているのかも判然としない。要件定義書や基本設計書が作成されていない理由について、Aは、ウォーターフォール方式ではなくアジャイルという開発手法をとったためである旨供述するが（原告代表者）、仮にそうだとしても、システムが完成したのであれば、少なくともテスト結果を記録した書面や被告側の確認をとった旨記載された書面等は作成されるはずであり、E及びAは、そのような書面が作成されていない合理的な理由について説明していない」
と判示し、ドキュメントが作成されていないことについて、ベンダー側が合理的な理由を説明していないことから、システムが完成したとは認められないとしました。
要件定義書、外部設計書、テスト結果報告書のようなドキュメントを作成し、ユーザーに提示することはベンダーの責任であるとするITコンサルタントの方もいます。
ITシステムという直接目に見えないものを対象とする開発の場合は、特にドキュメントが重要となるのです。
ところが、ドキュメントの重要性を全く認識していないと思われる裁判がありました。
ある裁判では、ウォーターフォール方式の開発において、ベンダー側が、単体テスト、結合テスト等を行ったが、ユーザー側がシステムテストを行わなかったことが原因で、システム開発プロジェクトがとん挫したものであり、ユーザー側の協力義務違反であるとして、ベンダーがユーザーに対して不法行為に基づく損害賠償を請求した事件がありました（ベンダー側が行うテストが、単体テスト、結合テストだけでよいのかとか、ユーザー側がシステムテストを行う必要があるのかなど、別の問題もあるのですが、ここでは触れません。）。
他方、ユーザーは、単体テスト、結合テスト等ベンダーが行うべき作業が行われていない、もし単体テスト、結合テスト等が行われたというのであればテスト結果報告書があるはずであるとして、テスト結果報告書を提出するよう文書提出命令の申立てをしました。
これについて、裁判所は、文書提出命令の申立てを却下し、テスト結果報告書を確認することなく、ベンダーの代表者の陳述書だけで、ベンダーは単体テスト、結合テストを行ったということを認定し、ベンダーの主張を認め、ユーザーに対し損害賠償義務があると判断してしまいました。そもそも、当事者が争っているにもかかわらず、ベンダーの代表者の陳述書だけで、ベンダーがすべき作業はすべて行っていたと認定すること自体無理があり、事実認定において大いに疑問のある判断なのですが、それ以上に、本来、システム開発で作成されるべきドキュメントを確認しなかった点で、システム開発への理解の不十分さが出た裁判でした。
また、システム開発につき費用が前払いだったケースも問題となります。費用前払いのケースでは、仮にシステム開発がとん挫した場合、ユーザーは支払った費用を取り戻す必要があるので、ユーザーの方から裁判を提起しなければなりません。ユーザーは、すでに渡した費用の返還を求めて、債務不履行に基づく損害賠償請求や不当利得返還請求を提起します。ユーザーが原告であるということは、ユーザー側に、ベンダーの債務不履行、法律上の原因が無いことの立証責任があり、債務不履行、法律上の原因が無いことを立証できないと、ユーザー側は敗訴することになります。これが、民事訴訟の原則です。
しかしながら、そもそも、ベンダーの方がシステム開発に詳しい上（情報の非対称性）、自ら作業を行うことから多くの資料・証拠を有しています（証拠の偏在）。
また、ITシステムがクラウド型の場合、ベンダーが用意したサーバー上にベンダーがシステムを構築し、ID、パスワードなどを用いてシステムにアクセスすることになります。ところが、ユーザーが、ベンダーに債務不履行があるとして契約を解除しようとすると、ベンダーは、システムへのアクセスを拒否します。とすると、ユーザー側には、ベンダーの債務不履行（システムが未完成であるなど）を立証する証拠がなくなってしまいます。
もし、民事訴訟の立証責任の原則を形式的に適用すると、狡猾なベンダーは、あえて費用を前払いさせ、いい加減に作業を行い、完成していないにもかかわらず、完成したとユーザーに嘘を言っても、ユーザー側は立証する証拠が手元にないことから、ユーザー側の請求は悉く棄却されてしまうことになるでしょう。
これが公平な裁判でないことは明らかです。
そもそも、ユーザーの義務である費用負担を正当化するためには、その反対給付である、ユーザーの求めるシステムを開発するという義務が果たされていなければなりません。ユーザーの求めるシステムを開発する（使用できるようにする）ことは債務の本旨（契約の重要部分）です。仮に、途中でとん挫した場合でも、ベンダーが工程通りの作業を行っていたことが必要となります。
そこで、ベンダー、ユーザーどちらの手元にあるかにかかわらず、ドキュメント（要件定義書、外部設計書、詳細設計書、工程表、作業報告書、テスト結果報告書など多くのドキュメントが考えられます。）を確認することが必要なのです。このことを十分認識していたのが先ほどの裁判例（東京地判平成２６年９月１０日）です。先ほどの裁判例では、ベンダー側が原告なのですが、ユーザーである被告は、反訴として、債務不履行（履行遅滞）に基づく損害賠償請求を提起し、結果として被告の主張が認められています。
本来、作成されるはずのドキュメントが作成されていなかったり、本来、持っているはずのドキュメントが合理的理由なく提出されないということは、システム開発が完成していなかったり、作業が進んでいないことを裏付けることになります。
システム開発においては、ウォーターフォール方式だけでなくアジャイル開発であっても、ドキュメントが重要であるということをもう一度、認識すべきだと思います。