プロジェクトはPMBOKでもウォーターフォールでもアジャイルでも失敗する


横に座っている同僚がトラブルになりかけているプロジェクトをサポートしているのです。現場のマネージャから要請があって、の対応なのですが端から聞いているとその状況がちょっと酷い。何が酷いかと言うと、プロジェクトマネージャを担っているエンジニアにその責務を果たせるほどのスキルがない、らしい。だから、問題点を洗い出して、課題を設定して伝えてもプロジェクトマネージャのエンジニアには理解できないようでヒューズが飛んでしまうらしい。何せ、隣の席に座っている人の大きな声のツイートを耳をダンボにして情報を拾っているだけなので「らしい」ばかりでソースが怪しく聞こえるのはご愛嬌なので。


ならと、隣を向いて「で、どうしたの?」と促せば小1時間、は言い過ぎだけどアレコレとプロジェクト上の課題を教えてくれる。「それは大変だ。」「プロジェクトマネージャの仕事をしていないなぁ。」とワタシの感想はそんなところを行ったり来たり。


プロジェクトは失敗する。


それは、明らかなことだから、誰もが成功するために様々な試行錯誤と暗黙知を持ち寄って形式知に仕立て上げ、それを試みている。ソレの一つがPMBOKなのだけれど、様々な業種で適用すること目指した結果、あまりにも汎化しすぎてしまいプロジェクトマネジメントのフレームワークという器の存在になってしまっている。その姿が良いのか悪いのかと問われれば、そうした概念は必要なのだと思う。プリミティブなことを辞書のように積み上げられて「理解せよ」と言われるより概念で伝えられた方が理解しやすいのだから。だから、とても必要だし、その価値はある。概念としても良く出来ていると思うんだ。


ただ、現実のITプロジェクトをキャリーするということを目の前にして、「では、どうするのか。」と実利的なところで経験の少ないプロジェクトマネージャは手が止まってしまうのです。それは、システム開発方法論を体系的に学んでおらず、それに関した形式知を知らないからね。知らない、それはそのプロジェクトマネージャの知識の引き出しが空っぽだということ。空っぽだから過去の経験しか持ち合わせておらず、その拙い限定された経験値を持ち出してコトに当たろうとするというループに入る。だから、失敗するんだ。


zdnetの調査によれば68%のITプロジェクトは失敗する。スコープ、コスト、スケジュール。どれか一つでもオーバーランすれば予算は超過し、失敗に至る。追加養蚕が出なければ、受託側がコストオーバーランを招き、追加予算を出すことになれば、委託側がコストオーバーランを招く。ひいてはスケジュールオーバーランを誘発し、とあとは語るまでもないわけで。


でもその失敗もいきなり失敗するわけではないので。小さな予兆に気づかずになんでも積み重ねてしまう。だから、ひとたび何かの拍子に崩れ始めると一気に崩壊したように見える。けれど、プロジェクトはそんなことで失敗はしないんだ。


では、アジャイルシステム開発手法として取り入れたらプロジェクトはうまくいくのだろうか。勿論、そんなことはないです。アジャイルだろうが、なんだろうがシステム開発手法がプロジェクトの問題や課題などのリスクをコントロールする魔法の杖でも銀の弾でもないことはご承知のとおりで、それを使う側の器量に委託されるからなのですよ。


PMBOKでもウォーターフォールでもアジャイルでもダメなのか。


当たり前のことだけれど、やったようにしかコトの結果はついてこない。それは、中学校のテストで学んできたハズで。掛けた手間に見合った点数しか取れない。テストの問題見合いのところもあるけれど、それは顧客の要件の不明瞭なことのようなものだ。いや、それよりは不確定さの振れはすくないかもしれない。いずれにしても、手間賃だけしか得るものはないのだ。


それは、実現したい、ここではプロジェクトを成功させたいという目標を識別し、共有できるゴールを設定し、そのゴールにたどり着くための手段を示し、試行錯誤しながら次の行動を修正しながら進む他ないのです。何を持ってきても、結局、持ってきたもの、手法を使うのは人なのですから。人が、エンジニアが、プロジェクトマネージャが失敗しないように、成功するように自分から働きかけないとどうしようもないのです。手法、ツールはそれを少し助けてくれるだけなのです。