https://atmarkit.itmedia.co.jp/ait/articles/1704/17/news012_3.html
「この開発がたまたま裁判になったから、裁判所がシステムを完成したと判断するためにドキュメントが必要だっただけではないのか。通常のシステム開発で、裁判を意識することはまずないし、ユーザーと話し合い、検討し、テストを行っていくのだから、要件定義書や基本設計書、テスト結果報告書など不要なのではないか。一体、誰のためにドキュメントを残すのか」——そんな読者の声が聞こえてきそうだ。
確かに開発を成功裡に終了させること「だけ」を考えれば、必要なドキュメントは、話し合いの備忘録と、保守運用に必要なマニュアル程度かもしれない。開発中に要件の齟齬(そご)などが見つかったら、かつて残したメモを見ながらまた話し合えば済むかもしれない。
しかし、だ。
筆者は強く言いたい。システム開発にかかる数千万から数10億円というお金は、ユーザー企業の社員が汗水垂らして稼いだものだ。ユーザー側のシステム担当者は、大切なお金を使って作ったシステムの結果や効果を社員に説明できるようにしなければならないのではないか。それができなければ、背任を疑われることにもなりかねないし、システム監査にも耐えられない。
そうなるとベンダーには、ユーザーのシステム担当者が社内に説明できるだけのドキュメントを作る義務があるのではないだろうか。
「要件定義書」と「外部設計書」、その記載内容が実現していることを示す「テスト結果」。少なくともこの3つは、第三者が理解できるものを作成し、ユーザー社内に公開すべきだ。それが他人のお金を使ってシステム開発を行うものの責任だ、と筆者は考える。
システム開発の目的は、ユーザーとなる組織の業務を改善することにあり、だからこそ、会社の利益を減らしてでも実施する。ならば、使ったお金が確かに組織の経営や業務にメリットをもたらすことを、「いつでも」「誰にでも」説明できる必要があり、そのためには、開発ドキュメントをきちんと残しておくのは大切なことではないだろうか。
昔も今も、システム開発に携わる人間は視野狭窄(きょうさく)に陥り、「システムが正しく動作すること」ばかりに注意を向けがちだ。しかし、ドキュメント作りも決して軽視すべき作業ではない。これは、しっかり肝に銘じるべきことだ。
ITコンサルタント
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。