ビジネスを取り巻く環境は、日々その変化のスピードを上げ複雑さを増し続けています。
特にIT関連のビジネスにおけるスピードと変化の速さ・複雑さは、あらゆる業界のなかでも顕著と言えるでしょう。
ユーザーのニーズも多様化し、またその移り変わりはあまりに素早く、世の中で流行っているサービスやトレンドは1年(あるいは半年や3ヵ月)も経てば大きく様変わりをする時代を迎えています。
そうした時代において、未来のニーズやトレンドを正確に予想して、それに対応するソフトウェアやサービスを開発することは極めて難しいことと言えます。
ニーズをとらえて企画を立案し、要求や要件を定義し、設計に取り掛かったころにはまた新たなニーズやトレンドが生まれていたり、あるいはその前提としていた状況に大きな変化が生じていたりすることは、現代において決して珍しいことではありません。
特にソフトウェア開発においては、このような環境の変化にも柔軟に対応できるよう、近年ではアジャイルソフトウェア開発(agile software development、以下アジャイル開発という)が採用されるケースが一般的となってきています。
本記事では、近年ますます多くの企業やプロジェクトで採用されることが増え、もはや一般的な開発手法の1つとなったアジャイル開発について、あらためてその定義から、概要や特徴、アジャイル開発の進め方やメリット・デメリットなどについてご紹介します。
なお、アジャイル開発手法の1つとして注目を集める「スクラム」については、以下のスクラムに関する連載記事で詳しくご紹介しています。宜しければ併せてご参照ください。
<スクラム連載記事一覧>
スクラムとは|スクラムの定義や特徴、体制とチーム内の役割
スクラムイベントとは|スクラムにおけるスプリントと4つのイベント
スクラムの3つの作成物|プロダクトバックログ、スプリントバックログ、インクリメントについて
アジャイル開発とは
アジャイル開発とは、顧客の満足を最優先し、顧客にとって価値のあるソフトウェアを素早く提供することを何よりも重視するソフトウェア開発手法の一つです。
そのために、アジャイル開発ではチームや顧客とのコミュニケーションや協力関係、変化に対応するための柔軟性を取り入れることを重要としています。
また具体的な手段として、要求・要件の定義から計画・設計・実装・テストといった一連の開発工程を比較的短期間で繰り返し、開発を進める中での学びや顧客・ユーザーからのフィードバックといったさまざまなインプットを得ながらプロダクトの完成度を上げていくというアプローチを採用しています。(この1連のサイクルは「イテレーション(反復)」や「スプリント」と呼ばれます)
アジャイル開発の大きな特徴のひとつに、短期間の開発を反復的に(イテレーティブに)繰り返すことにより、環境やニーズの変化、またそれらに対応するための要求や仕様の変更を行いやすいというメリットが挙げられます。
また、ウォーターフォール型開発と比べると、早い段階で顧客・ユーザーからフィードバックを得て開発に反映させることが可能なため、顧客にとってより価値のあるプロダクトの創出につなげやすいという特徴もあります。
関連記事:ウォーターフォール開発とは何か|メリットやデメリット、アジャイル開発との違いについて解説
「アジャイル開発」のアジャイル(Agile)には「素早い」「機敏な」「迅速な」という意味がありますが、その名称は変化の速い環境に合わせてソフトウェア開発においても機敏さや小回りを実現することを重視したことに由来しています。
アジャイル開発は、あらゆる変化のスピードが速まり、予測不可能性が高まりつつある現代や未来の環境に対応するために、ある種時代に要請される形で「必然的」に生まれたソフトウェア開発手法とも考えられるのではないでしょうか。
アジャイル開発は、すでに一般的な開発手法の一つとして広く活用されていますが、今もなお高い人気や関心を集めています。
以下のグラフは2021/2/26~2024/2/26のGoogleトレンドにおける「アジャイルソフトウェア開発」トピックの人気度の動向ですが、高い人気が継続していることが読み取れます。
出典:Googleトレンド アジャイルソフトウェア開発
アジャイル開発という概念を生んだ「アジャイルソフトウェア開発宣言」
アジャイル開発という概念が生まれたのは、今から約20年さかのぼる2001年になります。当時アメリカのユタ州に集った技術者たちによって議論され、その結果としてまとめられたのが「アジャイルソフトウェア開発宣言」と呼ばれる文書であり、これが公式にアジャイル開発を定義した文書であると一般的に考えられています。
「アジャイルソフトウェア開発宣言」の内容は、以下の通りです。
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。
この宣言では「個人との対話」「動くソフトウェア」「顧客との強調」「変化への対応」を重視すると述べられており、静的で形式的なソフトウェア開発ではなく、ダイナミックかつ実質的に顧客にとって価値のあるソフトウェア開発を志向しているということが読み取れます。
近年ではアジャイル開発は主流のソフトウェア開発手法の一つとなっていますが、それはここで宣言されている価値観が数々の事例を通じて実際に価値を生み出し、世の中に広く受け入れられてきたことの証左と言えるでしょう。
なお、「アジャイルソフトウェア開発宣言」の背後にある原則が記された「アジャイル宣言の背後にある原則」という文書もありますので、アジャイル開発に関わる方はぜひセットでご参照ください。
また、アジャイルソフトウェア開発宣言とその背後にある原則については、以下の記事で詳しくご紹介しています。宜しければこちらも併せてご参照ください。
アジャイルソフトウェア開発宣言と、その背後にある12の原則を読み解く
アジャイル開発の基本的な進め方の例
アジャイル開発にはスクラムやエクストリーム・プログラミング(XP)といったさまざまな開発手法がありますが、ここでは基本的なアジャイル開発の進め方の例についてご紹介します。(スクラムやエクストリーム・プログラミングについて、詳しくは後述します)
- 開発エンジニアやプロジェクトマネージャー、テストエンジニアなど、プロダクトを開発するのに必要なスキルを持った比較的小規模(10名以下など)の開発チームを組成します
※開発するプロダクトによってはデザイナーやライター、その他さまざまな役割が含まれることがあります - 開発対象の全体に対して、複数回の開発・リリースを通して完成させることを前提に、1~4週間程度の期間で完了できる規模に機能や業務を切り分けます
- 切り分けられた機能や業務に対して重要度に応じて優先順位をつけ、優先順位に従って作業に着手します
- 2で定めた期間内に、要求・要件の定義から計画・設計・実装・テスト・修正・レビューといった一連の作業を実施し、その時点で開発された範囲をリリースします
- リリース内容に対するフィードバック、開発のなかで得た気づきや学び、未開発の範囲などを総合的に検討し、次に着手する内容を検討し判断します
- 2~5を一連のサイクル(イテレーション)として繰り返しながら、徐々にプロダクトを完成に近づけていきます
アジャイル開発とウォーターフォール開発との違い
現在主流となっているソフトウェア開発手法は、本記事でご紹介しているアジャイル開発とウォーターフォール開発の2種類に大別されます。
では、アジャイル開発とウォーターフォール開発にはどのような違いがあるのでしょうか。
まず、アジャイル開発は上でも述べた通り、要求・要件の定義から計画・設計・実装・テストといった一連の開発工程を短く区切り、それらを何度も繰り返し適宜修正や改善を加えながら完成に近づけていくというアプローチを取ります。
一方でウォーターフォール開発は、その名の通り滝の水が上から下に流れるように、原則的に一連の各開発工程を上流工程から下流工程まで、段階的に完了させていくという開発手法です。
ウォーターフォール開発では、あらかじめ厳密に定義した要求や要件に対して、それらを満たすように忠実に設計・実装と各工程を進めていくことから、契約内容や責任範囲が明確になる、予算や人員の計画を立てやすいといったメリットがある一方で、上流にあたる要求や要件、設計にミスや変更があった場合の修正が難しく、プロジェクトの規模が大きい場合や工程が下流に進んでしまっていて手戻りが発生する場合などに、大きな時間やコストのロスが発生するというリスクもあります。
ゆえに、環境の変化が早く、要求や要件が短期間で変わり得るようなプロダクトや、あるいは計画段階で先の予測が難しく、開発を進めながら要求や要件の検討を深めていきたいプロジェクトなど、変化や適応を前提とした場合においては、ウォーターフォール開発よりもアジャイル開発が適していると言えます。
しかし一概にどちらの開発手法が優れているというわけではなく、上のように一長一短があることから、プロダクトやプロジェクトの特性に合わせてどの開発手法を採用すべきかを検討することが重要となります。
アジャイル開発のメリット・デメリット
ここまでアジャイル開発の概要や特徴、ウォーターフォール開発との違いなどについて、主にアジャイル開発の良い点に焦点を当ててご紹介をしてきましたが、もちろんアジャイル開発にもデメリットと言えるものが存在します。
そこで、こちらではアジャイル開発にはどのようなメリット・デメリットがあるのかをご紹介します。
アジャイル開発のメリット
アジャイル開発の紹介として上で述べた内容とも重複しますが、アジャイル開発は開発工程を短期間に区切って繰り返していくことから、開発側での臨機応変な対応を可能とします。そしてまた、アジャイル開発では実際に動くプロダクトが早いタイミングで作られることから、以下のようなメリットがあると考えられます。
- 早いタイミングで顧客やユーザーからのフィードバックが得られるので、よりタイムリーかつ高い精度でニーズに対応しやすい
- 開発工程の途中であっても要求や要件、仕様の変更や追加に対応しやすく、顧客にとってより価値が高いプロダクトを作るためのアプローチを取りやすい
- 要求や要件、仕様の漏れや間違い、認識のズレに早い段階で気づきやすく、コミュニケーションの改善や不具合の検出・修正を早い段階で実施でき、手戻りの抑止や軽減につながる
- 短い周期で一連の開発工程を繰り返すことから、開発チームやプロセス自体の課題の発見・解決機会が多く提供され、チームやプロセスの改善、成長を促進しやすい
アジャイル開発のデメリットと対策
一方で、アジャイル開発の柔軟性や短期間で開発を繰り返すというアプローチの裏返しとして、アジャイル開発には以下のようなデメリットが存在すると考えられます。
- 外部環境やユーザーニーズの変化に合わせてさまざまな変更を受け入れながら開発を進めていくことで、意図しない方向性のズレや、全体としての整合性が取れなくなるというリスクが生じやすい
- 要件や仕様単位で開発を進めるため、全体的なスケジュールの把握や管理が難しく、納期への影響が発生しやすい
上記で挙げたアジャイル開発のデメリットに対しては、以下のような対策が考えられます。
- 顧客やステークホルダーからの要求や、コミュニケーションを開発側でしっかりとコントロールし、柔軟性を保ちつつも対応すべきこと・対応すべきではないことを明確にしながら進める
- 「プロダクトを開発する理由」や「どのような価値を提供するのか」といった基本的な事柄(例えば、後述のスクラムにおけるプロダクトゴールなど)をあらかじめ定め、チームや関係者間で合意しておく
- プロダクトの難易度やチームの経験・スキルに合わせたバッファを事前に積んでおき、遅延のリスクを吸収する
アジャイル開発は柔軟で変化に強い一方で、その変化のしやすさゆえにコントロールが難しいという特徴をしっかりと意識した上で、プロジェクトおよびイテレーションの前・中・後において継続して対策・改善を続けることが重要と言えるでしょう。
アジャイル開発の手法
アジャイル開発に分類される開発手法にも、さまざまな手法があります。
こちらでは代表的なアジャイル開発の手法である、「スクラム」と「エクストリーム・プログラミング(XP)」について、簡単にご紹介します。
スクラム
スクラムとは、複雑な問題に対応する適応型のソリューションであり、外部の環境や、チームの学習や経験によって変化・改善をしながら、チームとして価値を生むための軽量級フレームワークです。
もともとはソフトウェア開発の手法として生み出されたものですが、その有用性や汎用性から、現在ではソフトウェア開発に限らずさまざまな領域で活用されています。
スクラムには「スクラムガイド」と呼ばれる公式ガイドが存在しており、基本的にはこのガイドで定義されたルールや価値観、チーム、イベントに従って進められますが、スクラムは上述の通り軽量級のフレームワークに過ぎず、「具体的にどうやるのか」といった詳細な方法論までは示されていません。
したがって、プロダクトや組織、チームのスキルなどの実態に合わせて、チームの全員が「どうすることが価値を生む上でベストなのか」を日々問い続けながら、開発を進めていくことになります。
スクラムのチームメンバーには各々が自律的に動くことが求められ、プロダクトのゴール設定やバックログの作成、それを実現するための反復的な短期間の開発工程(スプリント)の計画や実行、日々のミーティング、振り返りといったスクラムイベントをチームで繰り返しながら、プロダクトを完成に近づけていきます。
スクラムについては、詳しくは以下の記事でも解説していますので、宜しければ併せてご覧ください。
<スクラム連載記事一覧>
1. スクラムとは|スクラムの定義や特徴、体制とチーム内の役割
2. スクラムイベントとは|スクラムにおけるスプリントと4つのイベント
3. スクラムの3つの作成物|プロダクトバックログ、スプリントバックログ、インクリメントについて
エクストリーム・プログラミング(XP)
エクストリーム・プログラミング(XP)とは、開発に柔軟性を取り入れ環境やニーズの変化への対応を容易にし、顧客にとってより大きな価値を提供するための開発手法です。
スクラムと同様に、短期間で何度もリリースを繰り返しフィードバックを得ながら、生産性や品質の向上、ニーズへの対応を進めていきます。
XPの大きな特徴として、ソフトウェア開発をより良いものにするためにさまざまな価値や原則、プラクティスを定義しています。
ここではその一例として、「XPの5つの価値」について簡単にご紹介します。
コミュニケーション(Communication)
XPでは、コミュニケーションこそがチームによるソフトウェア開発において最も重要と位置付けています。
なぜならば、コミュニケーションはチーム内での情報や知識の共有において不可欠であり、またチームワークの醸成を促進します。そして多くの問題はコミュニケーションの欠如から発生するためです。
開発チームにおけるコミュニケーションはもちろんのこと、ユーザーとのコミュニケーションやフィードバックを重視するとしています。
シンプリシティ(Simplicity)
XPでは、最もシンプルな方法を好ましいものと考えます。
ここでいうシンプルとは「無駄な複雑性が排除された状態」を差しており、その状態を実現するために何ができるかという発想で考えることを重要としています。
フィードバック(Feedback)
状況は常に変化するという前提のもと、システムや顧客、チームらからのフィードバックを受けて常に改善し続けていくことを、XPでは重要な要素の一つとしています。
XPで短期間でのテストやリリースを行うのは、このフィードバックをできるだけ早く・できるだけ多く得るためと言えます。
勇気(Courage)
XPにおいて勇気とは、「恐怖に直面したときの効果的な行動」と定義されています。
時には急な変更への対応を迫られたり、あるいは既存の好ましくない方法を思い切って捨てる・変える必要があったり、また何らかの難しい問題に対して取り組む必要があるといった場合において、勇気をもって立ち向かうことが重要とされています。
リスペクト(Respect)
XPにおける上記の4つの価値は、根底にチームメンバーの相互のリスペクトがあってはじめて意味をなすとされています。
チームメンバーが互いに関心を持ち、その貢献を尊重しあう関係性がソフトウェア開発の品質や生産性にとって極めて重要であるとしています。
アジャイル開発におけるドキュメントの考え方
「アジャイル開発にはドキュメントが不要」というように言われることがありますが、アジャイル開発におけるドキュメントの考え方にはさまざまなものがあり、議論が分かれるポイントでもあります。
「アジャイルソフトウェア開発宣言」において「包括的なドキュメントよりも動くソフトウェアを」という一文があることから、アジャイル開発におけるドキュメントの優先度は動くソフトウェアを作ることに比べると高くないと捉えることもできますが、とはいえ「ドキュメントを無視して良い」と断言されているわけでもなく、あくまでも価値観や優先順位について語られているに過ぎません。
特に大規模かつ長期的な開発・運用を前提としたプロダクトにおいて、開発会社の変更や人の入れ替わりが想定されていたり、運用フェーズにおける追加開発を見込んでいたりする場合など、ドキュメントの不在により問題が発生することが容易に想像できるケースもあります。
誰も読まないような価値の無い形式的なドキュメントは作る必要が無い一方で、必要性が認められる価値のあるドキュメントについては、アジャイル開発であったとしても必要に応じて作成した方が良いと言えるのではないでしょうか。
さいごに
アジャイル開発は変化が激しく、また複雑さを増す現代に適したソフトウェア開発手法であるがゆえに、現在では主流の開発手法の一つとして多くの開発現場において採用されています。
しかしながら、本記事でもご紹介した通り、アジャイル開発には多くのメリットがある一方で、同時にデメリットも存在することには留意が必要です。
開発対象のプロダクトの特性や規模、あるいは開発の体制などにより、場合によっては従来のウォーターフォール開発や、その他の開発手法の方が適していることもあります。
そのため、それぞれの開発手法のメリット・デメリットを把握した上で、プロダクトや状況に応じて適切に選択することが大切です。
もし開発手法としてアジャイル開発を採用した場合は、その特徴である柔軟性を最大限に活かし、顧客に寄り添った開発をスピーディーに進めることや、継続的な成長・改善をはかりながら開発を進めるなど、その利点を価値に変える工夫や意識が重要となります。
スクラムもそうですが、基本的な概念や枠組みはシンプルでわかりやすい一方で、実際にやってみること、そしてそれを価値に結び付けることはとても難しく、一筋縄ではいきません。
アジャイル開発とは決して表面的な方法論ではなく、実際に開発の場に身を置いて自身もそこに参加するなかで初めて経験的に学べるものであり、むしろ「学び、成長し、改善していくこと」そのものがアジャイル開発の本質であるという見方もできるのではないでしょうか。
SHIFT ASIAについて
私たちSHIFT ASIAは、ソフトウェア品質保証・第三者検証のリーディングカンパニーである 株式会社SHIFT(プライム市場上場)の海外戦略拠点として、ベトナム・ホーチミンにてソフトウェアテスト事業を手掛けながら、近年はソフトウェア開発にも事業領域を拡大させてきました。長年に渡り培ってきた品質保証のナレッジとハイレベルなエンジニアの技術力を背景とした、高品質かつスピーディな開発をその特長としています。
アジャイル開発やスクラムを採用した多数の開発実績もございますので、ソフトウェア開発やテストでお困りのことがありましたら、ぜひお気軽にお問い合わせください。
お問い合わせContact
ご不明点やご相談などがありましたら、お気軽にお問い合わせください。