// シス担のミカタ
プロジェクト管理の基本概念

プロジェクトマネージャー ぷろじぇくとまねーじゃー

プロジェクト管理PMスケジュール管理ステークホルダーリスク管理ITプロジェクト
プロジェクトマネージャーについて教えて

簡単に言うとこんな感じ！

プロジェクトの「船長」みたいな存在だよ！目的地（ゴール）を決めて、チームを引っ張り、スケジュールや予算を管理しながら、無事に港（完成）まで届ける役割なんだ。略して「PM」とも呼ばれることが多いよ！

プロジェクトマネージャーとは

プロジェクトマネージャー（Project Manager／PM）とは、特定の目標を達成するための「プロジェクト」を計画・実行・完了まで一貫して管理・推進する責任者のことです。システム開発・インフラ構築・業務改革など、ITプロジェクトにおいて欠かせない中心的な役割を担います。

PMが管理するのはスコープ（何をやるか）・スケジュール（いつまでにやるか）・コスト（いくらでやるか）の3本柱です。これらは「プロジェクト管理の鉄の三角形」とも呼ばれ、どれか1つが変わると他の2つにも影響が出るため、常にバランスを取りながら意思決定を行うことが求められます。

また、PMはチームメンバーやシステムベンダー（外部委託先）、経営層、発注部門など多くのステークホルダー（利害関係者）の間に立ち、情報を整理・共有して「誰も置いてけぼりにしない進行」を実現することも重要な役割です。

PMの主な役割と責任範囲

役割具体的な内容
計画立案プロジェクトのゴール設定、スケジュール・予算の策定
チーム管理メンバーのアサイン、作業分担、進捗の把握
リスク管理問題の予兆を早期発見し、対応策を事前に準備
ステークホルダー調整経営層・発注部門・ベンダーとの連絡・報告・交渉
品質管理成果物が要件を満たしているかを確認・承認
課題管理発生した問題を記録・追跡し、解決まで導く

覚え方：「スコ・スケ・コス」

PMが管理する3本柱はこう覚えると楽です。

スコ（スコープ）… 何をやるか
スケ（スケジュール）… いつまでにやるか
コス（コスト）… いくらでやるか

この3つは「QCD（品質・コスト・納期）」とセットで語られることも多く、発注側としても必ず押さえておきたいポイントです。

PMとPLの違い

IT現場では「プロジェクトリーダー（PL）」という肩書きも登場します。混同しやすいので整理しておきましょう。

項目プロジェクトマネージャー（PM）プロジェクトリーダー（PL）
主な視点プロジェクト全体・経営視点技術チームの現場視点
責任範囲予算・スケジュール・顧客対応など全体開発チームの作業管理・技術判断
対象ステークホルダー全体開発メンバー
規模感大規模プロジェクトで特に明確に分離される中小規模では兼任することも多い

歴史と背景

  • 1950年代：米国の軍事・宇宙開発プロジェクト（NASAなど）で大規模な計画管理の必要性が高まり、「プロジェクト管理」という概念が体系化される
  • 1969年：PMI（Project Management Institute） がアメリカで設立。プロジェクト管理の国際的な標準化を推進する団体として活動を開始
  • 1987年：PMIが PMBOK（Project Management Body of Knowledge） の初版を発行。プロジェクト管理の知識体系として世界中に普及する
  • 1990年代〜：IT産業の急成長とともに、システム開発プロジェクトでPMの重要性が急速に高まる
  • 2000年代〜：PMP（Project Management Professional） 資格が世界標準の認定資格として普及。ITベンダー選定時に「PMPを持つPMがいること」が要件になるケースも増える
  • 2010年代〜：アジャイル開発の普及により、従来型（ウォーターフォール）の管理手法に加えて柔軟なプロジェクト管理スタイルも重要視されるようになる

PMBOKと主要な管理知識エリア

PMの仕事は経験や勘だけでなく、PMBOK（ピンボック）という国際標準のガイドラインに体系化されています。PMBOKはPMIが発行する「プロジェクト管理の教科書」で、PMが押さえるべき知識を10の領域に整理しています。

PMBOK 10の知識エリア（プロジェクトマネージャーの管理領域） プロジェクト統合管理 全体の計画・実行・統制 スコープ管理 何をやるかの範囲を管理 スケジュール管理 期間・順序・納期の管理 コスト管理 予算の計画と実績管理 品質管理 成果物の品質確保 資源管理 人・物・設備の調達と管理 コミュニケーション管理 情報共有・報告の仕組み リスク管理 問題の予防と対応準備 調達管理 外部委託・契約の管理 ステークホルダー管理 関係者との関係構築 発注側が特に注目すべきポイント 「スコープ・スケジュール・コスト・リスク・ステークホルダー管理」は 発注側も一緒に関わる領域。PMに任せっぱなしにせず連携することが重要！

発注側の担当者も、PMがどの知識エリアで何を管理しているかを理解しておくと、「今どのフェーズにいるか」「何を求められているか」が明確になり、プロジェクトへの関わり方が格段に改善されます。

発注側が知っておくべき実務のポイント

システム発注を担当するビジネスパーソンにとって、PMとの関係構築はプロジェクト成否に直結します。

1. PMに何でも任せすぎない PMはプロジェクトの推進を担いますが、「何を作るか（要件）」の最終決定は発注側の責任です。要件が曖昧なままPMに「よろしくお願いします」と丸投げすると、完成したシステムが期待と全然違う…という事態が発生します。

2. 定期報告会には必ず出席する PMが主催するステータス報告会（週次・月次）には、発注側の責任者が出席することが重要です。「忙しいので議事録だけ送って」では、問題が大きくなるまで気づけないリスクがあります。

3. スコープ変更の影響を理解する 「ちょっとこの機能も追加して」という変更依頼は、スケジュールや予算に連鎖的な影響を与えます。PMから「スコープ変更の影響試算」が提示されたら、必ず内容を確認してから承認しましょう。

関連用語