PMの仕事

PMの仕事は「作る」より「運ぶ」に近い立場です。設計や開発、テストといった実作業は各担当が行い、PMはそれらが期日・予算・品質の枠に収まるよう全体を見ます。プロジェクトの目的とゴールを言語化し、そこへ向かう道筋を関係者が共有できる形にするのが起点になります。

担う機能はおおむね次のように整理できます。

• 目標とスコープの管理：何を作り、何を作らないかの線引きを決め、途中で膨らむ要求を交通整理します。
• 計画と資源の割り当て：作業を分解して担当と期日を決め、人員や予算を配分します。
• 進捗とリスクの監視：予定と実績のズレや、これから起きそうな問題を早めに拾い上げます。
• 関係者との橋渡し：発注側・開発側・関連部署の間で情報と判断をつなぎます。

成果物として残るのは、プロジェクト憲章や計画書、課題管理表、進捗報告といった「判断とその根拠を記録した文書」です。コード自体を書かなくても、これらの整備を通じてプロジェクトの状態を可視化するのがPMの仕事の中身になります。

PMの一日は打ち合わせと調整で占められがちですが、その背後にはプロジェクトの時間軸に沿った一連の流れがあります。おおまかには立ち上げ、計画、実行・監視、終結という順で進みます。

• 立ち上げ：目的・体制・大まかな範囲を固め、キックオフで関係者の認識をそろえます。ここで作るのがプロジェクト憲章です。
• 計画：作業を分解し、担当・順序・期日・見積りを組み、スケジュールと予算、リスクの見立てをまとめます。ガントチャートやWBSがこの段階の成果物です。
• 実行と監視：作業が計画どおり進んでいるかを追い、遅れや品質問題、範囲の変更を課題管理表で捌きます。定例で状況を共有し、判断が必要な点を上申します。
• 終結：成果物を検収に通し、振り返りで学びを残して次に渡します。

日々の実務でいえば、朝に進捗を確認して遅れの兆しを拾い、詰まっている担当の障害を取り除き、発注側からの追加要望を影響度とあわせて整理し、定例で合意を取る、といった動きの繰り返しです。作業そのものより、判断の前提を集めて意思決定を前に進めることに時間の多くを使います。

PMの仕事は目に見える成果物が自分の手からは出にくいぶん、成果が問われるのは「プロジェクトが予定どおり着地したか」という結果です。同じ失敗の形が繰り返し起きやすいので、典型を知っておくと備えやすくなります。

• スコープが静かに膨らむ：小さな追加要望を都度受けているうちに、当初の期日や工数では収まらなくなります。変更の影響を見える形にせず口頭でのませてしまうと、後半で一気に破綻しがちです。
• 進捗が「感覚」で語られる：担当の「だいたい終わりそう」を鵜呑みにすると、結合やテストの段階で遅れが表面化します。何をもって完了とするかの基準を先に決めておく必要があります。
• リスクを問題になってから扱う：起きてから対応すると選択肢が狭まります。予兆の段階で洗い出し、起きたときの備えを用意しておくほうが動きやすくなります。
• 関係者の期待がずれたまま進む：発注側と開発側が違うゴールを描いていると、完成間際に食い違いが噴き出します。前提を文書で共有し直す手間を惜しまないことが助けになります。

いずれも共通するのは、口頭や感覚で流していた前提を、記録と基準で見えるようにできていなかった点です。管理の道具をそろえるより、それを日々使い続ける運用のほうが難しい、といえます。

PMの仕事を理解するうえで、近い立場の役割と比べると輪郭がはっきりします。ここでは「何に責任を持つか」という軸で並べてみます。

• プロダクトマネージャー（PdM）：作るもの自体の価値や優先順位に責任を持ちます。PMが「決めたものを期限内に届ける」のに対し、PdMは「何を作るべきか」を問います。守備範囲の重なる部分もありますが、問いの向きが異なります。
• PMO：複数プロジェクトを横断して標準やルールを整え、支援する立場です。個々のプロジェクトを直接運ぶPMとは、視点の高さと対象範囲が違います。
• スクラムマスター：アジャイル開発でチームが自律的に動けるよう支援する役割です。指揮より支援に重心があり、計画と統制を担うPMとは進め方の思想が異なります。
• リーダー（現場責任者）：実作業の技術判断や品質を担います。PMは作業の中身より、それらが全体計画に収まるかを見ます。

実際の現場では、これらの役割を一人が兼ねることも珍しくありません。肩書きよりも、そのプロジェクトで自分がどの責任を引き受けているかを見極めることが、仕事の範囲を過不足なく捉える助けになります。

PMの仕事で身につく力は、特定の業界や技術に縛られにくいのが特徴です。計画を分解する、進み具合を見える形にする、立場の違う人の間で合意を作る、といった動きは、規模や領域が変わっても応用が利きます。そのため、開発現場のPMから社内のDX推進、事業開発の進行役へと軸足を移していく道も描けます。

キャリアを考えるうえでは、自分がどの責任に強みを持つかを棚卸しすることが出発点になります。計画の精度なのか、関係者との調整なのか、リスクの先読みなのか。得意な軸をはっきりさせておくと、次にどの役割へ広げるかを選びやすくなり、求人を見るときの判断材料にもなります。

PMの仕事は未経験からでも始められますか。

小規模なプロジェクトの進行補佐やサブリーダーから入る道が一般的です。まずは進捗管理や課題整理といった一部の役割を担い、計画づくりや関係者調整へ広げていく形が現実的です。開発やコンサルなど前職の土台を活かせる場合もあります。

PMは技術の知識がないと務まりませんか。

自分でコードを書けることは必須ではありませんが、作業の中身をある程度理解できないと見積りや遅れの判断が難しくなります。担当と会話が成り立ち、リスクの深刻さを見分けられる程度の理解は、進めるうえで助けになります。

PMの仕事で最も時間を使うのは何ですか。

作業そのものより、関係者との調整と情報の整理に多くを使う傾向があります。進捗の確認、課題の交通整理、発注側との認識合わせ、判断が必要な点の上申といった動きの繰り返しで、意思決定を前に進めることが中心になります。