前回（第2回）は、ウオーターフォールモデルによる情報システム開発プロジェクトや、それが定着したIT業界では、顧客の顔が見ないまま仕事を進め、技術力を磨く機会にも恵まれないままの“システム屋”を量産してしまう問題を指摘しました。

　ウオーターフォールモデルには、さらに欠点があります。“システム屋”が情報システム構築を発注する顧客に対して決断を求めるプロセスが曖昧になることです。

　どのような商品・サービスであっても、顧客が最終決定権を持つのは当然です。外食店で料理を注文する時なら、料理の種類や価格帯、肉・魚の焼き加減は顧客が決めます。家を建てる時なら、立てる場所や広さから内外装のデザインまで顧客が決定するはずです。

　ウオーターフォールモデルで「顧客が決断しない」というのは、ある意味で逆説的です。ウオーターフォールモデルでは、各工程で成果物を明確にし、それぞれの段階で顧客・ユーザーの確認・承認という決定を得てから次の工程へ進むからです。「逆流」を防ぐために、ITベンダーが何十年もかけてこの方法を確立し、徹底させようとしてきました。

　私が“システム屋”として色々なケースを見てきた経験からすると、工程ごとにユーザーの決断を迫るこの手法が、結果として顧客に決断力を要求しない取引慣行につながってしまうことが多いように思います。日本の大企業社員の「責任回避体質」とも関係があるかもしれません。

締め切りを先延ばししたがるユーザー

　この数十年間に、情報システム開発を発注する顧客企業・ユーザーの担当者たちは何度となく「早く決めてください」「これでよろしいですか」「いつまで待てばよろしいでしょうか」と決断を迫られ、急かされてきたことでしょう。ユーザー企業も、「逆流」すれば責任を問われる立場に置かれています。責任を取って決断できない場合は、とりあえず決断を遅らせてこの状況を乗り切るしかありません。

　ユーザーの担当者が責任を取らされることにならない“正しい”決断をするためには、自分自身が慎重に確認するだけではなく、関係者や先輩たちにもよく相談する必要があります。日常業務や私生活などで多忙だと冷静な判断が難しくなりますから、締め切りは出来るだけ先延ばししたほうが良いことになります。

　決断すべきユーザーの担当者が複数いれば、その中で一番遅い人の時間軸にプロジェクト進行が引っ張られることになります。ビジネスの世界では、スピードが遅いことは時に致命的な事態を引き起こすのですが、どういうわけか、決断が遅いことによって責任を感じなければならない事態にはなりません。