「考えろ」組と「考えさせるな」組のせめぎあい

檜山正幸のキマイラ飼育記:ウォーターフォール擁護論

ウォーターフォールの利点、というか、私がよいと思うところは、実は大多数である(理解力/向上心/責任感的に)信頼できない開発者が混ざっても何とかさせようとした方法論であることです。
欠点は、実際には手戻りが当たり前なのに、手戻りのための手続きコストを下げる策がなく、(そのため終盤になると仕様変更に異常に拒否的になってしまい)最終的には顧客の要求を全て満たすことができないため顧客を満足させにくいことです。

いわゆるアジャイル(この言葉、何を意味してるかよく解らないので好きではありません)だと、Win-Win になれる可能性が高いのですが、全員に「考える」というスキルを要求するのでまさしく大規模な開発現場ではまず成功しないと思っています。

当然自分のプロジェクトでは「考える」ことができると確信している人しか加えないですけど^^;。

(追記)
「考えさせるな」について補足すると、ウォーターフォール(に限らず比較的多くのソフトウェア工学的)は、プロジェクトメンバーの最低レベルに合わせて作られるのが普通で、なんというか、そのいわゆる最低レベルに当たる人が中途半端に「考える」と、ひずみが出てしまう、という点と、できる/意欲ある人が「考える」と、多数の「うまく考えられない人」がついていけなくなったり、それを真似した結果悪い影響が出てしまったりすることを懸念した結果、意欲ある人まで「考えるな」と言ってしまうようなことが起こるのだろうと思っています。
どちらの方法論も、プロジェクトのメンバーの立ち位置をどちらか一方に集約することが前提になっているため、「通常の」ばらばらの能力の人たちが集まったプロジェクトにおいては、どちらの方法にしてもおかしなところが出てきてしまいます。

ということは、メンバごとにスタンスを選べればよいのではないか？と短絡的に考えられるわけですが、「考える」ことにあまり意欲がなかったり、向いてないと考えられる人が、自ら受動的スタンスを選んだとしても、本当にそれがしたいわけではないので、結局あんまり良い成果には結びつかなかったりします。

私だったら、やっぱりその人が一番好きなことの中でそのプロジェクトに役に立ちそうなことを探すのに一番集中するかな。まぁ既に方法論の話から逸脱してますが^^;。ただ、これを踏まえて言えば、「メンバーの気質に合わせて方法論を切り替える」ようにする、というのが自分なりの答えです。大規模プロジェクトに対する答えにはなっていませんが、大規模であっても、基本的な考え方は変わらないです。