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

ソフトウェア工学における**アジャイルソフトウェア開発** (アジャイルソフトウェアかいはつ、) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。

## 概要

**アジャイルソフトウェア開発**は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（アジャイルソフトウェア開発宣言）。すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。

この価値観を共有する開発がアジャイルソフトウェア開発であり、アジャイルソフトウェア開発という言葉はソフトウェア開発工程やソフトウェア開発方法論、またはその総称ではない。特定の開発工程に縛られることはないが、実態として多くのアジャイルソフトウェア開発でみられる典型的な開発工程が存在する。典型的にはまずアイデアを価値を生む範囲で小さく分割する（例: 新機能のコア部分）。その価値を実現する成果物を短いイテレーションの中で計画・実装・デプロイすることで（⇒反復型開発）、迅速にプロダクトを届け価値の実証・学習・適応をおこなう。適応はプロジェクトにおける優先度の更新として可視化される。

## アジャイルソフトウェア開発宣言
アジャイルソフトウェア開発宣言（）は「アジャイルソフトウェア開発」という概念を提唱した文書である。

2001年に、軽量ソフトウェア開発手法（と当時呼ばれてた）分野で名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法が共有する価値観を議論した。彼らはその結果を「アジャイルソフトウェア開発宣言」(*[https://agilemanifesto.org Manifesto for Agile Software Development]*) という文書にまとめた。アジャイルソフトウェア開発宣言はアジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている (参考: アジャイル宣言の背後にある原則) 。

この宣言は以下の4つの価値観を示し、これらの価値観を有するソフトウェア開発を「アジャイルソフトウェア開発」と名付けた。

* （*プロセスやツールよりも*'個人と対話**を''）
* （''包括的なドキュメントよりも**動くソフトウェア**を''）
* （''契約交渉よりも**顧客との協調**を''）
* （''計画に従うことよりも**変化への対応**を''）

== 適応型の価値提供 ==
ソフトウェアは解決策（ソリューション）であり、目的ではない。ソフトウェアの利用を通じて問題が解決し、[[価値 (マーケティング)|価値]]を提供することこそが目的である。そのためには重要な問題を見出し、その問題を適切に解く解決策を届ける必要がある。

しかし重要な問題はしばしば複雑であり、一見してもその重要性を判断できず、また解決策が容易に見出せない。予測型（）の価値提供、すなわち「完璧に計画された価値提供」は往々にして不完全に終わる。見立てた問題が重要でない、あるいは解決策に穴があることが実利用時に判明してしまう。

そうでないやり方の1つが**適応型**（）の価値提供である。適応型では完璧な予測が困難だと認め、実際の価値提供から学ぶことを重視する。仮説としての問題を定め、解決策をつくり、それを実際のユーザーへ届ける。この実際の価値提供により仮説に対する学びを得る（例: そもそも使われない・使われるが非常に使いづらい）。この学びに基づいて価値提供を適応する、すなわち問題自体・その解決策を方向修正する。たとえ事前に完璧な予測ができなくても、すばやく適応し価値を高めていくことで段階的に良い価値提供が可能になる。これが適応型の価値提供である。

適応型の価値提供にとって、実際に価値を提供できる、すなわち動くソフトウェアは最も重要である。価値提供の素早い適応には、ソフトウェアの高頻度リリースと利用が必要である。実際の価値提供に基づく学習では[[価値 (マーケティング)|価値]]（例: [[顧客満足]]）に焦点を合わせる。学習に基づく適応こそが本質であり、問題と解決策が変わることは狙い通りであり、むしろ価値向上の機会として歓迎されるべきである。

適応型の価値提供こそがアジャイルの目的である。アジャイルとはこの適応に対する姿勢である。宣言における「変化への対応」、[[スクラム (ソフトウェア開発)|スクラム]]における「適応」、[[エクストリーム・プログラミング]]における（''変化ヲ抱擁セヨ''）はこの精神に他ならない。

== 開発チーム ==
アジャイルは価値提供に関して経験を通じた学び・適応を重視する。それは人間/開発チームにも同様のことが言える。もし開発チーム全体が問題仮説の実証に携わり続けていればチームには経験が蓄積し、適応時により良い問題仮説をチーム全体から提唱できる。逆に開発チームが指示された解決策の実装にのみ従事していると問題仮説に関する経験は蓄積しない。また他者への価値提供を担う権限と責任を持つチームは高い意欲を持つことができる。指示された解決策の実装のみを担っても意欲は高まらない。

提供する価値の最大化がアジャイルの目的である。その価値を提供するソフトウェアは人間の手によって開発される。ゆえにアジャイルソフトウェア開発は開発プロセスより開発する人間/チームを重視する。価値を最大化できるチームは**自己組織的なチーム**である。すなわち価値提供を担うことで高い意欲を持ち、問題設定・解決策提案・実装・適応をチーム自ら繰り返し経験を積み能力があり、それらをチームの権限と責任でおこなえるチームである。アジャイルソフトウェア開発ではチームの能力を信頼しチームの自己組織化に必要な環境・権限・責任をチームに付与することで提供価値を最大化する。

チームの構成は自由であるが、典型的にはエンジニア・デザイナー・プロダクトマネージャー・マーケター、他にもテスト担当者・テクニカルライタ・管理職などが見られる。

== 典型例 ==
アジャイルの価値観を共有している全ての[[ソフトウェア開発]]はアジャイルソフトウェア開発である。特定の[[ソフトウェア開発工程|開発工程]]に縛られることはないが、実態として多くのアジャイルソフトウェア開発でみられる典型的な[[ソフトウェア開発工程|開発工程]]が存在する。以下はその例である。

=== イテレーション ===
開発を短期間に区切りこの区切りごとに計画・開発・デプロイ・適応をおこなうパターンがしばしばみられる。この1サイクルは**イテレーション**（例: エクストリームプログラミング）や**スプリント**（例: [[スクラム (ソフトウェア開発)|スクラム]]）と呼ばれる。イテレーションを導入する目的は、迅速にプロダクトをデプロイし適応するサイクルが着実に回るよう[[インセンティブ (経済学)|動機づけ]]る・習慣づけることである。

== 他の開発手法との比較 ==

開発は計画と実行の観点から4つに分類できる。

計画のタイプは**予測型**（）と**適応型**（）に分類される。予測型は「事前の充分な予測により完成形の計画が策定できる」という立場をとり、必要な計画を事前に確定させる。一方適応型は「初期の計画を実行し、実行結果に基づいて計画を適応させる」という立場をとり、小さい計画・仮説を立てて実行し判明した問題点から計画自体を改善する。

実行のタイプは**逐次型**（）と**反復型*'（）に分類される。逐次型は「計画全体を多段プロセスに分け、プロセスを順次実行する」という立場である。例えばまず設計プロセスを、次に実装プロセスを、最後にテストプロセスを、とシーケンシャルに実行する。反復型は「計画を価値・機能に基づき分割した上で "1つの価値・機能に対する全プロセス実行" を反復する」という立場である。例えば動画アプリを再生機能とお気に入り機能に分け、まず再生機能の設計からテストまでを完成させ、次にお気に入り機能の設計からテストまでを完成させる。

アジャイルは価値の実証と適応を繰り返すため、適応型計画・反復型実行タイプの開発である。[[反復型開発]]も同じタイプに分類される。事前に完璧な計画をおこなって次に実装・テストと段階を進める、すなわち予測型計画・逐次型実行の開発スタイルの代表例は[[ウォーターフォール]]モデルである。アジャイルとウォーターフォールでは開発プロセスが全く異なる。



開発タイプにより完成時期や抱えるリスクが異なる。アジャイルは他のタイプと比較し、完成時期の目処が初期に立たないというリスクがある。これは計画自体が徐々に改善されて初めて意味ある計画となる特性に由来するため、本質的に避けられないリスクである。



=== 反復型開発 ===
アジャイルソフトウェア開発は適応型計画・反復型実行の観点で[[反復型開発]]と共通している。違いとして反復型開発は厳密なプロセス・様々なベストプラクティスを強調するが、アジャイル開発では開発体制すなわち人/開発チームに大きな価値をおきチームの非定型なコミュニケーションを推奨する。すなわちアジャイルは反復型開発と比較して人材に対するリスクの取り方が異なる。

=== カウボーイコーディング ===
カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。

アジャイルソフトウェア開発は適応を軸にそれを支える明確な価値観がある。アジャイルソフトウェア開発でみられる計画の頻繁な再評価・直接顔を合わせた意思疎通の重視・比較的少ない文書化などは明確な価値観に基づいたプロセスと結果であり、無秩序ではない。すなわちカウボーイコーディングとは異なる。

== 適性 ==
アジャイルソフトウェア開発は万能な[[ソフトウェア開発]]ではない。アジャイルソフトウェア開発が適性を発揮すると広く考えられている環境は以下が挙げられる。

* 1か所で作業を行う小規模なチーム（10人以下）
* 複雑な問題・要件が頻繁に変更される環境

適用の是非が議論される環境には以下が挙げられる。

* 20人以上の大規模なチームでの開発
* 開発者が地理的に分散した状況での開発
* ミッションクリティカル・人命に関わるシステム: （非）適応のための「失敗」が許されない。（是）失敗を必ずfallbackする設計による対応
次の環境ではアジャイルの価値観が機能せず適用が難しいと考えられている（アジャイルソフトウェア開発の欠点）。

*人材不足: アジャイルソフトウェア開発は優れたチームを信頼して結果を出す思想であり、人材を前提とする
* 命令型組織文化: アジャイルソフトウェア開発は価値を生む自己組織的チームを用いる思想であり、権限委譲を前提としている

アジャイルソフトウェア開発に対して「[[ソフトウェア設計|設計]]工程が不十分」との指摘があるが、アジャイルソフトウェア開発は[[ソフトウェア開発方法論]]ではなくその前提となる価値観である。またアジャイルソフトウェア開発を可能にする[[ソフトウェア開発方法論]]には様々な批評がある。これらは具体的方法論への批評であり、アジャイルの価値観に対する批評とは限らない。[[エクストリーム・プログラミング]] (XP) の初期の風評、およびその[[ペアプログラミング]]や継続的設計 (進化的設計) のような賛否両論のある実践原則は、特に批判の対象となった。
一方でこうした批判の多くは、アジャイルソフトウェア開発に対する理解不足に基づいていると、指摘されることがある ([http://www.sdmagazine.com/documents/s=1811/sdm0112h/0112h.htm The Threat of the New]) 。
Matt Stephens は、[[エクストリーム・プログラミング]]を再検討し批評して、再構成した ([http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp Extreme Programming Refactored]) 。アジャイル開発手法の一つ Agile Modeling は、不十分な設計や少ない文書という批判に対して、解決するべく取り組んでいる。

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

アジャイルで反復的な開発手法の実践例は、ソフトウェア開発の歴史の初期に見出すことができる ([https://pdfs.semanticscholar.org/058f/712a7dd173dd0eb6ece7388bd9cdd6f77d67.pdf Iterative and Incremental Development: A Brief History (PDF)]) 。

今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。
先述したとおり、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) は[[ヨーロッパ]]で最初に確立されたアジャイル開発手法であると考えられている。

== アジャイルソフトウェア開発手法の実例 ==
アジャイル[[ソフトウェア開発]]を可能にする[[ソフトウェア開発方法論]]の一部を示す。
* 
* 
* 
* ダイナミック・システム開発メソッド (DSDM)
* 
* [[エクストリーム・プログラミング]] (XP)
* [[ユーザー機能駆動開発]] (FDD; Feature Driven Development)
* 
* [[かんばん (ソフトウェア開発)]]
* [[Rapid Application Development|RAD(Rapid Application Development)]]
* [[スクラム (ソフトウェア開発)|スクラム]]
* 
* Crystal Clear および他の Crystal 開発手法
*[https://circleci.com/ja/blog/all-about-agile/ アジャイル開発について]
*[https://www.lucidchart.com/blog/ja/what-is-agile-methodology アジャイル方法論の概要]

[[その他]]の手法
* Agile Documentation
* Agile ICONIX
* Microsoft Solutions Framework (MSF)
* Agile Data Method
* Database refactoring

ソフトウェア開発との直接な関係はないが、類似した手法
* [[リーン生産方式]] (Lean manufacturing)

== 注釈 ==


== 脚注文献 ==



== 参考文献 ==
* 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]].  [http://www.martinfowler.com/articles/designDead.html *Is Design Dead?*].
** 小野剛(訳) [http://www.objectclub.jp/community/XP-jp/xp_relate/isdesigndead 設計の終焉?]
** *Extreme Programming Explained* 所収, G. Succi and M. Marchesi, ed.,  Addison-Wesley, Boston.  2001, ISBN 0201710404 .
** 「第一部 第1章 設計の終焉?」『XPエクストリーム・プログラミング検証編 : XPの基礎・応用・発展を考察する33篇精選論文集』ジャンカルロ・ズッチ(編)、ミシェル マルケシ(編)、小野剛(訳)、細川馨(訳)、石川真之(訳)、ピアソンエデュケーション、2002年、ISBN 4894715422
* Riehle, Dirk.  [http://www.riehle.org/computer-science/research/2000/xp-2000.html *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*.
** [http://www.t-doi.org/agile/index.html アジャイルソフトウェア開発宣言] 土居俊彦(訳)
** [http://www.metabolics.co.jp/XP/AgilePrinciples.html アジャイルソフトウェアの原則] 有限会社メタボリックス(訳)
* McBreen, P.  *Questioning Extreme Programming*.  Addison-Wesley, Boston.  2003. ISBN 0201844575
* Larman, Craig and Basili, Victor R. [http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf *Iterative and Incremental Development:A Brief History '' IEEE Computer, June 2003  (PDF)]
* アート・オブ・アジャイル-デベロップメント-―組織を成功に導くエクストリームプログラミング James Shore (著), Shane Warden (著), 木下 史彦(監訳) (監修), 平鍋 健児(監訳) (監修), 笹井 崇司 (翻訳), オライリージャパン, 2009, ISBN 4873113954

## 関連項目
* ソフトウェア工学
* エクストリーム・プログラミング
* ソフトウェア開発工程
* テスト駆動開発
* ビヘイビア駆動開発

## 外部リンク
* Manifesto for Agile Software Development
** アジャイルソフトウェア開発宣言 - 土居俊彦（訳）
** アジャイルソフトウェアの原則 - 有限会社メタボリックス（訳）
* 設計の終焉? - マーティン・ファウラー（著）、小野剛（訳）
* Agile business Institute
*  The Agile Alliance
* Agileskunk/work
* アジャイルプロセス協議会
* Agile Planet weblog aggregator
* SoftwareReality.com - a critical eye on agile development - Matt Stephens のウェブサイト
* www.testdriven.com - テスト駆動開発のコミュニティのサイト
* 東邦チタニウム - 国内事例 - CASE FILE  - CIO Online
* 記事 "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths
* 論文  Neill, C. J., and Laplante, P. A. Requirements engineering: the state of the practice. IEEE Software 20, 6 (Nov./Dec. 2003), 40-45; (PDF)

* 記事 Agile, Multidisciplinary Teamwork - 著者: Gautam Gosh
* 記事 Agile Requirements - 著者: Rachel Davies
* 記事 Worse is worse - 著者: Jim Waldo
* 記事 Agile Modeling: Effective Practices for XP and RUP - Ambler, S.W. の著書紹介
* What is agile project management ?
*