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

日本で本格的に普及が始まりつつあるアジャイル開発の意味や歴史、メリットとデメリット、そして課題について説明します。さらに8種類の代表的なアジャイル開発手法を紹介します。

アジャイル開発(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つの主な価値に関して共通認識を得て、それをアジャイルソフトウェア開発宣言として公開しました。

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

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

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

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

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

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

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

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

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

ウォーターフォール・モデルとの違い

アジャイル開発の特徴を理解するために、アジャイル開発と対局に位置するウォーターフォール・モデルと比較してみましょう。

ウォーターフォール・モデルとは、システム開発を、例えば「要件定義」、「外部設計」、「内部設計」、「プログラム設計」、「プログラミング」、「統合テスト」、「システムテスト」という工程に分割して、上流から下流へ水が流れるように後戻りすることなく開発する手法です。

ウォーターフォール・モデルでは要件定義でシステム開発の要件が決定すれば、それを正しいものとして必要な開発要員や開発期間などを積み上げて、開発計画を立てます。各工程を別のチームが担当することも多く、場合によっては別の会社が引き継ぎます。

各工程の引き継ぎはドキュメントによって行われます。従って、相当量のドキュメントを作成することが求められます。各工程を担当するチームがQCD(Quality Cost Delivery、品質、納期、コスト)をコミットすることで、大規模なシステム開発を工程毎に分業して、計画的に進めることができます。

ウォーターフォール・モデルは計画重視の開発手法です。最大のメリットは、大規模開発においても、要件定義を前提に予算、スケジュール、開発人員など緻密な計画が立てられることです。また、ウォーターフォール・モデルは上流で定義した最終成果物に対して対価を設定する開発請負契約に向いています。

ウォーターフォール・モデルの最大の弱点は、要件の変更に弱いことです。開発途中で業務的、あるいは技術的によりよい方法が見つかっても、当初の計画を変更することは容易ではありません。計画を変更すると、多くの他チームの工程に影響を与えてしまうからです。場合によっては契約内容の変更も必要です。

また、ウォーターフォール・モデルでは、利用者が成果物を確認するのが総合テストなど最後の工程になることが多く、要件定義の不備や不足が露見するのが遅くなります。このため、要件定義に利用者が積極的に関与していないようなプロジェクトでは、開発の最後の段階で成果物が業務に適用できないことが判明するような大きなリスクを抱えることになります。

一方、アジャイル開発は開発途中で要件が変わることを前提としています。ウォーターフォール・モデルのように当初計画したものを計画通りに開発することが目的ではなく、限られた時間とコストの中でより価値の高いソフトウェアを生み出すことを目的としているからです。

そのため、開発チームにはソフトウェアのビジネス価値を判断できる利用部門の代表が参画します。そして開発は10名程度の小規模なチームで設計からリリースまで一貫して行います。小規模なチームで価値や仕様を共有することで、ドキュメントは最小限、短い期間でプログラムをリリースして、動くプログラムで利用部門の確認をとります。

よりよい方法が見つかれば、利用部門の代表が判断して、次の反復(Iteration)で対応します。このように逐一要求と成果物を評価することで、要件変更のリスクを最小化することができます。

アジャイル開発では納期までに当初計画した機能をすべて実装することよりも、全体として最も価値の高いアウトプットとなるように計画の変更を積極的に受け入れます。

アジャイル開発のメリットとデメリット

アジャイル開発はウォーターフォール・モデルに代表される計画重視型・重量開発手法のアンチテーゼとして考え出されました。

最大のメリットは前述の通り要件変更に強いことです。プロジェクト開始時に業務要件が詰め切れないようなシステムや、技術変化が激しく、プロジェクトの途中でも新たな方法が現れる可能性のあるシステムは、開発途中で仕様変更が発生する可能性が高くなります。

アジャイル開発であれば、実際に動くプログラムを逐一確認しながら開発を進められるので、大きな乖離にあとで気が付くリスクを最小限に抑えられます。例えば、UI/UXを重視するスマートフォンを使ったアプリ開発などでは、利用者は実際に動くものを見て確認するのが一番です。臨機応変に対応することでソフトウェアのビジネス価値を最大化することが可能です。

もうひとつの大きなメリットはモチベーション向上とチームの成長です。作業が細分化されているウォーターフォール・モデルとは異なり、アジャイル開発では、チーム全員が開発するシステムのビジネス価値を共有し、ビジネス価値が最大になるように工夫しながら、設計からリリースまで責任を持って開発します。

チームは同じ場所でフェイス トゥ フェイスのコミュニケーションを主体に、お互いを尊重しながら開発を進めます。チームの成長はアジャイル開発の重要な要素です。このような環境での開発が、モチベーションを向上させチームや開発者の成長を促すと言われています。

一方、デメリットは何でしょうか。

アジャイル開発のデメリットは、改善を繰り返すことで、全機能の開発が終わらず納期が守れないリスクがあることや、そもそも進捗状況が把握しにくいことがあげられます。計画重視のウォーターフォール・モデルに比べてプロジェクト計画のコントロールが難しいのです。

また、アジャイル開発ではビジネス価値を最大にすべく、ITの専門家とは限らない利用部門の要求に応じて、個々のアプリケーションの改善を繰り返しますが、要求が正しいとは限りません。プロジェクト全体を俯瞰できる者がいなければ、当初の方針や目的から機能が大きくブレたり、全体整合性が取れなくなる恐れがあります。

アジャイル開発の課題

現在の日本でアジャイル開発を実施する上で大きな課題は、アジャイル開発のための環境が十分整っていないことです。日本でもようやくアジャイル開発が普及し始めましたが、エンタープライズ分野の大規模システム開発ではまだまだウォーターフォール・モデルが主流です。その最大の理由は契約と開発体制です。

エンタープライズ分野のシステム開発においては、通常、利用部門は要件定義が完了すれば、その後はシステムテストまでは開発に参画しません。要件定義で約束した成果物に対して納期と費用を確定させてソフトウェア開発契約を結ぶのです。このような成果物固定の契約にアジャイル開発は向いていません。一方、成果物を固定させない契約は予算が確定せず締結しにくいのが実情です。

また、アジャイル開発を実施しようとすると、利用部門が主体的に開発チームに参画しなければなりません。利用部門が随時ソフトウェアにかかるコストとビジネス価値を評価しながらブレないように舵を取らねばならないのです。利用部門の参画が中途半端な体制でアジャイル開発を実施すると、当初予定していた成果物が納期通りにはできないだけでなく、成果物が当初のビジネス目的とずれてしまう可能性があります。しかしながら、利用部門から開発チームをリードできる人材を拠出することは難しいのが実情です。

一方、IT技術者側も分業が進み、プログラミングができない上級SEや上流設計ができないプログラマーも多く、アジャイル開発で必要な設計からプログラミングまですべてできる人材をそろえるのも簡単ではありません。アジャイル開発チームを構成することに高いハードルがあるのです。

このような理由で、日本のエンタープライズ分野の開発ではアジャイル開発の普及が遅れています。ただし、利用者と開発者が一体となっているような開発、自分たちの製品やサービスの開発を自身で行うような開発は、日本でもアジャイル開発が当たり前になりつつあります。最近では大規模な開発をアジャイル開発で実施する事例も増加しており、環境は徐々に変化していくでしょう。

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

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

スクラム(Scrum)

スクラムとは

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

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

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

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

スクラムチーム

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

1．プロダクトオーナー

プロダクトオーナーはステークホルダー及び利用者の代表であり、そのプロジェクトの最高責任者であり、すべての決定を行うことができる最高権限者です。プロダクトオーナーはプロダクトのビジネス価値を最大化するために、プロダクトのビジョンを定義し、開発チームに浸透させます。

従来のステークホルダーの代表者との最大の違いは、プロダクトオーナーはどっぷりとプロジェクトに入り込んで、他のステークホルダーや利用者と連絡をとりながら、プロダクトの価値が最大化するように、常に、プロダクトバックログへの開発項目の追加・変更、優先順位の再構成を行っていることです。プロダクトオーナーは開発チームとステークホルダーとのHUBであり、そのため、プロダクトオーナーに最も求められるのは高度なコミュニケーション能力です。

なお、プロダクトオーナーはステークホルダーの立場でプロダクトをビジネス価値の観点のみから判断する必要があります。従って、実際に開発を行うスクラムマスターなどとの兼任は認められません。

2．開発チーム

スクラムにおける開発チームはスクラムマスターを含まず4名から9名がいいとされています。9名より多くなると、さまざまな調整が複雑になり過ぎるのです。一方、3名より少ないと開発者同士の相互作用による生産性向上が期待できず、また、プロダクトバックログを完遂するための専門技術がそろわない恐れも出てきます。

開発チームは各スプリントにおいて、リリース判断可能なプロダクトバックログの成果物を完成させることが使命であり、逆にそれができるのは開発チームだけです。開発チームはこれを完遂するための知識や技術をチーム内に備えていなければならず、機能横断的でなければなりません。また、作業を完遂するための方法をすべて開発チーム内で決定できる自己組織的であることも要求されます。

3．スクラムマスター

スクラムマスターはスクラムチームのパフォーマンスを最大化するために、スクラムの価値、理論、プラクティス、ルールに精通し、プロダクトオーナーと開発チームを支援する役割を持ちます。例えば、プロダクトオーナーを支援し、スクラムチームの全員がプロジェクトのビジョン、ゴールを理解できるようにしたり、プロダクトバックログを適切に管理し、優先付をしやすいようにしたりします。

また、開発チームに対しては、スクラムの教育、自己組織化、機能横断的な開発チームのコーチング、進捗の障害となるものの排除などの支援を実施します。このように、スクラムマスターはスクラムチームのメンバーが成果を上げるために側方から支援する役割を担います。

スクラムのイベント

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

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

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

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

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

2．デイリースクラム

デイリースクラムとは毎日実施する15分程度の開発チームのミーティングです。開発チームはデイリースクラムでスプリントバックログの進捗の確認や、今日やるべきことの確認、問題点の共有などを行います。スクラムマスターはデイリースクラムを開催すること、15分のタイムボックスで済ませることを指導しますが、具体的な運営方法は自己組織化された開発チームに委ねられます。

デイリースクラムは開発チームのコミュニケーションを改善し、余分なミーティングを省き、問題点の早期共有と迅速な意思決定を行うための重要なイベントです。

3．スプリントレビュー

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

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

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

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

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

XPとは

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

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

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

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

XPのプラクティス

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

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

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

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

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

1．スペキュレーション

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

2．コラボレーション

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

3．ラーニング

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

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

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つの原則に沿っていると認められた場合、それを「リーン」と呼ぶことができるのです。

1．ムダを省く

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

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

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

1. 完成していない作業
2. 使われないコードや余分な機能
3. 余分な作業
4. タスクの引継ぎ
5. 手渡し
6. ソフトウェア開発の遅れ
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やスクラムなどの他のアジャイル開発プロセスと組み合わせて適用する必要があります。

また、アジャイルモデリングはモデリングのための、価値、原則、プラクティスを集めたものであって、ある種類のモデルを作成するための手順を定義したものではありません。モデリング担当者が効果的に仕事をするにはどうすればよいかについてのアドバイスです。

例えば、主要なプラクティスでは、モデルは「中身をシンプルにし」、「シンプルに描き」、「少しずつモデリング」する。すなわち、目的がはっきりしたモデルを作成し、余分なものはモデルにしないようにします。また、「適切な成果物を使う」、「他の成果物に移る」、「複数のモデルを並行してつくる」、「他の人々といっしょにモデリングする」、「コードで確かめる」、「テストできるか考える」により、有効性の高いモデルを作成することを目指します。

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

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

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

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

クリスタル・クリアとは

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

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

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

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

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

DSDM(Dynamic System Development Methodology)

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

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

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

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

等があげられます。

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

FDDとは

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

FDDの活動

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

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

1．全体モデル開発

全体モデル開発の成果物は、対象となるドメイン全体のオブジェクトモデルです。まず、モデルリングチームを作成し、そのシステム領域のドメインエキスパートによるウォークスルーを実施します。モデリングチームはドメインの理解を深めながら、小さなドメイン領域に分割してオブジェクトモデルを作成します。

このオブジェクトモデルをベースに議論し確定させてから、それらをいくつか結合させて分野別のオブジェクトモデルを作成します。さらにそれらを結合させて、最終的にはドメイン全体のオブジェクトモデルを作成します。

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

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

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

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

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

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

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

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

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

FDDのプラクティス

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

FDDの特徴

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

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

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

などがあげられます。

参考文献、参考URL

アジャイルソフトウェア開発宣言：
https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェアの背後にある原則：
https://agilemanifesto.org/iso/ja/principles.html

Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation：
http://agilemodeling.com/