住友電工情報システム
ホーム > ITキーワード > アジャイル開発

アジャイル開発(Agile Software Development, アジャイルソフトウェア開発)

アジャイル開発(Agile Software Development, アジャイルソフトウェア開発)とは?

アジャイルピラミッド

アジャイル開発(アジャイルソフトウェア開発)とは、ある種の開発技法やツールの集まりでも特定の開発手法の名称でもなく、アジャイル宣言で謳われた価値や主義のことであり、また、それに基づく一連の開発方法や開発技術の総称です。すなわち、アジャイル開発とは一連の開発方法や手法であると同時に、ソフトウェア開発に対するマインドセット、考え方と言えます。

「アジャイル」という言葉は「機敏」、「迅速」という意味であり、仕様が確定できない混沌とした状態において変化に対応していくことができることを意味します。「アジャイルソフトウェア開発」という言葉が生まれる以前から様々な軽量開発手法が、ウォータフォール開発やVモデル開発のような、それまで主流だった重量ドキュメント駆動の開発手法へのアンチテーゼとしてとして提案されました。反復型開発(Iterative and Incremental Development)の始まりは1957年頃に遡ります。1970年代には漸進的開発手法や適応型ソフトウェア開発が現れていました。1990年代初めには、RAD、UP、DSDMがなどの手法が現れ、その後、現在アジャイル開発手法として有名なScrum、Cristal Clear、XPなどが現れます。

そして、2001年、17名の軽量ソフトウェア開発の方法論の専門家達が米国ユタ州スノウバードに集まり、それぞれがもつ開発方法やさまざまなソフトウェア開発へのアプローチについて議論し、共同でアジャイルソフトウェア開発宣言を公開しました。アジャイル開発とは、アジャイル宣言で謳われた価値や主義に基づき、12のポリシーに従う開発手法なのです。

アジャイル開発の特徴は、自己組織された、機能横断型のチームと顧客(ユーザ)が協力して要求と解決策を提示しながら開発を進めることです。ウォータフォール型開発に代表される従来型の計画重視の開発と比べると、アジャイル開発は、より仕様が複雑、未確定、変化しやすい性質のソフトウェア開発をターゲットとしています。そのために、適応型の計画、反復型の開発、早期のリリース、継続的な改善、そして変化に対する迅速で柔軟な対応が推奨されます。

多くのアジャイル開発手法は、開発すべきシステムを小さな単位に分割します。反復(Iteration)の期間はそれまでの以前の反復型開発手法よりもよりも短く、2週間から1か月程度です。開発はひとつのチームで、計画、分析、プログラミング、単体テスト、受け入れテストすべてを実施します。すなわち、機能横断型チームです。ひとつの反復の最後に顧客(ユーザ)に稼働する成果物を見せます。

このように、短期間に動く成果物で顧客に確認してもらうことで、リスクを軽減し、変化に迅速かつ柔軟に対応し、最終的には顧客価値の高いソフトウェアを提供するのです。動くプログラムが進捗の指標です。

アジャイルソフトウェア開発宣言(The Manifesto for Agile Software Development)

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

2001年2月、それぞれの軽量で適応型のソフトウェア開発方法を実践する専門家17名が集い議論を交わしました。彼らは自分たちの持つ開発方法論に関して統一を図ることはありませんでしたが、4つの主な価値に関して共通認識を得て、それをアジャイルソフトウェア開発宣言として公開しました。

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

私たちは、ソフトウェア開発の実践 あるいは実践の手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

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

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

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

© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

1.プロセスやツールよりも個人と対話を

アジャイル開発では、予め決められたプロセスや開発ツールよりも、開発チームの人間関係や共通意識、それが果たす役割を重視します。12の原則の6番目にもあるように、アジャイル開発ではフェイス トゥ フェイスのコミュニケーションを重視し、開発チーム、顧客が一同に会することにより、仕様書には書けない情報伝達が活発になり、新しい気づきを生むことができるのです。もちろん、プロセスやツールも使います。その価値を認めた上で本質的な価値を個人との対話に置いているのです。

2.包括的なドキュメントよりも動くソフトウェア

アジャイル開発は、変化に迅速かつ柔軟に対応し、顧客にとって価値の高いソフトウェアを提供することが大きな目的です。どれだけ顧客価値が実現できているかを確認するには、仕様書やテスト報告書よりも、動くソフトウェアで確認するのが最も早くて確実です。動くソフトウェアで素早く仮設検証を繰り返すことで価値の高いものが生まれるのです。

3.契約交渉よりも顧客との協調を

12の原則の4番目にもあるとおり、アジャイル開発では、開発チームと顧客が一丸となって同じ目標に向かうべく日々働くことが求められています。変化を許容し顧客満足度の向上をめざして、立場を超えて協調することでよりよい仕事のやり方が生まれ成果につながります。

4.計画に従うことよりも変化への対応を

計画は重要ではあるが、とりまく環境や技術、そして顧客の優先度は常に変化しています。そもそも、アジャイル開発では、顧客に価値のあるソフウェアを提供することが最も重要視されます。改善のための仕様変更はネガティブではなく、新たな価値追加を生む原動力としてポジティブに捉えることが求められています。

このアジャイルソフトウェア開発宣言はその背後にある12の原則に基づいています。

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

  1.  1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2.  2.要求の変更はたとえ開発の後期であっても歓迎します。
     変化を味方につけることによって、お客様の競争力を引き上げます。
  3.  3.動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔で
     リリースします。
  4.  4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5.  5.意欲に満ちた人々を集めてプロジェクトを構成します。
     環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6.  6.情報を伝えるもっとも効率的で効果的な方法はフェイス トゥ フェイスで
     話をすることです。
  7.  7.動くソフトウェアこそが進捗の最も重要な尺度です。
  8.  8.アジャイル・プロセスは持続可能な開発を促進します。
     一定のペースを継続的に維持できるようにしなければなりません。
  9.  9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. 10.シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. 12.チームがもっと効率を高めることができるかを定期的に振り返り、
     それに基づいて自分たちのやり方を最適に調整します。

代表的なアジャイル開発手法

アジャイルソフトウェア開発手法には多様なものが提案されています。それぞれの手法はソフトウェア開発のライフサイクルをすべてカバーするものとは限らず、プロジェクト管理に重点をおくもの、プログラミングに重点をおくもの、上流設計に重点をおくもの様々です。代表的なものの概要を下記に紹介します。

スクラム(Scrum)

スクラムの繰り返しプロセス

スクラムはプロジェクト管理に重点を置いたアジャイル開発のフレームワークです。このフレームワークはKen Schwaberと Jeff Sutherlandがスクラムガイドとしてまとめています。

スクラムのルーツは1986年に日本の竹中弘高、野中郁次郎共著の「The New New Product Development Game」です。この論文は1980年代の日本の新製品開発プロセスについて述べたものであり、様々な専門性を持つ人がひとつのチームとして自立的に活動できる環境を与えられ、開発の最初から最後までを担当する。このようなチームを「スクラム」と呼びました。この「スクラム」はもちろん、ラグビーのスクラムから命名されました。

スクラムの基本的な考え方は、顧客の望むものや要求は常に変化し、それは前もって計画することはできない。上流工程で仕様のすべてを定義することはできないということを前提に、そこには力を注がず、素早いリリース、新たな要求への対応、技術や変化への適応するためのチーム力最大化に全力を注ぐことにフォーカスしています。

スクラムはプロジェクト管理に重点をおいた手法であり、ソフトウェア開発のライフサイクルで必要なすべての手法やプラクティスを含んでいません。従って、実際の開発では足りない部分を補ってやる必要があります。例えば、スクラムとXPを組み合わせることも可能です。逆にこのシンプルで自由に組み合わせられることが、最も普及している理由のひとつにもなっています。

スクラムでは次の3つの役割分担があります。

  1. 1.プロダクトオーナー
  2. 2.開発チーム
  3. 3.スクラムマスター

また、スクラムでは反復的に開発を進めますが、その反復の単位、タイムボックスを「スプリント」と呼びます。通常1つのスプリントは1か月以内で設定されます。それぞれのスプリントは下記の作業で構成されます。

  1. 1.スプリントプランニング
  2. 2.ディリースクラム
  3. 3.開発作業
  4. 4.スプリントレビュー
  5. 5.スプリントレトロスペクティブ

XP(eXtreme Programing, エクストリームプログラミング)

XP 計画/フィードバックグループ

XPはスクラムと並んで最も普及しているアジャイル開発プロセスです。XPはKent Beck等により、ソフトウェアの品質を改善し、顧客の要望の変化に適応する能力を高めるために提案されました。1996年、Kent Beckは自身が働いていたクライスラー社の給与支払いシステム開発プロジェクトを担当することになり、この時の経験を基に、1999年8月に「eXtreme Programming EXPlained」として公開しました。

XPでは要求変更によるコスト増を抑えるために、短期間での頻繁なソフトウェアリリースをします。さらに、ペアプログラミング、テスト駆動開発(自動テストの同時開発)など、開発を効率化し要求変更コストを抑える12プラクティスを含みます。XPでは、ソフトウェア開発プロジェクトにおいて、要求の変化は当然かつ不可避であり、むしろ望ましいものと考えます。

XPでは次の5つの価値を重視します。

  1. 1.コミュニケーション(Communication)
  2. 2.シンプル(Simplicity)
  3. 3.フィードバック(Feedback)
  4. 4.勇気(Courage)
  5. 5.尊重(Respect)

開発チームのメンバーは顧客、及び他のプログラマーと常に身近にいてコミュニケーションをとります。今日必要な機能だけを実装し仕様をシンプルに保ちます。将来必要になるかもしれない機能は実装しません。これは、よくYAGNI(You aren’t gonna need it)アプローチと呼ばれています。反復毎に稼働するプログラムをすばやくリリースしてフィードバックに注意深く耳を傾け、あらゆる必要な変更を施します。また、システムをシンプルに保つ勇気、リファクタリングする勇気、コードを捨て去る勇気、勇気とは徹底することを意味します。チームメンバーは全員の仕事や貢献を尊重します。

XPで実践すべき項目(プラクティス)は次の4つに分離された12項目です。

1.きめ細かなフィードバック
(1)ペアプログラミング
(2)計画ゲーム
(3)テスト駆動開発
(4)チーム全体
2.継続的プロセス
(1)継続的インテグレーション
(2)コードリファクタリング
(3)頻繁なリリース
3.理解の共有
(1)コーディング標準
(2)チームコード共有
(3)シンプル設計
(4)システムメタファー
4.プログラマーの福利厚生
(1)持続可能なペース

ASD(Adaptive Software Development)

ASD

ASDはジム・ハイスミス(Jim Highsmith)とサム・ベイヤ(Sam Bayer)がRADを進化させて考案したものです。2000年「Adaptive Software Development: A Collaborative Approach to Managing Complex Systems」を出版しています。

それまでのウォータフォールモデルに代表される計画に基づいた重量開発手法は、比較的安定した変化の少ない事業に関しては有効でしたが、そもそもプロジェクト開始時点で計画しきれない、複雑な状況や変化の激しい領域に対しては有効ではありません。ASDはこのような計画困難なプロジェクトに対応するために、継続的に変化を受け入れ、それに適応していく手法です。

ASDのフローでは下記の主要な3つのイベントを繰り返します。

  1. 1.スペキュレーション(Speculation)
  2. 2.コラボレ―ション(Collaboration)
  3. 3.ラーニング(Learning)

スペキュレーションでは、まずプロジェクトの開始(Initiation)を行います。ここでは、プロジェクトミッションの設定、制限事項の理解、チームの作成、要求事項の概要作成、初期のプロジェクト規模とスコープ見積、そして主なリスクの定義を行います。次に反復開発の計画を行います。すなわち、タイムボックス(反復の期間)、反復回数等を決めていきます。ここでは、現時点で計画できない未確定なものの存在を認め、それについては反復の中で確定させていくと割り切ります。この際、プロジェクトミッションの理解が非常に重要になります。一方、確定しているものについては計画します。

コラボレーションでは、開発チームの技術者、マネージャーが協力して開発を行います。小さなプロジェクトでは物理的に同じ場所で働き、口頭やホワイトボードなどを活用して密な情報交換を行います。大きなプロジェクト、分散配置された環境ではコミュニケーションのための何らかの工夫が必要です。

ラーニングでは、品質レビューを行います。品質レビューには主に①成果物に対する顧客観点からのフィードバック、②成果物に対する技術観点からのフィードバック、③チーム運営に対する観点からのフィードバック、④プロジェクトのあり方の観点からのフィードバックがあります。ASDでは最初から及第点の品質を求めるわけではありません。不具合やまちがいから開発チームが学んでいくことが最も重視されるのです。そうすることにより、プロジェクト全体としてリワークを減らすことができるのです。

ASDのライフサイクルは次の6つの基本的な特徴を持っています。

  1. 1.ミッション重視(Mission focused)
  2. 2.機能ベース(Feature based)
  3. 3.反復(Iterative)
  4. 4.期間固定(Time-boxed)
  5. 5.リスク駆動(Risk driven)
  6. 6.変化に寛容(Change tolerant)

LSD(Lean Software Development, リーンソフトウェア開発)

LSD

LSD(リーンソフトウェア開発)はその名の通り、製造業向けのリーン生産方式をソフトウェア開発に適用したものです。リーン生産方式は1980年代のトヨタ生産方式を研究することで生み出されたもので、1991年、ジェームス・P・ウォマック(James P.Womack)、ダニエル・T・ジョーズ(Daniel T. Jones)、ダニエル・ルース(Daniel Roos)によって提唱されました。リーン生産方式は「ムダ」、「ムラ」、「ムリ」を最小化するための体系的な方法論といえます。

このリーン生産方式をソフトウェア開発に適用できるという考えは、1993年にはボブ・シャレット(Bob Charette)により提唱されていました。2001年のアジャイルソフトウェア宣言後、LSDもアジャイル開発のひとつと認められました。その後、メアリー&トム・ポッペンディーク夫妻(Mary & Tom Poppendieck)が共著で3冊の本を書いています。LSDの考え方はその後の複数の研究者によって進化し拡張しています。

LSDにはスクラムやXPなど違い固有のプロセスやプラクティスがありません。そのソフトウェア開発がLSDの価値や7つの原則に沿っていると認められた場合、それを「リーン」と呼ぶことができるのです。

LSDの7つの原則は以下の通りです。

  1. 1.ムダを省く
  2. 2.品質を作り込む
  3. 3.知識を作り出す
  4. 4.早く提供する
  5. 5.権限を移譲する
  6. 6.決定を遅らせる
  7. 7.全体を最適化する

アジャイルモデリング(Agile Modeling)

アジャイルモデリングはカナダのソフトウェア技術者スコット・アンブラー(Scott Ambler)によって提唱されました。当初はエクストリームモデリング(eXtreme Modeling, XM)という名称でしたが、2002年にアジャイルモデリング(Agile Modeling, AM)に改名し、同名の「アジャイルモデリング(Agile Modeling, Effective Practices for eXtreme Programming and the Unified Process)」を出版しました。

アジャイルモデリング(Agile Modeling)は、アジャイル開発プロセスにおいて、効果的なモデリングと文書化のみにフォーカスした方法論です。従って、実際の適用ではXPやスクラムなどの他のソフトウェア開発プロセスと組み合わせて適用する必要があります。

また、アジャイルモデリングはモデリングのための、価値、原則、プラクティスを集めたものであって、ある種類のモデルを作成するための手順を定義したものではありません。モデリング担当者が効果的に仕事をするにはどうすればよいかについてのアドバイスです。例えば、主要なプラクティスでは、モデルは「中身をシンプルにし」、「シンプルに描き」、「少しずつモデリング」する。すなわち、目的がはっきりしたモデルを作成し、余分なものはモデルにしないようにします。また、「適切な成果物を使う」、「他の成果物に移る」、「複数のモデルを並行してつくる」、「他の人々といっしょにモデリングする」、「コードで確かめる」、「テストできるか考える」により、有効性の高いモデルを作成することを目指します。

アジャイルモデリングはエクストリームプログラミングの考え方の影響を大きく受けており、その価値はエクストリームプログラミングの価値を採用し拡張したものです。

アジャイルモデリングの価値

  1. 1.コミュニケーション(Communication)
  2. 2.簡潔さ(Simplicity)
  3. 3.フィードバック(Feedback)
  4. 4.勇気(Courage)
  5. 5.謙虚さ(Humility)
アジャイルモデリングのベストプラクティス

クリスタル・クリア(Crystal Clear Method)

クリスタル・クリアは1998年にIBMのアリスター・コーバーン(Alistair Cockburn)が考案したソフトウェア開発手法「クリスタルファミリー」のひとつです。アリスター・コーバーンは、プロジェクトの特徴、すなわち規模やそのシステムが社会に及ぼす影響などにより開発プロセスを使い分けるべきと考え、クリスタル・クリア、クリスタル・イエロー、クリスタル・オレンジ、クリスタル・レッドと4種類の開発手法を考案しました。クリスタル・クリアはその中で最も軽量な開発プロセスで、6~8名程度の開発チームで人命に関わらないようなプロジェクトが対象です。

クリスタルファミリーすべてに共通する理念は人間とコミュニケーションです。また、クリスタルではそれぞれプロジェクト固有の特徴に合わせて、プロセスやプラクティスをテーラリングすることが求められています。ある意味非常に柔軟な手法と言えるでしょう。

クリスタル・クリアの7つのプロパティ

  1. 1.頻繁なリリース(Frequent delivery)
  2. 2.チームで判断する改善(Reflective improvement)
  3. 3.密なコミュニケーション(Osmotic communication)
  4. 4.個人の尊重(Personal safety)
  5. 5.仕事に集中できること(Focus)
  6. 6.キーとなるユーザがそばにいること(Easy access to eXPert users)
  7. 7.開発のための技術環境(Technical environment)

DSDM(Dynamic System Development Methodology)

DSDMはソフトウェア開発プロジェクトライフサイクル全般をカバーすることにフォーカスしたアジャイル開発手法です。1994年にRAD(Rapid Application Development)をベースとして提案されました。1990年代中旬以降、RADは多くの企業で導入が進みましたが、標準化された決まりやプロセスがなく各企業が独自の方法で導入していました。そこで、大手企業が共同で1994年にDSDMコンソーシアムを設立し、RADに理念と原則、プラクティスを加えて提案しました。

DSDMの特徴は、ソフトウェア開発フェーズだけでなく、その前段階(Pre-Project)やあと段階(Post-Project)までを定義していることです。ソフトウェア開発に着手する前に、ビジネスゴールを理解し、実現可能なゴールを綿密に設定します。納期通りにビジネス価値を提供することを重視し、タイムボックス方式で期間を固定し、MoSCoWによりビジネス優先度を考慮して成果物を取捨選択します。品質レベルの確保も重視します。

DSDMは、「いかなるプロジェクトも明確に定義された戦略目標に対応し、ビジネスへの具体的なベネフィットをできるだけ早く提供することにフォーカスしなければならない」ことを理念とします。そして、この理念を支援するために、次の8項目を原則としています。

  1. 1.ビジネス要求にフォーカスする
  2. 2.納期通りに提供する
  3. 3.協力
  4. 4.品質に妥協しない
  5. 5.確固たる基礎を築いてから漸進的に構築する
  6. 6.反復的に開発する
  7. 7.継続的に、明確にコミュニケーションする
  8. 8.プロジェクトを制御する

これらの原則を実現するための主な技法としては

  1. 1.タイムボックス
  2. 2.MoSCoW
  3. 3.プロトタイピング
  4. 4.テスト

等があげられます。

MoSCoW

FDD(Feature Driven Development, ユーザ機能駆動開発)

FDDはジェフ・デ・ルーカ(Jeff De Luca)が、1997年シンガポールの大手銀行の大規模な開発プロジェクト(50人、15ヵ月)のために提案したものです。Featureとは顧客視点での機能価値のこと。FDD(ユーザ機能駆動開発)は実績のあるベストプラクティスを組み合わせたもので、稼働するソフトウェアを繰り返し短い間隔で提供します。

FDD

FDDは次の5つの活動を含みます。

  1. 1.全体モデル開発
  2. 2.フィーチャーリスト構築
  3. 3.フィーチャー毎の計画
  4. 4.フィーチャー毎の設計
  5. 5.フィーチャー毎の構築

また、以下のようなプラクティスで構成されます。

  • ドメイン・オブジェクト・モデリング
  • フィーチャー毎の開発
  • クラス毎のオーナーシップ
  • フィーチャーチーム
  • インスペクション)
  • 構成管理
  • 定期ビルド
  • 進捗と成果の可視化

FDDの特徴はドメインモデル駆動型であること、そして比較的大きな開発チームであってもスケーラブルに機能することです。XPやスクラムとの違いは、
1.コミュニケーションにおいてドキュメントを比較的重視すること。情報の伝達は基本ドキュメントで行われます。
2.反復の期間が短いこと。例えばスクラムが2~4週間に対し、FDDは2~10日。
などがあげられます。

ページの先頭へ