住友電工情報システム
ホーム > 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 Product Development Game」です。この論文は1980年代の日本の新製品開発プロセスについて述べたものであり、さまざまな専門性を持つ人がひとつのチームとして自立的に活動できる環境を与えられ、開発の最初から最後までを担当する。このようなチームを「スクラム」と呼びました。この「スクラム」はもちろん、ラグビーのスクラムから命名されました。

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

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

スクラムチーム

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

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

1.プロダクトオーナー

プロダクトオーナーはステークホルダー及び利用者の代表であり、そのプロジェクトの最高責任者であり、すべての決定を行うことができる最高権限者です。プロダクトオーナーはプロダクトのビジネス価値を最大化するために、プロダクトのビジョンを定義し、開発チームに浸透させます。従来のステークホルダーの代表者との最大の違いは、プロダクトオーナーはどっぷりとプロジェクトに入り込んで、他のステークホルダーや利用者と連絡をとりながら、プロダクトの価値が最大化するように、常に、プロダクトバックログへの開発項目の追加・変更、優先順位の再構成を行っていることです。

プロダクトオーナーは開発チームとステークホルダーとのHUBであり、そのため、プロダクトオーナーに最も求められるのは高度なコミュニケーション能力です。なお、プロダクトオーナーはステークホルダーの立場でプロダクトをビジネス価値の観点のみから判断する必要があります。従って、実際に開発を行うスクラムマスターなどとの兼任は認められません。

2.開発チーム

スクラムにおける開発チームはスクラムマスターを含まず4名から9名がいいとされています。9名より多くなると、さまざまな調整が複雑になり過ぎるのです。一方、3名より少ないと開発者同士の相互作用による生産性向上が期待できず、また、プロダクトバックログを完遂するための専門技術がそろわない恐れも出てきます。開発チームは各スプリントにおいて、リリース判断可能なプロダクトバックログの成果物を完成させることが使命であり、逆にそれができるのは開発チームだけです。開発チームはこれを完遂するための知識や技術をチーム内に備えていなければならず、機能横断的でなければなりません。また、作業を完遂するための方法をすべて開発チーム内で決定できる自己組織的であることも要求されます。

3.スクラムマスター

スクラムマスターはスクラムチームのパフォーマンスを最大化するために、スクラムの価値、理論、プラクティス、ルールに精通し、プロダクトオーナーと開発チームを支援する役割を持ちます。例えば、プロダクトオーナーを支援し、スクラムチームの全員がプロジェクトのビジョン、ゴールを理解できるようにしたり、プロダクトバックログを適切に管理し、優先付をしやすいようにしたりします。また、開発チームに対しては、スクラムの教育、自己組織化、機能横断的な開発チームのコーチング、進捗の障害となるものの排除などの支援を実施します。このように、スクラムマスターはスクラムチームのメンバーが成果を上げるために側方から支援する役割を担います。

スクラムのイベント

スクラムでは反復的に開発を進めますが、その反復の単位、タイムボックスを「スプリント」と呼びます。通常1つのスプリントは1か月以内で設定されます。スプリントが長すぎると成果物(インクリメント)の仕様が変わったり、成果物が追加されたり、複雑になるなどのリスクが増大します。せいぜい1か月程度が予測可能で制御しやすいのです。

それぞれのスプリントは下記のイベント(作業)で構成されます。

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

1.スプリントプランニング

スプリントプランニングはスプリントの最初に行う作業です。1か月のスプリントでは最大8時間程度、短いスプリントではもっと短い時間で済ませます。スプリントプランニングでは、まず、このスプリントでリリースすべき成果物を予定します。インプットはプロダクトバックログ、以前のスプリントの最新の成果物、これまでの開発チームの開発実績、開発能力などです。

そして、リリースすべき成果物をスプリントゴールとして設定します。次に、スプリントゴールを達成するために必要な作業や方法を検討します。このスプリントゴールの成果物とそれに必要な作業を合わせてスプリントバックログと呼びます。

2.デイリースクラム

デイリースクラムとは毎日実施する15分程度の開発チームのミーティングです。開発チームはデイリースクラムでスプリントバックログの進捗の確認や、今日やるべきことの確認、問題点の共有などを行います。スクラムマスターはデイリースクラムを開催すること、15分のタイムボックスで済ませることを指導しますが、具体的な運営方法は自己組織化された開発チームに委ねられます。デイリースクラムは開発チームのコミュニケーションを改善し、余分なミーティングを省き、問題点の早期共有と迅速な意思決定を行うための重要なイベントです。

3.スプリントレビュー

スプリントレビューとは、各スプリントの終了後に開発チームとプロダクトオーナー、そしてステークホルダーとで行うレビューミーティングです。時間は1か月のスプリントの場合で最大4時間です。プロダクトオーナーは、そのスプリントの進捗状況、すなわち、当該スプリントにおけるプロダクトバックログの消化状況や、残ったプロダクトバックログから完成見込日の予想を行います。開発チームは成果物(インクリメント)や遭遇した問題点、その解決方法の説明を行います。

さらに、最新の状況から、プロダクトバックログの更新、優先順位変更などを実施し、次のスプリントでリリースする成果物をレビューします。スプリントレビューの最終成果物は次のスプリントに向けての改訂されたプロダクトバックログです。

4.スプリントレトロスペクティブ

スプリントレトロスペクティブとはスプリントレビュー終了から次のスプリントが始まるまでに実施する当該スプリントの反省会であり、スクラムチームをよりよくする改善計画を作成する機会です。時間は1か月のスプリントの場合で最大3時間です。スクラムマスターは次のスプリントをより効果的で楽しいものにするために、生産的でポジティブな議論をするように働きかけなければなりません。人、人間関係、開発ツールそれぞれの観点から、うまくいった点、改善すべき点を検査し、スクラムチームの改善計画を作成します。

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

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

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のプラクティス

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

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

1.ペアプログラミング(Pair Programing)

ペアプログラミングとは、2名のプログラマーがひとつのワークステーション上で、共同でプログラミングを行うプログラミング技術です。ひとりがコードを書き、コードが打ち込まれるたびにもうひとりがレビューします。XPにおいて最も短時間でのフィードバックを得られるプラクティスです。コードを書く担当者は目の前のコーディングに集中できる一方、レビューワは目の前のコードだけでなくもう少し広い視点からコードを見渡します。2名はかわるがわる役割を交代します。

ペアプログラミングの主な利点としては、2名が違う視点から同じコードを見るためコードの設計品質が向上しバグも少なくなること、ペアをさまざまに入れ替えることでコードの共有が進みチームの一体感が生まれやすくなること、また、初心者にとっては大きな教育的な効果が見込めること、2名で実施するので楽しく集中力が持続することなどが挙げられます。

2.計画ゲーム(Planning Game)

計画ゲームとは、顧客と開発チームがプロジェクト計画において、実装する機能、その優先度、それぞれにかかる工数、そして開発手順を、ゲームのように定められた役割、手順のルールに従って計画し、さらにその計画を運用していくことです。計画ゲームは大きくリリース計画とイテレーション計画に分けられます。それぞれの計画ゲームでは次のような手順で作業を進めていきます。

リリース計画は顧客と開発チームが参加し、開発する機能と期日を合意するものです。まず、顧客が必要な機能をストーリーカードに書き込みます(ユーザストーリー)。次に、開発チームがそれぞれのユーザストーリーの開発にかかる期間を書き込みます。そして、最も複雑なものを特定します。見積もることができない場合は、ユーザストーリーを書き直すことも検討します。見積もりが出そろえば、顧客がそれぞれのユーザストーリーを優先度別に3つに分類します。一方、開発チームはユーザストーリーを開発リスク別に3つに分類します。それらを考慮しながら、次のリリース期日とリリースするユーザストーリーを顧客と開発チームで合意します。

イテレーション計画は開発チームがユーザストーリーを開発するために、各プログラマーへの作業分担を行うものです。まず、ユーザストーリーをタスクに分割しタスクカードに書き込みます。作業性を考慮してタスクの結合・分割を実施した後に、各タスクにかかる期間を見積もります。次に、タスクカードをプログラマーに割り振り、各プログラマー自身がタスクにかかる期間を見積もります。そして、プログラマー毎のイテレーション期間の作業量を集計して、必要に応じて負荷調整を行います。開発フェーズではプログラマーはタスクカードをとり、テスト駆動開発やペアプログラミングをしながらタスクを消化していきます。

3.テスト駆動開発(TDD Test Driven Development)

テスト駆動開発は要求機能をまず小さな単位の具体的なテスト項目に書き下します。要求をテスト仕様で表すのです。そして、その個々のテストをクリアするようにプログラムを作成していきます。この際、テスト自動化を同時に行うことで、イテレーションによるテスト工数の増加を抑制し、コードの劣化を防ぎます。単体テスト自動化ツールとしてはJavaであればJUnitが有名です。最初に書くのはテストコードです。もちろん最初は、プログラムコードが未完成なのでテストはクリアできませんが、テストをクリアできるようプログラミングを進めます。すべてのテストをクリアした後に、必要であればプログラム全体を見直しコードのリファクタリングを行います。

テスト駆動開発は要求仕様を具体的かつ細分化されたテスト項目で表すことにより、プログラムの達成すべき機能を明確にし、余計な機能を実装せずコードをシンプルに保つことができるとされています。

4.継続的インテグレーション(CI Continues Integration)

継続的インテグレーションとは、プログラマーの開発したプログラムのビルドや単体テストを頻繁に実施し、短いサイクルでシステムを結合してテストを実施し続ける開発手法です。短いサイクルで結合テストまで実施できるため、早期に不具合を発見して修正でき、修正コストを抑えることができるとされています。継続的インテグレーションを実現するためには、手作業では難しく、自動ビルドツール、自動テストツールなどのツールあるいはサービス利用が前提となります。

5.コードリファクタリング

コードリファクタリングとは一旦完成したプログラムを、外からの挙動は変えないで、内部構造の改善をすることです。リファクタリングの目的は、コードをきれいに見やすく、論理的な構造にすることであり、機能、性能の改善は含まれません。XPなどのアジャイル開発では漸進的なシステム開発を実施し、プログラムをテスト駆動で開発するため、最初から無駄のない完璧なプログラムコードを目指すのではなく、まずはテストをクリアするところから初めて徐々に改善していく文化があります。一方、ドキュメントを極力作らないアジャイル開発では、ソースコードの可読性が高いことやプログラムコードがシンプルに保たれていることは、プログラムを維持・改善していく上で非常に重要な要件です。このような理由でコードリファクタリングはXPでは不可欠な作業となっています。

コードリファクタリングの具体的項目としては、まずはコーディング標準の順守であり、適切なネーミングやコメントでコードの可読性を向上させることです。また、抽象化レベルを適切に保ち、重複したコードの排除などを行うこと、さらには、大きすぎるメソッドやクラスを分割し、シンプルで汎用性が高く、テストしやすい構造に変更することなどが含まれます。きれいなコードは品質を保ちやすく、維持改善も簡単でコストを抑えることができるのです。

6.システムメタファー

システムメタファーとは、そのシステムがどのように動作するのかを、すべてのメンバー、すなわち、プログラマー、顧客、管理者が、感覚的に理解できる比喩表現です。ネーミングや簡単な表現で、システムの挙動を即座に理解できる言葉をチームで共有することは、チーム内でのコミュニケーションや相互理解につながり、システムのビジョンの共有も容易になります。さらに、適切なメタファーを考えるプロセス自身が、新たな発想やこれまで見えなかった問題点の抽出につながることもあるのです。

ASD(Adaptive Software Development)

ASD

ASDとは

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

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

ASDの3つの主要なイベント

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

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

1.スペキュレーション

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

2.コラボレーション

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

3.ラーニング

ラーニングでは、品質レビューを行います。品質レビューには主に①成果物に対する顧客観点からのフィードバック、②成果物に対する技術観点からのフィードバック、③チーム運営に対する観点からのフィードバック、④プロジェクトのあり方の観点からのフィードバックがあります。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とは

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.全体を最適化する

1.ムダを省く

ムダを省くことはLSDのもっとも重要な要素です。ソフトウェア開発でのムダとは顧客に価値をもたらさないすべてのものです。リーン哲学では7つのムダを次にように分類しています。

  1. (1)在庫のムダ
  2. (2)作り過ぎのムダ
  3. (3)加工のムダ
  4. (4)動作のムダ
  5. (5)運搬のムダ
  6. (6)手待ちのムダ
  7. (7)不良のムダ

メアリー&トム・ポッペンディーク夫妻はこれらの7つのムダをソフトウェア開発に置き換えて次にように対応させました。

  1. (1)完成していない作業
  2. (2)使われないコードや余分な機能
  3. (3)余分な作業
  4. (4)タスクの引継ぎ
  5. (5)手渡し
  6. (6)ソフトウェア開発の遅れ
  7. (7)不具合や品質問題

LSDでは上記のような顧客に価値を生まないソフトウェア開発プロセスのムダを徹底的に取り除くことを目指します。

2.品質を作り込む

ソフトウェアの欠陥は発見が遅れれば遅れるほど影響範囲が大きくなり、改修コストも大きくなります。LSDでは欠陥をソフトウェアリリース直前の最終テストの段階で見つけるのではなく、開発工程のできるだけ早い段階で発見することによって品質を保証します。そのための手段として、ペアプログラミング、テスト駆動開発や継続的インテグレーション等が推奨されます。また、欠陥を発見するだけでなく欠陥を作り込まない、欠陥が混入しにくいように工夫することも重要です。例えば、コードリファクタリングなどで、機能やコードをムダのないシンプルなものに保つことも効果的です。

3.知識を作り出す

LSDのようなアジャイル開発では、当初計画通りに開発が進むとは限りません。むしろ、計画の変更を受入れ、機敏に対応するのがアジャイル開発です。そのため、開発チームは開発プロセスを通して学び続け、常に新しい知識を作り出す必要があります。顧客や他のチームメンバーからの新しい知識をできるだけ早く得るために、機能をシンプルにして、コードを書いて、すばやくリリースしてフィードバックをもらいます。知識獲得のスピードをあげるためには、イテレーションをすばやく回してより多くのフィードバックを得られるようにします。

4.決定を遅らせる

ソフトウェア開発、特にアジャイル開発では、重要な決定を早めに行って計画してもその後の状況変化によって、決定を変更した方がよい場合が発生します。決定はできるだけ事実に基づいて下した方が確実なので、遅らせられるなら遅らせた方がアジャイルな対応が可能になります。ただし、決定を遅らせるというのは決して問題を先送りすることではありません。開発チームは予め顧客に選択可能ないくつかの提案をし、その選択をぎりぎりまで遅らせられるように工夫するのです。

これにより、より顧客のニーズによりフィットした価値の高い機能をリリースすることができます。決定を遅らせられるように、ソフトウェアアーキテクチャーとしても、機能選択や機能変更をやりやすいようなものにしておくことが望まれます。

5.早く提供する

顧客にできるだけすばやくソフトウェアをリリースしてフィードバックをもらいます。フィードバックを早期に獲得する重要性は前述した通りです。そもそも、開発チームのメンバーは誰しもすばやくリリースしたいと考えているので、留意すべきはすばやいリリースを阻害する要因です。例えば、将来の必要になるかもしれない要件まで深く考えすぎる、要件に対するオーバースペック、必要な回答を素早く返さない顧客などです。ただし、早くリリースするために夜遅くまで働き、休日を返上する必要はありません。シンプルな解決方法を顧客に提示し、少しずつ改善し、フィードバックをもらいながら進めることが重要です。

6.人を尊重する

人を尊重するとは、ひとつはチームメンバーの話を注意深く聞き、意見に耳を傾け、たとえ自分と考えが違っていてもチームから外したりしないことです。チームメンバーが発言しやすい雰囲気を作り、彼らの考え方を理解し共感しようと努力することです。開発メンバーひとりひとりを尊重すべき人間として接することが極めて重要です。

そして、もうひとつは権限委譲です。マネージャーが個々人を細かく管理するのではなく、やり方をチームに任せます。最も仕事の内容を理解しているのはマネージャーではなく、その仕事を担当しているチームメンバーなのです。チームメンバーが創造性を発揮し、発言しやすい雰囲気の中で議論を戦わせる中でこそ、チームでしか成し遂げられない成果を得ることができるのです。

7.全体を最適化する

開発チームはしばしば個別最適化に陥ってしまします。例えば、顧客から新しい機能を早くリリースするよう要求され、開発チームは何としても間に合わせなければと考えます。すばやくテストをクリアするためにプログラムコードの記述がだらしなく冗長になります。その結果、プログラムの内部構造が徐々に複雑になり、欠陥が増加します。欠陥が増加するとその改修という仕事が増えていきます。さらに、間に合わせねばというプレッシャーが強くなる悪循環に陥ります。

また、例えば、テスターの業務負荷が増大すると、開発者がコードを書いてからテスト結果のフィードバック得るまでの時間が長くなります。そうすると、フィードバックを得られない開発者はそのまま品質に疑いのあるコードを書き続けます。その結果、欠陥が増加してしまいます。

個別の開発工程を最適化するのではなく、開発工程全体を最適化するというのがLSDの考え方です。これは元々、製造業におけるバリューフローの考え方に基づいています。すなわち、設計、製造、販売、サービス提供など一連の価値の流れ全体を見渡して、顧客にすばやく価値を届けるためにフローを最適化するのです。

アジャイルモデリング(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)

アジャイルモデリングのコアプラクティスは下記の通りです

  1. 1.アクティブステークホルダーの参画(Active Stakeholder Participation)
  2. 2.アーキテクチャーの明確化(Architecture Envisioning)
  3. 3.継続的なドキュメンテーション(Document Continuously)
  4. 4.ドキュメントは後回し(Document Late)
  5. 5.動く仕様(Executable Specifications)
  6. 6.反復モデリング(Iteration Modeling)
  7. 7.ぎりぎりで十分(Just Barely Good Enough)
  8. 8.先読みモデリング(Look Ahead Modeling)
  9. 9.モデルストーミング(Model Storming)
  10. 10.複数のモデル(Multiple Models)
  11. 11.優先づけされた要求(Prioritized Requirements.)
  12. 12.要求の共有、見える化(Requirements Envisioning)
  13. 13.シングルモデル(Single Source Information)
  14. 14.テスト駆動設計(Test-Driven Design(TDD))
アジャイルモデリングのベストプラクティス

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

クリスタル・クリアとは

クリスタル・クリアは1998年にIBMのアリスター・コーバーン(Alistair Cockburn)が考案したソフトウェア開発手法「クリスタルファミリー」のひとつです。アリスター・コーバーンは、プロジェクトの特徴、すなわち規模やそのシステムが社会に及ぼす影響などにより開発プロセスを使い分けるべきと考えました。アリスター・コーバーンはシステム開発の領域を、開発チームの人員数とシステムトラブル時の影響度のマトリックスで分類しました。トラブル時の影響度は4段階、①人の命にかかわる、②会社存続に必要なお金を失う、③自由裁量のお金を失う、④快適さを失うに分類されています。開発チームの人員は下記のように区切られています。

  1. 1.クリスタル・クリア  1~6名
  2. 2.クリスタル・イエロー 7~20名
  3. 3.クリスタル・オレンジ 21~40名
  4. 4.クリスタル・レッド  41~80名
  5. 5.クリスタル・マローン 81~200名

クリスタル・クリアはその中で最も軽量なアジャイル開発プロセスで、6名以下の開発チームで人命に関わらないようなプロジェクトが対象です。チームメンバーは同じ部屋で直接コミュニケーションをとりながら作業することが前提となっています。チームはスポンサー、シニアデザイナー、プログラマーから役割構成されますが、最も重要な役割はシニアデザイナーです。

シニアデザイナーは技術面のすべての判断ができなければなりません。プロジェクトマネージャー、テスター、ビジネス分析などは他のメンバーが分担して行います。イテレーション期間は通常2~3か月程度。ドキュメンテーションは最小限にとどめます。

クリスタルファミリーの7つのプロパティ

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

クリスタルファミリーの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とは

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

FDDの活動

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

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

1.全体モデル開発

全体モデル開発の成果物は、対象となるドメイン全体のオブジェクトモデルです。まず、モデルリングチームを作成し、そのシステム領域のドメインエキスパートによるウォークスルーを実施します。モデリングチームはドメインの理解を深めながら、小さなドメイン領域に分割してオブジェクトモデルを作成します。このオブジェクトモデルをベースに議論し確定させてから、それらをいくつか結合させて分野別のオブジェクトモデルを作成します。さらにそれらを結合させて、最終的にはドメイン全体のオブジェクトモデルを作成します。

2.フィーチャーリストの構築

フィーチャーリスト作成チームを結成し、全体モデルから小さな機能を切り出してフィーチャーリストを作成します。ここで言うフィーチャー(Feature)とは、顧客視点の十分小さな単位の機能、価値であって、<action>、<result>、<object>という様式で記述します。この様式を使うということは、必ず利用者の操作と実装すべきオブジェクトを指定することを意味します。

フィーチャーは例えば、「売上金額合計を計算する」だとか「パスワードを検査する」などの単純な機能で、せいぜい2週間以内で開発できるものです。それ以上かかるようなフィーチャーは2週間以内になるように分割します。このように、フィーチャーを小さな粒度にすることによって、顧客がプロジェクトの規模や進捗を容易に測定できます。また、短い期間でフィーチャーが実装されるので素早いフィードバックが可能になるのです。

3.フィーチャー毎の計画

ここではプロジェクトマネージャー、開発マネージャー、及びチーフプログラマーが開発するフィーチャーの順番を決め、フィーチャーを実装先のクラスを担当する開発者に割り当てます。開発の順番や割り当ては、フィーチャーの依存関係や開発チームの負荷状況、フィーチャーの複雑さなどを考慮して決定します。

4.フィーチャー毎の設計

チーフプログラマーは担当するフィーチャーから一度に開発する分をいくつか選択してそれらをパッケージとします。そして、開発者からフィーチャーを実装先であるクラスのオーナーを選んでフィーチャーチームを作成します。対象となるフィーチャーのウォークスルーを実施し、ドキュメントを確認します。チーフプログラマーはフィーチャーのシーケンス図を作成し、それを基にオブジェクトモデルを更新します。開発者がクラスとメソッドの概要を書き、設計のインスペクションを実施します。

5.フィーチャー毎の構築

フィーチャーの実装を割り当てられたクラスオーナである開発者は、プログラムコードを書き、単体テストやコードインスペクションを実施します。

FDDのプラクティス

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

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

FDDの特徴

FDDの特徴は、ひとつは、ドメインモデル駆動型であることです。FDDではドメインの問題を非常に小さな単位、せいぜい2週間で開発可能な単位、まで細分化します。小さくすることで、問題の解決を容易にし、コミュニケーションも簡単になります。

そしてもうひとつは、比較的大きな開発チームであってもスケーラブルに機能することです。XPやスクラム等の他のアジャイル開発プロセスとの違いは、

  •  1.コミュニケーションにおいてドキュメントを比較的重視すること。情報の伝達は基本ドキュメントで行われます。
  •  2.反復の期間が短いこと。例えばスクラムが2~4週間に対し、FDDは2~10日。
などがあげられます。

ページの先頭へ