ウォーターフォール ～ となりのプログラミング用語

はじめに

『ウォーターフォール』は開発手法の一つです。ウォーターフォール型の開発、などのように総称としても使われます。

『ウォーターフォール』というと「川の流れ」のように響くかもしれませんが「水門のある運河」がより正しいイメージです。ウォーターフォールの肝心かなめはゲートの存在です。

「アジャイル」と比較されながら「ウォーターフォールはエンジニアを不幸にする」ようにしばしば言われていますので、その背景について私なりの考えをお話しします。

人々を分断する魔法のシールド

必要なことを調べる → 仕様を決める → 実装する → テストする → リリースする、ウォーターフォールではこのように工程が分けられます。そして各工程の間にゲートレビューがあります。

ゲートレビューでは作業が完全に終わったかをチェックします。ウォーターフォールは原則として逆流しませんから、仕事は完全な状態で次の工程に引き渡される必要があります。

ただ誰でも「おまえの仕事は完全か」と問われれば多少は不安になるでしょう。そこでゲートレビューは報告書なり仕様書に魔力を与える荘厳な儀式になります。

魔法のシールドにより当該工程の担当者としては「仕事が終わった」の安堵感を得られる一方、工程ごとに人々は心は分断されてしまいます。

重ならない関心、そして孤立する旅団

もうひとつ難しいことがあります。プロジェクトにかかわる人々の関心が重なる時間が短いのです。基本的に自分の工程にカーソルがあるときしか関心が高まりませんから。

プロジェクトの中途でなにかに気づいて手を挙げたとしても、自分の担当領域外のトピックであるとすると、その時間において関心を持って聞いてくれる人が周りにいないのです。

折角のアイデアが誰にも聞いてもらえないとしたら、それはとても寂しいことです。会社にとってもきっと損失でしょう。

そうして時間的距離にによっても人々の心は分断されてしまいます。

アジャイルという解決方法

アジャイルの特徴は「反復（イテレーション）」です。反復はまず仰々しい儀式を廃してときどき間違いながら徐々に進むことを許します。とうとう私たちは魔法のシールドを解除することができます。

そして短い間隔での反復により、プロジェクト関係者の関心の高く保たれるようになります。結果として、だれもが手を挙げやすくなり、プロジェクトがより良いアイデアを採用しやすくなりました。

アジャイルは万能のようです。ただこれらはアジャイルでしかできないことなのでしょうか？ウォーターフォールに構造上の欠陥があって、アジャイルがそれを修正したということなのでしょうか？

結局、ウォーターフォールの問題じゃない

魔法のシールドの問題は、開発手法上のプロセスが政治化したことが問題なのであって手法の欠陥ではありません。利用の仕方の問題です。

関心が重ならない問題は、もとから関心の無い人が無理に関心を高めて無理にウェーイしていることが問題なのです。関係者全員がプロダクトについて当初からどれほどの関心を持っていたでしょうか？

つまるところウォーターフォールかアジャイルかというより、関係者の心構えの問題だと思えてきました。

おわりに

「ウォーターフォールでエンジニアが不幸になる」という話は、「部内部長がいる会社に入ると不幸になる」みたいな「あるある」話かな、と私は思いました。

弊社では、様々なタイプの関係者（社員・準委任の業務委託の方々、請負で仕事をされるベンダーの方々）がいることからも、全方向を探索しながらプロジェクトを進めており、いつも悩んでいます。

いつか「弊社のベストプラクティス」みたいな記事を書いてみたいです。

最後までお読みいただきありがとうございました。