本記事では、筆者が考えるいまいちななPMの特徴について記載します。
この記事を書くきっかけは、現在参画しているプロジェクトのPMがいまいちだなと思える事が多く、その特徴を改めて整理したいと考えたからです。
当プロジェクトにおける筆者の役割は、顧客企業から依頼を受けて、そのＰＭを裏から支援するというものになります。そもそも筆者に依頼があったということから察して、顧客企業から見て、そのＰＭには何かしらの不安を感じる部分があったのでしょう。
ちなみにこの記事でいまいちだなと記載している内容は、完全に筆者の主観です。読む人よっては、そんな事はないと思われる方もいらっしゃるとは思いますが、筆者個人の感想として、聞き流していただけると幸いです。
※長くなってしまったので面倒な方は赤字のところだけ読んでください。
- いまいちなPMは未来に向けた仕事をしない
- いまいちなPMは計画を自分で作らず進捗だけ管理する
- いまいちなＰＭの課題管理は中身を理解しない
- いまいちなＰＭのレビューは見た目だけ
- いまいちなPMは顧客に適当に答えて無駄な工数を発生させる
- いまいちなＰＭはここまで記載した内容を認識できていない
※SE（システムエンジニア）編も記載しました。よろしくければこちらもご参照ください。↓↓↓
業務システム開発が失敗する理由は、ユーザとSEのコミュニケーションのすれ違いに有り
いまいちなPMは未来に向けた仕事をしない
いまいちなPMの特徴を一言でまとめると「未来に向けた仕事をしない」これにつきます。あらゆるPMのタスクが過去に向けた作業になっています。
これだけだとわかりづらいので、もっと一般的な言い回しをすると、
PM自身は頭を使わず、タスクをメンバーに丸投げして、自分はその進捗管理やレビューをすることを、マネジメントしていると勘違いしているPMという事になります。
では以降では具体的な行動を見ていきます。
いまいちなPMは計画を自分で作らず進捗だけ管理する
PMの役割はマネジメントをすることです。具体的には以下の役割が必要と考えております。
- 「品質／コスト／納期」などの観点でプロジェクトのゴールを設定
- 設定されたゴールに対して、それを達成するための戦略を立案
- 戦略に基づいて具体的かつ詳細なプロジェクト計画を策定
- 計画通りプロジェクトが進んでいるか進捗をチェックする
- 計画通り進まなそうなリスクや課題があれば具現化する前に手当てをする
- リスクや課題が具現化した場合、解決策を立案し計画を見直す
- プロジェクトの阻害要因になっている顧客側の課題があれば交渉して潰す
- 課題を解決するために大きな権限が必要であれば、より上位層の関係者を動かす
そして、マネジメントをするうえで一番大事なことは、ゴール設定／戦略立案／計画策定に関わる部分（まとめて計画と呼びます）ですが、いまいちなPMは自分で計画を策定しません。メンバーや他の人に計画などを策定させた上で、あたかも自分が作成したかのように進捗を管理します。
ですが、計画策定に関与していない状態で進捗だけ管理しても、それはマネジメントとはいえません。計画を自身で策定したわけではないので、リスクや課題を前もって予防することもできませんし、トラブルが発生しても柔軟に対策を立てることが出来ません。
せいぜいできることと言えば、進捗が遅延した事実に対して、何とかしてくださいと様々な手段（高圧的、低姿勢などモチベーションに訴えかける方法）を用いてメンバーに振るだけです。
要は、いまいちなＰＭは受動的に過去の進捗を管理（過去の実績に対する仕事）するのみで、将来に向けた計画策定や予防措置などの能動的な行動（未来への仕事）は行わないのです。
いまいちなＰＭの課題管理は中身を理解しない
ポンコツＰＭの課題管理は、課題の一覧とタスクを管理しているだけで、その具体的な中身に踏み込んでくることはありません。
課題に対する解決策の検討をメンバーに丸投げしておいて、ＰＭは「未着手／仕掛中／完了」などのステータスだけを管理します。
会議の場で、具体的な解決策の検討がなされても、一応、聞いている振りはしますが、実質は全然理解できていません。議論が無事終わった雰囲気を察したら、その中身の正否はおいておいて、課題管理表のステータスを「完了」にしますが、解決策の具体的な記載はメンバーに依頼します。
もちろん筆者も全部が全部理解できるとはいいませんが、技術的な視点から一歩引いて、PMならではの視点で助言ができることはたくさんあるはずです。
たとえば、この課題は他チームでも上がっているから共通で解決しようとか、過去に他プロジェクトで同様の課題があったから聞いてみようとか、対応するには工数かかりすぎるから運用で回避できないか調整するとか、技術的な内容から一歩引いた視点で助言できることは色々あるはずです。
要は、いまいちなPMはメンバーが検討した結果を管理するだけ（過去の検討結果に対する仕事）で、自分は課題を解決するための能動的な議論（未来に向けた仕事）には加わらないのです。
プロジェクトの役割として、課題を漏らさないために一覧表を管理する人が必要、ということは理解しますが、そのような課題を管理だけするだけの仕事は誰でもできるので、高い単価を貰っているＰＭがする仕事ではないと考えています。
いまいちなＰＭのレビューは見た目だけ
いまいちなＰＭは成果物をレビューすることは大好きですが、そのレビューは往々にして中身の話ではなく見た目の話になります。
見た目が汚いとか、文字の大きさが違うとか、段落がそろっていないとか、エビデンスの数が足りないとか、誤字脱字があるとか、そういった指摘のみにとどまります。
ですが、そのような見た目チェックはＰＭでなくても誰でもできます。それこそ几帳面な派遣社員の方とかを雇って、確認してもらえば十分ではないでしょうか。PMほどの高単価に見合った仕事とは思えません。
PMに求めるレビューとは、PMの立ち位置から見たもっと広い視点でのレビューです。たとえば、他チームと整合性が取れておらず繋いだ時にうまくいかない可能性があるから他チームと相談してみようとか、検討すべき事項が足りてないからここを検討してほしいとか、そういった一歩引いた視点でのレビューです。
要は、いまいちなPMのレビューとは、メンバーが記載した表面的な内容に対するレビュー（過去の記載内容に対する仕事）のみで、いまだ記載されていない本質的な内容に対するレビュー（未来に向けた仕事）はできないのです。
いまいちなPMは顧客に適当に答えて無駄な工数を発生させる
いまいちなPMは往々にして中身を理解していません。
ですので、顧客との会議では質問についてすぐに答えられない、もしくはその場しのぎで適当に答えることが往々にあります。答えられないだけならまだしも、明らかに技術的に実現できないことを、適当に「たぶんできるけど、持ち帰って検討します」と無意味な期待感を持たせて帰ってきます。
この様に適当な回答を続けることにより、顧客との信頼関係は徐々に崩れてきます。そうするとどうなるか。顧客はPMの事を信頼できないので、次から次へと事細かに報告を求めてきます。
それでも、その報告作業をPMが一人で食い止めてくれるならプロジェクトにとって問題はありません。
ですが、いまいちなPMは報告するための資料作りや元ネタををメンバーに投げてメンバーの負荷を増大させます。メンバーからすると単純に負担増なので当然不満はでますが、ＰＭは我知り顔でプロジェクト運営には必要な仕事なんだと上から目線で説教したりします。
いまいちなPMは、本質的な問題として、自分が顧客と信頼関係が気づけていないことが原因で、その要因は自分の技量不足という事を理解していないのです。
もちろん筆者も全部が全部PMで答えられるとは思いませんが、それでも最低限の知見は必要です。明らかに中身について理解していない（というか細かいことは理解しなくていいと考えている）PMが多すぎる気がします。
要は、いまいちなPMは、顧客に対する報告を受動的に行うだけ（過去の実績に対する報告）のみで、顧客とのコミュニケーション負荷を下げるような能動的な仕事（未来に向けた仕事）はできないのです。
いまいちなＰＭはここまで記載した内容を認識できていない
そしていまいちなPMは、今まで述べたような内容や状況を理解できていません。自分も含めたプロジェクト全体を俯瞰的かつ客観的にみる能力に欠けているのです。
想像するに、なんとなくのPM像やマネジメント像、もしくは教科書通りのPM像に従って、思考停止状態で仕事をしているのではないでしょうか。
このプロジェクトを成功させるために、自分は何のためにいるのか？どういった役割を果たすべきなのか？という事を自分の頭で考えたことがないのではないかと思ったりもしてしまいます。
