#225 PMBOKが「QCDから価値へ」転換した理由——PLM導入の失敗と、PMBOK第8版の思想は同じだった
Output / Outcome / Benefit / Value の4段階 · 「稼働したのにExcelを手放さない」の正体 · 経営改革としてのPLM
🏭 PLMシステム稼働1年後の製造業 PM：
「プロジェクトは成功しました。納期通り、予算内、品質基準もクリアです。」
😤 経営層：
「ところで——設計部門はまだExcelを使っているんだが、これはどういうことかね？」
💡 PLMマエストロ：
「そのPMはOutput と Result を達成したが、Outcome を定義しなかった。」
——そして2025年11月、PMBOKの第8版が静かにこの問題に答えを出した。「プロジェクトの成功基準を、QCDから価値（Value）へ転換する」と。
PMBOK第8版が起こした「静かな革命」——QCDではなくValueが成功基準になった
PMBOK（プロジェクトマネジメント知識体系）は、長年QCD——品質（Quality）・コスト（Cost）・納期（Delivery）——をプロジェクト成功の基準としてきた。しかし第8版は、その定義を根本から書き換えた。
「プロジェクトとは、成果物を作ることではなく、価値を生み出すことだ。」
この転換は、PLM導入の現場で長年繰り返されてきた「稼働したのに誰も使わない」という構造的失敗と、全く同じ問題意識から来ている。PMBOK8は、その失敗を「Output で満足したプロジェクト管理の限界」と定義し、成功の基準を4段階の連鎖で表現した。
PMBOK8が示した4段階の連鎖——Output → Outcome → Benefit → Value。PLM導入で問題になるのは、この連鎖の最初の一歩で止まってしまうことだ。「システムが稼働した（Output）」という達成感が、その後の問いを封じてしまう。
Outcomeが定義されなかった導入は、なぜ必ず失敗するのか
「Outcome」とは「誰の・何が・どう変わったか」の三位一体だ。「設計者の（誰の）× 設計変更リードタイムが（何が）× 3週間から3日に（どう変わったか）」——このように人の行動・状態の変化として記述できて初めて、Outcomeと呼べる。
Outcomeを導入前に定義しないと何が起きるか。プロジェクト解散後にPMは次のプロジェクトへ異動する。SIerとの契約は終了する。推進担当者は日常業務に戻る。そして「誰も評価しない」という真空地帯が生まれ、現場はExcelへ静かに先祖返りする。
これはPLM固有の問題ではない。PMBOK8が「価値（Value）」を成功基準にした背景には、あらゆるシステム導入でこの構造的失敗が繰り返されてきたという全世界のPMたちの反省がある。
PMBOK第8版 × PLM導入——同じ問いへの同じ答え
PMBOK8「プロジェクトの成功は、成果物の納品ではなく、ステークホルダーへの価値提供で定義される」
PLMマエストロ「動けば成功ではない。価値が出て初めて成功だ」
——この2つの主張は、全く同じことを言っている。
PMBOKという世界標準が、PLM導入の本質論と一致した——これは偶然ではなく、構造的な必然だ。
「PLM導入も PMBOK8 も、成功の基準は同じだ。
"システムが動いたか"ではなく、
"人と組織がどう変わったか"。
Output で満足した瞬間に、プロジェクトは失敗する。
Outcome を定義し、Benefit と Value まで見届けること——
それが、これからのPMとPLM導入の標準になる。」
PMBOK第8版が「QCDから価値へ」という転換を宣言したとき、PLM導入の現場では「それは10年前から言っていた」と感じたPMも多いはずだ。しかし世界標準がこの思想を正式に採用した今、「Outcomeなき導入」への言い訳は通用しなくなった。導入前にOutcomeを定義する——この一歩が、PLMを「使われるシステム」に変える唯一の道だ。
「言葉が思考を規定する。OutcomeではなくResultで考えるPMは、Resultしか生み出せない。」
