「Waterfall 2006 開催！」記事へのコメント

笑いとしてはイマイチなような

[kayama (22142)]

双方とも適材適所で、規模や状況に応じて使い分けるものなのに、
片方がもう片方の相手を一方的にあげつらうと、
「必死だな」感が醸し出されてしまうというか…

私が読み方を間違えてるのかなあ。

Re:笑いとしてはイマイチなような

[Anonymous Coward]

> 双方とも適材適所で、規模や状況に応じて使い分けるものなのに、

ウォーターフォールでうまくいったためしがないです。
品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。

どういった規模や状況だと、ウォーターフォールが有効なんだろうなぁ?

Re:笑いとしてはイマイチなような

[t-wata (10969)]

>ウォーターフォールでうまくいったためしがないです。
>品質ぼろぼろ、コスト上げ上げ、納期りぎりぎ。

まず、「納期」の変更ができない場合は、ウォーターフォールの開発はまずいです。agileな開発手法では、「優先度の高いものだけ終わらして納品」ということが可能ですが、ウォーターフォールでは、全工程がシーケンシャルに実施され、最終工程が終わらない限り、物自体が何も無い状態となります。 また、各工程の終わりに、次の工程に進むかどうかの判断が行われ、十分でないと判断された場合はその工程の成果物の修正、最レビューを実施する必要があります。もし、最初からぎっしり線表を引き、納期の変更ができない状況では後ろの工程にしわ寄せが行き破綻します。 そのため、納期は状況に応じ、いくらでも延ばせる必要があります。もちろんコストについても納期の遅れに伴い上乗せできる必要があります。

次に、ウォーターフォールでは、要求を理解し、仕様書から実際のプログラムを予見でき、ユーザーの要求とのギャップを指摘できる頭のいい人物がレビューアとして（特に上工程に）必要です。agileな開発手法では、プログラム自体を動かしてレビューすればよいため、一般的なユーザーのレベルの人物でも十分ですが（実際に想定ユーザーと同レベルの方がより良いフィードバックを期待できる）、ウォーターフォールでは、実際のプログラムができるのはずっと先、受け入れの段階であり、その前までは紙の上での議論に始終します。そして、紙の上の話は、完全に固めてから次の工程に進む必要があります。そのため、実際の想定ユーザーを熟知し、紙の上の話と現実に要求される事項とのギャップを指摘できる人物が必要です。

最後に、各工程において、レビューに参加、工程移行の承認をし、万が一仕様と要求とのギャップを見抜けなかった場合や、前工程で欠陥を見抜けなかった場合には全ての責任を取ってくれる（納期延長、予算拡大する）ユーザー（ステークホルダ）が必要です。また、この人物は、プロジェクトの途中で部署異動。退職などが絶対に発生しない人物であることが求められます。

以上の３つの条件

• 柔軟な納期
• 頭の良い人物
• 責任を取るユーザー

が全て揃っているならば、かなりの確率で成功すると考えます。恐らく失敗したプロジェクトは上記のうち、少なくとも1つ以上欠けていたのではないでしょうか？
次回は、全条件を満たしてから再チャレンジしてみてください。

Re:笑いとしてはイマイチなような

[Anonymous Coward]

これは通常いないもの・ありえないものを大真面目に
前提として書くことで皮肉にしてるんじゃないの？
だからウォーターフォールはうまくいかないんですよって。

いってみれば努力と幸運と機会があれば成功できますって
いってるみたいな感じ？これが「参考になる」モデで
いいのだろうか・・・

＃笑い系でもないので「面白おかしい」もちょっと違うけど