アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。近年、アジャイルソフトウェア開発手法が数多く考案されている。ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1つの機能を開発する（⇒反復型開発）。そして、この反復のサイクルを継続して行うことで、1つずつ機能を追加的に開発してゆくのである。また、各々の反復は、小規模なソフトウェア開発プロジェクトに似ている。なぜなら、計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行うからである。アジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェアをリリースすることを目指す。各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる (ここでの顧客とは、開発対象のソフトウェアが何であるかを定義する人々である。「顧客」は、時としてプロジェクト管理者である場合があるし、ビジネスアナリストや本物の顧客である場合もある) 。この作業場所では、テスト担当者、ユーザインタフェース設計者、テクニカルライタ、管理職も一緒に作業する場合がある。また、アジャイル開発手法では、実際に動くソフトウェアこそが最重要なプロジェクト進行尺度であることを強調する。この「実際に動くソフトウェア」という進行尺度の採用と、直接顔を合わせた意思疎通の重視とがあいまって、アジャイル開発手法で作成する文書の量は、他の開発手法と比較すると、非常に少ない。文書が少ないことは、しばしば無統制で雑な作業 (ハッキング、カウボーイコーディング) であるとして、アジャイル開発に対する批判材料の一つとなっている (後述する) 。アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。2001年に、アジャイルソフトウェア開発手法 (当時は軽量ソフトウェア開発手法と呼ばれていた) の分野において名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した。そして、彼らは「アジャイルソフトウェア開発宣言」("Manifesto for Agile Software Development") という文書にまとめた。アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている (参考: アジャイルソフトウェアの原則) 。この宣言には、著者として次の17人が名前を連ねている。アジャイルソフトウェア開発手法は、ソフトウェア開発手法を分類する視点である「適応的開発」手法から「計画重視」手法までの連続線上において、典型的な適応的開発手法に位置づけられる。従来の開発手法との違いは、適応的開発手法から計画重視手法までの連続線上に、各開発手法を位置づけることによって、適切に説明できる。他の開発手法のプロジェクトと同様に、アジャイル開発手法のプロジェクトでは、計画を立て、統制を行う。一方、アジャイル開発手法は、場合によっては、「計画駆動」手法や「統制された」手法の反対側に位置づけられると言及されることがあるが、これは誤りである。適応的 (adaptive) な開発手法では、現実世界で生じた変更にすばやく適応することに主眼を置く。プロジェクトで変更が必要となった場合、適応的手法のプロジェクトチームは、即座に変更に対応することができる。しかし、その一方で、将来起こりうる変更を正確に文書化することは困難である。そのため、長期的予測になるほど、予測の不確実性は大きくなる。つまり、次の週に行うべき作業は正確に文書化することができるが、次の月に行うべき作業は正確に文書化することはできない。したがって、6か月後のリリースについて質問を受けた場合、適応的手法のチームにできることは、6か月後のリリースに向けた課題を文書化することや費用対効果の予測を文書化することぐらいである。一方、計画重視 (predictive) の開発手法では、適応的手法とは対照的に、詳細な開発計画を立てることに主眼を置く。したがって、計画重視手法のチームは、開発プロセスの全期間にわたって、注意点と作業を正確に計画することができる。しかし、その一方で、プロジェクト中に生じた変更に対応することは困難である。なぜなら、計画立案時点を基準として、計画が最適化されているからである。そのため、プロジェクト中に変更が生じると、すでに完了した作業の一部は無駄になり、やり直さなければならないことになる。そこで、重要な変更だけを管理するために、変更管理委員会を設けることが多い。アジャイルソフトウェア開発手法の多くは、反復型開発手法と同様に、短い期間を単位として、リリース可能なソフトウェアを開発することを強調する。反復型開発手法ではリリースの期間単位が月単位であることが多いのに対し、アジャイル開発手法では週単位であることが多い。また、アジャイル開発手法では、高度に洗練された共同作業のもとで作業を行うことを強調する。さらに、アジャイル開発手法の多くでは、反復型開発手法よりも、厳密な期間単位のもとで作業を行う。アジャイルソフトウェア開発は、ウォーターフォールモデルによる開発との共通点が少ない。また、ウォーターフォール開発はもはや信頼を失っていると考える人もいる。しかし、2005年前後の時点でも、ウォーターフォール開発手法は未だ広く行われている ("The Demise of the Waterfall Model Is Imminent" and Other Urban Myths) 。ウォーターフォール開発手法は、数あるソフトウェア開発手法の中でも、最も計画重視であると位置づけられる手法である。ウォーターフォール開発手法では、要件定義、分析、設計、実装、テストの各工程を、予め計画された順序に厳格に従って行う。また、プロジェクトの進捗は、一般的には、次のような納品可能な成果物をもとに計測される。ウォーターフォールモデルは、一連の工程の大規模な統合であり、数か月から数年の長い期間単位を採用し、その期間単位の終了に向けてテストが行われる。この統合とテストの規模が大きくまた困難であることは、ウォーターフォールモデル開発のプロジェクトが失敗する際に、その原因の一つとなっていることが多い。アジャイルソフトウェア開発手法では、対照的に、1週間から数週間もしくは数か月という短い期間単位ごとに、完全に開発されたテスト済みの機能をリリースする (ここでの機能とはシステム全体のごく小さなサブセットである) 。アジャイル開発手法では、雑ではあるが利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調する。一部のアジャイル開発チームでは、小規模なウォーターフォールモデルが採用されている。この場合、反復ごとに完全なウォーターフォールのサイクルを繰り返す。また、一部のアジャイル開発チーム (特にエクストリーム・プログラミングで開発するチーム) では、ウォーターフォールモデルの各工程を、同時並行して行う。カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。アジャイルソフトウェア開発には、計画の頻繁な再評価、直接顔を合わせた意思疎通の重視、比較的少ない文書化などの特徴がある。以上のような特徴がアジャイル開発にはあるため、アジャイル開発とカウボーイコーディングを混同されることがある。しかし、こうした混同は正確ではない。アジャイル開発チームは明確なプロセスに従って作業する。そして、このプロセスは、統制され厳格である場合が少なくない。この点でアジャイル開発とカウボーイコーディングは異なっている。アジャイルソフトウェア開発は、10人以下の小規模なチームが1か所で作業を行うプロジェクトの場合に効果的であると説明されることが多い。また、アジャイルソフトウェア開発は、予測困難な要件や頻繁に変更される要件に直面するチームにとって、特に有効な手法であると指摘される。さらに、以上に述べた状況以外においても、アジャイル開発を採用して成功したチームの体験報告がいくつか存在する。しかし、2005年4月の時点では、企業においてアジャイル開発を採用した報告は少ない。また、次に列記する状況に対して、アジャイル開発手法を適用できるかということについては、議論の対象となっている。バリー・ベームとリチャード・ターナは、適応的 (アジャイル) な開発手法と計画重視の開発手法のどちらを選択すべきかという問題に対する指針として、リスク分析手法を提案した。ベームとターナは、適応的開発にも計画重視開発にもそれぞれ得意分野があると、述べている。アジャイル開発の得意とする状況計画重視開発の得意とする状況ベームとターナの主張によると、以上のような要素を指針としてプロジェクトを分析することで、アジャイル開発か計画重視開発かを検討する際の判断材料とすることができる。近年のアジャイルソフトウェア開発の定義は、1990年代半ばに、「重量ソフトウェア開発手法」への反対運動の一部から発展して形成されてきた。重量開発手法の特徴は、ウォーターフォール開発モデルを適用した場合に多くみられる、厳格な規律と統制、管理不足などである。ウォーターフォールモデルのこのような適用に端を発する重量開発手法は、官僚的で、もたもたしていて (slow) 、衰退的 (demeaning) で、そのためソフトウェア技術者が効果的に作業を進めるという観点と矛盾していた。アジャイルで反復的な開発手法の実践例は、ソフトウェア開発の歴史の初期に見出すことができる (Iterative and Incremental Development: A Brief History (PDF)) 。今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。先述したとおり、2001年に軽量開発手法において名声のある人々がスノーバードに会し、「アジャイルソフトウェア開発手法」と呼称を変えた。その後、スノーバードに会した人々の一部は、非営利組織 Agile Alliance を設立し、アジャイル開発を推進する活動を行っている。2000年以前に開発された比較的歴史の長いアジャイル開発手法には次のようなものがある。エクストリーム・プログラミング (XP) は、最初のアジャイル開発手法ではなかったようだが、数あるアジャイル開発手法の中で抜きん出た評判を確立した。エクストリーム・プログラミングは、ケント・ベックが1996年に開発し、米クライスラー社で苦境にあった Chrysler Comprehensive Compensation (C3) プロジェクトを立て直す際に、実践した。そのプロジェクトは最終的には中止となったが、ケント・ベックの開発手法は、Ron Jeffries による長期の指導と、ウォード・カニンガムの Portland Pattern Repository wiki での公開議論と、ケント・ベックのさらなる改訂を経て、1999年に書籍として出版された。エクストリーム・プログラミングの構成要素は、別のアジャイル開発手法 Scrum と、ウォード・カニンガムの Episodes pattern language を、基にしているようである。Dynamic Systems Development Method (DSDM) はヨーロッパで最初に確立されたアジャイル開発手法であると考えられている。広く知られたアジャイルソフトウェア開発手法の一部を示す。その他の手法ソフトウェア開発との直接な関係はないが、類似した手法アジャイルソフトウェア開発は、カウボーイコーディング (先述) であるとして、批判されることがある。エクストリーム・プログラミング (XP) の初期の風評、およびそのペアプログラミングや継続的設計 (進化的設計) のような賛否両論のある実践原則は、特に批判の対象となった。一方でこうした批判の多くは、アジャイルソフトウェア開発に対する理解不足に基づいていると、指摘されることがある (The Threat of the New) 。Matt Stephens は、エクストリーム・プログラミングを再検討し批評して、再構成した (Extreme Programming Refactored) 。アジャイルソフトウェア開発に対しては、構造的な批判と文書化に関する批判がある。アジャイル開発手法の一つ Agile Modeling は、不十分な設計や少ない文書という批判に対して、解決するべく取り組んでいる。こうしたアジャイル開発に対する批判への解決は、Agile Modeling だけでなく、他のアジャイル開発手法 (エクストリーム・プログラミングなど) においても行われていくとみられる。

出典:wikipedia