建設DXプロジェクトが炎上する典型パターンと立て直しの実務

「このプロジェクト、なんか雲行き怪しくないですか」と、面談でお会いした方がぽつりとおっしゃったことがあります。

結論から言うと、建設DXプロジェクトが炎上する背景には、いくつかの典型パターンがあると僕は考えています。要件定義の段階で現場感覚と本社主導の設計がズレている、ステークホルダーごとの温度差が放置されている、ゼネコンとITベンダーの責任分界が曖昧なまま進んでしまう——この3つが重なると、火種が一気に燃え広がる印象があります。今日は、僕がこれまで見聞きしてきた炎上プロジェクトの構造と、建設PMとしてどう立て直していくかを、実務のレベルで整理してみたいと思います。

1. 「炎上」とは具体的にどういう状態を指すのか

まず言葉の整理をしておきたいと思います。僕が「炎上」と呼んでいるのは、単発の遅延や仕様変更ではなく、複数の火種が同時多発的に発生し、誰も全体像を把握できなくなっている状態を指しています。スケジュールの遅延が1ヶ月を超えて続く、要件変更の依頼が週に何度も飛んでくる、現場側の不満が現場監督や施工管理者を経由せず直接本社や経営層に届くようになる——この3つが同時に出ている案件は、僕の体感値としてはかなり危険なゾーンに入っていると感じます。1つだけであれば、それは通常の調整の範囲に収まることが多く、慌てて「炎上対応」というラベルを貼る必要はないと考えています。

比喩で言うなら、これは小さな漏水を放置したまま増築を続けている建物に近い状態です。表面上は工事が進んでいるように見えても、基礎の部分でひずみが蓄積していて、ある瞬間に一気に表面化する。建設DXプロジェクトの炎上も同じで、要件定義や合意形成のフェーズで生まれたひずみが、実装やテストの段階になって一気に噴き出すことが多いというのが僕の実感です。だからこそ、炎上を「テスト工程で発覚した問題」として捉えるのではなく、「もっと手前の設計工程で仕込まれていた問題」として捉え直すことが、立て直しの第一歩になると考えています。

2. 典型パターン(1) 要件定義が現場感覚とズレている

最も多く見聞きするのが、このパターンだと感じています。本社のDX推進部門やIT部門が主導して要件定義を進めた結果、実際に施工管理ツールやBIM/CIM関連の仕組みを使う現場の感覚と噛み合わなくなるケースです。ある案件では、施工管理アプリの入力項目を本社側が「網羅性」を重視して細かく設計したのですが、現場の職員からは「これを毎日全部埋めるのは無理だ」という声が出て、稼働開始直後から入力率が僕の体感で3割程度まで落ち込むという問題に発展しました。

この手のズレは、要件定義のワークショップに現場代表者を1〜2名呼んでいるだけでは防ぎきれないというのが僕の考えです。呼ばれた代表者が現場全体の感覚を代弁できているとは限らず、むしろ「声の大きい一部の意見」だけが要件に反映されてしまうことがあります。建設PMとしては、要件定義の初期段階から複数の現場・複数の職種から声を拾う仕組みを設計段階で組み込んでおく必要があると考えています。具体的には、現場ヒアリングを1拠点だけで終わらせず、規模や工種の違う拠点を最低3つ回るだけでも、要件の偏りはかなり減らせるという印象を持っています。

3. 典型パターン(2) ステークホルダーの温度差を放置している

建設DXプロジェクトには、発注者・設計・施工・ITベンダー・経営層など、立場も温度感も異なる関係者が同時に関わります。この温度差そのものは自然に発生するものですが、炎上プロジェクトの多くは、その温度差を「見える化」せずに放置しているという共通点があると僕は感じています。

具体的には、経営層は投資対効果とスケジュールの遵守を重視し、現場は日々の業務負荷の増加を懸念し、ITベンダーは要件の確定を急ぎたがる、という三者の思惑がそれぞれ別の速度で動いてしまう状態です。誰かが悪意を持っているわけではなく、単に見ている時間軸と評価軸が違うだけなのですが、これを放置すると「経営層は現場を軽視している」「現場はDXに非協力的だ」という相互不信に発展しやすいという印象があります。建設PMの役割の一つは、この温度差を定期的に言語化し、関係者同士が同じ地図を見ている状態を作ることだと僕は考えています。僕の経験上、月次の報告会だけでこの温度差を吸収しようとするのは難しく、週次で短時間の同期を挟む方が結果的に手戻りを減らせると感じています。

4. 典型パターン(3) ゼネコンとベンダーの責任分界が曖昧

三つ目のパターンは、契約や体制の設計段階に起因するものです。特にPMO機能が組織図のどこにも明確に位置づけられていない案件では、「誰が最終的に意思決定をするのか」「仕様変更の承認権限は誰にあるのか」が現場任せになってしまうことが多いという体感値があります。ゼネコン側は「ベンダーが決めるべき」と考え、ベンダー側は「発注者側の業務要件だから発注者が決めるべき」と考える。この押し付け合いが数週間続くだけで、スケジュールへの影響は決して小さくありません。

僕がこれまで見た中で立て直しに成功した案件では、必ずと言っていいほど、契約段階もしくは炎上発覚後の早い段階でPMOの役割と権限を文書化していました。誰が何を承認し、誰が何をエスカレーションするのかを、いわゆるRACI表のような形で1枚の紙にまとめるだけでも、責任分界の曖昧さから来る停滞はかなり減らせるという印象を持っています。逆に、この文書化を後回しにした案件では、炎上が一度収まったように見えても、次の変更要求のタイミングで同じ押し付け合いが再発するケースを複数見てきました。

5. 立て直しの実務ステップ ー 今日からできるアクション

ここからは、実際に炎上プロジェクトに投入された建設PMが、今日からできる実務ステップを整理します。順番通りに進める必要はありませんが、僕の経験上この順番が比較的うまくいくことが多いと感じています。それぞれに、僕の体感値としての目安の所要時間も添えておきます。

1. 現状の可視化（目安1〜2日）：スケジュール表、課題リスト、関係者の発言メモを1つのドキュメントに集約し、誰が見ても「今何が起きているか」がわかる状態をつくる。
2. ステークホルダーマップの再構築（目安半日〜1日）：発注者・現場・設計・ベンダー・経営層それぞれの関心事と不満点を書き出し、温度差を見える化する。
3. スコープの再定義（目安1日）：全機能を一気に立て直すのではなく、直近1〜2週間で確実に成果が出せる範囲まで一度スコープを小さく切り直す。
4. 週次レポートの粒度見直し（目安数時間）：進捗率だけでなく、リスクと決定待ちの事項を明示するフォーマットに変更する。
5. 小さな成功体験の設計（目安1〜2週間で1つ）：現場が「使ってよかった」と感じられる場面を1つでも早く作り、そこを起点に協力姿勢を取り戻す。

特に5番目の「小さな成功体験」は、炎上プロジェクトの立て直しにおいて僕が最も重視しているポイントです。全体を一気に立て直そうとすると、関係者の疲弊がさらに進んでしまうことが多いので、まずは狭い範囲で「これはうまくいった」という実感を作ることが、その後の合意形成を大きく楽にすると考えています。ここで無理に大きな成果を狙うと、期待値だけが上がって次の失敗が余計に目立つという逆効果になりやすいので、あえて小さく設計するという判断が重要だと感じています。

6. よくある失敗と対処、ケースの比較

立て直しの過程でも、いくつかの失敗パターンが繰り返されやすいと感じています。代表的なものを比較表で整理してみます。

この表からも分かるように、失敗の多くは「善意で頑張った結果、範囲や合意形成の設計を誤る」という構造を持っていると僕は感じています。炎上プロジェクトの立て直しは、根性論や長時間労働で解決するものではなく、可視化と優先順位づけという地味な作業の積み重ねだというのが、僕の一貫した実感です。

実際に僕が話を伺った案件の一つでは、要件定義のやり直しに着手する前に、現場3拠点それぞれで30分程度のヒアリングを行い、不満点を項目ごとに分類しただけで、「本社は現場の声を聞く気がある」という印象が現場側に生まれ、その後の協力度が大きく変わったという話がありました。特別な技術や大きな予算を使ったわけではなく、順序を変えただけで空気が変わったという点が、印象に残っています。一方で、別の案件では同じような不満が出ていたにもかかわらず、本社側がすぐに新しいシステム機能の追加で対応しようとしてしまい、現場からは「話を聞かずに機能だけ増やされた」という受け止められ方になり、逆に信頼を落としてしまったという話も聞いています。この2つの案件の違いは、投じたリソースの量ではなく、最初に「聞く」という手順を踏んだかどうかにあったと僕は考えています。

(結論)

建設DXプロジェクトの炎上は、要件定義のズレ、ステークホルダーの温度差、責任分界の曖昧さという3つのパターンが重なって発生することが多いと僕は考えています。そしてその立て直しは、現状の可視化とステークホルダーマップの再構築という地味な作業から始まり、スコープを小さく切り直し、小さな成功体験を積み重ねていくプロセスだと感じています。建設PMという役割は、こうした炎上の火消しと予防を担う立場でもあり、その経験自体が次のキャリアにおける具体的な実績にもなり得ると僕は考えています。皆さんいかがでしたでしょうか。では今日もがんばりましょう。