結城浩のはてなブログ

ふと思いついたことをパタパタと書いてます。

手が仕事をする時

仕事をしていると、ときおり「頭が仕事をする」のではなく「手が仕事をする」時がある。
たとえば文章を書いているとき、もう構成はできていて、具体的な細部を書き込んでいるとき、私はときどき「じゃあ、後は、手にまかせておこう」と思うことがある。私は傍観者然として（というのは正しくないな、読者然として）、手が書いていく文章を読んでいる。
プログラムを書いているときもまったく同じようなときがある。リファクタリングをやっていて、ほぼ機械的な変形に入ったときなどによく起こる。もちろんそういうときにインテリジェントな統合環境を使っていれば自動化ができるのかもしれないけれど、私は「手が仕事をする」様子を眺めているのが好きなので、あまり自動化したいという気持ちはない。そういう決まりきったプログラム変形をやっていると、なんとなくそのプログラムをいじりまわしている感じがするからかもしれない。
しかし…矛盾したことを書くようだが、あまりにもその繰り返しが頻繁になってくると、自動化したくなるという場合もある。つまり、面白みというのは新しい部分と機械的な部分のはざまにある微妙な領域に存在するらしい。通り抜けができることはわかっているけれど、まだ通り慣れるというほどではない小道。
ところで、仕事とは関係なく、手が語りたがる場合もある。何をどうすればいいか、何を書きたいのか自分でもよくわからないんだけれど、手がむずむずするような感じがして、とりあえずキーボードに向かうこともある。そして「はい、どうぞ。好きなことを何でも書いていいですよ」と手に言う。そして手が語り出すのをじっと待つ。リラックスして、待つ。
そのうちに手がゆっくりと言葉をつむぎはじめる。細い糸の端をどこからか見つけ出し、切らないように注意しつつ手繰っていく。そして編み、集め、広げ、少しずつ大きく…。思いもかけず大きなタペストリが作られることもある。

朝、体重を量る／姿勢

朝、また体重を量るが、あまり減っていない。そろそろサチって(saturateして)しまったのだろうか。まあしばらくは淡々と体重を測定しつづけてみるけれど。ちょっとした待ち時間や、コンパイルの間、マシンがブートする時間などにストレッチをする。家内からはよく「あなたは姿勢が悪い」と指摘されるのでこの機会に姿勢もよくするように心がけることにしよう。家内の言葉は「姿勢が悪いのは筋力が足りないのよ」そして「姿勢が悪いと内臓にも負担がかかるのよ」と続く。こんなことを飽きずに言ってくれるのは世界中で家内しかいない。ありがたい。

フィードバックに対する敏感さ

文章（コンテンツ、作品、創作物、…）が、フィードバックに対してどれだけ敏感かを考える。
たとえばWikiはもっとも敏感なものの1つ。フィードバックがかかると（つまり誰かが修正をすれば）それで文章（マスター）本体が書き換わる。
それに準じるものは、blogやWeb日記、その他の活発に更新しているオンラインのコンテンツ。他の人からメールなどで著者にフィードバックがかかると、著者がマスターを書き直すことになる。
デジタル化されている文章であっても、マスターが著者の手元に存在しない場合、フィードバックがかかるのは遅れる。たとえばフリーソフトに同梱されているREADMEを考えよう。著者が自分のREADMEを書き直しても、すでにソフトを入手したほかのユーザにその反映は伝わらない。ユーザ登録しているユーザに対して「新しいのが出ましたよ」と連絡するか、ユーザがオフシャルサイトに行って新しいのをダウンロードしなければ反映されない。HTMLのようにマスターを毎回見せているわけではなく、コピーを配布しているからこれは当然だ。
いうまでもないが、紙などの別媒体に載せてしまった文章のフィードバックに対する反応は極めて鈍くなる。
このようなフィードバックに対する「敏感さ」と、そのコンテンツに対する「信頼」とはどのような関係にあるのだろうか。しょっちゅうフィードバックがかかって改訂されるものは常に最新だから信頼できる？いや、そうとも限らない。変化しないからこそ信頼できるというものは多い。いままさに開発が進行しているソフトの場合にはドキュメントも合わせて頻繁に更新されているほうが信頼できる。でも、いったんstableになったソフトに対するドキュメントが頻繁に更新されていたら「いつになったらドキュメントを安心してダウンロードしたらよいだろう」という気もちになる。
…という話をぼんやりと考えていたのだが、面白そうな、でもあたりまえのような考えにしか行き着かなかった。何か面白いダイナミクスと、その何かを測定する指標がそこにありそうなのだけれどね。

(2) パターン・ライティング

脳内仮想キャンプ

軽い昼食の後、ラウンジでミルクティを飲んでいると、ボーイさんがはがきを届けてくれる。家内と子供たちからの絵葉書だ。あちらはあちらで楽しくやっているようだ。
ミルクティのおかわりをしようと周りをきょろきょろ見回すと、キャンプのメンバーらしき一人が私のところにやってきた。手にはアイスコーヒーを持っている。20代のにこやかな男性である。ここでは仮にミラノさんと呼ぶことにする。
ミラノ「こんにちは、結城さん。ミラノといいます。ちょっとおしゃべりしてもいいですか。」
結城「ええ、いいですよ。」
ミラノ「私は普段はJavaでプログラムを書いているプログラマなんですが、結城さんのデザパタ本を読んでからパターンに興味を持つようになったんです。」
増補改訂版Java言語で学ぶデザインパターン入門
結城「そうですか。ありがとうございます。」
ミラノ「GoF本や、その他のデザインパターンの本なんかを読んでいて思ったんですけれど、パターンってどうやったら書けるんですか？」
結城「と、いいますと？」
ミラノさんはそこで言葉を探すように目をぱちぱちさせた。ラウンジではあちらこちらにグループができ、理数系の楽しげな会話が繰り広げられている。静かなバロック音楽が流れている。
ミラノ「説明がへたですみません。例えばGoFのAdapterパターンってありますよね。それからPreeのいろんなパターンも。それから『パターンハッチング』でブリジデスさんが1つのパターンを練り上げようとしているドキュメンタリーのような文章がありましたよね。私も、日常的に開発をしていて、自分なりのパターンのようなものがあるんですが、それをどういうふうに書いたら、みんなからパターンとして認めてもらえるかと思いまして。…言っていること、わかりますか？」
結城「ええ、わかりますよ。ええと…、まず私はパターンの本を書いていますけれど、特に学問的に研究しているわけではないので、もしかしたら間違っていることを言っているかもしれません。と、お断りしておいて。ミラノさんは自分の経験がいろいろとおありで、それをパターンとしてまとめたい、ということですよね。」
ミラノ「はい、そうです。それでどうやったら有用なパターンであるというお墨付きをもらえるかと思いまして。」
結城「そういう『お墨付き』を与える機関はないと思いますよ。しいて言うなら、PLoP (Pattern Languages of Programming)のようなパターンに関連したシンポジュームやカンファレンスに論文を出して、多くの人から『これは有用である』と認識してもらうことだと思いますけれど。」
ミラノ「はあ…。」
ミラノさんは、アイスコーヒーをゆっくりと飲む。私はボーイさんを呼んで、ミルクティのおかわりをたのむ。
結城「あまりピンと来ませんか。パターンに関してはいろんなところで人々が活動しています。日本に限って言えば、パターンワーキンググループができていますね。定期的にタスク活動を行っていますし、勉強会もやっていますよ。そういうところであなたのパターンを発表する機会を見つけてはどうでしょうね。」
ミラノ「それは知りませんでした。そういう団体があるのですね。」
結城「それから、パターンワーキンググループとは関係ありませんが、私が主催している[DP/ML]というメーリングリストもあります。あなたが自分のWebサイトでパターンを紹介したときなどには、[DP/ML]に流していただければ、たくさんの人の目には触れると思いますよ。そこから先は、あなたの書かれたパターンを他の人がどう思うか、ということになりますね。」
ミラノ「実は、アイディアはいろいろあるんですが、具体的にパターンを『書く』というのはどうすればよいかわからないんですけれど。」
結城「なるほど。PLoPなどではパターンライティングの講座が開かれることもありますね。それで敷居が高いようなら、ネットのあちこちで見つかるパターンを見よう見まねで書いてみるのがよいと思いますよ。パターンを書くにはいろんなフォーマットがありますので、それにしたがって書くのもよいですし『自分の書きたいことをもっとも適切に相手に伝えるにはどうしたらよいだろう』ということを考えて自分なりのフォーマットを作ろうと努力するのも楽しいと思いますよ。」
ミラノ「結城さんは絵本のパターンとかをお書きになっていましたよね。」
結城「ええ。絵本を読むときのパターン・ランゲージのことですよね。あれは、パターン・ランゲージで有名な建築家Alexanderのフォーマットにならって書いたものです。文脈と問題の提示があって、その問題に対する解法がある。そして関連する解法への参照がある。だいたいそういう形ですね。」
ミラノ「パターンとパターン・ランゲージは違うんですか。」
結城「個々のパターンを「単語」とみなしたとき、パターン・ランゲージは「言語」とみなすことができます。つまり、複数のパターンを組み合わせて、より大きくて有機的な解法の連鎖を生み出すことができるもの。それがパターン・ランゲージですね。「絵本を読むときのパターン・ランゲージ」の場合には、子供に絵本を読み聞かせるときに直面する複合的な問題（こまったこと）にどのように対処したらよいかを、私なりに提示したものです。このパターン・ランゲージを読むと、個々の問題を解決するだけではなく、子供に絵本を読み聞かせるというのは、いったいどんなことなのかがほのかに浮かび上がってくるような文章になるように心がけました。」
ミラノ「ふう…。なかなかたいへんそうですね。結城さんはどこでそういうことを学ばれたのですか？」
結城「恥ずかしながら、みようみまねです。パターンのことを勉強しているときに、石井勝さんからAlexanderのA Pattern Languageという本をすすめていただいたんです。結構古臭くて厚い本だったのですが、ぱらぱら見てみてその「形式」はすぐにわかりました。それでみようみまね、というわけです。」
ミラノ「じゃあ、私がパターンを書くときもそのAlexanderの形式にしたがったほうがよいでしょうか。」
結城「それはよくわかりません。まずは、GoF本を持っていらっしゃるなら、その形式でやってみてもよいかもしれませんね。よい方法は、自分でとにかくまず書いてみる。そしたら公開して他の人に見てもらう。そして率直なフィードバックをもらう。それがよいと思いますよ。あまり形式的なところを重視しすぎないで、他の人に自分の考えていることが伝わるだろうか／伝わっただろうか、というところに注意を向けたほうがよいと思います。」
ミラノ「何となくわかってきました。というか、いろいろと書いてみたくなりました。結城さんがお書きになったパターンは他にありますか？」
結城「これはご存知かもしれませんが、技術系メーリングリストで質問するときのパターン・ランゲージというページも、Alexanderの形式風に書いてあります。」
ミラノ「あ、聞いたことがあります。「過去ログを読むように」とか、「検索エンジンを使いなさい」とかですね。」
結城「ええ、そうです。そこら中の技術系メーリングリストで同じようなことが毎日のように繰り返されますよね。パターンというのは、繰り返し起きる問題に対する解法ですから、まさにこういう分野には適切な表現形式なのですよ。それから、Webサイトではありませんが、私のスレッド本の最終章には、マルチスレッドプログラミングのパターン・ランゲージが出てきます。」
Java言語で学ぶデザインパターン入門 マルチスレッド編
ミラノ「わかりました。今度読んでみることにします。なんだか長話になってしまいましたが、ありがとうございました。」
結城「いいえ、こちらこそ。何か面白いパターンが書けたら、ぜひ[DP/ML]で教えてくださいね。」