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

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

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

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

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

アジャイルの重要概念

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

ユーザーストーリー

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

ユビキタス言語

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

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

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

継続的デプロイ

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

インクリメント

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

インセプションデッキ

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

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

イテレーションはソフトウェア開発における「要件定義→設計→開発→テスト→リリース（運用）」の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のプラクティスは「ドメイン・オブジェクト・モデリング」や「クラス毎のオーナーシップ」が代表例です。他の開発手法に比べて、ソフトウェアのコーディング技法に関するプラクティス中心に構成されます。

まとめ

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

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

関連サービス