あるプロジェクトマネジャーの“つぶやき”【第2回】
プロジェクトマネジャーは「プロジェクトのクレーム処理係」なのか?
プロジェクトマネジャーには、複数部門の異なる立場にあるステークホルダーの意見をまとめ、プロジェクトを成功に導く使命がある。今回は失敗談を基に“プロジェクトマネジャーの役割”を考えてみる。
一口に「プロジェクトマネジャー」と言っても、その業務内容はそれぞれの会社や案件によってさまざまではないでしょうか。当社におけるプロジェクトマネジャーは“プロジェクト全体のまとめ役”はもちろんのこと、プログラミングやテストケースの作成などを行うこともあります。開発工程の多くに直接的にかかわることができるので、わたし個人としては喜ばしいことです。
プロジェクトマネジャーという立場であっても、わたしと同じように「システムの仕様策定や実装などの工程が好きだ」という人も多いと思います。やはり自分が手掛けて、モノが出来上がることは、とても喜ばしいものです。また、「コンピュータが好きでIT系の職に就いた」という経緯や、元来「人任せにすることが好きではない」という性格もあり、そうした気持ちがわたしは余計に強いのかもしれません。
しかし、プロジェクトのまとめ役がコーディングやテストなどの実作業を始めてしまうと、プロジェクト全体の進ちょくが止まることがあります。当たり前と言えば当たり前のことですが、いざ作業を始めるとついつい没頭してしまいます。その“ついつい”が原因でこれまでに幾度かの失敗を経験してきました。今回は、その失敗談を基にわたしが考える“プロジェクトマネジャーの役割”について、つぶやいてみたいと思います。
あるプロジェクトでの失敗談
あるプロジェクトで、「すぐに終わるだろう」と考えて手を付けたコーディング作業が予想に反して時間がかかり、その翌日も作業に没頭してしまったことがあります。その後、プロジェクトメンバーに各自の進ちょくを確認すると、Aさんは「Bさんのタスク待ちだ」といい、一方のBさんは「Aさんのタスク待ちだ」といった、まさに“デッドロック”のような状況が発生していました。
各メンバー間のタスク調整は彼らの仕事ではなく、プロジェクトマネジャーであるわたしの仕事です。コーディングに夢中になるあまり、メンバーのタスク調整を怠ってしまったのです。プロジェクトの指揮を執り、メンバーをまとめる立場にあるわたし自身が、プロジェクトメンバーに迷惑を掛けてしまいました。申し訳ない気持ちで居たたまれなくなり、深く反省しました。
また、プロジェクトメンバーへの情報共有を怠ったために、彼らを困らせてしまったこともあります。
あるプロジェクトで前日の作業が進んでいないメンバーがいたので、その理由を尋ねた際に「開発環境でアプリケーションが突然動作しなくなり、その原因を調査していたために作業が進まなかった」という答えが返ってきました。
わたしは、進行中のほかのプロジェクトについてもある程度把握していたので、すぐにその理由が分かりました。実は、別のプロジェクトが共有の開発環境をテストのために使用していたことが、こちらの開発プログラムに影響を及ぼしていたのです。しかし、そのことを知らないメンバーは“答えの出ない調査”に時間を取られ、結果としてプロジェクトの進ちょくが遅れるという事態になってしまいました。
これは「他プロジェクトの作業によって、このような事態が起こる可能性がある」ことを事前に周知していなかったわたしのミスです。プロジェクト内で情報共有がなされていれば、そのメンバーも自身でタスクのスケジューリングを前後するなどの対応ができたことでしょう。プロジェクトマネジャーがプロジェクトに及ぼす影響の大きさをあらためて認識した出来事でした。
プロジェクトマネジャーは「クレーム処理係」?
これらの失敗を踏まえ、わたしは「プロジェクトの“主役”は、設計/実装/テストなどの実作業を行うメンバーであり、彼らが快適に仕事を進められる環境を用意すること」が、プロジェクトマネジャーの役割だと意識するようになりました。
そのために、ほかのプロジェクトやメンバー間で作業が重複しないように調整したり、メンバー間の情報共有がなされているかなどを確認して回るなど、プロジェクトメンバーが自身の役割を理解して、業務に専念できる環境を用意することに努めています。こうした裏方的な業務こそが、プロジェクトの進ちょくを上げる潤滑油になっていたりします。各メンバーに効率よく作業してもらい、1つのチームとして機能できるようになると、プロジェクトの生産性も向上するものです。
しかし、実際には雑用とも思えるような作業もあって、つらいものです。以前のわたしであれば「それくらいのことは自分でやってほしい」と思わず口に出してしまいそうな場面でも、その言葉をぐっと飲み込んでいます。
プロジェクトマネジャーには潤滑油という意味で、もう1つ重要な側面があります。それは「プロジェクトのステークホルダー(利害関係者)間で円滑なコミュニケーションができるように努める」ことです。
多くのプロジェクトでは、社内外の複数部門にまたがるステークホルダーが存在します。その立場によって、業務要件やITに関する知識は異なります。中には、「自身で納得してからでないと、プロジェクトを進めたくない」という人がいます。ステークホルダーの了承を得てから、プロジェクトを進めることがプロジェクトマネジャーには求められます。
時には、プロジェクトとは直接的に関係しない部分を説明しなければならないこともあります。わたし自身、そうした説明をすることを面倒だと感じることが少なくありません。しかし、納得して進める場合とそうでない場合の効率の差は目に見えるものがあるのも事実です。そのため「その仕様に至った背景とは?」「この機能を実装する意味は?」と問われれば、「そこは(直接的には)関係ないです」という言葉をぐっとこらえて説明しています。
また、まれにプロジェクトメンバー同士で対立することがあります。こういう場面こそ、プロジェクトマネジャーの出番ではないでしょうか。実際の現場では、当事者が直接言い合ってもなかなか折り合いがつきませんし、堂々巡りになってしまいがちです。
プロジェクトマネジャーは双方の意見や愚痴を聞きつつ、相手方の立場を説明して理解してもらうことに努めます。時には、「なんで自分が……」という言葉をぐっと飲み込んで、折衷案を出したりすることもあります。ただ、実際にはそれぞれの主張が正しく思えることも多く、困ることもあります。皆さんにもそういう経験はありませんか?
プロジェクトマネジャーはプロジェクトメンバーの執事たれ
プロジェクトマネジャーは、プロジェクトの“主役”であるプロジェクトメンバーの“執事”という存在だと思います。その業務は、各メンバーのタスク管理や進ちょく確認、ほかのプロジェクト案件との調整、開発担当のベンダーのフォローなど、多岐にわたります。担当業務の中には“雑多とも感じてしまう”作業もあります。しかし、「主役たちが快適に仕事を進めることができる環境をいかに用意することができるか」が重要ではないでしょうか。
<筆者紹介>
小崎敬介(こさき けいすけ)
カブドットコム証券株式会社システム本部システム統括部システム開発課
2005年カブドットコム証券株式会入社。広島県出身。オンライン証券取引システムの設計開発運用業務に従事。主に発注系システムを担当する。座右の銘は、「『負けました』と言って頭を下げるのが正しい投了の仕方」(棋士:谷川浩司)。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用 -
技術文書・技術解説
[NTTインテグレーション株式会社] 「耐量子計算機暗号」(PQC)に今、取り組むべき理由とは? 実現の道筋も解説 -
製品資料
[株式会社リンプレス] どうしたら非デジタル人材を「自走するDX推進者」に変えられるのか? -
製品資料
[アステリア株式会社] 既存システムをAIレディに変える「連携型モダナイゼーション」の手法とは? -
製品資料
[アステリア株式会社] 「データ連携」徹底解説 要件整理から連携手法、ツール選択まで
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
2
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
3
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
6
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
7
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
8
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
9
「何から始めればいい?」 情報漏えい対策で悲鳴を上げる中小企業のリアル
-
10
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
4
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
5
「IT史に名を残すシステム障害」8選
-
6
SASE選定は「見極め力」で大きな差――本当に必要な製品を選ぶための6つの視点
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
9
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー