ウォーターフォールは複雑で不確実性の高い問題を簡単で不確実性の低い問題にすり替えようとしてしまう

アジャイル開発手法の文脈において、対立構造ではないことを強調するために「不確実性の低い場合はウォーターフォールが適している」という説明を聞くことがあります。しかし、紙業務をシステム化するとか、繰り返しの作業を自動化するといった不確実性の低い簡単な問題は一通り解決され、今残っている解く価値のある問題は、複雑で不確実性の高いものばかりです。そんな中で、ウォーターフォールの出番は減るはずであるにもかかわらず、実際には多くのシステム導入・開発の現場で今でも採用されています。

この時に行われるのが、システム導入・開発の裏側にあった複雑で、不確実性の高い本来の問題 - 売上を上げるのか、コストを削減するのか、従業員満足度を上げるのかはわかりませんが - を、計画通りにシステムを開発・導入するという簡単で、不確実性の低い問題にすり替える、手段を目的化してしまうことです。

不確実性と向き合いたくない

現状維持バイアスなどで知られているように、人はどうなるかわからない、不確実な状態を避けようとします。特に日本人は不確実性が苦手という研究結果もあります。

特別コラム「不確実性が問題なのか、不確実性に耐えられないことが問題なのか？」

こうした我々の性質に、ウォーターフォールによる問題のすり替えはぴったりなのです。やるべきことは事前に洗い出され、詳細なスケジュールと精緻な見積もりがわかります。予算に対する説明も合理性があるので、決裁者からの承認も簡単に得ることができます。

現場で何が起こるか

このようにして始まったプロジェクトにおいて、現場では何が起こるのでしょう。最悪のシナリオは次のようになります。

自分たちの時間を割いて協力しなければならない人たち、自分たちの業務を変えなければならない人たちは、当然なぜそれをやる必要があるのか？どんな効果が出るのか？合理的な理由を求めます。

しかし、プロジェクトのメンバーは予定通りにシステムを開発・導入するために動いているため説明はできません。決裁者の承認のもと始まったという事実を盾に強引に進めます。（一部のメンバーは、手段が目的化していることに気が付き、それを正当化するために自己欺瞞をしなくてはならなくなるかもしれません。）

結果として、本来の目的を失ったプロジェクトは、思うような成果を出せず、最終的に効果が出ていないことが現場から決裁者に知らされ、プロジェクトには失敗の烙印が押されます。

（これは自分も何度も経験したパターンです…）

複雑な問題に立ち向かう

このシナリオは、複雑で不確実性の高いな問題を簡単で不確実性の低い問題にすり替えたことから始まります。複雑な問題は、複雑なまま立ち向かわなければならないのです。そのためには、とりあえずやってみるとか、試行錯誤の姿勢が必要になります。

しかしこれは、ウォーターフォールで育ってきた人には行き当たりばったりに見える可能性が高いです。しかし、入念に計画を立て、それ通り実行することに重きを置くウォーターフォールは問題解決、プロジェクト推進の一つの方法でしかなく、それがあらゆる問題に対する最適なアプローチとは限りません。「ハンマーしか持っていないと全て釘に見える」というやつです。

以上です。