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

 第1部に登場した建築家アレグザンダーによるパターンランゲージ。次は、ソフトウェアの世界に取り込まれていく。第2部では、ソフトウェアの世界にどのように取り込まれていったのか歴史を追っていく。
 大きく分けて2つの流れが存在する。ウォード・カニンガムケント・ベックによるプログラミングのパターンランゲージへの取り組みと、平行して起こったプログラミングに繰り返し現れる構造を再利用しようというデザインパターンの流れ。そして、同時代の関係者をつなげる学会やシンポジウムといったコミュニティの存在と徐々に統合、ブラッシュアップされていくソフトウェアの世界におけるパターンランゲージ。現実のソフトウェア開発現場においてパターンランゲージを適用し有用性を示すことになったChrysler社におけるC3プロジェクトの存在。
 第2部はこのような流れになっている。

 最終的にXPという一つの思想にまとめあげられていく過程をつぶさにみていくことで面白いと思ったのが、建築の世界で形作られたうまく成果を残すことができなかった思想がソフトウェアの世界と取り込まれ広がっていくその流れ。そして、人と人がつながることで思想自体を統合したり、ブラッシュアップしたりする役目を果たすことになるコミュニティの発生。

 こっちの世界でうまくいかなくってもあっちの世界でうまくいって支持されている、というの一つの事例は自分にとっても今後ヒントになりそう。あとは、Li:d techも人と人が集まってやっているわけだけど、何かを生み出す流れになったらなあとぼんやりと思ったりして。

 以下はほぼ抜き書きメモです(完全な抜き書きではなく手も加えてます)。

  • 7章 オブジェクト開発
    • OOPSLAの設立
      • ACM(Association for Computing Machinery):オブジェクト指向に関するOOPSLA(Object-Oriented Programming, Systems, Languages, and Applications)1986年にオレゴンで第一回 p.60
      • ベックとカニンガムは「A Diagram for Object-Oriented Programs」(オブジェクト指向プログラムのためのダイアグラム)を発表
        • 1. タスクごとのウィンドウ(Window Per Task)
        • 2. ウィンドウ内にペインはできるだけ少なく(Few Panes Per Window)
        • 3. 標準的なペイン(Standard Panes)
        • 4. 短いメニュー(Short Menus)
        • 5. 名詞と動詞(Nouns and Verbs)
      • 簡素ですが、非常にエレガントなデザインが実現 p.64
      • 2人は結果を「オブジェクト指向プログラムのためのパターン言語の使用」という論文にまとめました。 p.64
    • 2人は、プログラミングに関するパターンの収集も開始していました p.65
      • 論文執筆の時点で10個ほど。20-30個のラフなアイディア。最終的には100-150個程度のパターンを収集できると予想していました p.65
      • ソフトウェアの設計に繰り返し現れる構造をどのようにとらえ、他の人と共有できるかについて考え、論文としてまとめました。 p.66

それと平行し、別のところでもソフトウェアに繰り返し現れる構造に目を向けている人がいた。

    • ジム・コプリエン(Jim Coplien)
      • C++言語特有の繰り返し現れる表現(イディオム)を収集し、辞典のように体系立ててまとめ、カタログ化しました。 p.66
      • 1991年に「C++ プログラミングの筋と定石」
      • 「パターン」という言葉を使っていなかったにせよ、ソフトウェアにおいて繰り返し現れる構造に目を向け、カタログ化しようと考える人が同時代的に発生していました。 p.66
    • コミュニティの発生
      • OOPSLAは、このような同じ考えを持った人が出会う場として重要な役割を果たすことになります p.66
    • デザインパターン誕生までの歴史
      • 「Toward an Architecture Handbook」 OOPSLA/ECOOP 1990
      • 「Architecture Handbook Workshop」 OOPSLA 1991
      • 「Documenting Frameworks using Patterns」 OOPSLA 1992
      • GoFの結成 OOPSLA1992
      • Hillside Groupの誕生
      • 「Patterns: Building Blocks for Object-Oriented Architectures」 OOPSLA 1993
      • PLoPの開催 パターンランゲージコミュニティの形成
      • デザインパターンという狭い範囲から始まったパターンの応用も、徐々に範囲を広げ、「町」「施工」といった違う粒度に相当するパターンも扱われるようになりました。 p.77
  • 10章 プロセスへのパターンの適用
    • PLoP 1994 で、コプリエンは「開発工程の生成的パターン言語」を発表 p.79
      • このパターンランゲージは、ソフトウェア開発を行う組織とその開発プロセスを改善するために望ましい組織のあり方や開発の進め方を提示したものです。この研究は実在する開発組織の実例を観察、考察することで行われ、42個のパターンによるパターンランゲージとしてまとめられています。 p.79
      • これは、組織やプロセスを対象としたパターン、つまり「組織パターン」「プロセスパターン」という新しい考え方を発明したのだと言えます。 p.80
      • コプリエンは組織が備えるべき「無名の質」についても言及しており、無名の質がソフトウェア開発を行う組織とプロセスの改善の糸口になるという考えを述べています p.80
    • PLoP 1995 カニンガムは「エピソーズ:競争力のある開発のパターン言語(EPISODES: A Pattern Language of Competitive Development)」というパターンランゲージを発表
      • エピソーズは開発チームの組織やプロセスを記述したパターンランゲージで、ソフトウェア開発における問題解決のための文書のあり方やグループの構成方法、各役割担当者の心構えなどを提示 p.80
      • カニンガムは、ソフトウェア開発にはドラマの起承転結のような流れと波があると考えました。そのためソフトウェア開発のさまざまな活動サイクルの単位を、メタファとして「エピソード」と呼びました。 p.81
      • コプリエンのパターンランゲージに大きな影響を受けていました。カニンガムは、コプリエンの組織パターンの例がなかったら、この題材(開発チームの組織やプロセス)をパターンの形式で扱えるとは思わなかっただろうと述べています。 p.82
    • C3(Chrysler Comprehensive Compensation project:総合報酬プロジェクト)プロジェクト
      • ソフトウェア開発の組織やプロセスをうまく進めるための知見を、それぞれの経験やさまざまなプロジェクトから収集してパターンランゲージとして形式知化し、コミュニティの中で共有し、練り上げていこうという動きが起こっていました。中心にはOOPSLA,Hillsode Group,PLoPで形成されてきたパターンコミュニティ、ベック、カニンガム、コプリエンがいた p.82
      • Chrysler社の給与計算プログラム、COBOL -> smalltalkに p.82
      • Chryslerにはおよそ6千人の役員と10万人の従業員がおり、部署や役職によって給与支払いの制度と計算ルールが異なるため、複雑化 p.83
      • プロジェクトは1993年に始まり1995年にはSmalltalkによる開発が始まっていたが、非常に難航 p.83
      • ベックは今までコミュニティが培ってきた組織とプロセスのパターンを徹底的に実践 p.83
      • C3プロジェクトで実践されたオリジナルのプラクティスは、ロン・ジェフリーズによって1997〜1998年ごろにまとめられ、Webで公開されました p.84
      • Chrytslerの野心的な新システムは1999年まで開発が続きましたが、約1万人の月給雇用者をカバーするようになったところでプロジェクトは中止 p.87
      • プロジェクトの体制や開発されたソフトウェアの品質については問題なかったが、ビジネス上の要求の変化によって中止の決定がなされたのだとベックは結論付けています p.88
      • C3プロジェクト修了後も、Chryslerのシステムに関わり続けたメンバーたちがいるそうです。彼らはXPを適用することで、非常にバグが少ないプロジェクトを実現しています。 p.88
    • 4つの価値から導きだされる5つの基本「原則」
        • 瞬時のフィードバック
        • シンプルの採用
        • インクリメンタルな変更
        • 変化を取り入れる
        • 質の高い作業
      • 「価値」と「原則」を達成するために、12個の「プラクティス」が提案
    • XP
      • C3プロジェクトによって実践されていたものを継承、発展させたものがXP p.91
      • ペアプログラミング」「共同所有」「オンサイトのユーザ」のように、当時のソフトウェア業界の常識からかけ離れたプラクティスも少なくありませんでした。 p.91
        • プロセスやツールよりも、人と人との交流を
        • 包括的なドキュメントよりも、動作するソフトウェアを
        • 契約上の交渉よりも、顧客との協調を
        • 計画に従うことよりも、変化に適応することを
      • 従来の開発手法を重量級であるとし、軽量ソフトウェア開発手法とし2001年にいくつか存在していた開発手法の重要な部分を統合し、「アジャイルソフトウェア開発宣言(Manifest for Agile Software Development)」、通称「アジャイルマニフェスト」をまとめあげた p.92
      • アジャイル」とは「俊敏な」という意味 p.92
      • 提唱者の17名には、ベック、カニンガム、ジェフリーズ、ファウラーら p.92
    • 第1版と第2版の違い
      • 価値 第5の価値として「尊重」が追加 p.94
      • 原則 5個から14個へと大幅に増やし、より広範囲な概念を採用 p.95
      • ラクティス 12個から25個(基礎プラクティス14個、応用プラクティス11個)基礎プラクティスは導入が簡単で即時的な効果が期待できるもの、応用プラクティスは基礎プラクティスを習得していないと導入が困難なもの p.96
    • 組織パターン、プロセスパターンからXPへ
      • XPのプラクティスは、ベックがC3プロジェクトを手がけるにあたって一人で編み出したものではなく、コプリエンとの取り組みやカニンガムとの議論、PLoPでの活動などを通じて蓄積してきたものが、花開いたのだと言える p.102
    • ベックはアレグザンダーの建築理論に大きな影響 p.103
        • 有機的秩序の原理」->「ストーリー」
        • 「参加の原理」->「実顧客の参加」
        • 「漸進的成長の原理」->「インクリメンタル設計」or「インクリメンタル配置」
        • 「パターンの原理」->「ストーリー」
        • 「診断の原理」->「常時結合」or「テストファーストプログラミング」
        • 「調整の原理」->「根本原因の分析」
      • XPはアレグザンダーが建築の世界で目指したプロジェクトの推進方法を、非常に上手にソフトウェア開発の世界に取り込んだ p.103
    • アレグザンダーの失敗
      • 建築家は社会的な役割が固定化していて、建築家は設計する建築の詳細を最終的に決めるのは自分たちだという態度を放棄せず、利用者はそのような状況で自分たちの要求を適切に伝える術を知りません。そのため、アレグザンダーは最終的には建築家と利用者の間のバランスをとることに失敗したのだと語っています p.105
      • 誕生して間もないコンピュータの世界であれば、利用者と開発者という社会的な関係を含めて新しくて意義しなおせるかもしれません。ベックは、「ソフトウェアでは、新たな社会構造を作る機会がある」(p.156)と語っています。つまりXPの本当の目的は「新たな社会構造を作る」ことにあるのです。 p.106
      • XPは、利用者と開発者が互いの垣根を越えて共同でソフトウェア開発へと向かい、生き生きとした、そして無名の質を備えたソフトウェアを実現しようと言う試みだったのだと言えます。 p.106
    • 建築の世界から始まったパターンランゲージの影響は、一巡りしてソフトウェア業界からアレグザンダーへとフィードバックされました。 p.107