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

ソフトウェア開発工程
中心となる活動
パラダイムとモデル
ソフトウェア開発方法論とフレームワーク
開発支援
プラクティス
プログラミングツール
標準と機関
用語集

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

概要

ペアプログラミング

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

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

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

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

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

この宣言は以下の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（計画に従うことよりも変化への対応を）

適応型の価値提供

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

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

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

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

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

開発チーム

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

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

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

典型例

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

イテレーション

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

他の開発手法との比較

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

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

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

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

表. 開発パターンの分類
計画
予測型 適応型
実行 逐次型 ウォーターフォール -[21]
反復型 段階リリース アジャイル・反復型開発

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

表. 開発タイプと特性
タイプ 完成時期 品質 リスク
予測型計画・逐次型実行 プロジェクト終了時 一定（計画の質次第） 不完全な計画による全体の手戻り・品質不足
予測型計画・反復型実行 機能別段階リリース 一定（計画の質次第） 不完全な計画による機能レベルの手戻り・品質不足
適応型計画・反復型実行 機能別段階リリース 低→中→高 初期段階では完成時期が不明

反復型開発

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

カウボーイコーディング

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

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

適性

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

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

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

  • 20人以上の大規模なチームでの開発[23][出典無効]
  • 開発者が地理的に分散した状況での開発
  • ミッションクリティカル・人命に関わるシステム: （非）適応のための「失敗」が許されない。（是）失敗を必ずfallbackする設計による対応

次の環境ではアジャイルの価値観が機能せず適用が難しいと考えられている（アジャイルソフトウェア開発の欠点）。

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

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

歴史

近年のアジャイルソフトウェア開発の定義は、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年に書籍として出版された[25]。 エクストリーム・プログラミングの構成要素は、別のアジャイル開発手法 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]

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

注釈

  1. ^ Cleverworks® | Digitize and automate Administrative- Sales and Marketing Processes
  2. ^ Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation
  3. ^ The Agile Unified Process (AUP) Home Page
  4. ^ DSDM Consortium - Enabling Business Agility
  5. ^ - XP_jp_TOP
  6. ^ Feature Driven Development | The portal for all things FDD.
  7. ^ Poppendieck.LLC
  8. ^ Control Chaos - Message from Ken
  9. ^ Coming Soon – Alistair Cockburn
  10. ^ Agile/Lean Documentation: Strategies for Agile Software Development
  11. ^ Agile Data Home Page
  12. ^ The Process of Database Refactoring: Strategies for Improving Database Quality

脚注文献

[脚注の使い方]
  1. ^ "私たちは以下の価値に至った。... 個人と対話 ... 動くソフトウェア ... 顧客との協調 ... 変化への対応... により価値をおく" アジャイルソフトウェア開発宣言.
  2. ^ ケント・ベック、マイク・ビードル（英語版）、Arie van Bennekum, アリスター・コーバーン（英語版）、ウォード・カニンガム、マーティン・ファウラー, James Grenning、ジム・ハイスミス（英語版）、アンドリュー・ハント（英語版）)、ロン・ジェフリーズ（英語版）, Jon Kern, Brian Marick, ロバート・C・マーティン（英語版）, スティーブ・メラー（英語版）、ケン・シュウェイバー（英語版）, ジェフ・サザーランド（英語版）, Dave Thomas
  3. ^ "プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.
  4. ^ "複雑な問題に対応する適応型のソリューションを通じて ... 価値を⽣み出す" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.
  5. ^ "経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.
  6. ^ "包括的なドキュメントよりも動くソフトウェアを" アジャイルソフトウェア開発宣言.
  7. ^ "動くソフトウェアこそが進捗の最も重要な尺度です。" アジャイル宣言の背後にある原則
  8. ^ "価値のあるソフトウェアを早く継続的に提供します。... 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。" アジャイル宣言の背後にある原則
  9. ^ "契約交渉よりも顧客との協調を" アジャイルソフトウェア開発宣言.
  10. ^ "顧客満足を最優先し" アジャイル宣言の背後にある原則
  11. ^ "計画に従うことよりも変化への対応を" アジャイルソフトウェア開発宣言.
  12. ^ "要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。" アジャイル宣言の背後にある原則
  13. ^ Don’t just Do Agile, Be Agile
  14. ^ "プロセスやツールよりも個人と対話を" アジャイルソフトウェア開発宣言.
  15. ^ "最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。" アジャイル宣言の背後にある原則
  16. ^ "意欲に満ちた人々を集めてプロジェクトを構成します。" アジャイルソフトウェア開発宣言.
  17. ^ "環境と支援を与え仕事が無事終わるまで彼らを信頼します。" アジャイル宣言の背後にある原則
  18. ^ "アジャイルプロセスには反復型のアプローチが必要であり、ウォーターフォール方式で作業することなどできない。だが、反復型のアプローチ（非ウォーターフォール）に従っているが、アジャイルではないことも可能である" Martin Fowler. (2019). ウォーターフォールプロセス. Martin Fowler's Bliki (ja).
  19. ^ "アジャイルの考え方には、適応型の計画づくりが必要不可欠な要素である。フィーチャはイテレーション間で移動し、新しいフィーチャが登場することもあれば、価値がなくなったフィーチャが破棄されることもある。" Martin Fowler. (2019). ウォーターフォールプロセス. Martin Fowler's Bliki (ja).
  20. ^ "ウォーターフォール方式は、予測型の計画づくりを強制してくる。このことは、あるフェーズ（たとえば要求分析フェーズ）が終わると、その成果物は後続のフェーズが乗っかる安定したプラットフォームになることが前提となっている" Martin Fowler. (2019). ウォーターフォールプロセス. Martin Fowler's Bliki (ja).
  21. ^ 逐次型の実行では学習した内容を適応すべき "計画" がすでに使用済みのため、理論上は存在しない。実務上、適応型計画をしているのにイテレーション#1が無限に終了しない場合はここに分類されうる。
  22. ^ a b Boehm, B. and Turner, R. (2004)
  23. ^ “Dr. Dobb's | Good stuff for serious developers: Programming Tools, Code, C++, Java, HTML5, Cloud, Mobile, Testing”. Dr. Dobb's. 20xx-xx-xx閲覧。
  24. ^ McBreen, P. (2003)
  25. ^ Beck, Kent (1999)

参考文献

関連項目

外部リンク