ソフトウェアを作ること・本を書くこと

[結] 2006年6月 - 結城浩の日記から。

本全体のテーマを決め、各章の内容を考える。まあここまではよい。その次の有効な一手は、「さらに詳細な内容を考える」ことではなく、「本文をいきなり書いてみる」ことではないかと思っています。本文の一部分を、完成原稿のつもりで書いてみる。ラフなスケッチではなく、この部分だけ出版してもかまわないというレベルまできちんと書いてみる。書いてみようとする。

もちろん、ちゃんとは書けないわけですけれど、書いてみようとする。そうすると、いろんな発見があります。実は、その発見がないと、本全体の方向性は決まらない。もっとも具体的で、もっとも詳細な「本文の執筆」で何かを確かめなければ、全体の構成を定めることができない(ある程度までは可能だけれど、限界がある)。

ものすごい端的に表すと、「迷わず書けよ、書けば分かるさ!」か。本を書くときの大まかな構成は考えておくべきだけど、それ以降のことは実際に書いてみないと細かいことは分からないと。そして、これはソフトウェアを作るときにも通じることだと。

なるほどなるほど。大体理解できます。私も卒業のために論文を書かなければなりませんでしたが、そのときにも似たようなアプローチを取っていた気がします。章立てぐらいはやるけど、それ以降はかなり具体的なレベルまで書いてみてそれをさらにブラッシュアップさせると。

その意味では、概ね賛成です。体験したことがある人にとって、ソフトウェア製作も執筆作業も具体的なものを作って初めて先に進めるということに異論を挟む人はあまりいないでしょう。

設計が全部終わってからコーディングに入るのではない。全部の構成が決まってから本文の執筆に入るのではない。

実際にコーディングしなければわからないことがたくさんある。それと同じように実際に本文を執筆しなければわからないことがたくさんある。コーディングしてみて得られた知見をフィードバックしなければ、ちゃんと設計できないのではないか。本文を執筆してみて得られた知見をフィードバックしなければ、構成は定まらないのではないか。

思うに、ソフトウェアも、本も、想像以上に複雑で大きなものであり、人間が誤りなく全体の設計を前もって行うというのは不可能なのではないか。設計が不要だとか、コードがすべてだという気持ちはさらさらないけれど、「コードを書かずに行う設計には何かしら本質的な限界がある」とは言えそうだ。

ただ、ソフトウェアと本がまったく同じアプローチが使えるかというと、それはまた違う意見を持っています。両者の大きな違いは、ソフトウェア製作が多人数で取り掛かるものだということに対し、本の執筆は基本的に一人、もしくは少人数で行うということです。

ソフトウェアを作るときには、他者とコミュニケーションを取るドキュメントなり何なりを反映させる必要があります。そのため、あまりむやみやたらに作っては消して…なアプローチを取ることはできないのではないでしょうか。そのような手法を取る際にも、ある程度の規約は作っておかないとすぐにプロジェクトは破綻するでしょう。

ただ、本の執筆のように一人、ないしは数人でやる作業に関してはインクリメンタルなアプローチがより適していると言えそうです。修正内容の影響も少ないので、どんどん書いては消して…という手法が有効的と考えます。


一人でプログラムを作っているときは楽でしたね。他の人に仕様を説明する必要もないし、面倒なドキュメントなどを作る必要もあまりなかったから。

ただ、自分は企業に雇われて大規模プロジェクトに携わる方の道を選んだのだから、そういうわけにもいきません。この道でしかできないこと、やりがいなどを突き詰めて、極めていきたいと思います。