アジャイル開発という言葉を聞いたことがある人も多いと思う。「アジャイル」とは日本語にすると「素早い」「機敏な」という意味合いになる。今回はアジャイル開発とは何か基本から説明したい。

そもそもアジャイル開発とは？

アジャイル開発とはシステム、ソフトウェア、アプリケーションなどの開発手法の1つで、「計画⇒設計⇒実装(開発)⇒テスト」といった開発工程を機能単位の小さいサイクルで繰り返す開発手法のことを指す。

目的としては、アジャイルという言葉の通り、コアな要件を満たしつつ、よりよりプロダクトを効率的に素早く開発することを目指している。

そして、優先度の高い要件から順に開発を進めていき、開発した各機能の集合体として完成形を目指す。

アジャイル開発のメリットとして、仕様変更に強い点が挙げられる。各機能単位で開発を進めていくため、途中で仕様が変わったとしても次の開発サイクルに取り込んでいくチャンスがあるため、仕様変更に柔軟に対応することができ、手戻りを小さくすることができる。

また、開発サイクルを短くすることができるため、サービスインまでの時間を短縮することができる。実際のユーザに使用してもらい、フィードバックを取り込むという改善もできるため、ある程度の不具合やシステムの不完全性が許容できるならば、マーケットに出してからの改善も可能だ。

アジャイル開発が注目されるようになったのは、ユーザ・ビジネスニーズの変化が速くなってきたことにある。テクノロジーの発達により、人々の変化も激しくなり、同時にユーザからのフィードバックもダイレクトに開発側に伝わるようになってきた。

このような背景から、小さい開発サイクルを回していくアジャイル開発がユーザ・ビジネスニーズの取り込みに向いているため、多くのプロジェクトで採用されている。

ウォーターフォール開発との違い

次に、従来型と言われるウォーターフォール開発との違いについて説明したい。ウォーターフォール開発とは、名前の通り滝のように各工程が上から下に一直線に流れる開発手法のことだ。

具体的には、企画⇒計画⇒要件定義(設計)⇒開発(実装)⇒テスト⇒リリースという工程が戻ることなく進行していく。大規模開発や金融機関の厳格なシステム開発では各工程での工程完了基準が明確に定められており、クリアしなければ基本的には次には進めず、プロジェクト遅延となる。

ウォーターフォール開発とアジャイル開発の大きな違いは、ウォーターフォール開発は前半の企画⇒計画⇒要件定義にかなりの時間をかけるためサービスインまでの時間が長くなってしまう。

また、要件定義完了以降の開発・テスト工程での仕様変更を受け入れにくい。基本的には定められた設計書通りに開発を進めていくため、その途中の不具合などは改修していくが、そもそもの要件と相違・追加している分については対応が難しく、追加コストがかかる場合がほとんどである。

加えて、追加改修の影響範囲次第では、開発計画内での吸収が難しく、プロジェクト自体が遅延となってしまうため、基本的には要件定義完了以降の仕様変更は受け入れにくいというのが開発サイドのスタンスだ。

一方で、ビジネス側としては要件定義フェーズで要件を出し切ったつもりでも、開発が進んでいくにつれて、「やはりこれがないと業務が回らない」というクリティカルな要件を見落としているケースもよくある。

このような見落としが発生してしまう要因の1つとして、設計書ベースでは具体的な業務のシーンを完璧にイメージすることは難しく、モックアップのようなデモ環境を触ってみて初めて気づくという事例も多い。

アジャイル開発が選ばれる条件

最後に、アジャイル開発が選ばれる条件について説明したい。まず、各機能・モジュールが別々に開発したとしても成立する必要がある。アジャイル開発は小さなチームを複数作り、そのチームごとに機能・モジュールを同時並行で開発するため、機能間のロジックを精緻化することが難しい。

次に、システムの拡張性・柔軟性があることも挙げられる。アジャイル開発はリリース後も頻繁にアップデートが入ることが前提となる。ユーザからのフィードバックをもとに改修するサイクルは多くなるため、システムを止めることなく追加改修ができるような拡張性・柔軟性が必要となる。

また、アジャイル開発のデメリットでもあるのだが、開発スケジュール全体のコントロールが難しいため、基幹システムとの結合・総合テストが必須の場合などは全体への遅延リスクが高くなる。

なぜなら、各チーム(スプリントと呼ばれる)ごとに開発を進めていくため、ウォーターフォール開発よりも全体開発スケジュールをコントロールしにくい。

加えて、要件を取り込みやすいとはいえ、限界はあるため要件出しの期間を明確に区切れず、あれもこれもと要件を吸収してしまい、開発キャパシティを超えてしまうこともよくある。

ユーザ・ビジネスニーズを取り込むことが目的ではあるが、各スプリントで明確にスコープを定義しなければ開発キャパシティを超えてしまうし、テストケースも膨大になってしまう。

また、業界の特徴もあると言える。アジャイル開発では開発スピードを上げるために設計書などのドキュメントを最小限にしているケースがある。このような開発スタイルは金融業界や官公庁など比較的お堅い業界には受け入れがたい。

金融業界などはウォーターフォール開発における各工程の終了判定基準を明確に設けているケースが多いため、ドキュメントを省略してしまうとアジャイル開発とはいえ、次に進めないケースがビジネスの判断としてありうる。

以上のように今回は、ウォーターフォール開発との比較を交えながらアジャイル開発の基本についてお伝えした。実際のプロジェクトにおける観点についても記載しているため、参考になれば嬉しい限りである。