プロジェクトマネジメントに必要なスキルと心得

プロジェクトマネジメントの基礎知識やエッセンスについては、こちらの記事をご覧ください。

プロジェクトマネージャの心得〜基礎編〜

プロジェクトでは膨大な作業を、多くのチームメイトと役割分担して、優先度をつけて進めます。 当然、PM（プロジェクトマネージャ）自身も膨大な作業を請け負います。

PMが一人のプレイヤーとして成熟させるべき基礎能力を紹介しましょう。

タスク管理を怠るなかれ

ここでまず重要なのは、自分自身のタスク管理です。 社会人として必須スキルとされるタスク管理ですが、これを完璧にマスターできている人は一体どれほどいるでしょうか？

PMは司令塔です。自分のタスクの優先順位と期限をしっかり切り分けできなければ、自分自身がタスクの山に溺れるだけでなく、PMがボトルネックとなりプロジェクト全体の遅延に直結するようになります。

作業スピードを極限まで上げる

PMは、多くの文章を読み書きします。文章に関わる作業は、クライアントだけでなくチームメイトに対しても、メールやチャットツールなど、相手や手段を問わず発生します。ドキュメント作成だけでなくコミュニケーションとしても、文章を膨大に書くでしょう。この速度と精度を高めることは、プロジェクトの生産性向上に役立ちます。PMはプロジェクトの司令塔です。PMが高速かつ高性能にタスクをこなせるほど、プロジェクトの生産性に貢献できるでしょう。 そのために、キーボードのブラインドタッチは当然ですが極めましょう。これも社会人の基本です。

ボールは持たない、すぐ打ち返す

業務をこなす上での作業は、わざわざタスク化するくらいならすぐに消化する方が良いものもあります。

代表的なものは、メールやチャットの返信です。 特にクライアントやチームメイトからのQ&A対応や作業指示確認などは、止めてしまうとそのままプロジェクト進捗のボトルネックとなることもあります。読んですぐに返信できるものはすぐに対応してしまいましょう。

メールやSlack、Teamsといったグループチャットを利用していると、自分に関連があるなしに関わらず日々膨大な情報が飛び交っています。 こうした中で、まず自分が見るべき情報は絶対見逃さないことと、見なくても良い情報を的確に仕分けできることは、社会人として生きていく上で死活問題です。

ツールを使いこなして業務効率化

PMは、まさにプロジェクトマネジメントをするために、多くのリストや表を作ることになるでしょう。

例えば、

• タスクリスト
• 見積リスト
• スケジュール表（ガントチャートetc.）
• 各種チェックリスト
• メンバーアサイン表（日別、週別、月別）
• プロジェクト収支表（週次、月次）

・・・ などです。 今や多くのプロジェクト管理ツールがありますので、これらの作成はツール上で効率的にこなすことができます。

しかし、Excelやスプレッドシートといった表計算ツールを全く使わないということは、少なくとも私はありません。 ちょっと表で整理する、ちょっと試算・計算する、というときにお手軽で痒いところに手が届くこれ以上のツールはありません。 表計算ツールのメリットは、グラフ化であったり、集計表だったり、複数の表から合算表を作成するといったことまでできてしまうところです。 気になる方は、「ピボット集計」や「VLOOKUP」というキーワードを調べることで深掘りできるでしょう。

プログラマでなくとも、このような表計算ツールをワンランク上のレベルで使いこなせるようになるだけで、飛躍的な生産性向上を実現できます。

プロジェクトマネージャの心得〜実践編〜

前述のPMとしての基礎能力は、社会人としての基礎能力に他なりません。すなわち、セルフマネジメントすらできずに、プロジェクトマネジメントを行うことなど到底不可能ということです。

また、これらの基礎能力を極限まで高めることで、PMとして真にやるべきプロジェクトマネジメントに対して、心のゆとりを持ってしっかり対峙できるようになるでしょう。ここからは、実際にPMとしてプロジェクトに取り組む際に必要となる考え方やスキルについて見ていきます。

人を動かすコミュニケーション能力

プロジェクトマネジメントの実践では、他者と関わり効果的にプロジェクト推進するための観察力とコミュニケーション能力が求められます。大きなプロジェクトを成し遂げるには、協調や協業が欠かせません。カーネギーの「人を動かす」を想起した方もいるでしょう。その通り、プロジェクトマネージャの仕事は、人を動かす仕事でもあるのです。 PMは単に仕事を指示したりお願いするだけではありません。自分の思い通りにしたいからこそ、周りをよく観察し、丁寧なコミュニケーションが必要とされます。

感謝の言葉はとりわけ重要です。私もPMとして相手の言葉遣いを普段からよく観察しているのですが、依頼やお願いの仕方一つとっても、「すみません」から入って依頼をするタイプと「ありがとう」と言って依頼をするタイプに大別できます。私自身も厳密にはケースバイケースで使い分けますが、基本的には「ありがとう」で依頼するように心がけています。なぜなら、自分こそが他人からそのように仕事を依頼された方が気持ちが良いからです。忙しい相手に対して追加の作業依頼をするのは確かに心苦しい側面があります。ですが、それ以上に仕事を受けてくれる相手への感謝があふれ出るというものです。

PMは人にお願いすることが本当に多い役割です。心苦しさ(仕事の負荷)と感謝のバランスを取りながら、PMはコミュニケーションもマネジメントする存在だと言えるでしょう。

正確な見積もり

プロジェクトは常に、特定の期限内に目的を成し遂げるものです。つまりは時間との勝負です。PMは常に、その作業にどれだけの時間・工数がかかるのか？いくらの金額がかかるのか？を意識します。冒頭で紹介した「プロジェクトマネジメントの基本」の記事でも述べているように、かかる時間とかかるお金は連動します。

仮に、ある製品における新機能の開発に、10人月の工数がかかるとしましょう。 人月とは、SIer（システムインテグレーター）の世界では一般的な工数を示す用語で、「1人のエンジニアが1ヶ月かけてできる仕事量」を示します。 プロジェクトの納期が10ヶ月ある場合、1人のエンジニアを割り当てれば、極論特に問題ないでしょう。

では、プロジェクトの納期が5ヶ月だったらどうでしょうか？ 到底1人では間に合いませんので、2人以上を投入することになるでしょう。

この考え方は非常に便利なのですが、注意点もあります。 エンジニアも人であり、一人ひとりのプログラミングに対する経験度合いや習熟度合い、得意不得意もあるのです。これをひとまとめに10人月と言ってしまうことにはリスクがあります。

PMは、元は自分もプログラマの1人、エンジニアの1人であることが多いです。そのため「これくらいの仕事だったらどういう前提で、こういう能力がある人ならこれくらいの時間でできるだろう」という計算をします。自身の経験と各メンバーの能力を合わせ見て、正確な見積もりを行う能力が必要です。

全体を俯瞰して見る

PMは日々の作業に忙殺されることも少なくありません。チームの仕事を滞りなく進捗させるためだけに奔走する日もあれば、クライアントとの打合せに終日費やすこともあります。

プロジェクトの目的に向かうための作業を細かく分解して、あとはただ実行するのみ！という状態にできたとしても、PMはその実行だけを考えるわけではありません。 目先のミクロな作業だけ見ていたら、マクロな目的・目標からいつのまにか遠ざかってしまっていた、ということはよくあります。 自分の行為やチームの行動が、全体としてのゴールに向かっているか、常に一歩引いた視点を持ちましょう。

違和感を見逃さない

「あれ？おかしいな」

プロジェクトを遂行している中で、こう感じることは重要です。変化や違和感を感じ取るアンテナをちゃんと張っておくようにします。

• Aさんちょっといつもと違うな
• Bのこの工程、管理ツール上は問題なさそうだけど、担当者のCさんがさっき変なこと言ってたな
• ベンダーD社に依頼してたあの件、それ以来どうなったっけ？

特にタスク管理において難しいのは、自分がボールを打ち返したあとの状態の把握です。打ち返した後は、基本的には相手のボールであり相手のタスクです。例えばメールのような軽いタスクの場合、その先を管理しようとすることは、私でもほとんどありません。しかし、相手が何の反応もしなければ、何かのタイミングで自分が思い出すまで感知できないでしょう。

些細なコミュニケーションの中でもこのような漏れが発生します。むしろ、タスク化するほどでもない、というものほどこうしたコミュニケーションロスは生じやすいのです。

ステークホルダーを巻き込み、動かす

権利と責任は表裏一体です。PMはプロジェクト成功の責任を負いますが、それに対し、得られる権利は何でしょうか？

PMは、人・モノ・お金などの決定に関して、ある程度の権限をもっているといえます。ですが、それらを勝手に決定できるわけではありません。それらの決定には、ステークホルダーの意見が大きく影響します。

自分の計画通りにプロジェクトをマネジメントするには、プロジェクトの成否に影響を与えるステークホルダーが誰であるかを見極め、自ずから働きかけていくことが重要です。 このマネジメントは、ステークホルダーマネジメントとも言われます。クライアントの営業部門の責任者を巻き込んでおかなかったばかりに、後々になって、「こんなシステムは使えない」と営業部門全体から総スカンを食らってしまう、などはよくある話です。

クライアントに限らず、自社の開発部門の責任者を巻き込む必要がある場合もあります。仮に、追加の見積もりが通ったとしても、社内に動ける開発者がいない！というケースに陥ります。

では、巻き込むとは具体的にはどういうことでしょうか？ まずはステークホルダーもプロジェクトの体制図に加え、プロジェクトに関わるメンバーだと自覚してもらいましょう。そして、重要なポジションの人ほど個別・少人数でのコミュニケーションの機会を取って、自分のプランをプレゼンテーションしましょう。大きい方針・方向性、独自性があるような点は、先に個別で握っておくのがおすすめです。 例えば、トップダウンが効きやすい組織構成であれば、社長や役員を押さえておくのが有効ですし、現場志向の組織であれば課長クラスでも重要なキーマンになります。

具体的な進捗管理などの手法は、こちらの記事をご覧ください。

プロジェクトマネジメントスキルを向上させるには

書籍や研修によって知識を得ることはもちろん重要です。 それは前提として、こと、PMにおいて経験にまさるものはありません。PMとしてでなくて良いので、まずはたくさんのプロジェクトに参画して、様々なPMと一緒に仕事をしましょう。彼らの一挙手一投足をよく観察してください。色々なことがわかると思います。

• クライアントとのコミュニケーション折衝・交渉がうまい（下手な）PM
• クライアントとの信頼関係構築がうまい（下手な）PM
• チームメイトが気持ちよく仕事できる環境づくりがうまい（下手な）PM
• キーマン（ステークホルダー）としっかりコミュニケーションがとれているPM
• 進捗管理がうまいPM
• 品質管理がうまいPM
• 自分では品質管理ができないけど、ちゃんと品質管理ができるメンバーをプロジェクトチームにアサインし、プロジェクト全体をうまくコントロールできるPM

すべてが素晴らしい、最高のPMなんていません。 PMも人間です。一緒に仕事をしていると、先輩PMから大いに学びがあるでしょう。一方で、自分がPMだったらもっとこうするのにな、こうすればもっと良くなるのにな、と思うシーンは必ずあります。 「あれ？」と思ったことを忘れずに、自分がPMだったらこうしよう、というPM像（自分なりに思い描くPMイメージ）を持ち、育んでいきましょう。

おわりに

プロジェクトマネジメントは、一人では到底体験しきれない膨大な経験知の集大成です。 50年前のプロジェクトマネジメント体系より、今のプロジェクトマネジメント体系の方が間違いなく進化しています。10年前の自分のプロジェクトマネジメントスキルより、今の自分のほうが圧倒的に高いプロジェクトマネジメントスキルを有しているべきなのです。

PMは、この叡智を借りながら、応用してプロジェクトを成功に導くために尽力します。

では、PMには誰がなるのでしょうか？どうしたらなれるのでしょうか？ 自分がPMではなかったときにも、これまで自分が関わったすべてのプロジェクトにPMはいたのです。 そしてPMには、自分でなりたいと思って、なりたくてなるのです。ぜひそうであってください。 ソフトウェア開発業界に限らず、プロジェクトの中心にはPMがいます。 （大きな）プロジェクトの中では、プロジェクトマネジメントが働いていて、それを執行するPMという役割が必要です。オーケストラにおける指揮者のように。

どの世界にいようと、なりたい人がPMという役割を担うのです。

本記事が、過去のプロジェクトマネジメントにおける経験や叡智の助けを借りながら、自分からコミットし、クライアントや仲間とともにプロジェクトをやり遂げることの助けとなれば幸いです。真の信頼関係を築くことができたプロジェクトチームでのプロジェクト成功ほど、気持ちの良いものはありません。