ここ数回にわたってユーザー企業における情報システム部門，CIO（最高情報責任者），ユーザー部門，そしてトップを，ユーザー（業務）部門の眼で取り上げてきた。今回は，供給側であるベンダーのプロジェクトマネージャ（プロマネ）を取り上げたい。

　ユーザーから見ると，ベンダーから派遣されるプロマネには指摘したい問題や要望が沢山ある。それらを解決しないとシステムはトラブルを起こし，ベンダー自身もやがて行き詰る。

任命されたはずのプロマネが行方不明に

　IT導入のプロジェクトが立ち上がると，プロジェクトマネージャが任命されるはずである。ここで“はずである”というのには，理由がある。実際は，プロマネが不明確だったり，プロマネの行方がしばしば分からなくなることがある。筆者にも，時としてそうした相談が持ちかけられる。

　プロマネが不明確になる代表的なケースは，プロマネとして紹介されたのが，実はベンダーの名刺を持たされたベンダー外注先の若手に過ぎなかったというものだ。その若手がリーダーシップを取れなければ，実質的にプロマネ不在になる。請負元の名刺を持たされてプロマネに任命された若手にしても，いい迷惑だろう。プロマネが行方不明というのは，複数のプロジェクトでプロマネを兼務しているらしく，一つのプロジェクトに関わっていられないというものだ。こちらは兼務なのに，専任面（ヅラ）を装うのが大変だろう。

　IT業界は慢性的にプロマネ不足の状態にあり，こういうことは今後も起こり得る。由々しき問題ではあるが，ベンダーの方針に起因するものでもある。

　このようなベンダーの方針に起因する不具合は，まだまだある。例えばプロマネは，自分が統括する組織の人事や予算について権限を持つとされている。しかし，そんなプロマネにお目にかかったことはほとんどない。自社のラインの職制にいちいち伺いを立てたり，社内調整に手間取ったりしている。結果として，結論を出すのが遅れたり，結論が曖昧になったりすることは稀（まれ）ではない。ユーザーにとっては，いい迷惑だ。

　さらに，ベンダーでのプロジェクトマネジメント体系の整備やプロマネ教育が不十分なせいか，経験と勘に頼るプロマネが多い。リーダーシップやコミュニケーションやリスクのとり方，新技術に対する知識や対応などに個人差が見られ，困惑させられる。

決断力がない，イエスマンも問題を引き起こす

　プロマネ自身の資質に起因する問題もある。

　筆者自身，何も決めることのできないプロマネに悩まされたことがある。製造業A社で，あるときERP（統合基幹業務システム）の導入プロジェクトが組まれた。このときのベンダー側プロマネは何も決められず，担当者がそれぞれ都合の良い解釈でプロジェクトを進めた。当然，後日問題が発生した。A社側のプロジェクトリーダーはとうとう我慢できなくなり，会議の時に結論を逐一確認し，記録しながらプロジェクトを進めることにした。それでも問題は相変わらず多発した。A社はベンダーにプロマネの交代を申し出たが，人材不足で，結局泣き寝入りとなった。

　イエスマンのプロマネも，トラブルメーカーだ。製造業B社におけるSCM（サプライチェーン管理）導入でベンダーから派遣されたプロマネは，一見優秀だった。歯切れは良く，ユーザーの要望をほぼ100％聞いてくれた。しかし出来上がった要件定義書を見て，B社の関係者は驚いた。B社の要望が，ほとんど無視されていたからだ。問い詰められたプロマネは力なく答えた。「（ベンダーの）社内で全て却下されました」。

　プロジェクトを成功させる重要な鍵の一つは，トラブルの芽をいかに早く摘むかである。それはプロマネの仕事である。そのためにプロマネは触覚を鋭く研ぎ澄まし，コミュニケーション力を発揮し，現場の悪い情報を把握しなければならない。決めることができないプロマネ，イエスマンのプロマネは周囲から軽んじられ，情報が入らない。いわんや悪い情報を好まず，窮地にあるメンバーを突き放すプロマネも，情報から疎外される。

　しかし，プロマネが可哀想で，同情したくなることも少なくない。プロマネがその上司から理不尽に叱責されたり，プロマネが泣いているのを目撃したことも，少なからずある。どうやら，何もかもプロマネの責任として押し付けられることが多いようだ。最初から赤字受注と分かっている案件でも，納期や品質が最初から無理な計画でも，それを何とかするのがプロマネだと，あらぬおだてられ方をされる。あるいは当事者意識が低いユーザーが，プロマネに業務を丸投げする。ユーザー企業内の調整までを，プロマネ任せにしようとする。

　そして結果的にうまくいかないと，すべてについてプロマネの責任を厳しく問う。

このままではプロマネは気の毒な職業

　プロマネには奮起を促したい。だが現状のままでは，プロマネとはある意味で気の毒な職業だ。「気の毒な職業」から脱出させるためには，状況を改善しなければならない。

　まず，プロマネ自身に心してもらわなければならない点がある。プロジェクト発足時にベンダー企業のサポートを取り付けることだ。このとき，プロジェクトを後方支援するはずの組織である「PMO（Project Management Office）」が管理中心で，支援が形式的なものであれば，そのことをあからさまにして，実質的な支援を取り付けるよう努力する。その上で，できないものはできないと周囲を説得する。それがプロマネの義務というものだ。

　基本的には，プロマネは人間的魅力を備えなければならない。こうした備えるべき資質については，随所で議論されているので，ここではこれ以上の詳述は避ける。

　ベンダー側にも，取り組んでもらいたいことがある。

　ベンダーは，プロマネ個人の力に大きく左右されない，普遍的なプロジェクトマネジメント手法を導入する。なおかつ，プロマネ不足の時代背景を踏まえて，プロマネ育成の体系を確立しなければならないのではないか。

　プロジェクトの形態が変化したことで，プロマネの負荷が増えたとも言われる。外注企業や競合企業とのコラボレーションやグローバル化で，プロジェクトのステークホルダー（利害関係者）は増えた。セキュリティへの要求が厳しくなり，ネットワークやソフト開発における技術面の間口・奥行きも深くなった。その一方で，プロジェクトが小型化して，ユーザー企業側の力が落ちてきたとも言われる。これらの背景がプロマネの負荷を増やしているのだろう。

　ベンダーにおけるプロジェクトマネジメント体系の確立とプロマネの育成が待たれる。例えば，賛否両論があるものの，国際的なプロジェクトの知識体系である「PMBOK（Project Management Body of Knowledge）」の採用などがあり得るだろう。ここで主張したいことは，プロマネの仕事が個々人の力量に左右されることがないように，あるいはプロマネに全てのしわ寄せがいかないように，ベンダーが体制を作るべきである，ということである。

　もちろん，プロマネ自身の奮起がその大前提となる。