「プロジェクトマネジメント（PM）」という言葉は知っていても、具体的に何をする仕事なのかは説明しにくいものです。部下を評価する「組織マネジメント」とは違い、PMは「案件・プロジェクトをどう進めるか」に責任を持つ役割です。
この記事では、PMが各フェーズで何をしているかを整理し、組織マネジメントとの違いも合わせて解説します。
プロジェクトマネジメントと組織マネジメントの違い
まず、2つの違いを整理します。
| 観点 | 組織マネジメント | プロジェクトマネジメント |
|---|---|---|
| 対象 | 人（評価、育成、配置） | 案件・プロジェクトの進行 |
| 期間 | 継続的（評価サイクル単位） | プロジェクト単位（期限あり） |
| 主な責任 | 部下の成果・成長 | 案件の品質・期限・予算 |
| 必要な力 | 評価、育成、配置調整 | 要件整理、進行管理、関係者調整 |
組織マネジメントは「人」を、プロジェクトマネジメントは「進行」を見る役割です。部下がいなくても、案件を進行管理する立場であればPMの機能を担っていると言えます。
フェーズ1. 要件定義
PMの最初の仕事は、何を作るのか、何を解決するのかを決める要件定義です。
- 現状業務を書き出し、困っていることを整理する
- 対象範囲を決める（やること、やらないこと）
- 必要な機能を一覧化し、優先度を分ける
- データ、権限、完了条件を決める
要件定義が曖昧なまま進むと、後工程で手戻りが発生しやすくなります。PMは、関係者の認識をここで合わせる役割を担います。
フェーズ2. ベンダー折衝
開発を外部ベンダーに依頼する場合、PMはベンダーとの折衝を担当します。
- 要件定義書をベンダーに共有し、疑問点を引き出す
- 見積もりの内容を、機能ごとに確認する
- 進行中の課題管理（誰が、いつまでに、何を決めるか）
- 不具合・遅延が出たときの対応ラインを事前に決めておく
ベンダー折衝で重要なのは、「責める」のではなく「課題を早く出せる関係性」を作ることです。見積金額の安さだけでなく、課題を早めに共有してくれるベンダーかどうかも、選定時に見ておきたいポイントです。
フェーズ3. テスト
特に決済・会員・販売・基幹系のように業務影響が大きいシステムでは、テスト期間を十分に確保することが重要です。
- 通常業務のパターンを網羅したテストケース
- 例外ケース（エラー、未入力、権限違いなど）
- 移行データを使った本番相当のテスト
「動けば良い」ではなく「想定外のケースでどう動くか」まで確認することで、リリース後の緊急対応を減らせます。
フェーズ4. リリース・保守運用
リリース後も、PMの仕事は終わりません。
- 運用開始後の不具合対応、改善要望の整理
- ログ・通知・エラー対応の仕組みが機能しているかの確認
- 保守担当者への引き継ぎ、運用手順の整備
PMは「作って終わり」ではなく、運用に乗って初めて成果が出るという前提で、リリース後の動きまで見ておく役割です。
PMに必要な力は「人を管理する力」ではない
PMに求められる力は、部下を評価・育成する組織マネジメントの力とは異なります。
- 要件を整理し、関係者の認識を合わせる力
- 複数の関係者（社内、ベンダー、現場）の間で調整する力
- 課題を早く見つけ、優先順位をつけて対応する力
- 進行状況を把握し、判断が必要な箇所を見極める力
これらは、部下を持たない立場でも経験できる力です。複数のプロジェクトを同時並行で進めてきた経験や、未知の領域を自分で調べて仕様化してきた経験も、PMの機能として説明できます。
まとめ
プロジェクトマネジメントは、人を管理する組織マネジメントとは異なり、案件・プロジェクトの進行に責任を持つ役割です。
- 要件定義で関係者の認識を合わせる
- ベンダー折衝では、責めるより課題を早く出せる関係性を作る
- テストは「動けば良い」ではなく想定外のケースまで確認する
- リリース後の保守運用まで見届ける
組織マネジメントの肩書がなくても、これらの機能を担ってきた経験があれば、PM経験として十分にアピールできます。
DX人材・PMキャリアの相談
local-navi.jpでは、PM経験の言語化、要件定義・ベンダー折衝の進め方について相談を受けています。
まずはLINEからの無料相談、または1回1万円程度のオンラインヒアリングから、自分の経験をどう整理できるかを一緒に確認することも可能です。
