「できるPM」と「それなりPM」との差とは？：有能プロジェクトマネージャ育成術（3）（2/2 ページ）

[大上建（株式会社プライド），ITmedia]

一般PMへのインタビュー：O氏の場合

　第1 SI事業部からもう1人O氏にインタビューを行った。

　O氏のプロジェクトでは、アウトソーシング事業部と共同で、システム保守を請け負っている。包括的な契約であるため、よほどの大きな変更でない限り、固定した請負金額の中で保守を行うこととなっている。

　包括的契約であることが背景となり、ユーザーは本当に必要な要件とそうでないもの、単なる使い勝手の改善など「かゆい所に手が届く」システムを、要件を峻別（しゅんべつ）せずに要求してくることが多くなった。従来の契約から包括契約になった当初は、それに対して安易に対応していたため、急激に利益率が低下したそうである。

　利益率の低下は事業部内で問題となり、対策が求められている。しかしユーザーが要求してくること自体は契約どおりであるため、直接的に要求を拒否することはできない。そこでO氏は次のように考えているそうである。

• ユーザー要求の安易な受け入れは、E社の利益率の低下を招くのみならず、システムの母体の肥大化や複雑化を生み、最終的には、保守性や変更容易性の低下を招く
• これはユーザーにとっても長期的には、要求対応期間の長期化や、包括契約金額の上昇となって跳ね返ってくるため不利益である
• 今後は長期的な利害を説明し理解を得たうえで、本当に必要なスコープや要件を見抜き、優先順位を明確にし、それをユーザーに示すことで合意を得ることが必要である

　O氏は現在この対応に取り組んでいる。ユーザーも長期的に不利益を招くこと自体は理解してくれるそうであるが、いざ個別の要件になるとなかなかうまくいかないそうである。しかし、うまく説得できる兆しはあり、O氏は「何か感じるものがあるんですよ」とコメントしていた。

-	一般PMへのインタビューから分かったこと

　一般PMのうち数人に見られた傾向として、PMノウハウを持っているように振る舞うということが挙げられる。このような人たちに、ノウハウを使ってうまくプロジェクトを実施した実例を聞いてみると、いつまでたっても実際の話にならず、論理の詳細化が続くのである。このような場合、一見PMノウハウに見えるものは、自分自身のものではないか教科書で学んだだけのものである。だから実際の事例がないのである。

　一般PMに支配的なビヘイビアだったのは、そもそも与えられた目標をただ達成すればいいという気持ちであった。それに対して有能なPMたちに共通していたのは、与えられた目標よりも良くすることに執念を燃やしていた点である。一番の違いは、結果を出すことへの執着心の差である。多くの場合、それは上司の同様の考えや行動を見て身に付けたものであった。

　そんな一般PMの中でも、N氏のように自らの行動規範に関しての信念を持っている少数の人がいた。このような信念の持ち主も、やはり上司の影響を受けてのものであった。

　このような結果に対する執着心や行動に対する信念なしにPMノウハウだけを教えても、一般PMが有能PMになれるわけではない。M氏が典型的な例であったが、PMBOK（the project management body of knowledge）などの理論を学んだだけでは、PMノウハウは身に付かない。

　PMノウハウは、第1回「ハイ・パフォーマーの“知”は、移転・共有できるか？」でも説明したように“個人のメソドロジ”である。組織においてメソドロジが機能するために組織的文化が背景に必要なように、個人でもメソドロジ実行の執着心や信念が背景に必要である。

　有能PMやN氏のような人は、ユーザーや部下を引き付ける魅力がある。信念に基づいた一貫した行動はパワーを持っているのである。有能PMを育てるのも有能PMであった。有能PMが1人いることの波及効果は非常に大きい。

　また、PMBOKはプロジェクト・マネジメント技術としての「方法」と「プロセス」を解説したものであるため、メソドロジ構造の中の、「コンセプト」を自分で持っていない人には、大きなパワーとはならないのである。建設やエンジニアリングなどの業種におけるプロジェクト・マネジメントでは、コンセプトは自明であるため、あらためて説明する必要はないが、ITにおけるプロジェクト・マネジメントでは、コンセプトを身に付けて初めて有効に活用することができるのである。M氏が、知識はあっても結果を出せていないのはここにも原因がある。

　一般PMの中には、O氏のように有効なPMノウハウに気付いている人もいた。O氏の考えは効果の大きなコンセプトであるが、それがうまくいかないことがあるのは、コンセプトを実現させるための「方法」レベルの技術、視点、達成水準が不足しているのである。インタビューの中で不足していると認識されたものは、優先順位の決定基準、ユーザーの信頼を得る進め方、などである。

　優先順位の決定基準について、われわれコンサルタントからいくつかのアイデアを提示し、O氏が自身の状況で効果が高そうだと判断したものは、「要件がユーザーのコア業務に寄与する度合い」と「ユーザーの中での要件の醸成度合い」を2軸に取り、両方の度合いが高いものを優先する考え方であった。

　O氏のように、現状の中から気付きを得てそれをコンセプトにすることのできる人がいる。これをPMノウハウとして完成させるためには、PMノウハウのフレームワークで示したような「技術・知識」「プロセス」を充足させなければならない。しかし、これも単なる知識としてでは役立つレベルでは身に付かない。そのためには、矢面に立たせてユーザーにしかってもらうこと、そして苦労して目標を超え、ユーザーに褒めてもらうことが必要である。

　PMノウハウを組織的に伝えるためには工夫を要する。