PMの仕事内容

PMが置かれる理由は、プロジェクトが放っておくと崩れるからです。期限・予算・品質・関係者の期待は互いに引っ張り合い、誰かが全体を見ていないとどれか一つが静かに壊れます。PMはこの綱引きの真ん中に立ち、どこを優先し、どこを譲るかを関係者と合意しながら決めていきます。

具体的には、発注側（顧客や事業部門）と作る側（開発チームや協力会社）のあいだに立ちます。発注側からは「いつまでに・いくらで・何を」を引き出し、作る側からは「それが現実的か」を引き出し、両者がかみ合う計画に落とします。QCDS（品質・コスト・納期・安全）のどれを軸に判断するかを、その場の空気ではなく事前の合意として持っておくことが、ぶれない進行の土台になります。

つまずきやすいのは、PMを「とりまとめ役の便利係」と捉えてしまうことです。依頼を右から左へ流すだけの窓口になると、判断が誰のものか曖昧になり、問題が起きたときに動きが止まります。PMは流すのではなく、決める材料をそろえて決めを促す立場だと押さえておくと、仕事の密度が変わります。

仕事は大きく、立ち上げ・計画・実行・監視・収束という流れをたどります。開発手法がウォーターフォールでもアジャイルでも、この骨格は共通していると考えてよいでしょう。

• 立ち上げと計画
  プロジェクト憲章やプロジェクト計画書で目的・範囲・体制を言語化し、WBSで作業を分解し、ガントチャートやマイルストーンで時間軸に置きます。ここで曖昧な範囲を残すと、後工程の全てがぶれます。
• 実行と進捗管理
  日々は進捗管理が中心です。WBSの各タスクが予定どおり進んでいるか、予実の差を定例やチケットで拾い、遅れの兆しを早めに見つけます。
• 監視とコントロール
  遅れやリスクが見えたら、人を足す・順番を変える・範囲を絞るなどの打ち手を比べ、関係者と合意して変更管理として記録します。
• 収束
  受け入れテストを経て納品し、振り返りで次に残す学びを整理します。

つまずきやすいのは、計画を一度作って終わりにすることです。計画は現実とずれるのが前提で、ずれを見つけて直し続ける行為そのものがPMの実務だと捉えるほうが実態に合います。

PMの時間の多くは、人との調整に使われます。相手は社内外のステークホルダー、開発メンバー、協力会社、そして予算や方針を握る上位の会議体（ステアリングコミッティなど）です。それぞれ関心事が違うため、同じ事実でも伝え方を変える必要があります。

調整の土台になるのが、役割の明確化です。RACI（責任分担マトリクス）のような形で、誰が実行し、誰が最終責任を持ち、誰に相談し、誰に報告するかを整理しておくと、「これ誰がやるんでしたっけ」という宙ぶらりんが減ります。協力会社が関わる場合は、ベンダーコントロールとして作業範囲と責任の線引きを契約段階からそろえておくことが、後の揉めごとを減らします。

つまずきやすいのは、悪い知らせを抱え込むことです。遅れやトラブルは、早く小さく共有するほど打ち手が増え、遅く大きく出すほど選択肢が減ります。関係者から嫌がられたくない気持ちが、報告のタイミングを遅らせる方向に働きがちな点は、意識して抑えておきたいところです。

PMは、名前の近い役割と混同されやすいため、違いを範囲と責任で切り分けておくと誤解を避けられます。

• PMO
  PMがひとつのプロジェクトの推進に責任を持つのに対し、PMOは複数のプロジェクトを横断して標準やルールを整え、PMを支援・監督する立場です。進める人と、進めやすくする仕組みを作る人、という違いがあります。
• プロダクトマネージャー（PdM）
  こちらはプロダクトを「何を作るべきか」から考える役割で、PM（プロジェクトマネージャー）は「決まったものをどう作り切るか」に軸足があります。略称が似ているだけで仕事の重心は異なります。
• リーダーやメンバー
  技術的な作り込みや設計の最終判断は、現場のリーダーや有識者が担うことが多く、PMはそれが滞りなく進む状態を保つ側に回ります。

つまずきやすいのは、PMが技術の細部まで自分で巻き取ろうとして、全体を見る時間を失うことです。役割の境界を引いたうえで、自分が見るべき高さを保つことが、結果として全体の進みを守ります。

PMの仕事内容を正しく捉えることは、そのままキャリアの設計図になります。計画・進行・調整という柱のうち、自分がどの柱で成果を出してきたかを言葉にできると、職務経歴書や面接での説明が具体的になります。「進捗を管理した」で止めず、どんな遅れをどう見つけ、どの打ち手を関係者と合意して立て直したか、という形まで書けると、再現性のある力として伝わります。

また、PMと一口に言っても、SIer型・社内DX推進型・上流コンサル寄りなど重心の違う型があります。自分の経験がどの型に近いのかを見極めると、次に広げる方向が選びやすくなります。どの型でも、全体を進め切った具体的な経験が市場での評価軸になる点は共通しています。

PMは自分で手を動かして開発するのですか。

規模によります。大きな案件では計画と調整が中心で、自分でコードや成果物を作ることは少なめです。小規模な案件では設計やテストなど現場作業を兼ねる場合もあります。ただし共通するのは、個々の作業より全体を進め切る責任を持つ点で、そこがメンバーとの違いになります。

未経験からPMになるには何から始めればよいですか。

まずは一つのプロジェクトのなかで、進捗管理やWBS作成、議事の整理といった補助的な役割から関わる道があります。小さな範囲でも計画を立てて進め、ずれを直す経験を積むことが土台になります。資格より、関係者をまとめて物事を前に進めた具体的な経験が評価されやすいでしょう。

PMに向いているのはどんな人ですか。

一概には言えませんが、全体を俯瞰して優先順位をつけること、立場の違う相手と対話して合意を作ること、悪い情報も早めに共有できることが助けになります。細部を自分で完璧に仕上げたい志向より、人に任せて全体を進める志向のほうが、この仕事では働きやすい傾向があります。