プログラミングとドキュメント

今日も一日外出で、時間の隙間がたっぷりできてしまったので、仕事をしながらブログも書いているところで、例によってあまり内容が濃くないのですが・・・

年度末で、多くの仕事が納品となります。今も実は納品に必要なドキュメントをそれらしく作ったりしていたのですが、とにかくドキュメント作成は嫌いです。。

以下、個人的な意見ですので、あまりまじめに受け止めないでいただきたいのですが、、

まず、ドキュメントの種類ですが、ソフト開発関連ですと、

・仕様書（設計書）：基本・詳細、その他画面、DB、プロトコルなど必要に応じて
・テスト仕様書兼成績書：単体・結合・総合

という感じです。

基本設計書は、受託開発ですと、依頼側で作成することがほとんどで、要求仕様という感じです。

詳細設計書は、プログラムの構造などを書くもので、これは開発側が作成します。必要に応じて、画面設計書・DB設計書・プロトコル仕様書なども作成します。

テスト仕様書兼成績書は、開発側は単体・結合を担当し、総合は依頼側で行うケースが多い感じです。単体テストの意義に関しては以前たっぷり書きました。

先ほど納品物として作っていたのは「単体テスト仕様書兼成績書」です。。はっきり言って「納品物としての価値」しかないものです。まあ、受け入れ側も大きな組織ですと、中身は分からない人が受け入れ判断を行うことも多いので、それなりに納品物が揃っているということくらいしか判断できないのだと思うのですが、実に無駄です。

仕様書・設計書は、意味がある内容なら価値があると思っています。ところが、これまた仕事のボリュームに応じたドキュメントの分厚さを求められてしまうと、「肝心なことを分かりやすくまとめる」というよりも、「分厚くするために、流れ作業で書き殴る」という感じになりやすく、そもそも、納品したドキュメントを活用しているプロジェクトはあまり見たことがありません。ドキュメントに書いておいても、結局何かの時にはダイレクトに問い合わせのメールや電話がくることがほとんどです。まあ、今回はちゃんと意味のある仕様書を書かせてもらえましたが。。

私が受託開発を嫌う理由はいくつかあるのですが、かなり大きなウエイトを占めているのが、「納品ドキュメント」の存在です。どうせ活用されないと分かっているのに、時間をつぎ込むのが嫌なのです。

製品はその点、無駄なドキュメントなど必要なく、製品がきちんと動くことと、しっかりしたサポートがあればOKで、最低限のマニュアルがあれば良いというのが、やる気がでます。

書く気になれば、著書を11冊も書いたくらいですから、ドキュメントを書くこと自体が嫌いなわけではないのです。単に、「どうせ使われないドキュメントを書くこと」が嫌いなだけなのです。

ということで、やる気度は、
プログラム：ドキュメント＝１０：０
というくらい、納品用のドキュメントは嫌いなのでした・・・。