この連載では、企業システムでのアジャイルの必要性を訴えてきた。ともすると、アジャイルが良く、ウォーターフォールがダメという風に捉えてしまった読者もいるかもしれない。そもそも良い悪い以前に、手法そのものを比較すること自体無意味だ。

 企業システムにはウォーターフォールが向く領域もあれば、アジャイルが向く領域もある。“ウォーターフォール悪玉論”が叫ばれてしまうのは、ウォーターフォールが向かない領域なのにウォーターフォールを採用して、失敗したプロジェクトに巻き込まれた経験をした人が多いからだろう。しかし、これはウォーターフォール自体が悪いのではなく、開発プロセスのデザインに失敗しただけだ。

 プロジェクトが最初に計画した通りに進むのならば、ウォーターフォールはむしろ望ましい開発プロセスだ。逆に何が「正しい」のか判断できない、正しいもの(機能、技術、ビジネス、マーケット)が変化する場合にはアジャイルの方が向く。

 キーワードとなるのが要求、技術、スキルなどに潜む「不確実性」だ。例えば、営業、マーケティングといったフロントオフィス業務であれば、ビジネス環境の変化が大きく、要求に関する不確実性が高い。スマートフォンアプリの開発であれば、要求も技術もスキルも不確実性が高いだろう。

バックオフィス業務はウォーターフォールでいい

 一方で、会計や契約管理といったバックオフィス業務を対象としたプロジェクトでは、不確実性は比較的低くなる。業務や現行システムが存在し、仕様やユーザビリティーの変化は限定的であることが多い。

 不確実性が低いプロジェクトでは、予測に基づいて厳密な計画を立て、計画に沿って実行していくウォーターフォールが向く。期間当たりの開発効率も高い。仕様変更が少ないなら、特定のフェーズだけ要員を増やして一気に開発できる。

 また、バックオフィス系システムは、アジャイルに向かない側面もある。アジャイルではシステムの重要な機能から順次実装していくが、バックオフィス系システムは全部の機能がそろわないと意味がないものが多い。例えば、契約管理システムで入力と記録管理機能だけをリリースされても、ユーザーは評価のしようがない。すべての機能を最初から正しく仕様化できる、それらの多くを同時にリリースする必要がある、開発期間が限定的である、といったプロジェクトなら確実にウォーターフォールで開発を進めるべきだ。

 アジャイルを採用すべきなのは、不確実性の高いプロジェクトだ。フロントオフィス系システムやスマートフォンアプリをウォーターフォールで開発すると、完成時には時代遅れのシステムになってしまう。または、プロジェクト中に何度も仕様変更を求められるかもしれない。アジャイルは不確実性を始めから完全に排除するのは困難と考え、早期にフィードバックを得られるようにして、プロジェクトの進展とともに不確実性を減少させていく。

 最後に補足すると、ウォーターフォールが「状況が変化するプロジェクト」に全く対応できないわけではない。変化が確定した時点で計画を再作成すればいい。しかしそのコストは小さくはない。ほとんどの場合、計画書だけでなく、仕様や設計の変更、担当者のアサインの変更など大がかりな作業になる。プロジェクト開始後の変更は例外処理になるのは、ウォーターフォールの“仕様”だ。正しく理解して開発プロセスをデザインしよう。