■ 本日の合コン

ぐうわッ、はぶさんも来るのか。ドキドキ。一時期、講演の追っかけみたいになっていたもんな。緊張して話せないかもしれません。あと、念願のtpircsタソに会えるのなｗ。

今日はバッチリ『256本 網道編』（たださんときたさんのサイン入り）を持って来た。arton師父、がっつりサインくださいませ。

■ 他人のものを書き換えるという抵抗。

昨日からJoel on Softwareの記事をちょいちょい見ておりますが、仕様書の項目で、コードよりも仕様書を書き換えるほうがコストが少ない、といった記述が見られました。仕様書におけるその是非はさて置いて、コードと文章、これは、CVSとWikiに通じるものがあるんじゃないでしょうか。

• 他人のコードを書き換える（コードの共同所有）- CVS
• 他人の記述を書き換える（文章の共同所有）- Wiki

まず後者を考えてみましょう。文章の共同所有ってのは、えらく難しい。ちょっとソコを書き換えたばっかりに、全体として文章が破綻することがままあるんですよね。というか、うまい具合に推敲するには、それなりのスキルが必要ですわな。まるっと削除、とかそう簡単に出来るもんじゃない。

一方、コード場合、その可否は「動かすこと」によって判断できるから、他人の書いたコードに対して「こっちのほうがいいよ」と具体例をもって提示できる。これが後者との決定的な差異。

こう見ると、後者のほうが抵抗が少ないように思えてくる。コードが先行しちゃって、ドキュメントがついていかない、なんていう状況はよく耳にするし。コードの書き換え抵抗のほうが低いんじゃないか？ もちろん、ジョエルの文章では、仕様書は「一人で書くもの」とされていたから、共同所有という条件を加えたら話は変わってくるのは重々承知しちょるけどね。

今、500円で買った『首都高バトルR』をやってるんだけど、これになぞらえると（というか一般常識の範囲だが）、スピードには加速度と最大速度の2つの要素がある。止まった状態からどれだけ早くスピードに乗せるか、そして出せる最大スピードはどれくらいか、ってな具合。

止まった状態からスピードにのってる状態に持っていくには、仕様書のほうがベター。走り出したら、コードがベター。こういう感じになるのかな、ということで自分としては手を打っておこう。

課題は「スピードの乗った状態での文章の書き換え」の抵抗をどうやって低くするか。そこには様々な仕掛けが必要なんだな。このへんをWikiばな2で何を話せたらな、とは思うんだけど。どうだろう。

やさしい機能仕様 - パート 2: 仕様書とはどんなものか?

http://japanese.joelonsoftware.com/PainlessSpecs/2.html

あなたの仕様書は陳腐化していて製品を反映していないかもしれないが、私の仕様書はいつもアップデートされている。

■ 今期のアサマシエイト結果

なんか、PofEAAよりもUML児玉本のほうが売れてるんですけど!! しかもものすごく売れてるんですけど!! 安いからか？ Amazonでの順位も810位のようです。すげ。ぼくは最後の章を残して止まってます。ちゃんと読まないとだな。

おっと、気になる金額は、だいたい毎月サーバ代くらいでしょうか。まかなってもらっています。

■ Joel on Software - 下っ端でも何かを成し遂げる方法

目頭がアツくなってきた。こういうのを世界は求めていたんだ。今後、「下っ端でも出来ること」シリーズとして気付いたことをメモしよう。世界は盆栽なのだ。すぐには思うようにはいかないが、気長に愛でていけば、近いところには来る。