#19:「管理」ではなく「監理」せよ：2026年、DXが失敗する本当の理由（Part 3 実行編開始に際して）
お世話になっております。 YMGアドバイザリーの山口です。
新年あけましておめでとうございます。引き続き本NewsLetterをお読みいただき、ありがとうございます。
1.2026年、現場DXは「実行」のフェーズへ
昨年のPart 2（方針立案編）では、現場DXがなぜ進まないのかを「文化の壁」「人の限界」「構造の欠如」という観点から分解し、
Closed-loopや翻訳プロトコルといった“構造論（Why/What）”を掘り下げてきました。
多くの読者の皆さまから「構造の重要性はわかった」「何をやるべきかの方向性は見えた」という声もいただきました。
一方で、ここから先が本番です。
なぜならDXは、理解した瞬間に成功するものではなく、わかっているのに泥沼化するのが常だからです。
「設計思想は正しいはずなのに、会議が増え、現場の疲弊が増え、最後は“やっぱり使えない”で終わる。」
こうした経験に心当たりがある方も多いのではないでしょうか。
今年から始まるPart 3（実行編）では、この“構造を現実に実装するためのHow”を、徹底的に解き明かしていきます。
その第一回として本稿では、DXプロジェクトが失敗する根本原因を、あえて一言で言い切ります。
「管理」しかしていないからです。2026年、必要なのは「管理」ではなく「監理」です。
2. PMのダッシュボードは「オールグリーン」なのに、なぜ現場は炎上するのか？
DXの失敗プロジェクトには、共通する“怪奇現象”があります。
定例会議では、こう報告されます。
スケジュール：順調です（グリーン）
課題管理：大きな問題はありません（グリーン）
要件定義：合意済みです（グリーン）
開発：計画通りです（グリーン）
ところが、リリース直前になって急に現場が反発し、炎上します。
「この画面では回らない」
「入力が増えるだけ」
「誰のためのシステムですか」
「結局、Excelに戻るんですよね」
PMのダッシュボードはオールグリーンなのに、現場は真っ赤。
このギャップが生まれる原因は、驚くほどシンプルです。
「進行（Progress）」だけを管理し、「構造（Structure）」を誰も見ていないからです。
タスクが消化されることと、正しいシステムができることはイコールではありません。
議事録が整備されることと、現場が動くこともイコールではありません。
多くのDXは、「管理」によって“動いている感”を作ります。
しかし本当は、その間にプロジェクトの設計図が歪み、現場との接続が切れ、
Closed-loopが途切れ、最後に破綻が顕在化します。
ここに、一般的なProject Managementの限界があります。
そして、この限界を超える役割こそが、次章で述べる「監理者」です。
3. 必要なのは「Project Manager」ではなく「Project Supervisor（設計監理者）」
建築の世界には、現場を動かす“現場監督”とは別に、「設計監理者」が存在します。
現場監督（PM）が工程・人員・資材を管理するのに対し、
監理者（Architect/Supervisor）はこう問い続けます。
図面の意図通りに施工されているか？
構造上の矛盾が埋め込まれていないか？
見えない部分（配管・配線・耐荷重）は破綻していないか？
完成後に“住めない家”にならないか？
DXも同じです。
PMが見るのは主に「進行の健全性」です。
ところがDXの成否を決めるのは「構造の品質」です。
この構造品質をチェックする役割がプロジェクト内に不在なまま、DXは進んでしまいます。
ここで、両者をあえて定義しておきます。
Manager（管理者）： 「納期に間に合うか？」「予算内か？」「課題は潰せているか？」を問う。— 進行のプロです。
Supervisor（監理者）： 「その設計でデータはつながるか？」「現場は回るか？」「判断ロジックは再現できるか？」を問う。— 構造のプロです。
ここでいう「構造」とは、業務フローや画面設計だけを指しません。
現場の思考様式・判断基準を、IT／業務設計、そして経営の意思決定へと接続するための「プロトコル変換（翻訳）」まで含めた設計品質を指します。
この変換が設計に埋め込まれていない限り、プロジェクトは“進んでいるように見えて”、現場と経営の間で意味がつながらず、最後に破綻が顕在化します。
多くのDXが失敗するのは、PMの能力不足だからではありません。
PMが見ていない領域に、失敗の原因が埋まっているからです。
YMG Advisoryが2026年に提供する価値は、この後者—設計監理者（Project Supervisor）としての視点です。
4. YMGが提供する「3つの監理視点」
Part 3では、YMGが「監理の技術」を体系化し、具体的なチェックポイントとして公開していきます。
監理の視点は大きく3つです。
① データの監理：つながるべきものは、つながっているか？
DXの現場では「データ連携」がしばしば“技術課題”として処理されます。しかし本質は技術ではなく設計です。
AM-BOM（As-Maintained BOM）とサービス実績、顧客情報、部品、作業ログが、Closed-loopとして循環する設計になっているか。
翻訳プロトコル（現場の判断基準をデータへ変換する規則）が、仕様に落ちているか。
ここが抜けた瞬間、DXは「見える化」で止まります。
② 業務の監理：非計画性を吸収する構造が、設計に入っているか？
フィールドサービスの現実は、予定通りには進みません。
突発対応、欠品、顧客都合、天候、二次障害、スキル差。
にもかかわらず、多くのDXは“理想的に計画された業務”を前提に要件を作ります。
監理者は問います。
「Bufferはどこに入っているか？」
「例外処理は“運用で頑張る”前提になっていないか？」
「非計画性を吸収する緩衝構造が、設計に明示されているか？」
ここを監査せずに実装へ進めば、現場は必ず詰みます。
③ 人の監理：評価制度とKPIは、システムの目的と整合しているか？
プロジェクトが炎上する最大の原因は、実は“機能不足”ではありません。
人が動かない設計です。
評価制度とKPIが、システムの目的と乖離していないか。
入力を求めるなら、その入力が現場に返ってくる循環（自己効力感）が設計されているか。
「現場のがんばり（気合い）」ではなく「学習が回っているか」を測る指標になっているか。
監理者は、ここを“制度として監査”します。
5. あなたのプロジェクトに「監理者」はいますか？
DXが泥沼化したとき、多くの組織は「管理」を強化します。会議を増やし、資料を増やし、進捗表を細かくし、赤字を潰します。
しかし、それは“スケジュール表を埋める作業”に逃げているだけかもしれません。
本当にやるべきは逆です。まず設計図を広げ、構造の歪みを見抜く（監理）ことから始めるべきです。
「管理」では、構造は良くなりません。監理があって初めて、管理が意味を持ちます。
あなたのDXプロジェクトに、設計監理者はいますか？
もし答えが「いない」なら、次に起こる炎上は“偶然”ではなく“必然”です。
次回以降、Part 3では、ここで述べた監理視点を具体的なチェックリスト—監理のPlaybookとして公開していきます。
現場DXを「管理」から解放し、「監理」によって成功へ導くために。2026年、実行編を開始します。
取り上げてほしいテーマ、ご質問、ご相談などございましたら、お気軽に ymg-info@ymg-advisory.com までご連絡ください。
2026年も、引き続きどうぞよろしくお願いいたします。