「書く」のは特別な道具

This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。

コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。

今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが全体を通して言いたいことです。

〈書き言葉〉は自分の心の中に降りていくための道具

また吉本隆明から引用する。

〈書き言葉〉は自分の心の中に降りていくための道具

ふだんはまったく意識してないと思うけれど、書くことと、話して相手にそれを通じさせようとすることはまったく別のことなんですよ。〈書き言葉〉っていうのは、何か得体の知れないところがある。書いてみると、自分でも気がついていなかった自分自身の気持ちがわかることがあるし、それをもっと深く掘り下げていくこともできる。〈話し言葉〉が相手に何かを伝えるための道具だとしたら、〈書き言葉〉は自分の心の中に降りていくための道具だといってもいい。

『ひとり 15歳の寺子屋』より。

もうこれだけで自分の言いたいことを言い切った感じもあるけれども、この手のことを言っているのは何も御大だけではなくいろんな作家のエッセイ、あるいは知的編集がどうこうという本でも似たような記述を良く見る。

よく自分が何をしなければいけないかを整理するのに、とにかく自分のやるべきことを文章にして書き出せみたいな話があるけれどもその手の How To の有効性も、ここに通じるのだと思う。

なぜ書くということがそういう性質を持っているのか、というのはいろいろな要因があると思うけれども、ひとつには、書く行為には今自分で考えたことを文章という形で外部化し、それを足がかりに次の思考のステップへ進むということを強制する側面がありそれが大きいと思っている。つまり、書く行為は思考過程の不確実性みたいなものを最小限に留めながら物事を考えるフレームワークになっている。

コードを書いている最中に解決策が思い浮かぶ

プログラミングをしていると、コードを書くまでは全く思いつかなかったようなアイデアや解決策が次々と思い浮かぶ、なんてことが本当に頻繁にある。これはプログラマなら誰もがそういう体験をしたことがあるはずだ。

コードを書きながら考えるということが創造的なソフトウェアを作るということとどういう関係があるかなんてのはあの『ハッカーと画家』にも書かれていて、それに感化されて自分も昔 http://d.hatena.ne.jp/naoya/20050518/1116425594 なんてエントリを書いた。(そして若気の至りで dis を加えたためにちょっと炎上した)

この、コードを書きながら初めて解決策が思い浮かぶ･･･みたいなことと、先の文章を書くことで新しい発見があるということは良くにている ─ と思っている。プログラミングにおいてはコードという形で思考を外部化し、文章の場合は自然言語というかたちで外部化する。プログラミングにしても自然言語にしても「言語」には本来的にそういう機能がある、ということなのかもしれない。

メモ魔

冒頭の話に戻ると、そんなことから自分も、少し時間のかかりそうな作業だとか手間のかかる問題解決をするときはエディタを立ち上げて、そこに自分の思考過程みたいなのをメモしながら進めていく。それが、自分の場合は割り込まれたときに作業を再開したいためというよりは、自分自身の思考の整理のためにそれをしているという側面が強い。

例えばちょうど最近また Docker を触っていたのだけど、そのときのメモの一部はこんな感じになっていた。

% docker export cbe3fe76c418 > files.tar
% cat files.tar | docker import - naoya:test
　
・そもそも commit ではファイルシステムだけが commit されるんだっけ?
　- プロセスの実行状態も含めて commit できたと思ったんだが･･･
　
・さすがにそれは思い込みっぽいか
　- http://d.hatena.ne.jp/naoya/20130620/1371729625
　- Dockerfile で CMD ["/usr/sbin/sshd", "-D"] とかしてるし
　
・Q. Docker の中のコンテナって最低限のサービスも動いてないんだけどこれで
　- 長時間運用できるのけ?
　
・とりあえずファイルシステムを export して import すれば virtualbox <=> AWS の交換は可能なのは分かった
　- OS 違ってていいのか、は謎

...

後から読み返すとバカみたいなのだけれども、思考の「過程」なので、これでよいのである。

ちなみに自分は会議の際も、自分がファシリテーター役になるようなときはモニタにエディタを映し出して発言を書いて整理しながらミーティングを進める。こうしておけば、後々議事録を書き起こす手間も必要ないし、なにより会議の話題が発散しなくていい。言ってみれば、普段自分がデスクトップ上でやっていることを、会議という場で実践しているだけでもある。

Google の DesignDoc

最近あまり話題にならなくなったけれども、Google には、エンジニアが何かの設計や実装に取り掛かるにあたって書くべき DesignDoc と呼ばれるドキュメントフォーマットがある (あった?) そうだ。詳しくは Google の Design Doc について - フリーフォーム フリークアウト のエントリなどに書かれている。

ソフトウェアの変更の背景だとか設計や変更の概要、セキュリティ的な懸念点などをペライチのドキュメントにまとめましょうみたいな話なのだけれども、面白いのはこの文書は他人と共有するのももちろんその目的の一つだけれども、より大きな目的として、作業するエンジニアの思考整理のための道具として活用されている (いた?) ということだ。

書いてみて初めてわかることがある。いきなりコードを書くんじゃなくて、それを事前に文章として書いて整理することで、自分でも気づいていなかった懸念点、課題、解決策を整理してから作業に取り掛かりましょう･･･ そのためのドキュメントである、ということらしい。

DesignDoc の仕組みは必ずしも万能薬ではないというか、うまく回ってない箇所もあったという話を聞いたことがあるのだけれども、少なくとも過去に自分が会った Googler の人は DesignDoc は非常に重要だと語っていて、エンジニアがドキュメントを書かされてしんどいみたいな話ではなく、自分の仕事を助けるためのツールとして DesignDoc という仕組みはとても良いと思うと評価していた。ただ、その良さがどういう良さなのかはなかなか外の世界には伝わらないみたいで、WebKit プロジェクトで Googler が DesignDoc を書くことをさも当然のようにしていたら他陣営からツッコミが入ったとかそんな話もあったらしいが。

過去に自分の仕事でも DesignDoc を真似てプロジェクト開始時に必ず似たようなドキュメントを書くようにしてみたが、その仕組みはとてもうまく回っていた。プロジェクト内容を本人が整理するためにも良かったし、プロジェクトのレビューを依頼される側としてもやりやすかったし、他チームに各プロジェクトの概要を伝えるのにも良かった。良いアイデアとは複数の問題を一度に解決するアイデアだ、なんていう話を思いすところである。

テストを「書く」という行為

自分の思考を先にアウトプットする、という観点でいくとテスト駆動開発なんかもこの文脈で考察できるところがあると思う。

テストを先に書いた方がインタフェースが綺麗になるとか、モジューラビリティが高まるとか、いろいろ。最近、ソフトウェアの自動テストといえば BDD スタイル (RSpec みたいなの) が主流だけれども、先に自分がエディタにメモしている･･･みたいな行為が、そもそも spec ファイルに書くことがそれに相当しているなんていうプログラマも結構いそうだ。

自分はそこまでテストエンジニア力がないので、いきなりテストでやりたいことを表現するというレベルにはなかなか到達できそうにない。

何にしてもテストを書くというのもまた、思考を整理するためのフレームワークになっているところがあると思われる。

チームでの共有

作業記録、DesignDoc、テスト、なんでもそうなのだがそうやって思考の整理のために書いた文書を、そのまま自分の引き出しにしまっておくだけというのはちょっと勿体ない。

You、せっかく書いたのだから共有しちゃいなよ、というわけだ。

先日 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー の中でも触れたのだが、自分はそういう文書をなるべくチームや組織で共有するということが、組織を運営していく上で長期的にとても重要なことだと思っている。そのための道具として、自分がはてなにいたときははてなグループがあったし、最近は(まあいろいろ不足してるところもあるのだが今後の期待も込めて) Qiita Team を使っている。クックパッド社には元技術部長が作ったグルーパッドというのがある、というのは今月の Web+DB PRESS に書かれている。

後からの検索性、ナレッジシェア、透明性の確保などいろいろな効果があるけれども、それを当たり前にやれている組織とそうでない組織というのを幾つか見てきて、やっぱり、当たり前にやれているチームほどチーム内の暗黙知は少なくそれでいてストロングカルチャーを持っているような、健康状態の良いチームを維持できているように感じた。

そんなわけで、自分が理想とするチームでは、みんなが自分の思考の整理のためにドキュメントや振る舞いベースのテストを書いていて、それが共有されていて、共有されているといっても単に Wiki に置かれているとかではなくフィードのような形で自分の手元に配信されてくる、そういうことが当たり前に行われていて欲しいと思っている。これ、やってみるとわかるのだが、当たり前の状態にするまでには結構苦労が要るのでチームが小さなうちから実践しておくということが非常に重要だ、とも思っている。

以上、すこしとりとめのない話になってきたが、何にしても、「忘れないために書く」ではなく「考えるために書く」ということ。そして書いたからにはできれば共有する。そういうことを続けて習慣化していくと良いだろう･･･と常々思っていて、ここまで長々と書いているとおり、それはちょっとやればいいんじゃないかな程度のものではなく、自分はそういうことに強くこだわりを持っている派であります。なかなか口頭でこれを伝えるのは難しいので、これから先に一緒に仕事をする人が運良くこれを読んでくれることも期待しつつ、ここに書き残しておく。

そしてこのエントリを書く、ということを通じて、自分の中でもこんな風に考えていたのだなと整理されたというオチがついてくるのである。