１ 天才プログラマーの絶対的な法則
先日、杉浦和史先生から参考になるから、と教えられたブログを読んでみました。「ソフトウェアの仕様書は料理のレシピに似ている」です。お書きになっているのは、天才プログラマーと呼ばれる中島聡さんです。
驚きました。プログラムの仕様書のことはよくわかりませんが、しかし、基本的な点で、文書作成と同じなのだと思いました。例えば、地位が高くなると文書を作らなくなる人がいます。本来、作り続けなくちゃいけないのですが、その点、以下のようになります。
「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。
やはりそうか！…と思います。テキスト作成などの教育用コンテンツを作る場合、人の作ったものをチェックするだけでは、やはりダメなのです。自分が作っていないと、人の作ったものに対する感性まで鈍ってきます。センスが悪くなるのです。
中島聡さんは、大学時代にCADソフト「CANDY」を開発して、３億円ものロイヤリティーを得たそうです。その後、マイクロソフトに移り、Windows 95、98やInternet Explorer 3.0/4.0のチーフアーキテクトを務めたとのこと。飛びぬけた人のようです。
２ プログラムの作りかたと文書の作りかた
プログラムを作る過程について語っている部分にも驚きました。文書作成の過程と全く同じなのです。文書の全体像が見えてきたら、実際に書いてみることで思考を固定化させていきます。そうしないと、検証ができないのです。
＜実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進める＞…とお書きです。したがって、作成手順は、以下のようになります。
プログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。
書くことによって、自分の思考が現実に見えてきます。わかっていたはずのことが実際に反復継続して見える状態になると、そこにイメージとしてもっていたものとのズレが見えてくるようになります。
清水幾太郎も、論文を書くときの苦しみについて書いています。設計図を作る過程で、材料不足に気づいて勉強しなおす結果になったり、そのために自分の考えがふらつくこともあると言っています［全体最適と部分最適］。
３ なぜ書き直すのか
書き出していくと、弱いところが見えてきます。その部分を次々に直していくことになります。しかし、これをすると構造があまりきれいでなくなります。そういうとき、どうしたらよいのでしょうか。
そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。
わたしがテキストを全部捨てて、もう一度作り直すと言うと、何で書き直すのですか、そこまでしなくても…とおっしゃってくださる方がいます。なぜなのかは、上記そのままです。
いったんラフスケッチができていると、好きなだけ書き足せますが、しかし、構造の弱さや不十分さが見えてきます。柱の立て方が違ってきますから、直さないといけません。構造を修正すればきれいになりますから、作り直したほうがよいのです。
天才の仕事の仕方が、垣間見えます。そして安心します。文書作成をする人にとって、参考になると思います。叩き台をつくり、それを元に次々修正を加え、ある程度納得できるところまできたら、もう一度書き直す…というのが文書作成の標準的な作成過程です。
