ウォーターフォールじゃだめなのか（３）

いよいよ最後。

そういや・・・
いつから、要件定義や設計でドキュメントしか作らなくなったんだろう？きちんとウォータフォールを守るようになったんだろう。プロジェクトによって工夫をさせなくなったんだろう。

スタートを改めよう。間違ったやり方の評価の仕組みなんて意味ないし。

・・・・・

実は、それでもこれだけ普及している理由には、ウォータフォールって、プロジェクトを外から管理するには非常に都合がいいからだ。
プロジェクトが拠れる、リカバリーしないといけない、そんなケースが増えてきた。じゃあ、失敗しないためにはどうするか?
組織的なレビュー、第三者によるプロジェクトレビューをやろう。
じゃあ、どうやる？
そこで都合よく出てきたのが、ウォーターフォールの特徴。
工程を後戻りさせない、契約の切れ目が明確。わからないものは、リスクリスクとして積み上げろ、成果物が決まっているからそれの進捗を確認しればいいじゃないか。

（もちろん、成果物といったって、プログラムじゃないんだぜ、基盤が立ち上がっているとか、サービス開始の条件がシステム的に整っているとかじゃないんだぜ、、、ドキュメントだよドキュメント。。しかもさ、ドキュメントの中身を評価しているんじゃないんだぜ、、、たとえばさ、
・テストケースの中身じゃなく、テストケース数とか
・機能の複雑さや粒度感の問題じゃなく、想定機能数がこなせていないとか、
・DB項目の複雑度とか項目数じゃなく、テーブル設計できているかどうかとか

ありえなくない？）

こういう評価しかできない人たちにとっては、非常に都合のいいプロセス。
それがウォーターフォール。文書化、工程、レビュー数、不具合率・・・わかりやすいよね。
中身関係なく評価できるんだから。。。。

いったんこれを味わったら、止められないんだよ。

なぜならね、
自分たちは同じようなやり方をやってきていないんだけど、人を評価するには、指標がいる。
しかも、定量的とか代用特性とか、いかにも正論に聞こえるから、困ったもんだ。

でも本当は、自分たちが頼れるのはこれしかないからしがみ付くわけさ。
だって、昔のようにプロジェクトには入れないから。
今の技術で入れてもらえないから。入れてあげるといってもそれも怖いから。
今の正論を吐く形なら安心できるから。

・・・・

ウォータフォールがだめなのか、といえば、自明さ。

ではなくて、
問題なのは、ウォーターフォールでしかプロジェクトを評価できない組織が問題だ。
そんな組織の代表が、アジャイルもやろうよ、といったって誰も信じないさ。

・・・・・

余談。

要件もまだ固まってない段階でＦＰ（ファンクションポイント）で見積もりを強制する、しかもそれを提案時の内部レビューで使っているようなSIerっていたら、どう思いますかね？