アジャイルがダメだとかウォーターフォールがダメだじゃなくて、何を大切にするかで判断したらいい

on

アジャイルがダメだらしい
“全体スケジュールにコミットできない”とか“アーキテクチャ上の無駄が生じる”とかの理由でアジャイルがダメらしい。その上で、次の議論をなどと提言されているけれど、ちょっと違うことを思った。


プロジェクトマネージメントの界隈で生きているものとしては、実際、システム開発方法論なんてなんでもいい。プロジェクトが成功するためのやり方のヒントが欲しいだ。


誰かにアレがいい、コレがいいといわれたから鵜呑みにしてやるもんじゃない。プロジェクトを成功させたいからそのツールとして方法論を枠組みとして使うのであって、アジャイル(具体的にはスクラム)やウォーターフォールなんて空っぽで、現場で必要なのは空っぽの枠組みであるフレームワークを埋める実作業でのツールまでなければ、全く用を成さないんだ。


現実は厳しい
現実は厳しいよ。ウォーターフォールでもスクラムでも失敗するプロジェクトは失敗するのだ。それもかなりの割合でなんらかプロジェクトの当初の目標を達成していない。ソースは？PMIのPM Networkでも漁って欲しい。


失敗する理由はプロジェクトの外にも内にも両方にもあって、プロジェクトが唯一のものであるように失敗する原因もプロジェクト毎に違う。それでもなお、プロジェクトはやらないければならないし、やるなら何とか成功させたいと思うし、成功体験がなければ藁にも縋りたい気持ちになるものだ。


スクラムがダメだよと言う人は、アジャイル宣言やその背景で要求していることを見過ているのではないかと思う。その辺に歩いているエンジニアを捕まえてスクラムやってよっていっても出来ないよ。ウォーターフォールより精神論が強いもの。


一方、ウォーターフォールがダメだよと言う人は、成功させるためのプロジェクトの中での継続的なカイゼンをしながらプロジェクトをしたことがないんじゃないだろうか。理論的にはウォーターフォールは工程の繰返しもできるし、思っている以上に柔軟にやっても問題なく運営できるんだ。


スクラムもウォーターフォールも「これだ！」と言って決めて係るもんじゃないんだと思うよ。


アナタがプロジェクトマネージャなら何を大切にするかで判断したらいい
タイトルとおり。プロジェクトマネージャじゃなくても一人のメンバとしてでもいい。プロジェクトを成功させるために何を大切にするか。その価値観をプロジェクトのチームや顧客と共有すれば自然と解は得られると思うよ。


ウォーターフォールでも、もうちょっと上手にコミュニケーションを取ることを大切にしたいと思うなら、スクラムのデイリースタンドアップミーティングを取り入れたり、カンバンを取り入れたりすることが出来るんだ。


スクラムだって規律を求めるんだよ。ガチガチじゃないけれど、必要な規律は必要なんだ。それはウォーターフォールのプロジェクトに資産があるじゃないかな。それを、必要なところだけに削って使えばいい。


大切なのは、自分が何をプロジェクトの成功のために大切と思い、何を取り入れ何を捨てるかテラーリングすることなんだ。