ここから本文です

アジャイルだか何だか知らないけれど、ドキュメントがないのでシステムは未完成ね――IT訴訟 徹底解説

4/19(水) 7:10配信

@IT

●アジャイル開発だからドキュメントはいらない?

 最近はアジャイル開発が一般的になり、ユーザーと一緒になって話し合いながらモノづくりをしていく現場では、「ドキュメントは必要ない」と考える技術者も増えていると思う。実際、最近の開発では、「要件定義書」や「設計書」、あるいは「テスト仕様書」や、その「結果報告書」も作成せず、簡単なメモを残すだけで、後はプログラム本体を納品すれば完了してしまうようなものもある。

【システム開発にドキュメントなんていらないよね】

 この考え方は、ある意味合理的だ。システムを細かい機能に分けて、ユーザーヒアリングやワークショップを行いながら、実装、テストする開発方式では、正式なドキュメントを作り、レビューや修正を行った後にプログラミングに入るより、できかけのプログラムをユーザーに見せて指摘をもらい、すぐに直してテストまで行ってしまう方が、効率的で生産性も高いともいえる。実際、余計なドキュメントの作成を後回しにするか、場合によっては「作らない」とするプロジェクトも増加しているのではないだろうか。

●ドキュメントがない納品

 そんなドキュメントより実物重視の時代に警鐘を鳴らすような判決が、平成26年に出た。「どこまで」のドキュメントを「いつまで」に残すべきか、そんなことを疑問に思うベンダー、あるいはユーザーは、ぜひ参考にしていただきたい。

---
東京地方裁判所 平成26年9月10日判決より

商品先物取引受託業務を行うユーザー企業が、業務システムの開発をITベンダーに依頼し、ベンダーはこれを行ったが、ユーザー企業は、請負代金などをベンダーに支払わなかった。理由は、ベンダーが期限までにシステムを完成させなかったとのことだったが、ベンダーは、システムは完成させたとして、未払の代金と開発中に使用したデータセンターの利用料の支払いを求めて裁判所に訴え出た。

一方ユーザー企業は、システムは完成しておらず、既払い代金の相当額を損賠として、その賠償を求めて、反訴を提起した。
---

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

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

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

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

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

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

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

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

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

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

●ドキュメントは誰のため

 「この開発がたまたま裁判になったから、裁判所がシステムを完成したと判断するためにドキュメントが必要だっただけではないのか。通常のシステム開発で、裁判を意識することはまずないし、ユーザーと話し合い、検討し、テストを行っていくのだから、要件定義書や基本設計書、テスト結果報告書など不要なのではないか。一体、誰のためにドキュメントを残すのか」――そんな読者の声が聞こえてきそうだ。

 確かに開発を成功裡に終了させること「だけ」を考えれば、必要なドキュメントは、話し合いの備忘録と、保守運用に必要なマニュアル程度かもしれない。開発中に要件の齟齬(そご)などが見つかったら、かつて残したメモを見ながらまた話し合えば済むかもしれない。

 しかし、だ。

 筆者は強く言いたい。システム開発にかかる数千万から数10億円というお金は、ユーザー企業の社員が汗水垂らして稼いだものだ。ユーザー側のシステム担当者は、大切なお金を使って作ったシステムの結果や効果を社員に説明できるようにしなければならないのではないか。それができなければ、背任を疑われることにもなりかねないし、システム監査にも耐えられない。

 そうなるとベンダーには、ユーザーのシステム担当者が社内に説明できるだけのドキュメントを作る義務があるのではないだろうか。

 「要件定義書」と「外部設計書」、その記載内容が実現していることを示す「テスト結果」。少なくともこの3つは、第三者が理解できるものを作成し、ユーザー社内に公開すべきだ。それが他人のお金を使ってシステム開発を行うものの責任だ、と筆者は考える。

 システム開発の目的は、ユーザーとなる組織の業務を改善することにあり、だからこそ、会社の利益を減らしてでも実施する。ならば、使ったお金が確かに組織の経営や業務にメリットをもたらすことを、「いつでも」「誰にでも」説明できる必要があり、そのためには、開発ドキュメントをきちんと残しておくのは大切なことではないだろうか。

 昔も今も、システム開発に携わる人間は視野狭窄(きょうさく)に陥り、「システムが正しく動作すること」ばかりに注意を向けがちだ。しかし、ドキュメント作りも決して軽視すべき作業ではない。これは、しっかり肝に銘じるべきことだ。

●細川義洋
ITコンサルタント
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

●書籍紹介
本連載が書籍になりました!
成功するシステム開発は裁判に学べ!~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
細川義洋著 技術評論社 2138円(税込み)
本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。

最終更新:4/19(水) 7:10
@IT