プロジェクトマネジャーには、複数部門の異なる立場にあるステークホルダーの意見をまとめ、プロジェクトを成功に導く使命がある。今回は失敗談を基に“プロジェクトマネジャーの役割”を考えてみる。
一口に「プロジェクトマネジャー」と言っても、その業務内容はそれぞれの会社や案件によってさまざまではないでしょうか。当社におけるプロジェクトマネジャーは“プロジェクト全体のまとめ役”はもちろんのこと、プログラミングやテストケースの作成などを行うこともあります。開発工程の多くに直接的にかかわることができるので、わたし個人としては喜ばしいことです。
プロジェクトマネジャーという立場であっても、わたしと同じように「システムの仕様策定や実装などの工程が好きだ」という人も多いと思います。やはり自分が手掛けて、モノが出来上がることは、とても喜ばしいものです。また、「コンピュータが好きでIT系の職に就いた」という経緯や、元来「人任せにすることが好きではない」という性格もあり、そうした気持ちがわたしは余計に強いのかもしれません。
しかし、プロジェクトのまとめ役がコーディングやテストなどの実作業を始めてしまうと、プロジェクト全体の進ちょくが止まることがあります。当たり前と言えば当たり前のことですが、いざ作業を始めるとついつい没頭してしまいます。その“ついつい”が原因でこれまでに幾度かの失敗を経験してきました。今回は、その失敗談を基にわたしが考える“プロジェクトマネジャーの役割”について、つぶやいてみたいと思います。
あるプロジェクトで、「すぐに終わるだろう」と考えて手を付けたコーディング作業が予想に反して時間がかかり、その翌日も作業に没頭してしまったことがあります。その後、プロジェクトメンバーに各自の進ちょくを確認すると、Aさんは「Bさんのタスク待ちだ」といい、一方のBさんは「Aさんのタスク待ちだ」といった、まさに“デッドロック”のような状況が発生していました。
各メンバー間のタスク調整は彼らの仕事ではなく、プロジェクトマネジャーであるわたしの仕事です。コーディングに夢中になるあまり、メンバーのタスク調整を怠ってしまったのです。プロジェクトの指揮を執り、メンバーをまとめる立場にあるわたし自身が、プロジェクトメンバーに迷惑を掛けてしまいました。申し訳ない気持ちで居たたまれなくなり、深く反省しました。
また、プロジェクトメンバーへの情報共有を怠ったために、彼らを困らせてしまったこともあります。
あるプロジェクトで前日の作業が進んでいないメンバーがいたので、その理由を尋ねた際に「開発環境でアプリケーションが突然動作しなくなり、その原因を調査していたために作業が進まなかった」という答えが返ってきました。
わたしは、進行中のほかのプロジェクトについてもある程度把握していたので、すぐにその理由が分かりました。実は、別のプロジェクトが共有の開発環境をテストのために使用していたことが、こちらの開発プログラムに影響を及ぼしていたのです。しかし、そのことを知らないメンバーは“答えの出ない調査”に時間を取られ、結果としてプロジェクトの進ちょくが遅れるという事態になってしまいました。
これは「他プロジェクトの作業によって、このような事態が起こる可能性がある」ことを事前に周知していなかったわたしのミスです。プロジェクト内で情報共有がなされていれば、そのメンバーも自身でタスクのスケジューリングを前後するなどの対応ができたことでしょう。プロジェクトマネジャーがプロジェクトに及ぼす影響の大きさをあらためて認識した出来事でした。
これらの失敗を踏まえ、わたしは「プロジェクトの“主役”は、設計/実装/テストなどの実作業を行うメンバーであり、彼らが快適に仕事を進められる環境を用意すること」が、プロジェクトマネジャーの役割だと意識するようになりました。
そのために、ほかのプロジェクトやメンバー間で作業が重複しないように調整したり、メンバー間の情報共有がなされているかなどを確認して回るなど、プロジェクトメンバーが自身の役割を理解して、業務に専念できる環境を用意することに努めています。こうした裏方的な業務こそが、プロジェクトの進ちょくを上げる潤滑油になっていたりします。各メンバーに効率よく作業してもらい、1つのチームとして機能できるようになると、プロジェクトの生産性も向上するものです。
しかし、実際には雑用とも思えるような作業もあって、つらいものです。以前のわたしであれば「それくらいのことは自分でやってほしい」と思わず口に出してしまいそうな場面でも、その言葉をぐっと飲み込んでいます。
プロジェクトマネジャーには潤滑油という意味で、もう1つ重要な側面があります。それは「プロジェクトのステークホルダー(利害関係者)間で円滑なコミュニケーションができるように努める」ことです。
多くのプロジェクトでは、社内外の複数部門にまたがるステークホルダーが存在します。その立場によって、業務要件やITに関する知識は異なります。中には、「自身で納得してからでないと、プロジェクトを進めたくない」という人がいます。ステークホルダーの了承を得てから、プロジェクトを進めることがプロジェクトマネジャーには求められます。
時には、プロジェクトとは直接的に関係しない部分を説明しなければならないこともあります。わたし自身、そうした説明をすることを面倒だと感じることが少なくありません。しかし、納得して進める場合とそうでない場合の効率の差は目に見えるものがあるのも事実です。そのため「その仕様に至った背景とは?」「この機能を実装する意味は?」と問われれば、「そこは(直接的には)関係ないです」という言葉をぐっとこらえて説明しています。
また、まれにプロジェクトメンバー同士で対立することがあります。こういう場面こそ、プロジェクトマネジャーの出番ではないでしょうか。実際の現場では、当事者が直接言い合ってもなかなか折り合いがつきませんし、堂々巡りになってしまいがちです。
プロジェクトマネジャーは双方の意見や愚痴を聞きつつ、相手方の立場を説明して理解してもらうことに努めます。時には、「なんで自分が……」という言葉をぐっと飲み込んで、折衷案を出したりすることもあります。ただ、実際にはそれぞれの主張が正しく思えることも多く、困ることもあります。皆さんにもそういう経験はありませんか?
プロジェクトマネジャーは、プロジェクトの“主役”であるプロジェクトメンバーの“執事”という存在だと思います。その業務は、各メンバーのタスク管理や進ちょく確認、ほかのプロジェクト案件との調整、開発担当のベンダーのフォローなど、多岐にわたります。担当業務の中には“雑多とも感じてしまう”作業もあります。しかし、「主役たちが快適に仕事を進めることができる環境をいかに用意することができるか」が重要ではないでしょうか。
2005年カブドットコム証券株式会入社。広島県出身。オンライン証券取引システムの設計開発運用業務に従事。主に発注系システムを担当する。座右の銘は、「『負けました』と言って頭を下げるのが正しい投了の仕方」(棋士:谷川浩司)。
Copyright © ITmedia, Inc. All Rights Reserved.
物流向けアプリケーションの開発を行うMeeTruckでは、アジャイル開発でPDCAをスピーディーに回すことで、業界での支持を拡大している。そんな同社の躍進を支えているのが、豊富なAPIを誇るコミュニケーションプラットフォームだ。
斬新なアイデアで人気を博すレシート買い取りアプリ「ONE」を提供するWEDでは、認証機能の開発工数を削減すべく、あるクラウドコミュニケーションAPIを導入した。SMS認証機能の実装をわずか2日程度で実現した同ツールの実力を紹介する。
アナログで非効率な業務が多く残る建設現場では、デジタル化によるプロセス改善が、喫緊の課題となっている。現場DXを推進する具体的な方法を提案するとともに、ノーコードツールの導入で大きな成果を収めた事例を紹介する。
ビルメンテナンス事業を展開する裕生では、全社的にDXへの意識が低く、従業員の意識改革に課題を抱えていた。そこで、取り組みの契機とすべくノーコードツールを導入。業務アプリの活用により現場の業務はどのように変化したのだろうか。
深刻化するIT人材不足の課題解消の方法として、プログラミングコードを書かずに業務用モバイルアプリを開発できる「ノーコード開発」が注目されている。従来のスクラッチ開発との違いを比較し、メリットや導入のポイントを解説する。
いまさら聞けない「仮想デスクトップ」と「VDI」の違いとは
遠隔のクライアント端末から、サーバにあるデスクトップ環境を利用できる仕組みである仮想デスクトップ(仮想PC画面)は便利だが、仕組みが複雑だ。仮想デスクトップの仕組みを基礎から確認しよう。
「サイト内検索」&「ライブチャット」売れ筋TOP5(2025年4月)
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10(2025年4月)
今週は、ECプラットフォーム製品(ECサイト構築ツール)の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」&「A/Bテスト」ツール売れ筋TOP5(2025年4月)
今週は、パーソナライゼーション製品と「A/Bテスト」ツールの国内売れ筋各TOP5を紹介し...