「作って終わり」はもう通用しない！PMBOK第8版に学ぶ「定常業務（オペレーション）」への引き継ぎ術

IT業界には「プロジェクトがスケジュールや予算通りに成功する確率は約30％しかない」という有名なデータがあります。
しかし、それ以上に深刻なのが「苦労して完成させたシステムの機能のうち、実際に現場で継続して使われているのは全体の30％程度しかない」という現実です。

「要件定義書の通りに作って納品したんだから、あとはそっち（現場）で使ってよ」と言いたくなる気持ちもわかります。
従来のプロジェクトマネジメントにおいて、成果物がリリースされた後の「運用」は、プロジェクトマネージャー（PM）のスコープ（責任範囲）外とされることが多かったからです。

しかし、PMBOK第8版では、この考え方に明確な警鐘を鳴らしています。
今回は、「プロジェクト」と「定常業務（オペレーション）」の違いを整理し、成果物を「使われるモノ」にするための重要な考え方を解説します。

プロジェクトと定常業務（オペレーション）の違い

組織の仕事は、大きく「プロジェクト」と「定常業務」の2つに分けられます。PMBOKでは、これらを明確に区別しています。

プロジェクトには「明確な始まりと終わり（有期性）」がありますが、定常業務には終わりがなく、継続していくという決定的な違いがあります。

「作って終わり」では価値は生まれない

これまでのPMBOKでも「プロジェクトと定常業務は違う」と言われてきました。
しかし、PMBOK第8版が最も強調しているのは、両者が完全に切り離されているわけではなく、「特定のタイミングで必ず交差し、成果物が移管（引き継ぎ）される」という事実です。

【PMBOK第8版の記述より】
プロジェクトの成果を組織の定常業務の枠組みへとシームレスに統合することを確実にするために、成果物、人的資源、および知識が、プロジェクトと定常業務の間で移管（引き継ぎ）される。

システムやプロダクトは、プロジェクト期間中に「完成」した時点では、まだ組織に1円の利益ももたらしていません。それが定常業務へと引き継がれ、現場のユーザーによって日々の業務で「使われ続ける」ことによって初めて、組織に「価値（Value）」をもたらすのです。

つまり、「タスクをこなして成果物を作ったらプロジェクトは終わり！」ではなく、「それが定常業務にしっかりと根付き、価値を発揮できる状態にする」ところまで見据えることが、これからのPMには求められます。

解決策：運用ユーザーを「初期から」巻き込む

では、どうすれば「現場で使われない」という悲劇を防ぎ、定常業務へスムーズに移管できるのでしょうか？

最大の解決策は、定常業務で実際にその成果物を利用するユーザーを、重要な「ステークホルダー」として捉えることです。

システム開発の現場では、決裁権を持つ経営層や部門長の意見ばかりを聞いてシステムを作ってしまい、いざ導入すると「現場の業務フローと合わなくて使いにくい」と反発されることが多々あります。

PMBOK第8版では、「プロジェクトの計画段階の初期に定常業務チームを関与させることが、プロジェクトの長期的な成功と持続可能性に大きな影響を与える」と明記しています。

プロジェクトが立ち上がった初期の段階から、こうした「現場（オペレーション）の声」をしっかりと吸い上げ、計画に反映させることが不可欠です。

まとめ：PMの責任は「納品」から「価値の維持」へ拡張した

プロジェクトと定常業務は、役割は違えど、組織に価値をもたらすための「両輪」です。

1. プロジェクトが組織を変革する新しい成果物を生み出す。
2. その成果物を定常業務にスムーズに移管（引き継ぎ）する。
3. 定常業務の中で使われ続けることで、長期的な「価値」が創出・維持される。

これからプロジェクトマネジメントを担う皆さんは、「自分の仕事は無事に納品することだ」とスコープを狭めず、「この成果物は、現場の定常業務で本当に使われ続けるだろうか？」という一段高い視点を持ってみてください。
その視点こそが、プロジェクトの成功率を劇的に引き上げる最強の武器になります。