部署間の対立をほどく方法――効いたのは管理表より「人間関係」だった

「それは、うちの担当ではありません」。プロジェクトの会議でこの一言が出はじめたら、要注意です。業務部門とシステム部門、発注側と開発側。部署間の対立が表に出ると、スケジュールも品質も、じわじわと崩れていきます。

アクセンチュアで12年、数百人規模のプロジェクトでPMOを務めるなかで、部署同士が「バチバチ」に対立している現場には何度も立ち会いました。そこで最終的に効いたのは、立派な管理表でも会議体の設計でもありませんでした。困ったときに助け合える人間関係です。

この記事では、部署間の対立がなぜ起きるのか、どうほどいてきたのかを、現場の経験から整理します。

部署間の対立で、プロジェクトは静かに止まる

システム開発では、たいてい「作る側」と「使う側」に分かれます。開発側とユーザー側、それぞれにコンサルタントがつくことも珍しくありません。クライアントの社内でも、営業部門は新しいやり方を入れたい、バックオフィスは業務をそろえたい、というように主張がぶつかります。

対立そのものは、どの組織にもあります。怖いのは、それがプロジェクトの動きを止めることです。

• 仕様の確認を投げても、相手の部署から返事が来ない
• テストで不具合が出るたびに「それは要件にない」「いや、書いてあった」の応酬になる
• 予算やシステム仕様の希望が部署ごとにかみ合わず、コンサルタントが板挟みになる
• 会議では誰も反対しないのに、終わってから別ルートで話がひっくり返る

こうなると、どれだけ細かく課題管理表を更新しても、プロジェクトは前に進みません。表に書かれた課題の「担当者」が、そもそも相手と話したくないからです。

対立が生まれる3つの原因

現場で見てきた対立は、おおむね次の3つが重なって起きていました。

1. 目的と利害がかみ合っていない

開発側は「期限内に仕様どおり作りきること」、ユーザー側は「現場の業務が回ること」を優先します。どちらも正しいのですが、ゴールの置き方が違うので、同じ出来事でも評価が逆になります。

2. 相手の本音が見えていない

公式の会議や文書だけでやりとりしていると、相手が「本当は何に困っているのか」が見えません。見えないものは、悪意に見えやすい。「わざと遅らせているのでは」という疑いが、さらに関係を冷やします。

3. 決める人のところまで届いていない

部署同士の話し合いで決着がつかない論点は、最終的には責任者が決めるしかありません。ところが、その論点が責任者に上がらないまま、現場同士の言い合いが続いてしまう。これも対立が長引く大きな理由です。

効いたのは「あちら側」に入っていくこと

ある大規模なシステム開発で、開発側とユーザー側がはっきり仲違いしていたことがあります。双方の目的と利害がかみ合っておらず、会議のたびに空気が重くなる状態でした。

開発側のコンサルタントだった私が選んだのは、ユーザー側のメンバーと打ち解けることでした。立場としては逆側ですが、「話のわかるやつ」として、あちら側に入っていこうとしたのです。

仲良くなってからは、開発側とユーザー側、両方の本音の不満を聞けるようになりました。こちらの意見も、誤解なく伝わるようになりました。最終的には、お互いに肩を組めるくらいの関係になっていました。

効果がはっきり出たのは、システムのローンチのときです。「私たちのほうでは、ここまでやりました。あとはお任せします」と伝えると、「あとは任せてください」と威勢のよい返事が返ってくる。煩雑な手続きや形式ばったやりとりを飛ばして、すぐに相談し、すぐに確認できる。連携は驚くほどうまくいきました。

別のプロジェクトでは、進むのが速いうえに成果も著しかったチームがありました。業務側の人がシステムテストに立ち会い、システム側の人が業務側の報告資料を一部つくる。一緒に食事に行ったと思ったら、ずっと仕事の話をしている。そこまでいくと、「それはうちの担当ではありません」と言うどころか、喜んで手を差し伸べ合うようになります。

相手側に入っていくときに大事にしていたのは、話す順番です。いきなり本題や自分たちの言い分から入るのではなく、次の順で話します。

1. まずは「いやー、大変ですよね」と、相手の状況に共感する
2. そのうえで、いまプロジェクトで起きている課題や論点を、こちらから率直に説明する
3. 最後に「あなたはどう思いますか？」と、相手の考えを聞く

共感から入り、状況を共有し、意見を求める。この順番で話すと、相手にとっては「責められている」のではなく「相談されている」場になります。こちらの言い分を押しつけずに、相手の見方を聞く姿勢を最初に示すこと。それが、本音で話せる関係の入口になります。

もちろん、飲み会や付き合いの形そのものが大事なのではありません。大事なのは、相手の事情を本音で聞ける関係を、利害や指揮系統の外側につくっておくことです。

対立をほどくときの手順：聞く・見極める・責任者に託す

人間関係だけで、すべての対立が片づくわけではありません。論点そのものに決着をつける必要があるときは、次の順番で進めてきました。

両方の意見に、徹底して耳を傾ける

まずは両方の部署に、こんなふうに聞いていきます。

• 「この件の不満点はどこですか？」
• 「相手の部署の、何が納得いきませんか？」
• 「よく思っていないのは、どうしてですか？」

どちらに理があるかを見極める

丁寧に聞いていくと、「どちらにも同じくらい理がある」というケースは、実はそれほど多くありません。多くは「筋の通った意見」と「そうではない意見」に分かれます。そうではない側には、気持ちには理解を示しつつ、現実を理解してもらえるよう説得します。両方とも筋が通っていない場合は、どちらにも肩入れしない、フラットな案を用意します。

最後の判断は、責任者に託す

「皆さんの意見をまとめると、こうなりました。どうしましょう？」と、相手方の上長も交えて議論します。両方の言い分がまっとうな場合でも同じです。対立がある以上、コンサルタントが責任を持てない意思決定がどうしても残ります。それはプロジェクトの責任者に託すのが筋です。

この進め方で、部署同士の対立が原因でプロジェクトが頓挫したことはありません。ぎりぎりまで追い込まれたことは何度もありますが、すべてリリースまでたどり着いています。

ひとつ注意があるとすれば、決定権のある人と良い関係を築いたとしても、頼りすぎないことです。その人の判断に偏りがあると、プロジェクトごと傾くことがあります。人をよく見ることは、人間関係づくりとセットです。

開発メンバーにもできること

部署間の対立をほどくのはPMOやマネージャーの仕事、と思われがちですが、開発メンバーの立場からできることもたくさんあります。

• ユーザー側のテストや業務説明に、一度でいいので立ち会ってみる
• 相手の部署が使う資料や報告の形を知り、ほんの一部でも手伝ってみる
• 「それはうちの担当ではない」と言いたくなったら、「誰に渡せば早く片づくか」を一緒に考える
• 相手の不満を聞いたら、自分のチームにそのまま持ち帰って共有する

こうした小さな越境は、立場を超えた信頼をつくります。そして、この「両側の言葉がわかる」経験こそが、上流工程やPMOの仕事でいちばん効いてくる力でもあります。

まとめ：管理表より先に、助け合える関係を

• 部署間の対立は、目的と利害のずれ・本音が見えないこと・決める人に届かないことが重なって起きる
• いちばん効いたのは、相手側に入っていき、本音で話せる関係をつくること
• 論点の決着は「聞く・見極める・責任者に託す」の順で進める
• 開発メンバーでも、小さな越境から関係づくりは始められる

プロジェクトのパフォーマンスを上げるのは、立派な管理表でも資料でもなく、困ったときに助け合える関係です。良好な人間関係は、最強の業務改善策だと思っています。

あわせて読みたい

• プロジェクトの進捗が止まる本当の理由は「決める人がいない」こと
• PMOに向いていない人とは？「いると疲れるPMO」と「助かるPMO」の違い