アジャイルとウォーターフォール――開発手法はどう選ぶ？

「アジャイルで開発します」と言われて、よくわからないまま了承していませんか。開発手法の実態と、外注現場でウォーターフォールが選ばれ続ける理由を解説します。

ウォーターフォール開発

要件定義→設計→開発→テスト→リリースと、上流から下流へ順番に進める手法です。各工程が完了してから次に進むため、計画を立てやすく、進捗が管理しやすいのが特徴です。途中の仕様変更に弱く、要件が変化しやすいプロジェクトには向きません。

システム外注の現場ではウォーターフォールが中心

日本のSIer（システムインテグレーター）や受託開発会社の多くは、現在もウォーターフォールを主体にしています。その背景には、いくつかの現実的な理由があります。

発注側の稟議・承認プロセス 多くの企業では、IT投資の承認を得るために上長や経営層への稟議が必要です。「総額いくらかかるか」「いつ完成するか」が事前に確定していないと、稟議が通りません。費用と期間を固定できるウォーターフォールは、このプロセスと相性が良いのです。

スケジュール管理のしやすさ ウォーターフォールは各工程の完了条件が明確なため、どこまで進んでいるかが把握しやすいです。発注者側が進捗を報告・共有しやすく、組織内の説明責任を果たしやすいという側面があります。

SIerの開発メンバーの管理 大手SIerは多くの場合、協力会社やパートナー企業のエンジニアを束ねてプロジェクトを運営します。設計書・仕様書をベースに分業するウォーターフォールの方が、人員の入れ替えや管理がしやすいという開発側の事情もあります。

アジャイル開発

短い期間（スプリント）を繰り返しながら、少しずつ機能を作り足していく手法です。要件が変化しても柔軟に対応でき、早い段階で動くものを確認しながら進められます。

自社開発のWebサービスやスタートアップでは主流です。「海外ではアジャイルが中心」という話はある程度正しく、特にIT企業・スタートアップ文化の強い欧米ではスタンダードです。ただし、これはあくまで自社開発の文脈です。海外でも大規模な業務システムの受託開発では、ウォーターフォールに近い管理体制が取られるケースは珍しくありません。

アジャイルは発注者側にも継続的な関与と意思決定が求められます。スプリントごとに確認・承認を行う必要があり、「お任せして待つ」スタイルとは相性が悪いです。また、受託開発の現場では「アジャイルで進めます」と言いながら実態はウォーターフォールに近い、というケースもあります。名称だけでなく、実際のプロセスを確認することが重要です。

その他の開発手法

スパイラル開発・MVP・プロトタイピングといった手法も存在しますが、これらが独立した手法として採用されるケースは現場では多くありません。実際にはアジャイルの一部として組み込まれたり、ウォーターフォールの前段の検証フェーズとして活用されたりすることがほとんどです。

たとえばプロトタイピングは、要件定義の精度を上げるための手段として位置づけられることが多く、それ自体が開発全体の手法というよりも、手法を補完するアプローチです。MVPも「最初にリリースする範囲をどう定めるか」という考え方であり、開発プロセスそのものとは別の話です。

結局どれを選べばいい？

外注でシステムを開発するなら、ウォーターフォールが現実的な選択肢になる場合がほとんどです。要件を固めてから発注し、変更を最小化して進める。そのための要件定義に時間をかけることが、外注開発を成功させる基本です。

要件がまだ固まっておらず試しながら進めたい場合は、プロトタイプやMVPで小さく始め、その結果をもとに本開発の要件を固めるというアプローチが有効です。