プロジェクトマネジャーは「プロジェクトのクレーム処理係」なのか？：あるプロジェクトマネジャーの“つぶやき”【第2回】

プロジェクトマネジャーには、複数部門の異なる立場にあるステークホルダーの意見をまとめ、プロジェクトを成功に導く使命がある。今回は失敗談を基に“プロジェクトマネジャーの役割”を考えてみる。

[小崎敬介，カブドットコム証券]

　一口に「プロジェクトマネジャー」と言っても、その業務内容はそれぞれの会社や案件によってさまざまではないでしょうか。当社におけるプロジェクトマネジャーは“プロジェクト全体のまとめ役”はもちろんのこと、プログラミングやテストケースの作成などを行うこともあります。開発工程の多くに直接的にかかわることができるので、わたし個人としては喜ばしいことです。

　プロジェクトマネジャーという立場であっても、わたしと同じように「システムの仕様策定や実装などの工程が好きだ」という人も多いと思います。やはり自分が手掛けて、モノが出来上がることは、とても喜ばしいものです。また、「コンピュータが好きでIT系の職に就いた」という経緯や、元来「人任せにすることが好きではない」という性格もあり、そうした気持ちがわたしは余計に強いのかもしれません。

　しかし、プロジェクトのまとめ役がコーディングやテストなどの実作業を始めてしまうと、プロジェクト全体の進ちょくが止まることがあります。当たり前と言えば当たり前のことですが、いざ作業を始めるとついつい没頭してしまいます。その“ついつい”が原因でこれまでに幾度かの失敗を経験してきました。今回は、その失敗談を基にわたしが考える“プロジェクトマネジャーの役割”について、つぶやいてみたいと思います。

あるプロジェクトでの失敗談

　あるプロジェクトで、「すぐに終わるだろう」と考えて手を付けたコーディング作業が予想に反して時間がかかり、その翌日も作業に没頭してしまったことがあります。その後、プロジェクトメンバーに各自の進ちょくを確認すると、Aさんは「Bさんのタスク待ちだ」といい、一方のBさんは「Aさんのタスク待ちだ」といった、まさに“デッドロック”のような状況が発生していました。

関連ホワイトペーパー

コミュニケーション | プログラミング | タスク管理 | ソフトウェアテスト | 開発プロセス