パターン、Wiki、XPは良書
「パターン、Wiki、XP」を読んだ。「ThoughtWorksアンソロジー
」のようにエッセー風だが、本質的なことがたくさん書かれているような気がした。
感想をラフなメモ書き。
【元ネタ】
パターン、Wiki、XP - 第1部:建築 - Li:d tech
パターン、Wiki、XP - 第2部:ソフトウェア開発 - Li:d tech
パターン、Wiki、XP - 第3部:Wiki - Li:d tech
404 Blog Not Found:時を超える創造の原則 - 書評 - パターン、Wiki、XP
書評リンク集 - 『パターン、Wiki、XP』サポートWiki
『パターン、Wiki、XP - 時を超えた創造の原則』感想、少しばかりの余談 - antipop
『パターン、Wiki、XP』と「協働=お互い様」のマーケティング | JOURNAL | FERMAT
【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のデザインパターンだろう。
僕は、パターンと言う考え方がとても好きだ。
その理由は下記で書いた。
開発現場のノウハウをパターンでまとめることで、他人に説明しやすくなるだけでなく、事象から本質的な概念を見出すことで暗黙的に理解していた内容を自分自身も理解できるようになるからだ。
パターンは事例に基づくので、どの文脈(コンテキスト)でそのパターンが有効なのか、そして他の状況では何故あまり有効でないのか、を明確に指摘してくれる。
パターンを作り上げる過程で自分の経験や考えていることを整理してくれるから、パターンはとても有用な考え方だと思う。
そして、パターンを作り上げるには、たくさんの事例を収集したり、経験しておくととても作りやすいだろうと思う。
但し、パターンが全ての事象を説明してくれるわけではない。
それぞれの事象をどのように分類するのかという観点を見出さない限り、パターン集はある特定の状況でしか適用できないノウハウに過ぎないから、MECEにパターンを作り上げるのはとても難しいと思う。
個人的にいつも思うのは、日本のIT業界では昔から品質管理やDOA、プロジェクト管理などで数多くの経験値があるにも関わらず、そのノウハウは散らばっていて、他人が使えるような概念にまとめていなかった。
むしろ、それらノウハウをIT企業独自の知的所有権として公開しなかったという背景もあるだろう。
だから、そんな昔の日本人の知見が今の日本人に生かされず、むしろアメリカ経由でアジャイルの発想に触れて熱狂しているという経緯もあるのだろうと思う。
忘れ去られた日本のIT技術~プロジェクト管理: プログラマの思索
忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索
【3】パターンランゲージを源流として発展した概念に、オブジェクト指向のデザインパターンやXPだけでなく、Wikiもあると「パターン、Wiki、XP」は説明している。
僕が興味を惹いたのは、TracはWikiエンジンとして生まれたという説明の箇所。
チケット駆動開発の発端となったTracは、Wikiを中核としたソフトウェア開発の支援ツールと見なすことができるわけだ。
そして、当初はTracのクローンとしてRedmineが生まれて、Redmine上でチケット駆動開発をアジャイル開発に適用できると気付いた経験が「Redmineによるタスクマネジメント実践技法」へつながっていく。
そう思うと、チケット駆動開発もパターンランゲージの思想を受け継いだ子孫と言えるかもしれない。
【4】今後考えてみたいのは、チケット駆動開発のプラクティスをパターンランゲージの文脈で置き換えたら、どのようにまとめられて、どのような関係性が見えてくるのか、という問題。
ラフに下記に書いた。
【追記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 オルタナティブ・ブログ
【追記6】
@daipresentsさんも本の感想を書かれています。
『パターン、Wiki、XP ? 時を超えた創造の原則』から感じた時を超えたソフトウェア開発の道 | daipresentsの世界
【追記7】
江渡さん(と角谷さんと懸田さん)のトークセッションのログが下記に書かれています。
| 固定リンク
「IT本」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「コミュニティ」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント