なぜウォーターフォールかアジャイルかという選択肢になるんだろう

こんにちは。天野です。

アジャイルコーチとして各所で話をしていると、今でもよくウォーターフォールのカウンターパートとしてアジャイルを採用すべきか否かという話に遭遇します。この手の話になると、いつも数年前に話題になった牛尾さんのブログ記事を思い出します。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

基本的には自分も同じ意見なのですが、なぜ「ウォーターフォール or アジャイル」という構図になるのか興味を持ったので、少し考えてみます。

アジャイルが「向いていない」問題領域はあるのか

よく聞くのが、プロジェクトの性質によってアジャイルを採用したり、従来型との「いいとこ取り」をするという話です。これは、暗にアジャイルには向いていない領域があることを前提にしていると思います。

アジャイルが「向いていない」問題領域はあるのでしょうか。問題の複雑さ・不確実性を理解するためのクネビンフレームワークでは、問題は5つの領域（無秩序、混沌、複雑、煩雑、単純）で構成されます。

https://www.servantworks.co.jp/posts/speech-cynefin/ より引用

多くのソフトウェア開発現場は複雑系(complex)ですが、プロジェクト全体が煩雑系(complicated)として扱える場合はウォーターフォールの方が向いていると言えます。しかし、煩雑系の問題に対してアジャイルなアプローチをしたからといって、プロジェクトが取り返しのつかない失敗をするわけではありません。せいぜい検査と適応のオーバーヘッドが無駄になるくらいです。

逆に、複雑系の問題に対してウォーターフォールなアプローチを選択した方が、プロジェクトの後半で取り返しのつかないこと（よくある炎上）が起こります。