2003年9月に発売された「アジャイルソフトウェア開発エコシステム」を読みました。
はじめに
今からおよそ20年前に発刊された書籍です。
"本書は、以下の3つの基本的な質問に回答する。
（１）アジャイルが最も得意とするのはどのような問題か。
（２）アジャイルとは何か。
（３）ASDE（アジャイルソフトウェア開発エコシステム）とは何か。"
ということで、アジャイル（開発）とASDEについて書かれた本です。
本の構成
本の構成は、下記のような章立てになっています。
＜構成＞
■パート１ 問題と解決策
第１章 変化主導経済
第２章 IDXシステムズ社
第３章 アジャイル
■パート２ 原則と人
第４章 Kent Beck（※補記：ケント・ベック）
第５章 有用なものの納品
第６章 Alistair Cockburn（※補記：アリスター・コーバーン）
第７章 人を信頼
第８章 Ken Schwaber（※補記：ケン・シュウェイバー）
第９章
第１０章 Martin Fowler（※補記：マーチン・ファウラー）
第１１章 技術的な素晴らしさ
第１２章 Ward Cunningham（※補記：ウォード・カニンガム）
第１３章 最もシンプルなことを行う
第１４章 Jim Highsmith（※補記：ジム・ハイスミス）
第１５章 適応性
第１６章 Bob Charette（※補記：ボブ・シャレット）
■パート３ アジャイルソフトウェア開発エコシステム
第１７章 スクラム
第１８章 DSDM（※補記：Dynamic Systems Development Method）
第１９章 クリスタル方法論
第２０章 FDD（※補記：Feature Driven Development）
第２１章 LD（※補記：Lean Development）
第２２章 XP（※補記：Extreme Programming）
第２３章 ASD（※補記：Adaptive Software Development）
■パート４ ASDEの開発
第２４章 エコシステムの明確化
第２５章 独自のアジャイル方法論の設計
第２６章 アジャイルのメタモルフォーシス
昨今スクラムやXPばかりが取り上げられている気がしてなりませんが、パート３では、それらも含めた主なASDEについて簡単な経緯も含めて解説してくれているのが個人的にありがたかったです。
印象に残った点
印象に残ったフレーズ、以下にメモしておく。
アジャイルとは何か
"他の複雑な概念と同様に、アジャイルには多くの定義がある。しかし、筆者は以下の定義が最も明確だと思う。
アジャイルとは、激動するビジネス環境で利益を得るために、変化をもたらし、かつ変化に対応する能力のことである。"
ASDEとは何か
"アジャイルソフトウェア開発方法論についての本書を書き始めたが、「方法論」という語に常に不安を抱いていた。なぜなら、「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。さらに、「方法論」という語を使用すると、アジャイルのプラクティスは従来のソフトウェア開発方法論と比較され、そのため誤った比較の目安が使用される。したがって、ASDE（アジャイルソフトウェア開発エコシステム）という用語を使い、3つの絡み合う構成要素を含む全体的な環境を表現している。この3つの構成要素とは、カオーディック（chaordic：カオスと秩序）な観点、協調的な価値と原則、最小限な方法論である。ASDEの提唱者を表すアジャイリストという用語も、この全体的な環境に含まれる。
「アジャイル」が少ないプロセス、儀式、簡略な文書を意味すると考える人もいる。しかし、「アジャイル」にはもっと広い観点があり、そのため「方法論」という語ではなくエコシステムという用語を使用している。"
カオーディックな観点
"日々のプロジェクト作業で、カオーディックな観点は以下の2つの成果をもたらす。この成果は、厳密な方法論とは正反対である。
●製品目標は達成可能であるが、予測可能ではない。
●プロセスは一貫性を助長するが、再現可能ではない。
"
主なASDEとその開発者
スクラム（Scrum）
スクラムはラグビーのスクラムから命名された。最初はKen SchwaberとJeff Sutherlandが開発し、その後Mile Beedleと共同開発した。スクラムはプロジェクト管理フレームワークを提供する。このフレームワークはスプリントという30日間周期の開発に焦点を当てる。各スプリント内では特定のバックログ群というフィーチャ群を納品する。スクラムのコアプラクティスは、調整と統合のために、毎日15分間のチームミーティングを行うことである。スクラムは約10年間、幅広い製品の納品を成功させるために使用されてきた。Schwaber、Sutherland、Beedleはアジャイル開発宣言の作成に参加した。
DSDM（Dynamic Systems Development Method）
1990年代中頃にイギリスで開発された。これはRAD（Rapid Application Development ）のプラクティスの派生物かつ拡張である。少なくともヨーロッパでは、各ASDEの中で最も支持されるトレーニングおよび文書化を誇る。DSDMは、活発なユーザ参加、頻繁な納品、チームでの決定、プロジェクトのライフサイクルを通じての結合テスト、開発における可逆変化などの9原則を含む。BennekumはDSDMコンソーシアム役員会のメンバで、アジャイル開発宣言の作成に参加した。
クリスタル方法論（Crystal Methodologies）
Alistair Cockburnは人中心の「クリスタル」ファミリーの作成者である。Cockburnは「方法論考古学者」で、世界中の多くのプロジェクトチームにインタビューし、機能することと、人が機能するということとを分離することに努めた。Cockburnとクリスタルは、協調、帰属意識、協力といった開発における人の側面に注目した。Cockburnはプロジェクトの規模、重要度、目的を使用し、適切に設定したプラクティスをクリスタルファミリーの各方法論（クリア、イエロー、オレンジ、レッド）のために作成する。Cockburnもアジャイル開発宣言の作成に参加した。
FDD（Feature Driven Development）
Jeff De LucaとPeter CoadはFDDを共同開発した。FDDは最小限の5ステップのプロセスで構成される。このプロセスは、総合的な「形状」オブジェクトモデルを開発し、フィーチャ一覧、およびフィーチャによる計画、イテレーティブなフィーチャによる設計、フィーチャによる構築の各ステップを順々に行う。FDDのプロセスは簡潔で（各プロセスは1ページで記述される）、FDDにおける2つの重要なロールはチーフアーキテクトとチーフプログラマである。FDDがXPと異なる点は、「軽い」事前のアーキテクチャモデリングである。オーストラリア人のDe Lucaは50人以上の（アジャイル開発としては）大規模なプロジェクトの事例を2つ提供した。John KernはCoadの会社であるTogetherSoft社のプロジェクト開発責任者で、アジャイル開発宣言の作成に参加した。
LD（Lean Development）
最も戦略的思考のASDEは知名度が一番低い。Bob CharetteのLDはリーン生産方式に由来する。リーン生産方式とは1980年代に日本の自動車製造業界で再構築された方式である。変化に対する従来の方法論的観点は、制限的な管理プラクティスで制御すべき損失のリスクであった。しかし、CharetteはLDでこれを拡張し、変化を、「リスク起業家精神」を使用して実行する「機会」の生産とした。LDはヨーロッパの大規模電気通信プロジェクトで多く使用され、成功した。
XP（Extreme Programming）
Kent Beck、Ward Cunningham、Ron Jeffriesが開発した。XPはコミュニケーション、シンプル、フィードバック、勇気の価値を説く。XPの重要な側面は、変化に対するコストの見方を変えるのに貢献したこと、およびリファクタリングとテストファースト開発によって技術的長所を強調したことである。XPは全体的な単位としての完全性が証明された動的プラクティスの体系を提供する。XPはアジャイル開発の中で最も関心を集めている。Beck、Cunningham、Jeffries、Fowlerは、アジャイル開発宣言の作成に参加した。
ASD（Adaptive Software Development）
アジャイル運動に対する筆者（Jim Highsmith）の貢献である。ASDはアジャイル方法論の哲学的な背景を提供し、ソフトウェア開発組織が、変化を避けるのではなく利用することで、返上のビジネス環境の激動に対応する方法を示す。ASDはイテレーティブな開発、フィーチャベースの計画、ユーザフォーカスグループレビューといったプラクティスと、リーダーシップ協調管理と呼ばれる「アジャイルな」管理哲学を含む。Highsmithもアジャイル開発宣言の作成に参加した。
その他、気になった点のメモ
ASDEとRSMの違い
ASDEとRSMの違いは、拡張的な文書化や、文書化がないのではなく、理解を伝達するための文書化と協調の混合である。アジャイルの実践者は、相互作用に傾倒する。厳密な方法論は、文書化に傾倒する。
BrownとDuguid2000
BrownとDuguidは、Xerox社のコピー機修理エンジニアの間での知識共有の研究について述べる。形式手な文書があるにも関わらず、難しい問題は、エンジニアが呼び出される前の朝食時の会話で解決されることが多いとわかった。
プロセスへの過剰な期待
すべてのツール、技術、好みのプロセスを配置せよ。しかし、最終的には成功と失敗の最大の違いは人である。プロセスのアイデアを作り出すためにどんなに一生懸命作業しても、期待できる最良のことは、プロジェクトにおける二次的な効果であるとわかった。したがって、一次的な人の要因を最大化することが重要である。
プロセスは、人が共同作業するのを支援する。共通のフレームワーク、共通の言語、問題を理解するのに役立つチェックポイントを提供することができる。しかし、コンピタンスや協調の問題を補うことはできない。
Bollesの指摘
手法がXPやCMMに関わらず、プロセスはスキルの代用物ではないということである。プロセスが重量でも軽量でも、アジャイルでも厳密でも、プロセスに従うだけでは優れたコード（または優れたテストケースなど）を作成できない。スキルが優れたコードを作成する。
プラクティス（または技法）
プラクティス（または技法）は方法論の活力源である。ペアプログラミング、スクラムのミーティング、ユーザフォーカスグループ、自動テストのいずれであっても、ASDEのプラクティスは才能とスキルがある個人によって実行され、成果を生む。
計画について
計画とはテストされる仮説であり、実現される予測ではない。
それぞれの中心主義者
プロセス中心主義者は人を後回しにする。プラクティス中心主義者は人を最優先する。プロセス中心主義者は（記述された）形式知を重視する。プラクティス中心主義者は（内部の）暗黙知を重視する。
ソフトサイエンス
人間工学、コミュニケーション、協調は「ソフトサイエンス」として知られているが、習得するのは難しい。
→soft science：科学そのものではなく、科学の利用の仕方を扱う科学を指すらしい
「方法論」という語はアジャイル開発の焦点（人、関係、不確定性）に適さない
「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。…（中略）…方法論（methodology）という用語は、アクティビティ、プロセス、ツールといった物事のビジョンを連想させる。
