アジャイルとウォータフォールの選択基準を考える

概要

ここ2-3年の間にウォータフォール、アジャイルの両方のプロジェクトを行いました。共に数千万円の中規模プロジェクトです。

コスト、期日、品質の全てで期待された結果を出しており、システム開発プロジェクトとしては成功と言って良いと思います。

ウォータフォールで失敗し、アジャイルで成功したという話は多いのですが、両方成功した前提で語られることは少ないと思い、実際にやってみた感想を纏めてみました。
何かの参考になれば幸いです。

なお、対照実験ではないため、同条件で比較したという話ではありません。

両プロジェクトで、システムアーキテクト、プロジェクトマネージャです。
企画、要件定義から関わっています。

ウォータフォールプロジェクトは、以下の特徴がありました。

アジャイルプロジェクトの特徴は以下の通りです。

やる事が明確ならウォータフォール、そうでなければアジャイルと言われます。
まさにそれが正しいことを実感しました。

ウォータフォールプロジェクトはリファクタリング目的であり、要件の固定を前提条件としました。
新規システム開発でも要件の固定自体は難しくなく、要件定義と設計・実装の契約を分け、設計以降は要件を固定することが一般的だと思います。

問題は固定したはずの要件について、実際に作ってみるまで本当の意味での合意が難しいという点にあります。
要件に対し、実際にどうなるのか見た事がないのであれば、要件の固定は不可能ということです。

このため、現実的にウォータフォールを採用できるのは、リファクタリング、ユーザの操作性に影響しないシステムリプレース、原因が特定された障害対応などに限定されます。

明確にウォータフォールが適しているのでなければ、アジャイルを採用すべきと言えます。

開発手法が直接品質に影響することは無いと感じました。
不具合の発生率に違いはありません。

ビジネス要求を受けて要件が変化することが多い中で、ウォータフォールでは変化への対応が難しいため、結果的に品質が低いと評価されるのだと思います。

そもそも予定のコストを算出できるのであれば、ウォータフォールで良いと思われます。
要件が固定できずに厳密なコストを算出できないのであれば、アジャイルを採用します。

コストの振れ幅を抑えたいのであれば、ウォータフォールを選択するための条件を整える必要があります。
不確実性のコーンを参考に、設計完了に近いことが条件です。

条件を満たさないのにウォータフォールを選択すると、高い確率でコストが超過します。

考え方はコストと同じです。

どちらの方が要員の調達が楽か?と言い換えてもいいと思います。

ウォータフォールの場合は、要員のスキルに幅を持たせることができますが、プロジェクトに必要なスキルを厳密に定義する必要があります。
アジャイルの場合は、同じレベルの要員で揃える必要があります。要員のスキルに幅があると機能しません。

どちらを採用しても要員の調達が楽ということはありません。
難しさのベクトルが異なるだけです。

開発手法に解決策を求めるべきでは無いと思われます。
アジャイルを選択しても、課題が解決出来る可能性に影響はありません。

プロジェクトを計画する段階で、課題の洗い出し、課題の解決、システム構築の3段階に分割しておく必要があります。

一般的にウォータフォールの方が楽だと言われます。
しかしながら、不測の事態が発生した場合に、ウォータフォールではプロジェクトの再構成に多大なコストがかかります。

不測の事態が発生しないプロジェクトは存在しないため、事前に完全な予定を組み立てないアジャイルの方が心理的な負担は少ないと思われます。

考える事が限定されるため、ウォータフォールの方が楽に感じるかもしませんが、作業スケジュールが厳密に管理されるため、心理的負担が大きいと考えられます。

管理と同様に、アジャイルの方が心理的安全性を確保しやすいのがメリットです。

予定をコミットするウォータフォールになります。
ただし、ウォータフォールを選択できる条件を満たすことが難しいため、ステークホルダーだけをみて開発手法を選択すると失敗します。

ウォータフォールは選択できる条件が厳しい開発手法です。
ステークホルダー側もこのことを理解し、条件を満たしていることを確認する手順が必要です。

ウォータフォールが適切であるという十分な確信が得られない場合は、アジャイルを選択すべきです。

ウォータフォールの方が採用するための敷居が高いことから、私は間違っていた。ごめん。ウォーターフォールは何のメリットも無いのように一律アジャイルという選択も妥当だと思われます。