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

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。例えばオブジェクト指向開発において、設計とプログラミングを何度か行き来し、トライアンドエラーで改良していく手法を指す。 特に「アジャイルソフトウェア開発宣言」が出された2000年代以降、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) やスクラム開発などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。

ソフトウェア開発
中心となる活動
パラダイムとモデル
方法論とフレームワーク
開発支援
プラクティス
ツール
標準と機関
用語集
  • 人工知能
  • コンピュータ科学

概要

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

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

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

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

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

イテレーションとスプリントの違い

アジャイル開発では、全体の開発期間を数週間程度の短い期間に区切って、この小さな開発単位ごとに設計・開発・テストを反復する。このアジャイル開発における開発サイクルのことを、XP(エクストリームプログラミング)では「イテレーション」、スクラム開発では「スプリント」という。

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

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

この宣言はアジャイルソフトウェア開発がもつ4つの特徴・価値を明らかにしている。

  • プロセスやツールよりも個人と対話を / Individuals and interactions over processes and tools
  • 包括的なドキュメントよりも動くソフトウェアを / Working software over comprehensive documentation
  • 契約交渉よりも顧客との協調を / Customer collaboration over contract negotiation
  • 計画に従うことよりも変化への対応を / Responding to change over following a plan

「変化への対応」はスクラムにおける「適応/adaptation」やエクストリーム・プログラミングにおける「変化ヲ抱擁セヨ/Embrace Change」に相当する。すなわちソフトウェアがもつ要件は素早く変化するものでありそれに適応しソフトウェアを改良する契機として利用することの価値を述べている。

他の開発手法との比較

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

<--アジャイル--> <--反復型開発--> <--ウォーターフォール-->
<------|----------------|----------------------|------->
   適応的開発                                計画重視

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

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

反復型開発との比較

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

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

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

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

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

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

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

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

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

しかし、2005年4月の時点では、企業においてアジャイル開発を採用した報告は少ない。

また、次に列記する状況に対して、アジャイル開発手法を適用できるかということについては、議論の対象となっている。

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

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

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

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

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

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

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

ベームとターナの主張によると、以上のような要素を指針としてプロジェクトを分析することで、アジャイル開発か計画重視開発かを検討する際の判断材料とすることができる。

歴史

近年のアジャイルソフトウェア開発の定義は、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年に書籍として出版された[2]。 エクストリーム・プログラミングの構成要素は、別のアジャイル開発手法 Scrum と、ウォード・カニンガムの Episodes pattern language を、基にしているようである。

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

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

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

その他の手法

  • Agile Documentation[※ 10]
  • Agile ICONIX
  • Microsoft Solutions Framework (MSF)
  • Agile Data Method[※ 11]
  • Database refactoring[※ 12]

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

批判

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

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

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

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

注釈

脚注文献

  1. Boehm, B. and Turner, R. (2004)
  2. Beck, Kent (1999)
  3. McBreen, P. (2003)

参考文献

  • Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. 2004. ISBN 0321186125
  • Beck, Kent. Extreme Programming Explained: Embrace Change (first edition). Addison-Wesley, Boston. 1999. ISBN 0201616416
    • 長瀬嘉秀(監訳)、永田渉(訳)、飯塚麻理香(訳) 『XPエクストリーム・プログラミング入門 : ソフトウェア開発の究極の手法 (第1版)』 ピアソンエデュケーション、2000年、ISBN 489471275X
    • Beck, Kent. Extreme Programming Explained: Embrace Change Second Edition. Addison-Wesley, Boston. 2004. ISBN 0321278658
    • 長瀬嘉秀(監訳)、テクノロジックアート(訳) 『XPエクストリーム・プログラミング入門 : 変化を受け入れる 第2版』 ピアソンエデュケーション、2005年、ISBN 4894716852
  • Fowler, Martin. Is Design Dead?.
    • 小野剛(訳) 設計の終焉?
    • Extreme Programming Explained 所収, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001, ISBN 0201710404 .
    • 「第一部 第1章 設計の終焉?」『XPエクストリーム・プログラミング検証編 : XPの基礎・応用・発展を考察する33篇精選論文集』ジャンカルロ・ズッチ(編)、ミシェル マルケシ(編)、小野剛(訳)、細川馨(訳)、石川真之(訳)、ピアソンエデュケーション、2002年、ISBN 4894715422
  • Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other.
    • Extreme Programming Explained 所収, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001, ISBN 0201710404 .
    • 「第二部 第3章 ASDとXPの価値体系を比較する : 方法論は、互いに何を学びうるか」『XPエクストリーム・プログラミング検証編 : XPの基礎・応用・発展を考察する33篇精選論文集』 他の書誌情報は [3] を参照
  • Tomek, Ivan. What I Learned Teaching XP.
  • M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003. ISBN 1590590961
  • D. Rosenberg, M. Stephens. Agile Development with ICONIX Process. Apress L.P., Berkeley, California. 2005. ISBN 1590594649
  • Beck, et. al., Manifesto for Agile Software Development.
  • McBreen, P. Questioning Extreme Programming. Addison-Wesley, Boston. 2003. ISBN 0201844575
  • Larman, Craig and Basili, Victor R. Iterative and Incremental Development:A Brief History IEEE Computer, June 2003 (PDF)
  • アート・オブ・アジャイル-デベロップメント-―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著), 木下 史彦(監訳) (監修), 平鍋 健児(監訳) (監修), 笹井 崇司 (翻訳), オライリージャパン, 2009, ISBN 4873113954

関連項目

外部リンク

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.