プロマネを育てる 長期戦
プロマネを育てるとタイトルをつけているけれど、実は育てることなんてできないのです。育って欲しい側は、育てる対象に手間隙を掛けているので育てたつもりになっているのですが、実際には育てられる側がその気になって若しくはやむなしと思わなければプロマネの亜種にしかならないです。
機会があれば、すっかりプロマネになってしまった人に何しをしたらプロマネになれるかを尋ねてみてください。自分から選んでプロマネになった人もいますが大概はPMにアサインされているうちになったと答えるでしょう。
最初はエンジニア
新人エンジニアでいきなりプロマネをやらせているとしたらそれはすごい組織ですね。だって、システム開発のシの字の知識もないままでプロジェクトをマネジメントさせるんですよ。
システム開発の対象となる業務ドメインの知識を専門家としてどこまで深掘りする必要があるかというと仕組みが概念化できる程度は必要です。概念化でモデルとして語ることができれば、専門家の意見に対して意思決定ができるからです。
システム開発スキルの習得
プロマネをするためには、プロジェクトマネジメントの方法論はもちろん、システム開発手法や生産性に見合ったツールや運営補助ツールなどの知識はもちろん、実践するスキルは必要ですし交渉などの基礎スキルも必要です。
専門家としてのプロマネはプロマネのスキルがあれば十分なのかもしれません。机上のスキルでよければ。
リスクを識別する知見の習得
PMBOKのような欧米での専門家としての責務を果たすならそれで良いでしょう。ただ、その場合も業務ドメインや適用技術に関する知見を持っているメンバをアサインすることが前提です。
なぜなら、そうした知見とシステム開発の複合で構成するために起きる不整合がリスクの発生源となるからです。
このようなリスクは形式知からも学ぶこと(=知ること)はできますが、リスクを発見する感覚を使い物にするためには相応の実践が必要です。
プロマネ候補者自身の識別
プロマネ候補者自身が自分でどの領域、どの程度のビジネスサイズのプロジェクトならキャリーできるのかは知っておかなければなりません。
なぜなら、人には目の届く範囲があるからです。その範囲は、人により違います。だから、自分はこの人数ならコントロールできるという閾値を知っておかなければキャパオーバーとなって失敗をするのです。
マネージャは交代する
プロマネ候補者である対象者は一人ですが育成する側のマネージャは組織の都合で代わります。あまり気にする人はいないと思いますが、これは実は大事なことです。何が大事かというと、マネージャは一時的にしか関与できない脇役でしかなく、主役はプロマネ候補者自身であるということがはっきりするからです。
プロマネになろうと意思決定して、それをやめようと決断するまでの間、プロマネ候補者と付き合えるのは本人だけです。そのくらいの長期戦になるのです。