プロジェクトマネジメントは誰のものか

最近立ち上がった勉強会での一コマ。

「若いうちからプロジェクトマネージャにアサインするケースがあるじゃないですか。でも、プロジェクトマネジメントの全体をわかっているわけではないので、日々の転がしで精一杯なんですよ。そう言う状況で経営にも報告しなければならないのって、すごく無理がありませんか」

「プロジェクトマネジメント自体が経営者のものだからねぇ。経営の見通しをするために進捗中のプロジェクトの健全性を把握するためのツールだし」

「そこにたどり着くまでにどれだけ時間が掛かるか…」

「プロジェクトマネジメントは経営のものだという前提に立って、経営に報告するためのインタフェースがレポートに当たるわけで。プログラムと同じでインタフェースのお作法は守らないと通信できないでしょう。だから、進捗管理をレポートに合わせられるメッシュでデータを持っておく必要があるし、そうしておかないとレポート用にリソースを割かなければならなくなってしまうんだなぁ」

プロジェクトマネージャになるとやらなければならないことがそれこそPMBOKに書いている知識エリア以上のことをやらなければならないので。

現場のチームを向けば、システム開発手法による実際のものづくりを進めなければならないし、それこそプロジェクトを経営者の代行としてマネジメントしなければならないので。

場合によってはプレイングマネージャだったりすると、一部のリソースはエンジニアとしての自分に振り分けなければならないことになってしまうので。

3つも帽子を被ろうとすると、それはそれで無理が出てくるわけです。だからプロジェクトマネージャは専任に、と言うよりはエンジニアとは分離せよ、なのだと思うのですが。

話はさらに続きます。

「経営がアジャイルでやろうとか、どこで齧ってきたのか突然バズワードを言い始めることがありますよね」

「世間ではあるようですね」

「どうですか」

「どうなんです、そちらでは」

「やばいですね。手段が目的…もあるんですが、プロジェクトのレポートをみて『アジャイルじゃダメか』とか」

「ウォーターフォールの事故数の方が積算では絶対数が多いいのにね」

「そうなんですよ」

「だから小さく、成功度合いの高いプロジェクトから適用しないといけないと言われるんだよね」

新しい手法に好感を持っていたり、広めたいと思っていたら成功させたいと思うことは当然です。失敗するとそこから学ぼうとする経営でなければ打ち切られて、2度と採用できなくなってしまいますから。

じゃあウォーターフォールはどうなんだと。

「アジャイルには標準がないと思うんですけど、何かテンプレートになるものがないですか」

「みんな誤解をしていると思うんだけど、ウォーターフォールだって標準ってないですよ。亜種ばっかり」

「そんなことはないのでは。エンジニアは誰でも知っているじゃないですか。それに特段、学習しなくてもウォーターフォールで開発を始められますよね」

「それは、エンジニアが過去に経験してきた経験知で予測して対応しているだけの世界ですよ。それが成り立たない上でのプロジェクトはすぐに崩壊してしまうんです」

結局、何かしらこれがテンプレートだと一旦仮置きしてそれをその組織の標準とするか、手続きのプロシージャだけを決めておくしかないのではないかと。

まあ、これがテンプレとできるくらいなら、ウォーターフォールであって当然なんだけれどどれだけあるんだろうなぁと思っているうちに、勉強会は続くことが決まったようでした。

さて、大元のプロジェクトマネージャはどう育てるのかしら。