日々の破片

_ エクストリームプログラミング

池袋ジュンク堂で、角さんと角谷さん（名前の字面に山がない）によるエクストリームプログラム新訳のトークセッション。

参考文献特集でいろんな本が売っていたが、まずは青木さんの新刊だ。と思ったら置いてないので、長田さんに頼んで持ってきてもらって、まずはゲット（後払いだけど）。

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)(青木 峰郎)

間違って早く着きすぎたので読み始める。

PostgreSQLを一応使うように書かれているが、それはあまり関係ない。

前書きを読むと、読者としてエンジニア（ソフトウェア開発者）とプランナー（データコンシューマ）の両方をターゲットとしていることがわかった。

・エンジニアはプランナーの意図を知るために読む。そしてエンジニアリングで何ができるかわからずに悶々としているプランナーの机の上にこっそり置く

・プランナーはエンジニアに意思を伝えるために読む。そしてデータ分析という観点が欠落しているエンジニアの机の上にこっそり置く

・プロジェクトの前にプランナーとエンジニアが勉強会を開いて一緒に読み、何をなすべきか合意する

と、3番目の読み方で、なんとエクストリームプログラミングのトークセッションの会場で売るにふさわしい本であることがわかった。

「XPは人と人とのつながりを変える」のだから、まさに青木さんのデータベースの本はエクストリームなのだった。

で、それはそれとして縦持ち横持ちとか（そうはいっても横持ちにも良い点はあると書いてから、では縦持ちにしましょうと進める余裕が、昨日の本の著者には無い文章作法で、実に心地よい）、ウィンドウ（これ、SQL Serverに導入されたとき、別の呼び方をしていたなぁと思い出しても思い出せない）とかを読んでいるうちに時間となった。

エクストリームプログラミング(ベック,ケント)

集まった人たちをみて、黒テントを観に行ったらじじばばばかりでびっくりしたのと同じような感慨を全員が共有しているところで、始まる。

そうか、PofEAA読書会の同窓会のようなものなのか。

角さんのお話は、エクストリームプログラミングは読みにくいので（初版の翻訳はとても問題があると考えていたが、いざ自分で訳してみたら、ケントベックの書き方に問題があることが良くわかったとか話していておもしろかった）、ではどう読むべきか、それは表層（テクスト）ではなく作家主義でいくしかない、というわけでケントベックの生い立ちなどの説明から始まった。

作家主義ってそうではないような（と、つい映画における作家主義を考えてしまう）。ゴダールやトリュフォーがジョンフォードやハワードホークスの生い立ちを調べたとわけではない。その作家の作品にはその作家の刻印があり、それはその作家の作品を見ることだ。映画は役者の名前でみるものでも、物語がどうしたとか、ジャンルがどうしたとかでみるものでもない。それは誰が作ったかで観るものだ（突然思い出したが池田ののびーは黒澤明について誰かの書いたものをとりあげて、映画作家という呼び方をふつうはしないと断言することで見識の狭さを妙なところでも発揮していたなぁ）というのが作家主義のような気がするが、テクストとの対比ということは文学用語なのかも。しかし、野坂昭如の韜晦を額面通りにとって引用するのを目にすると、作品を書いた言葉と同じ作家の言葉であるという言葉の本質を軽々と無視できるのがとても不思議になる。作家の言葉はすべて作品なのだから、作品であろうが作品について語ったものであろうがどちらもメタな言質であって額面通りに受け取ってはならない。

とか考えながらも、角さんのプレゼンはむちゃくちゃおもしろくてまったく時間を忘れるほどだ。語り口のうまさと興味をひかせるためのアイキャッチとしてのスライドの融合だな。実におもしろい。

で、終わった後の懇親会に参加するためにうろうろしていれば、いやでも入口に並べられた本に目が行く。

というわけで、参考文献特集から、とりわけ目をひいたものを購入してしまう。

ディズニーアニメーション 生命を吹き込む魔法 ― The Illusion of Life ―(フランク･トーマス)

ケントベックによれば(エクストリームプログラミングの参考文献リストにはケントベックによる一言コメントがついていて、そこも訳出されている。これが実におもしろい)、「ビジネスや技術の変化に対応するために、ディズニーのチーム体制が長年にわたり、どのように進化したかが描かれている。ユーザーインターフェイスデザイナーのヒントになることが満載。素晴らしい絵も収録されている。」

なのだが、そんな言葉を読む前に、目の前にした本の美しさとぱらぱらめくったときの書物としてのパターンに惹かれまくってしまったのだった。というか、タイトルがすでにデザインパターンではないか（魔法の形容ではあるけれど）。

その他、まだ読んでないことに気付いたので、クーンとか購入。

_ エクストリームプログラミングとチームギーク

思い出した。

角さんによれば、2つのタイプの人間がいる。

1つは目的至上主義。重要なのは目的の達成（成果を上げる）。

もう1つは手段至上主義。重要なのは過程を楽しむ。作る喜び至上主義。

で、続けて次のように断じる。

ケントベックは後者で、後者のことを世間知は「ボンクラ」と呼ぶ。

---

たとえば、「はじめに」を開いた途端に次の文章が目に入る。

「良いチームだろうと悪いチームだろうと、改善は必ずできる」

おかしい。

良いチームなら改善の必要ないじゃん。そんな余計なことをしている閑があったら、さっさと成果物を出せ。

とならずに、改善することが目的化していることにケントベックはまったく気づかずに改善に邁進する。

その結果、成否は問題とならなくなってしまう。重要なのは「開発者として最善を尽くすことだ（第1章の冒頭）」。

男だぜ。

というか、なるほどボンクラであるな……

が、そこがエクストリームプログラミングで語られていることの要点なのだった。

1980年代の流行語（世界的）にattitudeがあった。すべてのかっこよさはその個人のアティチュードに起因する。まさにエクストリームプログラミングとはあるべき（とるべき）アティチュードを示すものだ。なるほどケントベックが職業人としての道を歩み始めたのは1980年代だ。

それは真摯である。人間であるならば、かくありたいものだ。

エクストリームプログラミング(ベック,ケント)

したがって、本書の対極にあるのが、チームギークだ。

チームギークにはチームワークをうまく回すためのいろいろな戦術が書かれている。なぜそのように振る舞うのか？ それは成果を上げるためだ。多様性の尊重よりも、エゴの抑制（多様性を尊重するということは、おれさまのアティチュードも認めろということに他ならない）。すべてはチームの成果のために！

そこには人間としての真摯さというポエジーはない。あるのは、冷徹な計算だ。

まさにクール！ スマート！ ～（ボンクラ）である。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか(Brian W. Fitzpatrick)

中庸を良しとするのであれば、両方から学ぶことができる。

そうでなければ、エクストリームプログラミングを勧める。「中庸を良しとする」妥協策が気に入らないとすれば、それは手段を重視しているからだ。