ウォーターフォール・モデル開発とは

詳細はwiki 参照ください：wiki : ウォーターフォール・モデル

開発の各工程をおよそ以下の様に定義し、水が流れる様に上から下の工程を順にこなしていく、という考え方。

要件定義：エンドユーザーの業務のうち、本システムで解決する課題を定義
外部設計：要件定義に従い、どのような機能、UIを持つかの設計
開発：外部設計に従い、プログラムを作成。昔は内部設計があったが開発者が同時に行う事が多い
テスト：外部設計書に従い、機能を満たしているか試験

1や2の「何を作るか」を決める工程では、作る物をドキュメント化し、それぞれの工程の終わりでは、前工程の責任者がレビューを行い、期待値通り作られていることを確認、承認し次工程へ進める開発手法だ。

次工程に進むには承認が必須だから手戻りしない

この**『前工程の責任者に責任を持って承認してもらう』事によって手戻りが発生しない**ことが本手法の最大のメリットだ。

だが少し待ってほしい。資本主義社会においては**『世の中に存在しないものを作らないと新たな価値とならない、つまりは誰も見たことがないものを生み出さねばらなない』あるいは、業務を効率化しコストを削減するシステムを作るのであれば、『どこにコストがかかっていて、どのようなユーザーがどのように使うとコストが下がる』ということを把握していなければならない。
この様な前提の中で『これでよいです』**と承認できる人間は預言者か異世界から転生したチート能力の持ち主くらいではないだろうか。

外部設計においても同様である。設計者は開発のプロではあるが、顧客の業務についてはシロートなのである。案件毎に１から顧客の業務を覚え正しく要件を理解し、仕様に落とし込むには充分な時間が必要であるが、その時間が与えられることはまずない。同じ案件を長くやっていれば別だが、基本的には案件毎に一夜漬けで覚えた知識を元に試験に望む様な作業が外部設計なのだ。

開発のプロである設計者が、業務アプリケーションの延長としてWebアプリケーション開発を行う際に、Excel画面仕様書でおよその合意を取ると、以下の図の様な深刻な認識の相違が生まれる可能性がある。

図. 立場が異なれば常識も異なる

90年代の Windows アプリケーションであれば、Excel画面仕様書はかなりの再現度を誇っていたし、パワポで作ったi-modeの仕様書も充分完成形がイメージできていた。

だが、2020年に作っているのは動的なウェブサイトである。静的な仕様書から『動き』まで想像して承認などできるだろうか。
普通の人であれば『実際動いてるの触らないと分からないっす』と言って機能として過不足ないか確認までできるのが精一杯ではないだろうか。

この認識の齟齬をなくすのであれば、製品コードでそのまま利用できるモックやプロトタイプを作って、それを確認してもらいながら進めるのが現実的かと思われるが、それらもこれなら絶対に間違いないですよね？と承認を取ろうとすると莫大な工数がかかってしまい元々の用途からそれてしまうことが懸念される。

ここまで考察してみると、手戻りが発生しないことを保証する『承認行為』は、相当に胆力が必要な行為であり、その規模が大きくなればなる程、難易度が上がる行為であることが推察できると思う。

『承認行為』は当然必要であるが、『不用意に大きな成果物』に対しての『承認行為』が必要になるプロジェクト運営は、リスクが大きくなると言えるのではないだろうか。

不完全な承認と手戻り

『不用意に大きな成果物』に対して承認を行うプロジェクト運営を行うと、誤りに気づく機会も損失することになる。
「開発者とテスターが設計者の意図通りに仕様を読み取らなかった問題」の発生と発覚をシーケンス図として以下に示す。

恐ろしいことに、ウォーターフォール・モデル開発では、実装誤りが納品して顧客の手に渡るまで発覚しないのである。
このクラスの障害が発生すると過去の議事録を大捜索し言った言わないの水掛け祭りが始まるかもしれない。

※QAの質問数と回答数が異なる、各種ドキュメントが更新され続け前工程が完了しないまま次工程に入ってるのは、正しく問題を把握するための作為的な図。¹

まとめ

手戻りは、関係者全員が精神的にも工数的にも大被害を被るので可能な限り避けるべきだと思う。
避けるには『顧客が本当にほしいもの』を理解してこまめに確認が取りながら一緒に『プログラムではなくプロダクト』を作っていくことが望ましく思えた。

高校の時の数学の恩師が図形の問題で三角形を描いていたら「理想的な図を描くと問題を見誤るからいびつに描く方がよい」と教えてくれたので、可能な限りいびつに描いたフィクションです。 ↩