プロジェクト管理 ぷろじぇくとかんり
簡単に言うとこんな感じ!
「いつまでに・いくらで・何を作るか」をきっちり決めて、ゴールまで迷子にならないようにする仕組みだよ!放っておくと予算オーバーや納期遅れが起きちゃうから、計画→実行→監視→完了のサイクルで進めるんだ。
プロジェクト管理とは
プロジェクト管理(Project Management)とは、明確な目標・期限・予算のある「プロジェクト」を成功させるために、スコープ(範囲)・スケジュール・コスト・品質・リスクなどを計画し、監視・調整しながらゴールへ導く一連の活動です。「日常業務」と違い、プロジェクトは「始まりと終わりがある一時的な取り組み」であることが前提になっています。
ビジネスの現場では、新しいシステムの導入・オフィス移転・新製品開発など、あらゆる「やったことのない取り組み」がプロジェクトに該当します。きちんと管理しないと、気づいたときには予算が底をついていた・納期に間に合わなかった・誰が何を担当するか不明確になった、という事態が起きがちです。
プロジェクト管理は「勘と経験だけ」ではなく、体系化された知識・手法・ツールを使うことで再現性高く成果を出せるようになります。その代表的な体系が後述する PMBOK(ピンボック) です。
プロジェクト管理の5つのプロセス
プロジェクト管理は「何を・どの順番でやるか」というプロセスに分かれています。PMBOKではこれを5フェーズで整理しています。
| フェーズ | 主な活動 | アウトプット例 |
|---|---|---|
| ①立ち上げ | 目的・目標を定義し、関係者を確認する | プロジェクト憲章、ステークホルダー台帳 |
| ②計画 | スケジュール・コスト・リスクを計画する | WBS、ガントチャート、予算計画書 |
| ③実行 | 計画に従ってチームを動かす | 成果物、進捗報告、課題管理表 |
| ④監視・コントロール | 計画とのズレを検知し修正する | 変更要求、是正措置 |
| ⑤終結 | 完了を確認し、教訓をまとめる | 受入確認書、振り返りレポート |
覚え方:「立計実監終(りっけいじっかんしゅう)」
「立ち上げ・計画・実行・監視・終結」の頭文字を並べて 「立計実監終」 と覚えると、5フェーズの順番が頭に入りやすいですよ!
プロジェクトの三大制約(トリプルコンストレイント)
プロジェクト管理の核心は、互いにトレードオフとなる以下の3要素のバランスをとることです。
品質(Quality)
△
/ \
/ \
/ \
コスト━━━━━━━━━スコープ
(Cost) (Scope/Time)
ひとつを変えると、他の2つに影響が出る!
たとえば「スコープ(機能・範囲)を増やしたい」なら、コストか納期(時間)のどちらかを増やさないと品質が落ちます。この関係を常に意識することがプロジェクト管理の基本です。
歴史と背景
- 1950年代 — 米国国防総省や建設業界でCPM(クリティカルパス法)・PERT(パート)が生まれる。大型プロジェクトを科学的に管理する必要性から誕生
- 1969年 — PMI(プロジェクトマネジメント協会) が米国で設立。プロジェクト管理を専門職として体系化する動きが始まる
- 1987年 — PMIが「PMBOK(Project Management Body of Knowledge)」の初版を発表。プロジェクト管理の知識体系が世界共通の言語に
- 1990年代 — ITバブルを背景にソフトウェア開発でのプロジェクト管理が急速に普及。失敗プロジェクトの多さが社会問題化
- 2001年 — 「アジャイル宣言」が発表され、変化に強い反復型の開発手法が登場。ウォーターフォール型と並ぶ重要な潮流となる
- 2010年代〜 — クラウドツール(Jira・Asana・Notionなど)の普及でプロジェクト管理がより身近になる。リモートワーク対応も加速
主な手法とアプローチの比較
プロジェクト管理には大きく「ウォーターフォール」と「アジャイル」という2つの流派があります。どちらが優れているではなく、プロジェクトの性質で使い分けます。
代表的なフレームワーク・手法一覧
| 名称 | 特徴 | 向いているシーン |
|---|---|---|
| PMBOK | 知識体系の国際標準。資格(PMP)もある | 大規模・複雑なプロジェクト全般 |
| スクラム | アジャイルの代表格。2〜4週の反復(スプリント)で進める | ソフトウェア・プロダクト開発 |
| カンバン | 作業をボードで可視化して流れを管理 | 運用保守・継続的な改善業務 |
| PRINCE2 | 英国発の段階的承認型フレームワーク | 公共機関・欧州企業のプロジェクト |
| クリティカルパス法(CPM) | 最長経路を特定して納期を管理 | 建設・製造など工程が固定の案件 |
発注側が知っておきたい実務ポイント
システム発注・導入プロジェクトでは、発注側(お客さま側)にも明確な役割があります。「あとはベンダーにお任せ」は失敗のもとです。
- ステークホルダー管理 — 関係者(経営層・現場・IT部門・ベンダー)の意見をまとめ、利害の対立を調整するのは発注側の重要な役割
- スコープ管理 — 「あれもこれも追加したい」というスコープクリープを防ぐために、変更管理のルールを最初に決めておく
- リスク管理 — 「もし〇〇が起きたらどうする?」を事前に洗い出し、対応策を準備しておく(リスク対応計画)
- 進捗確認 — ガントチャートや課題管理表を使って、計画通り進んでいるかを定期的に確認する
関連する規格・RFC
| 規格 | 内容 |
|---|---|
| ISO 21500:2021 | プロジェクト・プログラム・ポートフォリオ管理の国際標準ガイダンス |
| ISO 21502:2020 | プロジェクトマネジメントのガイダンスと実践(PMBOK第6版と整合) |