アジャイル開発とウォーターフォールの違いは？概念や開発手法を詳しく解説

2022年3月31日掲載

アジャイルは人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発です。要件定義・設計・開発・テスト・リリースといった開発工程を素早く繰り返すことで学習と改善を行い、スピード感のある開発を実現します。

ここではアジャイル開発の概念や手法について分かりやすく解説してまいります。

エンジニアや企画開発担当の方、情報システム部門の方向けに、アジャイル開発についての概念や手法について解説します
本記事を読むことで、アジャイル開発を始めるきっかけになれば幸いです。

アジャイル開発とは

アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発です。アジャイルには「素早い」、「機敏な」という意味があります。開発工程を小さな機能単位のサイクルで繰り返すため、従来の開発手法よりもスピード感のある開発が実現します。

アジャイル開発の背景と目的

アジャイル開発が普及した背景にはインターネットとクラウドによるビジネス環境の変化が考えられます。従来のITサービスは買い切り型のパッケージサービスとして提供されていました。一方で近年のITサービスは定額制で、提供サービスに対して継続的に機能追加やデザインの変更が行われます。そのためサービス運営者はユーザからのフィードバックを通じて、継続的かつ素早くサービス改善を行うことが求められます。このような課題に対するアプローチとして、アジャイル開発は多くの開発現場で支持を拡大しているのです。

アジャイルソフトウェア開発宣言（Agile Manifesto）と原則

アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に定義した文書です。この宣言は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

アジャイル開発宣言はその行動指針として、12個の原則も定義されています。

1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

これらの宣言と原則は世界中で翻訳され、アジャイル開発の教科書・解説書にも引用されています。アジャイル開発の手法は数多くありますが、いずれもこの宣言と原則に基づいて設計されているのです。

アジャイル開発の流れ

アジャイル開発の具体的手法に唯一絶対なものはありません。組織の規模や文化、事業領域や課題の中身によってその手法は多種多様です。後述するスクラムなどは代表的な手法ですが、その適用範囲は自分達で柔軟に決める必要があります。

アジャイル開発も基本的な工程は「要件定義→設計→開発→テスト→リリース（運用）」で、一般的なソフトウェア開発と同様です。大きな違いとしては、開発期間を小さく区切っており、要件定義からリリースまでの期間が非常に短い点になります。この短い1サイクルは開発手法によって「スプリント」や「イテレーション」と呼ばれます。

アジャイルとウォーターフォール

ウォーターフォール開発は要件定義からリリースまでの工程を企画段階で詳細に見積もります。そのため、予算やデザイナー・エンジニアのアサイン計画を立てやすいのが特徴です。また、工程の変更や出戻りを想定しておらず、下流工程で問題発生が起きないように開発が進んでいきます。要件定義からリリースまでの工程を1サイクルで完了させるため、大規模な開発や品質重視の開発向きの手法です。

一方アジャイル開発はプロジェクトの完了までに、要件定義〜リリースのサイクルを複数回行います。そしてリリースごとに顧客からのフィードバックを得て、その都度機能開発や改善の方向性を見定めます。そのため、ウォーターフォール開発に比べてサービス利用者の要望やフィードバックを、素早く、かつ柔軟にプロジェクトに反映できる点が特徴です。

アジャイルとウォーターフォールはそれぞれに適した組織・プロジェクトがあり、どちらが優れているというものではありません。近年ではこの2つを組み合わせた取り組みもあります。たとえば、設計と開発だけアジャイルで行い、ほかの工程はウォーターフォールで行うなどです。開発組織とその運営管理者は、それぞれの開発手法の特徴を理解して、その都度開発プロセスを設計する柔軟性が求められています。

アジャイルの重要概念

アジャイルには開発手法に関する概念や手法が数多くあります。ここではその中でも特に覚えておきたいものについてピックアップして紹介します。

ユーザーストーリー

ユーザーストーリーはサービス利用者の言葉や目線で、ソフトウェアが提供する価値について記述したものです。誰が、なぜ、どんなことを実現したいのかが書かれています。ソフトウェア開発者はユーザーストーリーを通じて、利用者の要望を理解します。そしてどうすればその要望や期待に沿って、サービスの具体的な機能や技術の要件を検討するのです。

ユビキタス言語

ユビキタス言語はプロダクト開発チーム内における共通言語です。例えば、扱う領域の専門用語やサービス名、普段の会話の中で頻繁に利用される略語が単語リストとして整理されています。このような単語の意味が統一的に整理されることで、開発チーム内におけるコミュニケーション齟齬を減らせるのです。ユビキタス言語は実際のソフトウェアコード内でもクラス名や変数名として利用されます。

受入テスト/ユニットテスト

受入テストは当初想定した要件や目的に沿ったソフトウェアになっているか、プログラム実装後に検証するプロセスです。サービス利用者の環境も考慮したテストを行います。開発プロジェクトの初期段階で設計を行い、受入テストを完了するとソフトウェアがリリースできる状態と判断されます。一方でユニットテストはテスト対象を一つの機能やコンポーネントに絞った検証です。ソフトウェアテストはテストケースが膨れやすいものです。そのため開発チームは受入テストとユニットテストの自動化や組み合わせを行い、効率的な検証を実施します。

継続的デプロイ

継続的デプロイは、デプロイのプロセスを自動化することで、高頻度で最新のソフトウェアを提供する手法です。よく似た用語に継続的デリバリーがあります。継続的デリバリーは高頻度でソフトウェアの新機能をリリースできる状態にする手法で、デプロイのプロセスは含まれません。

インクリメント

インクリメントは完成定義を満たしている成果物です。アジャイル開発では要件定義〜リリースまでの1サイクルの成果物が、インクリメントとなります。インクリメントが積み重なることで、プロダクトが最終的な完成形に近づきます。

インセプションデッキ

インセプションデッキはThoughtWorks社のRobin Gibson氏が考案した手法で、プロジェクトの全体像をまとめたドキュメントです。全部で10の質問で構成されており、チームメンバーの意思共有を行います。

我われはなぜここにいるのか
エレベーターピッチを作る
パッケージデザインを作る
やらないことリストを作る
「ご近所さん」を探せ
解決案を描く
夜も眠れなくなるような問題は何だろう
期間を見極める
優先順位は？
何がどれだけ必要なのか

（引用元：The Agile Inception Deck）

イテレーション（スプリント）

イテレーションはソフトウェア開発における「要件定義→設計→開発→テスト→リリース（運用）」の1サイクルです。イテレーションはエクストリームプログラミングと呼ばれる開発手法の一つです。イテレーション同様に、期間を意味する用語にスプリントがあります。スプリントはスクラムと呼ばれる開発手法における開発のサイクルです。イテレーションとスプリントは用いられる開発手法が異なるだけで、その相違点は非常に曖昧です。

ストーリーポイント

従来のソフトウェア開発では見積もりを日数や週数など作業時間単位で行います。一方でストーリーポイントはある一つの開発サイクルを完遂するために必要な数値です。ストーリーポイントには作業の複雑性、作業量、リスクが含まれ、1/2/3/5/8/13/21/40の数値のみ利用可能です。ストーリーポイントを用いることで、開発者の知識や能力に依存せずに見積りできるようになります。

ベロシティ

ベロシティはスプリント中に完了する平均作業量をストーリーポイントで表したものです。ベロシティを用いてチームが作業を進める速度が予測できます。ベロシティはスプリントが多いほど、実績が可視化されて予測精度が向上します。プロジェクトに用いる際には、管理者を決めて、時間と共にベロシティの変化を追うことが重要です。

プランニングポーカー

プランニングポーカーはプロジェクトのチームメンバー全員で意見を出し合い、見積もりを行う手法です。見積にはストーリーポイントを使うことが一般的です。工数に対して相対的に見積もりを行うことから、メンバー間での認識やギャップを小さくできます。

アジャイルの開発手法

アジャイルには数多くの具体的開発手法が提案されています。これらはソフトウェア開発の現場で培われてきた、さまざまな手法やツールを体系的にまとめた理論です。ここでは5つの開発手法について紹介します。

スクラム（バックログ，レトロスペクティブ）

スクラムはラグビーのセットプレーが語源のソフトウェア開発手法です。特徴として「チームワークの重視」と「経験主義」があげられ、理論よりも経験に重きを置いて開発を推進します。アジャイルの中でも特に有名な開発手法です。

スクラムチームの役割は開発者、プロダクトオーナー、スクラムマスターの3つです。プロダクトオーナーは顧客と製品の意思決定に責任を持ちます。スクラムマスターはスクラムフレームワークが正しく適用されることを保証し、プロジェクト管理は行いません。開発者はスプリントを完遂する実行者として、幅広い作業を担います。各メンバーは専門性を持ちつつも、その分野にとらわれず1つのゴールを目指す姿勢が求められます。

プロダクトバックログはプロダクトが目指すべき姿と、そうなるための要素一覧です。スクラムではプロダクトオーナーがプロダクトバックログを作成し、スプリントを計画・実行します。また、スプリントの最後には振り返りとして必ずレトロスペクティブの機会を設けます。そこでスプリント内で発生した問題や改善策を話し合い、次のスプリントに適用するのです。

カンバン

カンバンは豊田自動車の生産方式に由来するソフトウェア開発手法です。その特徴は「タスクの可視化」、「同時進行タスクの制限」、「タスク完了の平均時間短縮」です。スクラムと異なり、カンバンではタスクの見積や議論を行いません。タスクの実行と集中が優先され、マネージャは実行完了したタスク数でプロジェクト管理を行います。カンバンでは同時進行タスクに制限があることから、タスクの完了が遅い場合に問題発見までの時間を短縮できるのです。

エクストリーム・プログラミング

アジャイル宣言の起案者の一人ケント・ベックは、1999年にエクストリーム・プログラミング（XP）を書籍として出版しました。XPはコミュニケーション・シンプルさ・フィードバック・勇気・尊重の5つの価値観で説明されます。また4つにグループ分けされたプラクティス（慣習）もXPの特徴です。XPの有名なプラクティスとして、ペアプログラミングやテスト駆動開発があります。これらのプラクティスはXPとして整理される以前から存在していました。XPではそれらの要素を「極端な（エクストリームな）」レベルに持っていくことが語源です。

ASD

ASD（Adaptive Softwate Development）は適応型ソフトウェア開発と訳されます。スクラムやXPに比べて抽象度の高い開発手法です。そのコンセプトは推測（Speculate）、協力（Collaborate）、学習（Learn）の3つです。ASDでは複雑なシナリオの計画や予測は困難であるという立場をとり、プロジェクトのゴール設定とその共有を重要視します。推測は、プロジェクト完了までに必要になりそうな、期間と開発サイクル数の検討です。開発サイクルはチームメンバーが協力して行うことを強く推奨されます。そしてテスト完了後・リリース前に振り返りを行い、次の開発サイクルの改善につなげます。

ユーザー機能駆動開発（FDD）

FOD（Feature Driven Development）はユーザー機能駆動開発と訳されます。その名が示すように、ユーザー目線で価値のある機能を中心に開発を進めます。FODにおける開発サイクルは機能（feature）単位です。プロジェクトチームはfeatureごとに計画・設計を行い、工程ごとに進捗率をマイルストーンとして設定します。FODのプラクティスは「ドメイン・オブジェクト・モデリング」や「クラス毎のオーナーシップ」が代表例です。他の開発手法に比べて、ソフトウェアのコーディング技法に関するプラクティス中心に構成されます。

まとめ

アジャイルを体系的に理解することで、ソフトウェア開発現場で起こるさまざまな課題へのアプローチが見つかります。ソフトウェア開発は複雑な課題が絡み合い、予測不能な事態も度々起こります。そのような課題に柔軟かつ素早く対応するためにも、アジャイルの概念と手法を理解・実践することは、プロダクトの価値向上に強く寄与することになるのです。

アジャイル開発は自由度が高く、体系的な適用が必ずしも正解とはならないことも多いです。その場・その時に必要とされる価値や目的に合わせて、自分達ならではのアジャイルのあり方を模索しましょう。