プロジェクトマネージャー経験者が教えるアジャイル開発

アジャイル開発という言葉を聞いたことがある人は多いと思います。「アジャイル」とは日本語にすると「素早い」「機敏な」という意味合いです。

今回はアジャイル開発とは何か基本から説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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