パターン、Wiki、XPは良書

「パターン、Wiki、XP」を読んだ。「ThoughtWorksアンソロジー」のようにエッセー風だが、本質的なことがたくさん書かれているような気がした。
感想をラフなメモ書き。

【元ネタ】
パターン、Wiki、XP - 第1部：建築 - Li:d tech

パターン、Wiki、XP - 第2部：ソフトウェア開発 - Li:d tech

パターン、Wiki、XP - 第3部：Wiki - Li:d tech

Smile Experience: パターンランゲージの会

404 Blog Not Found:時を超える創造の原則 - 書評 - パターン、Wiki、XP

書評リンク集 - 『パターン、Wiki、XP』サポートWiki

『パターン、Wiki、XP - 時を超えた創造の原則』感想、少しばかりの余談 - antipop

『パターン、Wiki、XP』と「協働＝お互い様」のマーケティング | JOURNAL | FERMAT

Wikiの起源と進化(論文PDF)

なぜそんなにもWikiは重要なのか(論文PDF)

【1】「パターン、Wiki、XP」を読んで、デザインパターンやXPの思想に触れたような気がした。
分かったと言うのはおこがましいが、本質に手を触れた感触。

XPがすごいと思いながらも、なかなか実践できなくて腑に落ちないと感じた理由は、それらのプラクティスや原則、価値を有機的に理解できていなかったからだと思う。
XPのプラクティスは最初は12個あって、それぞれのプラクティスの意味は理解できるが、何故そんなにたくさんあるのか、という疑問がいつもあった。
著者によれば、XPのプラクティスは、下記のアレクザンダーの6つの原理から生成されたものだと言われる。

(引用開始)
・有機的秩序の原理 (The principle of organic order)：計画や施工は，全体を個別的な行為から叙々に生み出してゆくようなプロセスによって導かれること．
・参加の原理 (The principle of participation)：建設内容や建設方法に関するすべての決定は利用者の手に委ねること．
・漸進的成長の原理 (The principle of piecemeal growth)：各予算年度に企画される建設は，小規模なプロジェクトに特に重点を置くこと．
・パターンの原理 (The principle of patterns)：すべての設計と建設は，正式に採択されたパターンと呼ばれる計画原理の集合によって指導されること．
・診断の原理 (The principle of diagnosis)：コミュニティ全体の健康状態は，コミュニティの変遷のどの時点でも，どのスペースが生かされ，どのスペースが生かされていないか，を詳しく説明する定期的な診断に基づいて保護されること．
・調整の原理 (The principle of coordination)：最後に，全体における有機的秩序の緩やかな生成は，利用者の推進する個々のプロジェクトの流れに制御を施す財政的処置によって確実なものとされること．
(引用終了)

「パターン、Wiki、XP」の説明で分かりやすかったのは、「参加の原理」がオンサイト顧客、「漸進的成長の原理」が小規模リリース、「診断の原理」が常時統合(CI)やテストファースト(TDD)を生み出したという箇所。
「パターン、Wiki、XP」には書かれていないけれど、XPのメタファは「パターンの原理」から生成されたのだろうと思う。

つまり、XPはパターンランゲージの思想を開発プロセスへ適用して生まれた斬新なプロセスなのだ。
だから、表面的なインパクトのあるプラクティスの名前にこだわるのではなく、その背後にあるパターンランゲージの思想を理解しなければ、本当に理解できた事にならないのだろう。

また、アジャイル開発における「ユーザに価値あるソフトウェアを届ける」というユーザ重視の姿勢は、パターンランゲージにある利用者重視の思想から来ていると考えることもできる。
その考え方がリーンソフトウェア開発や継続的デリバリーの概念まで発展していく。
アジャイルマニフェストの内容もまさにその思想そのものだ。

(引用開始)
・プロセスやツールより人と人同士の相互作用を重視する。
・包括的なドキュメントより動作するソフトウェアを重視する。
・契約上の交渉よりも顧客との協調を重視する。
・計画に従うことよりも変化に対応することを重視する。
(引用終了)

最近のアジャイルUXなどの考え方も、この思想の延長にあると思えば理解しやすくなる。
何故なら、利用者に使いやすいユーザインターフェースとは何か、という考え方はまさにユーザ重視の姿勢と同じだから。

【2】同様にパターンランゲージがプログラミング言語に影響した例は、GoFのデザインパターンだろう。
僕は、パターンと言う考え方がとても好きだ。
その理由は下記で書いた。

Twitter / @akipii: 「パターン、Wiki、XP ~時を超えた創造の原則」を読んで僕はパターンという考え方がとても好きだ。開発現場で良いと思われるノウハウを他人に説明できる概念に変換してくれる。パターン化することで暗黙的に理解していた内容を自分でも認知できる。パターンはボトムアップ指向なのも良い

開発現場のノウハウをパターンでまとめることで、他人に説明しやすくなるだけでなく、事象から本質的な概念を見出すことで暗黙的に理解していた内容を自分自身も理解できるようになるからだ。
パターンは事例に基づくので、どの文脈(コンテキスト）でそのパターンが有効なのか、そして他の状況では何故あまり有効でないのか、を明確に指摘してくれる。
パターンを作り上げる過程で自分の経験や考えていることを整理してくれるから、パターンはとても有用な考え方だと思う。
そして、パターンを作り上げるには、たくさんの事例を収集したり、経験しておくととても作りやすいだろうと思う。
但し、パターンが全ての事象を説明してくれるわけではない。
それぞれの事象をどのように分類するのかという観点を見出さない限り、パターン集はある特定の状況でしか適用できないノウハウに過ぎないから、MECEにパターンを作り上げるのはとても難しいと思う。

個人的にいつも思うのは、日本のIT業界では昔から品質管理やDOA、プロジェクト管理などで数多くの経験値があるにも関わらず、そのノウハウは散らばっていて、他人が使えるような概念にまとめていなかった。
むしろ、それらノウハウをIT企業独自の知的所有権として公開しなかったという背景もあるだろう。
だから、そんな昔の日本人の知見が今の日本人に生かされず、むしろアメリカ経由でアジャイルの発想に触れて熱狂しているという経緯もあるのだろうと思う。

忘れ去られた日本のIT技術～プロジェクト管理: プログラマの思索

忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索

【3】パターンランゲージを源流として発展した概念に、オブジェクト指向のデザインパターンやXPだけでなく、Wikiもあると「パターン、Wiki、XP」は説明している。
僕が興味を惹いたのは、TracはWikiエンジンとして生まれたという説明の箇所。
チケット駆動開発の発端となったTracは、Wikiを中核としたソフトウェア開発の支援ツールと見なすことができるわけだ。
そして、当初はTracのクローンとしてRedmineが生まれて、Redmine上でチケット駆動開発をアジャイル開発に適用できると気付いた経験が「Redmineによるタスクマネジメント実践技法」へつながっていく。
そう思うと、チケット駆動開発もパターンランゲージの思想を受け継いだ子孫と言えるかもしれない。

【4】今後考えてみたいのは、チケット駆動開発のプラクティスをパターンランゲージの文脈で置き換えたら、どのようにまとめられて、どのような関係性が見えてくるのか、という問題。
ラフに下記に書いた。

Twitter / @akipii: 「パターン、Wiki、XP 時を超えた創造の原則」によれば、XPのプラクティスはアレグザンダーの6つの原理に深く関係していて、各プラクティスはお互いを補完する構造を持つ。XPのプラクティスは有用だが個数が多すぎて把握しづらいけど、背後に原理があるという指摘でようやく納得できた。

Twitter / @akipii: チケット駆動開発のプラクティス「No Ticket, No Commit」「Ticket First」「Version is Iteration」「No Ticket, No Work」などもアレグザンダーの原理やパターンランゲージで理論化したい。それらは有機的で独自の存在を持つ

Twitter / @akipii: XPのオンサイト顧客はアレグザンダーの原理「参加の原理」から。小規模リリースは「漸進的成長の原理」から。常時統合やTestFirstは「診断の原理」から発生していると「パターン、Wiki、XP」では言う。ではチケット駆動開発のプラクティスはどの原理から導き出されたのか？

【追記1】
著者が何故「パターン、Wiki、XP」を書いたのか、という理由が下記に書かれている。
この本はまさに歴史書、哲学書と言えるのかもしれない。

『パターン、Wiki、XP』という本を書きました - えとダイアリー

下記で「はじめに」「あとがき」は読むことができる。

パターン、Wiki、XP ―― 時を超えた創造の原則（WEB+DB PRESS plusシリーズ）｜gihyo.jp … 技術評論社

【追記2】
システム提案や要件定義でよく出る絵として「オレゴン大学の絵」がある。
「オレゴン大学の絵」は、利用者・設計者・開発者それぞれの立場で作るべき対象は何なのかを理解しようとするものの、それぞれの理解が異なるとどれだけずれてくるのか、を表現した教訓にようなもの。
顧客が本来作りたいものは何なのか、を考える時に役立つ比喩のような資料と言っていい。
その発端はアレグザンダーにあったのが驚き。

オレゴン大学の絵 Dora_PaPa_san's_Pages/ウェブリブログ

［姿勢編］理由無き要求は機能化してはいけない - プロジェクト・マネージャの「やってはいけない」：ITpro

【追記3】印象に残った文章 - 『パターン、Wiki、XP』サポートWiki
から「印象に残った文章」を引用しておく。

(引用開始)
(p.45) パターンランゲージによる建築は、表面的な言葉だけをとらえると、パターンを組み合わせて建築するのだと思いがちです。ある意味、レゴブロックを組み合わせて建築を作り上げるように、それぞれのパターンに適する実体があって、それを単につなぎ合わせるようなイメージを生じさせます。しかし、それはアレグザンダーが言おうとしたことの正反対です。あらかじめ部品を用意してつなぎ合わせるだけといった考え方は、彼が最も反対した考え方なのです。

(p.194) デザインパターンは書籍に取り上げられた23個のパターンがすべてで、それを使いこなすことがパターンを使いこなすことだという考え方は、まったく間違っています。そうではなく、プログラマがプログラミングする際に、自分のプログラムにどのようなパターンが見いだされるかを自分自身で考え続けながらプログラミングすることが、本当の意味でパターンを使いこなす道なのです。つまり、デザインパターンは、読者が自分自身のパターンを見いだすための土台として使うのが正しい使い道なのではないでしょうか。

(p.195) XPではさまざまなプラクティスが提唱されていますが、それを「決まりごと」として受け取ってしまうと、開発プロセスはまったく改善されないでしょう。そうではなく、XPのプラクティスを入り口として、自分たちの開発プロセスを改善する方法を自分たち自身で考え続け、そこから得た経験をまたプラクティスとして抽出するようにする。そのようなプロセスを続けることによって初めて、XPのプラクティスが有効に働くようになると思います。

(p.195) Wikiは、非常に自由度が高いコラボレーションツールです。その自由度の高さのもとで、どのように使えばいいのかを自分たち自身で考えながら使うようにします。利用のルールを自分たち自身で考え続けて実践することで、初めてWikiをWikiらしく使いこなせるようになるのではないでしょうか。

(p.46) 建築計画では、往々にしてそれまであった古い建物を取り壊して更地にし、その上に新しい建物を建てるというスクラップ＆ビルドの考え方がとられます。しかし、古い建物を活かし、新しい建物と有機的な関係を保ち続ける方法を模索し、そのための手段をさまざまに講じることが、パターンランゲージの目指す方法論です。

(p.42) これは非常に難しい問いです。自然都市は自然にできたのだから自然都市なのであって、それを「意図的」に繰り返せば人工都市になってしまうのではないでしょうか。

(p.105) しかし、ソフトウェア開発における利用者と開発者は、まだ固定した関係には至っていないとベックは続けます。誕生して間もないコンピュータの世界であれば、利用者と開発者という社会的な関係を含めて新しく定義しなおせるかもしれません。ベックは、「ソフトウェアでは、新たな社会構造を作る機会がある」(p.156)と語っています。つまりXPの本当の目的は「新たな社会構造を作る」ことにあるのです。
(引用終了)

【追記4】
「パターン、Wiki、XP」書籍中の全URLを下記で一覧化してくれている。

Idea, Design, Engineering, Architecture, etc: [読書]パターン、Wiki、XPのリンク

下記の資料も参考になる。
翻訳 - オブジェクト指向プログラムのためのパターン言語の使用

【追記5】
平鍋さんもパターンランゲージとXPの関係について過去に書かれている。
とても分かりやすい。

パターン･ムーブメントからアジャイル・ムーブメントへ：An Agile Way：ITmedia オルタナティブ・ブログ

XPとパターン Ralph Johnson'sの見解

【追記6】
@daipresentsさんも本の感想を書かれています。

『パターン、Wiki、XP ? 時を超えた創造の原則』から感じた時を超えたソフトウェア開発の道 | daipresentsの世界

【追記7】

江渡さん（と角谷さんと懸田さん）のトークセッションのログが下記に書かれています。

パターン、Wiki、XP――時を超えた創造生成の原則(2009-07-10)