プロジェクトマネジャーは「プロジェクトのクレーム処理係」なのか？：あるプロジェクトマネジャーの“つぶやき”【第2回】
プロジェクトマネジャーには、複数部門の異なる立場にあるステークホルダーの意見をまとめ、プロジェクトを成功に導く使命がある。今回は失敗談を基に“プロジェクトマネジャーの役割”を考えてみる。
一口に「プロジェクトマネジャー」と言っても、その業務内容はそれぞれの会社や案件によってさまざまではないでしょうか。当社におけるプロジェクトマネジャーは“プロジェクト全体のまとめ役”はもちろんのこと、プログラミングやテストケースの作成などを行うこともあります。開発工程の多くに直接的にかかわることができるので、わたし個人としては喜ばしいことです。
プロジェクトマネジャーという立場であっても、わたしと同じように「システムの仕様策定や実装などの工程が好きだ」という人も多いと思います。やはり自分が手掛けて、モノが出来上がることは、とても喜ばしいものです。また、「コンピュータが好きでIT系の職に就いた」という経緯や、元来「人任せにすることが好きではない」という性格もあり、そうした気持ちがわたしは余計に強いのかもしれません。
しかし、プロジェクトのまとめ役がコーディングやテストなどの実作業を始めてしまうと、プロジェクト全体の進ちょくが止まることがあります。当たり前と言えば当たり前のことですが、いざ作業を始めるとついつい没頭してしまいます。その“ついつい”が原因でこれまでに幾度かの失敗を経験してきました。今回は、その失敗談を基にわたしが考える“プロジェクトマネジャーの役割”について、つぶやいてみたいと思います。
あるプロジェクトでの失敗談
あるプロジェクトで、「すぐに終わるだろう」と考えて手を付けたコーディング作業が予想に反して時間がかかり、その翌日も作業に没頭してしまったことがあります。その後、プロジェクトメンバーに各自の進ちょくを確認すると、Aさんは「Bさんのタスク待ちだ」といい、一方のBさんは「Aさんのタスク待ちだ」といった、まさに“デッドロック”のような状況が発生していました。
各メンバー間のタスク調整は彼らの仕事ではなく、プロジェクトマネジャーであるわたしの仕事です。コーディングに夢中になるあまり、メンバーのタスク調整を怠ってしまったのです。プロジェクトの指揮を執り、メンバーをまとめる立場にあるわたし自身が、プロジェクトメンバーに迷惑を掛けてしまいました。申し訳ない気持ちで居たたまれなくなり、深く反省しました。
また、プロジェクトメンバーへの情報共有を怠ったために、彼らを困らせてしまったこともあります。
あるプロジェクトで前日の作業が進んでいないメンバーがいたので、その理由を尋ねた際に「開発環境でアプリケーションが突然動作しなくなり、その原因を調査していたために作業が進まなかった」という答えが返ってきました。
わたしは、進行中のほかのプロジェクトについてもある程度把握していたので、すぐにその理由が分かりました。実は、別のプロジェクトが共有の開発環境をテストのために使用していたことが、こちらの開発プログラムに影響を及ぼしていたのです。しかし、そのことを知らないメンバーは“答えの出ない調査”に時間を取られ、結果としてプロジェクトの進ちょくが遅れるという事態になってしまいました。
これは「他プロジェクトの作業によって、このような事態が起こる可能性がある」ことを事前に周知していなかったわたしのミスです。プロジェクト内で情報共有がなされていれば、そのメンバーも自身でタスクのスケジューリングを前後するなどの対応ができたことでしょう。プロジェクトマネジャーがプロジェクトに及ぼす影響の大きさをあらためて認識した出来事でした。
プロジェクトマネジャーは「クレーム処理係」？
これらの失敗を踏まえ、わたしは「プロジェクトの“主役”は、設計／実装／テストなどの実作業を行うメンバーであり、彼らが快適に仕事を進められる環境を用意すること」が、プロジェクトマネジャーの役割だと意識するようになりました。
そのために、ほかのプロジェクトやメンバー間で作業が重複しないように調整したり、メンバー間の情報共有がなされているかなどを確認して回るなど、プロジェクトメンバーが自身の役割を理解して、業務に専念できる環境を用意することに努めています。こうした裏方的な業務こそが、プロジェクトの進ちょくを上げる潤滑油になっていたりします。各メンバーに効率よく作業してもらい、1つのチームとして機能できるようになると、プロジェクトの生産性も向上するものです。
しかし、実際には雑用とも思えるような作業もあって、つらいものです。以前のわたしであれば「それくらいのことは自分でやってほしい」と思わず口に出してしまいそうな場面でも、その言葉をぐっと飲み込んでいます。
プロジェクトマネジャーには潤滑油という意味で、もう1つ重要な側面があります。それは「プロジェクトのステークホルダー（利害関係者）間で円滑なコミュニケーションができるように努める」ことです。
多くのプロジェクトでは、社内外の複数部門にまたがるステークホルダーが存在します。その立場によって、業務要件やITに関する知識は異なります。中には、「自身で納得してからでないと、プロジェクトを進めたくない」という人がいます。ステークホルダーの了承を得てから、プロジェクトを進めることがプロジェクトマネジャーには求められます。
時には、プロジェクトとは直接的に関係しない部分を説明しなければならないこともあります。わたし自身、そうした説明をすることを面倒だと感じることが少なくありません。しかし、納得して進める場合とそうでない場合の効率の差は目に見えるものがあるのも事実です。そのため「その仕様に至った背景とは？」「この機能を実装する意味は？」と問われれば、「そこは（直接的には）関係ないです」という言葉をぐっとこらえて説明しています。
また、まれにプロジェクトメンバー同士で対立することがあります。こういう場面こそ、プロジェクトマネジャーの出番ではないでしょうか。実際の現場では、当事者が直接言い合ってもなかなか折り合いがつきませんし、堂々巡りになってしまいがちです。
プロジェクトマネジャーは双方の意見や愚痴を聞きつつ、相手方の立場を説明して理解してもらうことに努めます。時には、「なんで自分が……」という言葉をぐっと飲み込んで、折衷案を出したりすることもあります。ただ、実際にはそれぞれの主張が正しく思えることも多く、困ることもあります。皆さんにもそういう経験はありませんか？
プロジェクトマネジャーはプロジェクトメンバーの執事たれ
プロジェクトマネジャーは、プロジェクトの“主役”であるプロジェクトメンバーの“執事”という存在だと思います。その業務は、各メンバーのタスク管理や進ちょく確認、ほかのプロジェクト案件との調整、開発担当のベンダーのフォローなど、多岐にわたります。担当業務の中には“雑多とも感じてしまう”作業もあります。しかし、「主役たちが快適に仕事を進めることができる環境をいかに用意することができるか」が重要ではないでしょうか。
＜筆者紹介＞
小崎敬介（こさき けいすけ）
カブドットコム証券株式会社システム本部システム統括部システム開発課
2005年カブドットコム証券株式会入社。広島県出身。オンライン証券取引システムの設計開発運用業務に従事。主に発注系システムを担当する。座右の銘は、「『負けました』と言って頭を下げるのが正しい投了の仕方」（棋士：谷川浩司）。
Copyright © ITmedia, Inc. All Rights Reserved.