(Wikipedia アジャイルソフトウェア開発より)

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

近年、アジャイルソフトウェア開発手法が数多く考案されている。
ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。
アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。
非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。

概要

アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。
1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。

アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する（⇒反復型開発）。
この反復のサイクルを継続して行い、1つずつ機能を追加開発してゆくのである。
おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。
各反復では、それまでに開発した成果物に1つの小さな機能を追加する。
計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。

アジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェア (ビルド) をリリースすることを目指す。
各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。

アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。
ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。
この場合の関係者には、少なくともプログラマと「顧客」が含まれる (ここでの顧客とは開発対象のソフトウェアが何であるかを定義する人々である。「顧客」は、時にはプロジェクト管理者であったり、ビジネスアナリストや本物の顧客である場合もある) 。
この作業場所では、テスト担当者、ユーザインタフェース設計者、テクニカルライタ、管理職も一緒に作業する場合がある。

またアジャイル開発手法では、実際に動くソフトウェアこそが最重要なプロジェクト進行尺度であることを、強調する。
この実際に動くソフトウェアという進行尺度の採用と、直接顔を合わせた意思疎通の重視とがあいまって、アジャイル開発手法で作成する文書の量は、他の開発手法と比較すると、非常に少ない。
この少ない文書化については、無統制で雑な作業 (ハッキング、カウボーイコーディング) であるとして、アジャイル開発に対する批判材料の一つとなっている (後述する) 。

アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。
2001年に、アジャイルソフトウェア開発手法 (当時は軽量ソフトウェア開発手法と呼ばれていた) の分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した。
そして、彼らは「」(') という文書にまとめた。
アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている (参考: ) 。
この宣言には、著者として次の17人が名前を連ねている。

• Kent Beck (ケント・ベック)
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham (ウォード・カニンガム)
• Martin Fowler (マーティン・ファウラー)
• James Grenning
• Jim Highsmith
• Andrew Hunt (アンドリュー・ハント)
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber (ケン・シュウェイバー)
• Jeff Sutherland
• Dave Thomas (デイブ・トーマス)

他の開発手法との比較

アジャイルソフトウェア開発手法は、ソフトウェア開発手法を分類する視点である「適応的開発」手法から「計画重視」手法までの連続線上において、典型的な適応的開発手法に位置づけられる。
従来の開発手法との差異は、適応的開発手法から計画重視手法までの連続線上に、各開発手法を位置づけることによって、適切に説明できる。
他の開発手法のプロジェクトと同様に、アジャイル開発手法のプロジェクトでは、計画を立て、統制を行う。
アジャイル開発手法は、場合によっては、「計画駆動」手法や「統制された」手法の反対側に位置づけられると言及されることがあるが、これは誤りである。

適応的 (adaptive) な開発手法では、現実世界で生じた変更にすばやく適応することに主眼をおく。
プロジェクトで変更が必要となった場合、適応的手法のプロジェクトチームは即座に変更に対応する。
適応的手法のチームにとっては、将来起こりうる変更について、正確に文書化することは難しい。
長期的予測になるほど、予測の不確実性は大きくなる。
適応的手法のチームは、次の週に行うべき作業については、正確に文書化することができる。
しかし、次の月に行うべき作業については、正確に文書化することはできない。
適応的手法のチームは、6か月後のリリースについて質問を受けた場合、チームにできることは、6か月後のリリースに向けた課題を文書化することや費用対効果の予測を文書化することぐらいであろう。

計画重視 (predictive) の開発手法では、適応的手法とは対照的に、詳細な開発計画を立てることに主眼をおく。
計画重視手法のチームは、開発プロセスの全期間にわたって、注意点と作業を正確に計画することができる。
計画重視手法のチームにとっては、プロジェクト中に生じた変更に対応することは、苦手である。
チームによって立てられた計画は、計画立案時点の開発対象に最適化されていることが多い。
そのため、プロジェクト中に変更が生じると、すでに完了した作業のいくつかは無駄になり、別途やり直すことになる。
計画重視手法のチームは、重要な変更のみを管理するために、変更管理委員会を設けることが多い。

反復型開発との比較

アジャイルソフトウェア開発手法の多くは、反復型開発手法と同様に、短い期間単位でリリース可能なソフトウェアをビルドすることを強調する。
反復型開発手法はリリースの期間単位が月単位であることが多いのに対し、アジャイル開発手法では週単位であることが多い。
アジャイル開発手法では、高度に洗練された共同作業のもとで作業を行うことを強調する。
アジャイル開発手法の多くではまた、反復型開発手法よりも、厳密な期間単位のもとで作業を行う。

ウォーターフォールモデルとの比較

アジャイルソフトウェア開発は、ウォーターフォールモデルによる開発との共通点は少ない。
一部の人々は、ウォーターフォール開発はもはや信頼を失っていると考えるが、2005年前後の時点でも、ウォーターフォール開発手法は未だ広く行われている () 。
ウォーターフォール開発手法は、数あるソフトウェア開発手法の中でも、最も計画重視であると位置づけられる。
要件定義、分析、設計、実装、テストの各工程を、厳格に、予め計画された順序に従って行う。
プロジェクトの進捗は、一般的には、次のような納品可能な成果物をもとに計測される。

• 要求仕様
• 設計文書
• テスト計画
• コードレビュー
• など

ウォーターフォールモデルは、一連の工程の大規模な統合であり、数か月から数年の長い期間単位を採用し、その期間単位の終了に向けてテストが行われる。
この統合とテストの規模が大きくまた困難であることは、ウォーターフォールモデル開発のプロジェクトが失敗する際に、その原因の一つとなっていることが多い。
アジャイルソフトウェア開発手法では、対照的に、1週間から数週間もしくは数か月という短い期間単位ごとに、完全に開発されたテスト済みの機能をリリースする (ここでの機能とはシステム全体のごく小さなサブセットである) 。
アジャイル開発手法では、雑ではあるが利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調する。

一部のアジャイル開発チームでは、小規模なウォーターフォールモデルを採用する。
この場合、反復ごとに完全なウォーターフォールのサイクルを繰り返す。
また一部のアジャイル開発チーム (特にエクストリーム・プログラミングで開発するチーム) では、ウォーターフォールモデルの各工程を、同時並行して行う。

カウボーイコーディングはアジャイル開発とは異なる

カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。アジャイルソフトウェア開発には、計画の頻繁な再評価、直接顔を合わせた意思疎通の重視、比較的少ない文書化などの特徴がある。こうしたアジャイル開発の特徴のため、一部の人々はアジャイル開発とカウボーイコーディングを混同してしまうことがある。しかしこうした混同は正確ではない。アジャイル開発チームは明確なプロセスに従って作業する。そしてこのプロセスは、非常に統制され厳格である場合が少なくない。この点でアジャイル開発とカウボーイコーディングは異なっている。

アジャイルソフトウェア開発手法をいつ使うか

アジャイルソフトウェア開発は、10人以下の小規模なチームが1か所で作業を行うプロジェクトの場合に有効であると、説明されることが多い。
またアジャイルソフトウェア開発は、特に、予測困難な要件や頻繁に変更される要件に直面するチームにとって、有効な手法であると指摘される。
以上に述べた状況以外においても、アジャイル開発を採用して成功したチームの体験報告がいくつか存在する。
しかし2005年4月の時点では、企業においてアジャイル開発を採用した報告は少ない。

アジャイルソフトウェア開発の次に列記する状況における適用可能性については、議論の対象となっている。

• 20人以上の大規模なチームでの開発 (開発規模に対する戦略については を参照)
• 開発者が地理的に分散した状況での開発
• ミッションクリティカルなシステムや人命に関わるシステムの開発
• 「指示と管理」を社風とする企業

ベームとターナによるリスクベースの指針

バリー・ベームとリチャード・ターナは、適応的 (アジャイル) な開発手法と計画重視の開発手法のどちらを選択すべきかという問題に対する指針として、リスク分析手法を提案した。
ベームとターナは、適応的開発にも計画重視開発にもそれぞれ得意分野があると、述べている。

アジャイル開発の得意とする状況

• クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム)
• 熟練した開発者が参加する場合
• 開発中に頻繁に要件が変わる場合
• 開発者が少ない場合
• 混沌とした状況に意欲をもって取り組む組織的文化

計画重視開発の得意とする状況

• クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステム)
• 経験の少ない開発者が多い場合
• 開発中に要件がほとんど変わらない場合
• 開発者が多い場合
• 秩序を重視する組織的文化

ベームとターナの主張では、このようなそれぞれの得意分野の指針に照らして、これから取り組むプロジェクトを分析することで、アジャイル開発か計画重視開発かを選択する検討材料とすることができるとする。

歴史

近年のアジャイルソフトウェア開発の定義は、1990年代半ばに、「重量ソフトウェア開発手法」への反対運動の一部から発展して形成されてきた。
重量開発手法の特徴は、ウォーターフォール開発モデルを適用した場合に多くみられる、厳格な規律と統制、管理不足などである。
ウォーターフォールモデルのこのような適用に端を発する重量開発手法は、官僚的で、もたもたしていて (slow) 、衰退的 (demeaning) で、そのためソフトウェア技術者が効果的に作業を進めるという観点と矛盾していた。

アジャイルで反復的な開発手法の実践例は、ソフトウェア開発の歴史の初期に見出すことができる () 。

今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。
先述したとおり、2001年に軽量開発手法において名声のある人々がスノーバードに会し、「アジャイルソフトウェア開発手法」と呼称を変えた。
その後、スノーバードに会した人々の一部は、非営利組織 Agile Alliance を設立し、アジャイル開発を推進する活動を行っている。

2000年以前に開発された比較的歴史の長いアジャイル開発手法には次のようなものがある。

• スクラム (1986)
• Crystal Clear
• エクストリーム・プログラミング (XP) (1996)
• Adaptive Software Development
• ユーザ機能駆動開発 (FDD; Feature Driven Development)
• Dynamic Systems Development Method (DSDM) (1995)

エクストリーム・プログラミング (XP) は、最初のアジャイル開発手法ではなかったようだが、数あるアジャイル開発手法の中で抜きん出た評判を確立した。
エクストリーム・プログラミングは、ケント・ベックが1996年に開発し、米クライスラー社で苦境にあった Chrysler Comprehensive Compensation (C3) プロジェクトを立て直す際に、実践した。
そのプロジェクトは最終的には中止となったが、ケント・ベックの開発手法は、Ron Jeffries による長期の指導と、ウォード・カニンガムの Portland Pattern Repository wiki での公開議論と、ケント・ベックのさらなる改訂を経て、1999年に書籍として出版された。
エクストリーム・プログラミングの構成要素は、別のアジャイル開発手法 Scrum と、ウォード・カニンガムの Episodes pattern language を、基にしているようである。

Dynamic Systems Development Method (DSDM) はヨーロッパで最初に確立されたアジャイル開発手法であると考えられている。

アジャイルソフトウェア開発手法の実例

広く知られたアジャイルソフトウェア開発手法の一部を示す。

• エクストリーム・プログラミング (XP) http://www.objectclub.jp/community/XP-jp/
• スクラム http://www.controlchaos.com/
• Agile Modeling http://www.agilemodeling.com
• Adaptive Software Development (ASD) http://www.adaptivesd.com/
• Crystal Clear および他の Crystal 開発手法 http://alistair.cockburn.us/crystal/wiki
• Dynamic Systems Development Method (DSDM) http://na.dsdm.org/
• ユーザー機能駆動開発 (FDD; Feature Driven Development) http://www.featuredrivendevelopment.com/
• Lean software development http://www.poppendieck.com/
• Agile Unified Process (AUP) http://www.ambysoft.com/unifiedprocess/agileUP.html

その他の手法

• Agile Documentation http://www.agilemodeling.com/essays/agileDocumentation.htm
• Agile ICONIX
• Microsoft Solutions Framework (MSF)
• Agile Data Method http://www.agiledata.org/
• Database refactoring http://www.agiledata.org/essays/databaseRefactoring.html

ソフトウェア開発との直接な関係はないが、類似した手法

• リーン生産方式 (Lean manufacturing)

批判

アジャイルソフトウェア開発は、カウボーイコーディング (先述) であるとして、批判されることがある。
エクストリーム・プログラミング (XP) の初期の風評、およびそのペアプログラミングや継続的設計 (進化的設計) のような賛否両論のある実践原則は、特に批判の対象となった。
一方でこうした批判の多くは、アジャイルソフトウェア開発に対する理解不足に基づいていると、指摘されることがある () 。
Matt Stephens は、エクストリーム・プログラミングを再検討し批評して、再構成した () 。

アジャイルソフトウェア開発に対しては、構造的な批判と文書化に関する批判がある。

• 何人かの熟練した開発者が開発に参加する必要がある
• ソフトウェア設計工程が不十分である
• アジャイル開発に適応するには組織の文化を大きく変える必要がある

アジャイル開発手法の一つ Agile Modeling は、不十分な設計や少ない文書という批判に対して、解決するべく取り組んでいる。
こうしたアジャイル開発に対する批判への解決は、Agile Modeling だけでなく、他のアジャイル開発手法 (エクストリーム・プログラミングなど) においても行われていくとみられる。