はじめに
プロジェクトというとIT技術者はついIT導入プロジェクトが思い浮かぶと思います。
でも、プロジェクト管理というものはありとあらゆるものに適用が可能といえるほど多様なものを管理することができます。一方で現場では、
- 「納期遅延」
- 「要件ブレ」
- 「リリース後に障害多発」
など、プロジェクトが炎上するケースも少なくありません。
ITサービスマネジメントのフレームワークとして広く知られている ITIL4 にも システム開発や導入で必須となる プロジェクト管理（Project Management）。
どちらもITの現場では頻繁に登場しますが、
- ITILとプロジェクト管理ってどう違うの？
- 両者はどう組み合わせるのが正解？
と疑問を持つ方も多いのではないでしょうか。
本記事では、ITIL4とプロジェクト管理の関係を整理し、実務での使い分け・連携のポイントを解説します。
ITIL4とは何か？
ITIL4は、ITサービスを継続的に価値提供するためのベストプラクティス集です。
特徴
- サービス中心（Service-centric）
- 継続的改善（Continuous Improvement）
- 価値共創（Co-creation）
ITIL4では、以下のような要素を中心に構成されています。
- サービスバリューチェーン（Service Value Chain）
- プラクティス（Practice）
- 原則（Guiding Principles）
目的
「安定的かつ継続的に価値を提供すること」
例えば：
- システム障害を素早く復旧する（インシデント管理）
- 変更による事故を防ぐ（変更管理）
- 問題の根本原因を排除する（問題管理
プロジェクト管理とは何か？
プロジェクト管理（PM）は、明確な開始と終了を持つ「プロジェクト」を成功させるための管理手法です。
特徴
- 期限がある（Temporary）
- 成果物が明確（Deliverable-driven）
- スコープ管理・進捗管理が重要
代表的なフレームワーク：
- PMBOK
- PRINCE2
- アジャイル / スクラム
目的
「決められた時間・コスト・品質で成果を完成させること」
ITIL4とプロジェクト管理の違い
| 観点 | ITIL4 | プロジェクト管理 |
|---|---|---|
| 目的 | 継続的なサービス提供 | 一時的な成果物の達成 |
| 時間軸 | 継続（Ongoing） | 一時的（Temporary） |
| 対象 | サービス運用全体 | 個別のプロジェクト |
| フォーカス | 価値提供 / 安定運用 | 納期・コスト・品質 |
| 代表活動 | インシデント管理、変更管理 | スケジュール管理、リスク管理 |
結論：役割は違うが、現場では必ず連携する関係
ITIL4の中にある「プロジェクト管理」
ITIL4では、実は「Project Management」がプラクティスの一つとして定義されています。
ITIL4におけるプロジェクト管理の位置づけ
- 大きな変更（例：システム導入）はプロジェクトで実施
- プロジェクト管理は「変化を実現する手段」
つまり、
ITILは「運用の世界」、PMは「変化を実現する手段」
両者の関係を一言で言うと
「ITILは運用、プロジェクト管理は変化を実現する手段」
実務での使い分け
ケース① 新システム導入
| フェーズ | 活用 |
|---|---|
| 要件定義〜リリース | プロジェクト管理 |
| リリース後 | ITIL4 |
流れ
- プロジェクトでシステムを設計・構築
- リリース前に運用設計・引き継ぎを実施
- リリース後はITILプロセスで運用
- インシデントや改善点を継続的改善へフィードバック
ケース② システム変更（非定常）
- 小規模 → ITILの変更管理（Change Enablement）
- 大規模 → プロジェクトとして実施
規模に応じて使い分けるのがポイント
ITIL4 × プロジェクト管理の連携ポイント
① 変更管理とプロジェクトの連携
ITIL4の変更管理（Change Enablement）は重要。
- プロジェクトで実施する変更も
- ITILの変更プロセスに従う
ガバナンス維持
② 移行（Transition）の重要性
プロジェクトでよく問題になるのがここ：
「作ったけど運用できない」
ITIL4では以下を重視：
- ナレッジ移管
- 運用設計
- サポート体制
プロジェクト完了＝運用可能状態
③ 継続的改善（CI）との接続
プロジェクトは終了しても改善は続く
- ITILの継続的改善に引き継ぐ
- 改善テーマが次のプロジェクトになることも
よくあるアンチパターン
###① プロジェクトだけ重視して運用軽視
- システムは完成
- でも運用が回らない
ITIL視点が不足 → 運用崩壊の典型パターン
###② ITILガチガチでスピード低下
- すべてに変更申請
- 承認プロセス過多
プロジェクトの俊敏性が失われる
③ 引き継ぎ不足
- 運用に丸投げ
- ドキュメント不足
典型的なトラブル原因
ベストプラクティス
1. 両方を「補完関係」として扱う
- PM：短期目標達成
- ITIL：長期価値維持
2. DevOpsと組み合わせる
ITIL4はDevOpsと親和性が高い
- 開発（プロジェクト）
- 運用（ITIL）
- 継続改善（CI/CD）
現代の標準構成
3. ライトなガバナンス設計
- 小変更 → 簡易プロセス
- 大変更 → 厳格管理
バランスが重要
まとめ
ITIL4とプロジェクト管理の関係
- ITIL4は「サービスの運用・価値提供」
- プロジェクト管理は「変化を実現する方法」
実務では
プロジェクトで作る → ITILで運用する → 継続的に改善する
成功のポイント
運用まで見据えたプロジェクト設計
ITILとPMの役割分担
スピードと統制のバランス
最後に
ITの現場では、
「プロジェクトは成功したのに運用が崩壊」
「運用は安定しているが変化に弱い」
といった悩みがよくあります。
これを解決する鍵は、ITIL4とプロジェクト管理の適切な連携です。
ぜひ、自組織のプロセスにも取り入れてみてください。
一般的マネジメントプラクティス一覧
- アーキテクチャ管理
- 情報セキュリティ管理
- ナレッジ管理
- 測定と報告
- 組織変更の管理
- ポートフォリオ管理
- プロジェクト管理
- 事業関係管理
- リスク管理
10.サービス財務管理
11.戦略管理
12.サプライヤ管理
13.要因及びタレント管理 ← 今回はコレ
14.継続的改善
株式会社ジールができること(宣伝)
AIを活用するためには確かなデータ基盤とPDCAのそもそもPを始めるためのデータの可視化が必要です。ジールではZ-BISS BI製品選定サービスというものを提供しております。はじめてのデータ活用、もっとデータ活用したい方へ。また、数十以上のBI製品を取扱う安心安全のBI選定サービスをご利用になりたい方は、 BI・データ活用の窓口「Z-BISS」 へアクセスしてみてください。もしれません。同じような経験をした方の参考になれば幸いです。