エンジニアリングとしてのプロジェクトマネージャの育成フレームワークのデザイン


研究会のあとの懇親会にお誘いされて、自分でも珍しく「出てみようかな」と思って出てみたら割とこじんまりとした人数で普通の居酒屋のテーブル席に納まる。


どうやらほとんどの出席者は顔見知りのようで、こうしたときにはビジネスマンらしく名刺で素性を認識させるのが面倒な手間をかけなくていいので名刺を配りながらも、顔見知りの方には所属が変わった旨をお伝えすると、先方も変わったらしいことを知る。


まあ、好き勝手に話はするのだけれど、人が話している間はきちんと聞いた上で、それぞれが疑問に思っていることを話したり、話の風呂敷を広げてみたり。なにより、人の話をさえぎるようなことがないのは当たり前なことなんだけれど、できていることをみると高学歴な人たちの中に間違って混ざっている自分のことは棚に上げてでてよかったと思う。


いろいろ話したような気がするのだけれど、研究会のテーマはプロジェクトマネジメントであることと、今、自分が関心を持っていることが育成なのでそうしたことしか思い出せない。


やはり、飲みながらでもノートとペンを出して、キーワードをメモっておくことをすればよかったと思う。飲んで寝てしまって挙句に忘れてしまってから思ってもしょうがないことではある。


プロジェクトマネージャは育成できるか
プロジェクトマネージャの育成は今始まったことではない。2000年代前半にPMBOKが流行ったのも「プロジェクトマネージャの担い手がいない」からである。あれから10年以上経過しているけれど、プロジェクトマネージャが余っているという話は聞いたことがない。


連綿と当時から言われ続けているのは「プロジェクトマネージャになりたいくない」である。


そうはいっても、現場では毎年ロールが上がるシステムエンジニアは意思を持ってか、マネージャの判断によりプロジェクトマネージャにアサインされる。それが繰り返される。


そこにあるものは、プロジェクトマネージャのラベルを貼られたシステムエンジニアが顧客の前で右往左往しているだけである。


そしてないものは、体系的なプロジェクトマネージャの育成である。


育成を放棄することで失っているもの

OJTで十分」「自分で学ばないと身につかない」


これは育成をしない口実である。資質を持ったプロジェクトマネージャが自然発生的に生まれることでよしとするならそれもありだろう。だが、中期経営計画から落ちてくるビジネスを実現するためにはサイズアップしたプロジェクトを受注するか、プロジェクト数を増やすか、高い収益なビジネスに転換するか、コストを圧縮したプロジェクトを選ぶほかない。


4つあるタイプのどれを取っても辣腕を振るえるプロジェクトマネージャが必要であることには変わりないし、プロエジェクト数を増やすということは、失敗しないプロジェクトマネージャの増員が必要なのである。


つまり、プロジェクトマネージャの育成を放棄することはマネージャとしての、将来のキャリアを自ら絶っているということなのである。


体系的な育成をデザインする
体系といっても、教科書を並べて座学で教えるようなものだけでは不十分なことは明白である。知識を与え、テストがよければ良いプロジェクトマネージャが得られるのであれば、2000年代前半から続いているプロジェクトマネージャの不足は解決している。


机上では、形式知だけではどうにもならないし、PMBOKの方法論だけではプロジェクトをキャリーできないことは自明なことだ。


形式知と実践知を身につける体系的な育成デザインのフレームワークが必要なのである。それをデザインできないマネージャや組織はプロジェクトマネジメントをエンジニアリングとして概念化できていないのである。


たしかに、身につけなければならない知識の中には、エンジニアリングとして検証できるような性質とは違うエリアがあることは認識した上で、それでもなお、一つのパターンに落とし込むことで、そのパターンの仮説が正しいかどうかを検証しながら全体としてはエンジニアリングとしての育成のデザインを試みることが必要なのである。