プロジェクトミューズ　バイリンガルプロジェクトは辛いよ　～その6～　プロジェクトマネージャとは？

このプロジェクトには本当に振り回されっぱなし。そもそも言葉の壁がある中で、当たり前が当たり前でない難しさ、プロジェクト管理方法が根本から違うことに起因する発注側の期待と請負側の温度差の違いには、さすがの私もあっけに取られることが続出しています。

今回のテーマはプロジェクトマネージャ。普通、プロジェクトマネージャといえば、プロジェクトの総責任者。計画通りに進捗するようスケジュール管理をしたり、遅れが発生した場合にはその遅れを取り戻すべく対策を講じたり、何か決断を迫られた場合には最終決定権があるポジションと考えるのが当たり前ですよね？　このプロジェクトミューズでも、発注側はPMにこのような役割、権限、責任を期待していました。

ところがです。開発に遅れが出始め、進捗管理の不備を指摘しても、このPMからは「具体的な進捗の詳細は開発チームの責任者（アーキテクト）が掌握しており、自分の担当ではない。」とのたまうようになったのです。納得できない発注者が請負業者の責任者に問いただすと「うちはチーム体制でこのプロジェクトを管理している。PMと要件定義するアーキテクトと要件を設計・実装方法に展開するアーキテクトで分業している。」というのです。

連絡のやり取りは現地に常駐しているPMが窓口になっているのですが、技術的な質問に対するアーキテクトからのコメントや回答をPM経由で、後日アーキテクト自身と話をした時に話が合わず、PMからの回答を元に決定したことが反古にされることが発生し始めました。またPMとの間で合意した事項が、後日アーキテクトによって覆されるという問題も起きています。

アーキテクト達は他の案件との掛け持ちなので、このプロジェクトだけに係っているわけでもなければ、現場に常駐しているわけでもありません。なのでPMが連絡窓口に指定されてきたわけです。

ところが、アーキテクト本人相手でなければ、具体的なことは何もできないとわかった時点で、PMを窓口に連絡のやり取りをすることの無駄と欠点が表面化されてきたのです。

しかもこのPM、議事録の作成だけはしてくれても、開発の遅れに対する施策を提案するわけでなし、個々のデベロッパーや機能要件開発の進捗状況を把握しているわけでもなく、PMとしての機能を果たしていません。単なる「秘書役」とあまり変わりがないのです。まったく気配りがなく、気が利かない分、秘書よりはレベルが低いと言っても過言ではありません。

PMのパフォーマンスの問題を請負業者の責任者にエスカレートさせると、彼はPMを一方的に弁護するばかりで、「I think he is doing very well. This challenging project is well managed. I am not involved in the project and thus I have no idea about the details. The details are up to the project manager. (彼はとてもよくやっていると思う。この難しいプロジェクトをうまく管理している。私自身がこのプロジェクトを担当しているわけではないので詳細についてはいっさい知らない。細かいことはPMに任せてある。）」というお門違いの発言はまったく相手になりません。

問題の根源は、この責任のたらい回しにあると言えます。
「プロジェクトの責任を持っているのはPMだ」と言う請負業者の責任者、一方でPMは単なる連絡係りとしてしか機能しておらず、開発の実質的管理は実装担当アーキテクトが行っている。そのような分業制の中で誰も「自分がプロジェクトの責任を持っている」という自覚がないことが明らかになったのです。

さてこのような場合、どうすればよいのでしょうか。
このPMは責務を果たしていないという問題の他、最近、不貞腐れた態度を取ったり、無責任な言動が多く見られるようになったため、発注者から更迭要求が出され、近々解任される予定です。
担当者が変われば解決する問題なのでしょうか？
実はこのPMは2代目で、前回のPMも似たり寄ったりの管理スキルしかありませんでした。
問題の根本は、「PMの役割と責任」の定義が発注側と請負側でまるで異なっているという点にありそうです。だとすると、いくらメンバーチェンジをしても問題の解決にはなりそうもありません。

当面考えられる対策は：
（1）PMに期待する責任と役割を明文化し、該当する人材を任命してもらう、
（2）発注側でPMを用意する、
という2つのオプションです。けれどもどちらにも一長一短あります。

（1）の場合、同じ会社の社員であるという連帯感、通訳を介さずにプロジェクトメンバーと会話ができる、プロジェクトチームとしての責任境界点が明確になるというのがメリットである一方、PMに期待する役割を一字一句明文化することは非常に困難です。しかもこれまで2回うまく行かなかった手法であれば3度目ならうまく行くという保証はどこにもありません。

（2）の場合、PM対プロジェクトチームの心理的摩擦が危惧されます。管理されることに慣れていないこのプロジェクトチーム（チームメンバーは国連よろしく世界各国のデベロッパーの集まり）とマイクロマネージメントと呼ばれる細かい管理したがる日本の慣習の格差も心配です。プロジェクトチームと直接会話ができるだけの英語力があり、ある程度技術のこともわかり、かつ優秀なプロジェクト管理能力の人材を探すというのは並大抵のことではありません。ただし、（2）のオプションには、発注側が自分達の納得のいくプロジェクト管理を試すことができる、今まで重視されてこなかった側面を強化できるというメリットが期待できます。

発注側が提示した現PMの解任時期は8月末。当面は時期プロジェクトのPMがこのプロジェクトのPMを兼任することになっており、とりあえずは（1）案が実行されることになります。このPMに対向する発注側のPMをどのように決めるのか。ここが肝になりそうです。