最近のお題は「プログラム設計書」らしい。

私はプログラムに書くコメントが嫌いだ。それどころか

コメントを書いたら負け

とさえ思っている。同じ理由で、「プログラム設計書」とか「詳細仕様書」と呼ばれるコードレベルの設計書も嫌いだ。嫌いなだけじゃなくて不要だと思っている。

なんせそういったコードレベルの設計書に書くべきことは細かい。細かいということは、「実装を縛る」ものだから、その分精度が必要となる。ところが、精度を追及すると、

• 書くのが大変
• 検証が大変
• 版管理が大変

ということになって、いたずらに工数が増える。そして、タチの悪いことに、

すぐ嘘になり、その嘘を検証するのが困難

ということになってしまう。

何しろ人間ってのは間違える。間違えなくても、想像力に限界がある。そのため、コードレベルの設計書はどんどん改訂しなきゃいけないことになるのだが、その改訂に付随する手間もさることながら、そうやっている時の間違いの検証が難しい。何しろ設計書に嘘を書いても、コンパイルエラーすら出ない。「デバッグ」するにもコード化してからでないと出来ない。

もちろんそのためにレビューをやるし、レビューをやれば精度は上がる。XPよろしく「ペアデザイン」をやるという手もある。でも、動かないものを、限りある人間の想像力で作業する限り、「思い込み」とか「勘違い」によるエラーを防ぐのは限界がある。「ペアデザイン」やっていても、二人で間違えていたら世話はない。

「ペアプログラミング」の時はすぐ間違いに気がつくことが出来るから、勘違いや思い込みによるエラーは消しやすい。「ペア」でなくても、かなり気がつく。ところが、そういった機械的客観的検証手段を持たない「詳細設計」は、いつまでも間違いに気がつかないこともある。

そういった意味で、私はコードレベルの設計書は、

書くだけムダ

とさえ思っている。

逆に、もっと上流の要件定義レベルだとか、概念設計レベルといった設計は、これは十分時間かけて良いものを作るべきだと思っている。これは顧客でも理解可能だから(そうでなかったらその時点で負け)、レビューもやろうと思えばちゃんと出来るし、この辺がおかしかったらこの先どれだけ精度上げても無意味だ。また、これはシステムの土台や骨組に当たるものであるから、ちゃんと作ってあればそうそう変更も必要がないはずだし、変更されても困る。本当はこのレベルまで反復設計法が使えると嬉しいと思うのだが、少なくとも日本の企業はそういったことには向いた組織になっていないし、担当者レベルでそこまでの見識を期待するのは難しい。「理念」に属することはやはりトップに意思決定して欲しいし、それでこそエンタープライズシステムだ。

だから、どうせすぐ紙くずになってしまうような、コードレベルの設計書なんてやめてしまって、コードレベルやデータベースの詳細設計レベルあたりまでは、

プログラマの仕事

と切り分けてしまって、アジャイルでも何でもやってしまえばいいと思う。その分、上流工程をしっかりやっておけばいい。「なんちゃら設計書」は、せいぜい「画面のファンクション」とか「データベースの概要」あたりまででやめておいて、それより下は「プログラマ頑張れ」にするべきなんじゃないかな。だいたい、不条理で妙に細かいコードレベル設計書を出されても、

プログラムは会議室じゃない。現場で作ってるんだ！

とプログラマは言いたいはずだ。また、そうやって「詳細設計よりもちょっと上」あたりにプログラマを活躍させるのは(そして担当者同士で会話することは)、モチベーション管理、キャリア設計、スキルアップといった点でも意味がある。また、「紙くず」の生産に時間や手間はコストをかけないでも済む。

確かにいろんな理由から、コードを縛りたいという要求はあると思う。また、プログラマを顧客に会わせたくないという場合もあったりもする。だけど、土台となる部分がちゃんとしていれば、コードは多少クソであっても最悪局所的な書き直しで済む。いや、そうなるような設計をしておくのが上流の仕事だ。またそうなれば、個々のコードをガチガチに縛る必要はない。

縛らない代わりに、何かの設計ミスやプログラマの問題が局所化されるように、きっちり上流を作っておけばいい。それが上流の「腕」だろう。だから、

コードレベルの設計書は、必要になったら負け

だと思うのだが、どう？

PS.

←に「プログラマ」と書いてるから誤解されるかも知れないけど、仕事ではコンサルからハードウェアまでやります。第8レイヤから第0レイヤまでカバーします。「システム開発」の世界だと、バリバリ上流工程な人です。連載の次回は「オープンソースと上流工程」とか書いてみるかな。