建設PMのステークホルダーマネジメント実務｜発注者・設計・施工・ベンダー調整

「山根さん、発注者と施工がまた揉めてるんですけど、PMって結局何をしてる人なんですか」——先日、施工管理から建設PMへの転職を考えている方に、こう聞かれました。

結論から言うと、建設PMの仕事の半分以上は「揉め事の手前で手を打つ」作業だと僕は考えています。技術力やITスキルは前提条件であって、実際に評価されるのは発注者・設計・施工・ITベンダーという性格の異なる4者の利害を、プロジェクトが止まらない形で整理し続ける力です。今日はこの調整実務を、僕が現場で見聞きしてきた範囲で具体的に分解してお話しします。

0. 建設PMの調整業務がなぜ「本業」なのか

PMの1日のスケジュールを分単位で追ってみると、資料作成や進捗表の更新よりも、会議・電話・立ち話に費やす時間の方が長いことに気づきます。体感値で言うと、実働時間の4〜5割は誰かと誰かの間に立っている時間です。これは伝統的な建築プロジェクトでも同じですが、DX導入案件になるとステークホルダーの数そのものが増えます。従来のCM案件では定例会議が月2回程度で足りていたものが、施工管理アプリやBIM/CIMツールを提供するベンダーのカスタマーサクセス担当が加わることで、週1回・月4回程度まで増える傾向があると僕は見ています。会議の回数が倍になるということは、単純に調整対象の組み合わせも増えるということです。だからこそ、調整業務を「片手間の雑務」ではなく本業として設計し直す必要があると僕は考えています。

1. 発注者との調整――要望と予算のギャップをどう埋めるか

発注者側の関心事は、投資対効果と予算内での着地です。厄介なのは、要望が最初の稟議を通った後から少しずつ増えていくことです。ある中堅ゼネコンのBIM導入案件では、当初は設計フェーズの干渉チェックだけが目的だったものが、着工後に「施工管理アプリとの連携も見せてほしい」という要望が追加され、当初予算では吸収できないスコープ拡大が起きました。このとき僕がやったのは、要望を断ることではなく、追加要望をいったん一覧化し、優先度と概算コストを添えて発注者の意思決定者に返す作業です。感情的な押し問答を避け、判断材料を渡す役に徹することが、この局面での調整のコツだと感じています。実務手順としては、要望が出た当日中に一覧表への追記を済ませ、遅くとも3営業日以内に概算コストと影響工期を添えて発注者に一次回答を返すことを僕は目安にしています。この初動が遅れると、要望を出した側は「無視された」と感じ、後の交渉が余計にこじれるためです。逆に、初動対応を怠って2週間近く放置してしまった別の案件では、発注者側が業を煮やして直接施工側に要望を伝えてしまい、PMを介さない情報伝達が常態化しかけたことがありました。このときは慌てて発注者との定例を週次に戻し、すべての要望をPM経由で受ける運用に立て直すまで、1か月ほど余計な調整コストがかかっています。

2. 設計との調整――仕様変更のタイミングと合意形成

設計側の関心事は、意匠・構造の整合性です。設計者は基本的に「良いものを作りたい」という動機で動いているため、施工性やコストの制約を後から突きつけられることを嫌がります。仕様変更のタイミングがずれると、設計側は「なぜ今さら」と感じ、施工側は「なぜもっと早く言わないのか」と感じる、典型的なすれ違いが起きます。僕の経験では、BIM/CIMを使った合意形成の場を設計フェーズの早い段階で週次に設定し、施工性チェックを都度その場で共有しておくと、後工程での大きな手戻りを減らせます。会議の頻度を上げることは一見コスト増に見えますが、手戻りによる工期遅延の方が影響が大きいというのが僕の体感です。失敗例として、ある案件では設計フェーズ後半まで施工側の意見聴取を先送りにした結果、着工直前に配管ルートの再検討が発生し、着工が2週間程度遅れたことがありました。このときの反省は、施工性チェックを「終盤にまとめて行う」のではなく「毎週少しずつ確認する」方式に切り替えるべきだったという点です。以後、僕が関わる案件では設計フェーズ開始から2週目には必ず施工側の代表者を会議に招き入れることをルール化しています。

3. 施工との調整――スケジュールと安全を最優先させる技術

施工側の関心事は工程遵守と安全確保です。設計変更や発注者の要望追加は、現場から見れば「予定していなかった手戻り」でしかありません。ここで大事なのは、変更を伝えるタイミングと伝え方です。金曜日の夕方に来週の工程変更を伝えるようなことは避け、変更が確定した瞬間に、影響範囲と代替案をセットで持っていくようにしています。僕が意識している実務手順は次の3段階です。まず変更確定から2時間以内に現場責任者へ一報を入れること。次に24時間以内に影響範囲と代替案をまとめた資料を渡すこと。最後に48時間以内に現場側の対応判断を確認し、必要であれば再調整することです。連絡だけして判断材料を渡さないと、現場側は独自の解釈で動いてしまい、後から二度手間になるケースが少なくありません。施工管理側との信頼関係は、変更の回数よりも「事前に知らされていたかどうか」で決まると僕は考えています。

4. ITベンダー・SaaS導入側との調整――現場の抵抗をどう扱うか

建設DX案件で新しく登場するのが、施工管理アプリやSaaSを提供するベンダー側の担当者です。彼らの関心事は導入実績とライセンスの継続利用ですが、現場の職人や若手監督にとっては、新しい入力作業が増えるだけの負担に感じられることが少なくありません。あるプロジェクトでは、日報入力アプリの導入初月に現場からの入力率が想定の半分程度にとどまり、ベンダー側は「操作説明が足りないのでは」と考え、現場側は「そもそも紙の方が早い」と考えるという、典型的なすれ違いが起きました。このときは、入力項目を導入当初の3分の2程度まで絞り込む交渉をベンダーと行い、同時に現場側には入力にかかる時間が1日あたり数分短縮される見込みであることを数字で示すことで、双方の言い分を一段階ずつ譲歩させる形で着地させました。導入後2か月目には入力率が導入初月の水準からおおむね倍近くまで回復したことを、その後の定例会議でベンダー・現場双方に共有し、次の機能追加交渉の材料としました。ITベンダーとの調整で大事なのは、現場の抵抗を「ITリテラシーの問題」と単純化しないことだと僕は思っています。

5. 利害が衝突したときの優先順位づけ――僕が使う判断基準

4者の利害が同時に衝突したとき、僕が実務で使っている優先順位は「安全・工期・予算・品質」の順です。これは絶対のルールではありませんが、多くの案件でこの順序に沿って判断すると、後から関係者の納得を得やすいという体感があります。重要なのは、この優先順位をプロジェクト開始時に発注者と合意しておくことです。衝突が起きてから順位を決めようとすると、その場にいる声の大きい人の意見に引っ張られやすくなります。事前に紙一枚で共有しておくだけで、判断の速度と納得感の両方が変わってくると感じています。実際、ある案件では優先順位を事前合意していたため、安全確保のために工期を数日延ばす判断を発注者にその場で了承してもらえましたが、別の案件では優先順位が曖昧だったために同様の判断に1週間以上かかり、結果的に現場の不満が募る事態になりました。この差は、判断基準そのものの正しさよりも、それを事前に紙で共有していたかどうかにあったと僕は振り返っています。

6. 転身直後にありがちな失敗と、その対処

施工管理や設計の出身者がPMに転身した直後によく見る失敗は、自分の出身分野の関心事を優先しすぎてしまうことです。施工出身のPMは工程を守ることに意識が向きすぎて発注者への説明が後手に回りがちですし、設計出身のPMは仕様の完成度にこだわりすぎて施工側の負担を軽視しがちです。僕自身も転身直後は、現場の安全と工程を優先するあまり、発注者への状況共有が週1回の定例任せになってしまい、発注者側から「進捗が見えない」という不満を受けたことがあります。この対処として僕が実際に行ったのは、定例とは別に、進捗の要点だけを箇条書きでまとめた短い報告を毎週金曜に発注者へ送る運用に変えたことです。分量にして5行程度の簡単なものですが、これだけで発注者からの不満はほぼ解消しました。転身初期は、自分がどの立場に偏りやすいかを早めに自覚し、意識的に他のステークホルダーへの発信頻度を増やすことが有効な対処になると僕は考えています。

(結論)

建設PMのステークホルダーマネジメントは、特別な交渉術というより、誰の関心事を優先すべきかをあらかじめ決めておき、変更が起きた瞬間に影響範囲を添えて伝える、という地味な積み重ねだと僕は考えています。施工管理や設計の経験がある方は、自分の出身分野の視点が強く出やすい分、他のステークホルダーの関心事を言語化する練習が転身初期の課題になるはずです。皆さんいかがでしたでしょうか。調整業務は目立ちにくい仕事ですが、プロジェクトの成否を左右する本業です。では今日もがんばりましょう。