ウォーターフォール開発じゃだめなのか（２）

前回のつづき。

だめなものを使ってどうするっていっていたんだけど、、、
聞こえてくるわけさ・・・

ウォーターフォールをやって皆が失敗しているわけじゃない。うまくいくプロジェクトはうまくいく・・・ってね。

失敗するのは、ドキュメントがきちんとかけてないからだ、とか。仕切りができていないからだ、もっとみんなの進捗を管理して、期限までにやるようにしろとか、顧客に期日を切ってやるように申し入れろとか、・・・
でも、実際プロジェクトやっていると、そううまくいかないことも多いさ、あまり経験したことのないプロジェクトや面倒な利害関係者、なかなか固まらない仕様とか、あるよ。だから、それにどう対応するかが問題なんだけどさ。

そもそも、想定外の要件が後から出てくることをどうやって予想できるんだ？全ての要件をあらかじめ定義するやり方は破綻していることは歴史が証明している、当の昔に。（ウォーターフォール型は、そこで破綻したんだから）

お前たちだめだな、といわれてもねえ。なんか違う気もするしなあ。

なにいってんだ、うまくいったプロジェクトもあるじゃないか。おれたちはやってきたぞ、切り抜けてきたぞ、困難を乗り越えてきたぞ。それをどう考えるんだ！
（いやいや火消しの嵐だったとおもうんだけど・・・まあそれはそれとして）

・・・・・

さて、うまくいったプロジェクトってなんでうまくいったのだろう？
たしかに、いろいろあっても成功といえるレベルに品質や納期、コスト（まあ途中で何度も見直ししている結果だろうけど）を実現したプロジェクトあるよなと。

実は、ウォーターフォール開発をまじめにやらずに、プロジェクトにあわせていろんな工夫をしてきたからなんじゃないかとおもう。
たとえばさ、
新しい基盤を使うことになっているからフィージビリティを評価する工程をいれるとか、かんたんなモックアップを作って仕様を確認するとか、設計にあたって技術的な確認をするために簡単なプロトタイプを作るとか。
誰もとにかくドキュメントだけを書けばいいなんて思ってないさ。
危ないと思えば、評価プロセスを入れるし、フォードバックプロセスもいれる。並行性が必要なら並行的に開発もする。
確実に動くものが必要と思えば、開発単位を小さくして確認してきたさ。要求仕様が大きくなれば、機能を減らして最初にリリースすることに専念してきたさ。

だからうまくいっているんだよ・・・もっと成功分析をしようよ。
それをプロジェクトマネージャの能力とか、管理とか、そういうことじゃないよね。。。計画重視の進捗チェックだけに頼るなよ。
計画が難しい案件に対してどう取り組むべきか、どう対処していくべきか、そのプロジェクト特性や技術特性、業務要件にあわせたやり方を考えようよ。システムに最適なやり方を探そうよ。

これらをウォーターフォールと呼ぶならそれでもいいさ、もっとプロジェクトの工夫を活かそうよ。

いわゆるウォーターフォールをまじめにやると失敗するんだぜ。

成功した人たちは、ウォーターフォールじゃないやり方をやったんだって。（表面的にはどう振舞ったか別だけどさ）

失敗した人は、ウォータフォールのまんまだったんだよ。

そう思わないかね？

・・・・・つづく。いよいよ真相へ。