全体は詳細に先行するか？あるいは、「作り出す」ことの中心について。

結城さんの、「ソフトウェアは、私たちの想像よりもずっと複雑」を読んで。
http://www.hyuki.com/d/200606.html#i20060616093839

本を書く、という行為の中で結城さんが至った一つの結論は、執筆活動は章立てや理論的なブレークダウンで進んでいくのではなく、「具体的な本文を書き出す」ことが、必要だ、ということ。以下、引用。

本全体のテーマを決める。つぎに各章の内容を考える。全部の内容が決まったら、さらに詳細な内容を考え、節ごとにブレークダウンする。全体の節が出来たところで、いよいよ本文を書き始める。こんな風に、まっすぐな流れで詳細化が進み、その結果として最後に完成する――というふうには進まないのです。

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

ぼくも、ソフトウェアと本、の両方を書いたことがある身として、とっても同意してしまう。本を書くのもソフトウェアを作るのも、ともに「発見過程」なんだ。まだ世の中に１つもないものを作っている場合、「問題の理解と解決は同時にすすむ」。プロセスを定義し、全体の計画を立て、計画通りにやるという方法では進まない。そこに潜む潜在的なリスクやら、おもしろみ、やらをあらかじめ予測できない。

「Without Practice, No Emergence」でもあり、「Seeing is Understanding」かもしれない。また、工学的には、設計は逆問題の典型であり、悪構造問題(ill-structured problem)だ。すなわち、正しい唯一の解は存在しないし、また、解があるかどうかも定かではない。その場合には、「具体的にやってみる」ことで「発見」し、それを「解決に組み込む」という学習ループが不可欠だといえる。

結城さんのブログは、一流の日本語で、ソフトウェアと本の執筆の共通点を書いている。

P.S.
Paul Graham だったか、なぜアメリカが「映画」と「ソフトウェア」で世界に圧倒的強さを誇るか？という命題を立て、そして、それは作り方がいまだにめちゃめちゃで、プロセスが工業的になっていないからだ、といういうようなことを言っていたと思う。そんな場面では、「ルールを作る」とか「ルールを変える」とか、大仕掛けの発想転換ができる思考素養をそなえた、アメリカが有利なんだそうだ。（あ、出展は「ハッカーと画家」だったと思う。）