嘘つきのはじまり

世間の人々は、コンピュータシステムがどのように動くかということは、きちんと文書にまとめられているものと思っているかもしれない。プログラムは、仕様書を元に寸分違わず作り上げられるものだろうと。「コンピュータ」とか「プログラム」という言葉には、そのようなキッチリとしたイメージがある。

しかし、実際には全くそんなことはない。仕様書（設計書）が全く書かれない場合もあるし、書かれていても「嘘」であることも多い。プログラマに設計書とソースコードを渡して、そのプログラムがどのような動作をするか尋ねてみるといい。そのとき、「確実な答えが欲しい」と念を押せば、彼は必ずソースコードを読むだろう。

★

もちろん、設計書に最初から嘘が書かれているわけではない。システムを作っているうちに、実際のプログラムと一致しなくなってしまうのである。システム開発では、設計後に仕様変更が発生したり、想定外の問題に直面して実装方法を変更したりすることは日常茶飯事だが、そのときに設計書を修正しないからだ。

なぜ修正しないかって？　そのための時間が足りないからである（つまり費用や納期の問題である）。以前に、「システム屋はテストを削る」と書いたが、「ドキュメントの修正」も削られることは多い。

プログラムが出来たら設計書は捨ててしまえばよいと思われるかもしれない。ロケット打ち上げ時のエンジンのように、開発が軌道に乗ったら切り離してしまうわけである。それなら修正する必要もない。

しかし、設計書はシステムの開発に使われるだけではなく、ユーザーの受け入れテストや、その後の保守や改訂にも利用される。「納品物」になっていれば、捨ててしまうわけにもいかない。

そんなわけで、システム開発工程の最後に「ドキュメント整理」などというフェーズを作って、後から設計書を直すようなこともある。

★

仕様をドキュメントに書けば、ソースコードとの「二重メンテ」は避けられない。ドキュメントの量に比例して、メンテナンスの工数は増え、書かれていることが「嘘」になる危険性も増大する。余計なドキュメントは書かないに越したことはない。「ドキュメントの修正工数を削る」くらいなら、「ドキュメント自体を作らない」ほうが安全である。

もちろん、ドキュメントが全く不要というわけではない。顧客との意思統一のために必要なものや、他システムとのインターフェース仕様など、削れないものはある。しかし、「誰が読むの？」というようなドキュメントを大量に書かせるプロジェクトも少なくないのには困ったものだ。

「ドキュメントはとにかく多いほうがよい」と信じている人、「いつも書いているお決まりの設計書を書いておけばいいだろう」程度に考えている人は、自分の思考停止に気づくべきである。何が必要で何が必要でないか。そして、どのように書くのが良いのか、きちんと考えることが大切だ。

このブログの順位は？・・・