アジャイルだか何だか知らないけれど、ドキュメントがないのでシステムは未完成ね：「訴えてやる！」の前に読む IT訴訟 徹底解説（39）（2/3 ページ）

IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「システム開発におけるドキュメントは、何のために必要か？」を解説する。

[ITプロセスコンサルタント 細川義洋，＠IT]

　判決文を見ていくと、このシステムには、「テスト発注」や「顧客情報登録ができない」などの重大な欠陥があり、ベンダーに不利な判決とならざるを得ない。

　この開発では、ITベンダーは十分なドキュメントを残さず、ユーザーとの「システムの画面イメージ」のやりとりにとどまっていたようだ。「要件定義書」や「設計書」「テストの仕様」や「テスト結果」も残されていない。

　ITベンダーはこれらを、「この開発はアジャイル方式で行っていた。この方式は従来のウオーターフォールと異なり、余計なドキュメントは残さないものだ」と説明した。

　確かにアジャイル開発方式の中には、「開発中に無駄なドキュメントを作るのは、非効率だ」とする方法論も存在する（アジャイル開発方式には、幾つもの種類がある）。システムの出来栄えはユーザーと共に確認するので、「納期とコストを守るために、ドキュメントは極力作らない方が良い」という考え方だ。

　では裁判所は、「ユーザーのために必要なドキュメントとは、何なのか」について、どのような見解を示したのだろうか。

東京地方裁判所 平成26年9月10日判決より（続き）

システムの開発が完了したといえるためには、これが顧客が使用する端末機器などにおいて支障なく動作し、商品先物取引受託業務を行うに当たり十分な性能を有するものである必要があると解されるところ、ベンダーは、画面のイメージを提出するにとどまり（中略）要件定義書、基本設計書、テスト結果報告書などを提出しておらず、システムがどのような性能を有しているものか判然としない。

要件定義書や基本設計書が作成されていない理由について、ベンダーは、ウオーターフォール方式ではなくアジャイルという開発手法をとったためである旨供述するが、仮にそうだとしても、システムが完成したのであれば、少なくともそのテスト結果を記録した書面やユーザー側の確認をとった旨記載された書面などは作成されるはずであり、（中略）そのような書面が作成されていない合理的な理由について説明していない。

　まとめると、「システムが本当に完成したのだと言うためには、要件定義書、基本設計書、テスト結果報告書などの客観的な証跡が必要である。それなしには、そもそも何を作れば良かったのかが分からず、また要望通りにできたのかも確認できない」ということだ。

　モノづくりにドキュメントは必須でなくても、モノが確かに出来上がったことを客観的に証明するためには、必要なドキュメントもあるということだ。