The Writer's Process
読書記録。
大きめの変更を始めるにあたり design doc 的なものを書きたいが時間がとれず、考えがまとまらず、もしかして design doc を書くのって文章を書く人々から学ぶことがあるのでは・・・みたいな謎の気の迷いから聴いた。それなりに興味深い本ではあった。プロセスの話で、どうやって時間をとるか、どういうフェーズがあるか、というようなトピックを議論していく。
時間がないのは、ソーシャルメディアとかしてるんじゃないよ、自分にあった時間帯を見つけて書くんだよ、みたいなことをいうんだけどいやそうじゃなくて他の仕事があるせいで時間がないのだよ・・・。しかし根本的に時間は必要なので確保するしかないという現実に目を向けることができたのはよかった。
その後仕事（バグ取りなど）の忙しさは一段落したので、時間をとって書くことができた。もともとそんなに長い文章ではなく、3-5 ページくらいの短いもの。こんなものすら書けないとは・・・。
フェーズは、Research, Incubate, Structure the idea, Writing the first draft, Let the draft reset, Revise... とつづく。
自分のように大きめのリファクタリングをするだけ、みたいなケースは「調査」が必要という事実を忘れがちだが、人を説得するのに design doc を書くんだからちゃんと調べて（この場合、既存のコードを丁寧に読んで）やることを正当化したり事前に整理した方がいいね、という当たり前のことを remind できた。
アイデアを整理するにあたり、freewriting すなわちなんでも頭にあることを書き出してみるアプローチを推していて、自分はこれを以前から braindump と読んでいるけれど、そういうのも自覚的にやってみたら割とよかった。 3 ページの mini doc なんてズバっとかけそうなものだけれど、それでも一段階 freewriting / brandump を挟むとだいぶ認知の負荷が下がって良い。それにしても blog 書くのにやってんだから design doc でもやれっつう話ではある。
The Writer's Process が想定しているのはたとえば「本を書く」ように文章そのものが最終成果物なプロジェクトである。一方で自分はソフトウェア開発すなわちコードを書くという具体的かつ専門的なゴールがあり design doc はその一部に過ぎない。なので良いドキュメントを書くことに重点を置きすぎるのは的外れだし、場合によっては BDUF につながる恐れもある。特に自分はコード中心探索的アプローチ原理主義者なので事前にドキュメントを書くことに強い reservation がある。
一方で design doc を書くと決めたならそれを機能させる必要があるが、内容に何を含めるかはともかく「作文のプロセス」にはあまり共通見解みたいのはない気がする。ちょっと探した感じではこれというのが見当たらなかった。まあソフトウェア開発にとって作文は本題でないから仕方ない気もするけれど、それにしても人々はどうやって書いてるんだろうね、ドキュメント。
自分は design doc をガっと書くような気合が失われているので、コードを読んで調査をまとめたり疑問やその答えを記録して、やりたいことを箇条書きして眺め、というのを二周くらいして、それからドラフトを書く、という簡易版 writer's process がよく機能した。
それにしても立ち入った考え事をする能力が弱っているなあ。こうやって crutch を探しながら進まざるをえない人生のきびしさ。