連携│部門間の壁は、仲の悪さではなく情報の非対称が作っている。

連携

部門間の連携が悪い会社を見ると、多くの経営者は「仲が悪い」と言う。

営業と開発が噛み合わない。
CSと営業で温度感が違う。
管理部門が現場を分かっていない。
現場は管理部門を信用していない。

もちろん、感情の問題がゼロとは言わない。
だが本質は、そこではない。

連携を壊しているのは、性格ではなく情報の非対称である。

営業は顧客の圧を見ている。
開発はリソースの限界を見ている。
CSは継続の危険信号を見ている。
管理部門は数字の悪化を見ている。
社長は全体を見ている。

全員が違う景色を見ている。
しかも、その景色が互いに十分には共有されない。

だから、それぞれの正しさがぶつかる。
その結果、「連携が悪い」と見える。

危機時の組織で問題なのは、部門間の関係が冷たいことではない。
見ている現実が揃っていないことである。

今回のテーマは、その連携だ。

前回の記事では、決まらない会議は時間の問題ではなく、議題の設計が間違っていると書いた。

前回の記事はこちら

会議は、共有の場なのか、意思決定の場なのか、詰まりを外す場なのかを切り分けなければ、会社は前に進まない。

これはその通りだ。

ただ、会議で何かを決めても、現場で噛み合わない会社がある。

優先順位も決まった。
役割も切った。
やることも見えた。
それでも部門間で動きが揃わない。
営業は営業で走る。
開発は開発で守る。
CSはCSで危機感を持つ。
管理部門は数字を出す。

なのに、会社としては前に進んでいない。
そのとき根っこにあるのが、連携不全である。

危機時の連携は、仲良くすることではない。
違う景色を見ている部門同士が、同じ現実を持てる状態を作ることである。

状況

よくある会社の風景がある。

売上が鈍化している。
新規案件はあるが、受注までの温度感が落ちている。
既存顧客の継続も怪しくなっている。
開発現場には割り込みが増え、優先順位が揺れている。
粗利も落ちてきた。
資金にも余裕がなくなってきた。

この局面で、部門間のズレが表に出る。

営業は言う。
「今は案件を落とせない。顧客の要望に応えないと競合に負ける」

開発は言う。
「このまま個別要望を入れ続けたら、既存の重要案件が全部遅れる」

CSは言う。
「受注より先に既存顧客が冷えている。今は継続のほうが危ない」

管理部門は言う。
「売上より粗利と入金条件を見ないと、数字が持たない」

全員、正しいことを言っている。
ここが難しい。

誰か一人が間違っているわけではない。

それぞれ、自分の持ち場から見える現実を語っているだけだ。

だが、そのままだと会議はぶつかる。

営業は「現場を分かっていない」と思う。
開発は「また無理を押しつけられる」と思う。
CSは「新規ばかり見て既存を軽く見ている」と思う。
管理部門は「感覚で仕事を進めている」と思う。

こうして会社では、「連携が悪い」という言葉が出始める。

だが本当は違う。
連携が悪いのではない。
見ている現実が揃っていないのである。

--

問題

部門間の壁は仲の悪さから生まれるのではない

情報の非対称から生まれる。

営業は顧客接点を持っている。
だから、失注しそうな温度や、今この案件を逃したくない焦りを知っている。

だが、開発の優先順位変更が全体に何を起こすかは見えていない。

開発は工数の逼迫を見ている。
だから、どの割り込みが全体を壊すか分かっている。

だが、顧客側の温度や、営業現場の圧は見えていない。

CSは既存顧客の不満の蓄積を見ている。

管理部門は数字のズレを見ている。

社長は全体の資源配分を見ている。

全員が違う情報を持ち、違う危機感を持つ。
このとき組織に起きるのは、意見の不一致ではない。

危機認識の不一致

営業にとっての危機は失注かもしれない。
開発にとっての危機はリソース崩壊かもしれない。
CSにとっての危機は継続率低下かもしれない。
管理部門にとっての危機は粗利悪化やキャッシュ悪化かもしれない。

どれも危機だ。
だが、どれを先に扱うかが揃っていないと、組織は部門最適で動く。

すると、連携しているように見えて実際には相殺し合う。

営業が取った案件を、開発が嫌がる。
開発が守った計画を、CSが現場感とズレていると感じる。
CSが守りたい顧客に、営業は工数を割けない。
管理部門が止めたい支出を、事業側は必要投資だと思う。

この状態になると、会社は一つの組織ではなく、
それぞれの正しさを主張する複数部門の集合体になる。

危機時に本当に怖いのは、部門対立そのものではない。
部門ごとに違う現実を持ったまま経営を進めることである。

--

判断・管理・実行

では、連携はどう作るべきか。

まず判断として必要なのは

部門ごとに見えている情報の違いを前提に置くことである。

営業はなぜそう言うのか。
開発は何を恐れているのか。
CSはどんな異変を見ているのか。
管理部門はどの数字を危ないと見ているのか。

ここを「分かっていない」で片づけるのではなく、
それぞれが持つ情報の偏りとして理解しなければならない。

次に管理として必要なのは

部門をまたいで共通で見る現実を作ることである。

たとえば、

- 重点顧客の定義を営業・CS・経営で共通化する
- 割り込み案件の承認条件を営業・開発で共通化する
- 低粗利案件の判定基準を営業・管理部門で共通化する
- 継続危険顧客のサインをCS・営業・経営で共通化する
- 入金遅延の優先順位を経理・営業・経営で共通化する

こうした共通指標がないと、連携は感覚論になる。
感覚論の連携は、危機時には持たない。

そして実行として必要なのは

部門間の境界で発生する仕事に、接続責任を置くことだ。

営業案件のどこから開発が関わるのか。
継続危険顧客は誰が起点を持つのか。
粗利が悪い案件は誰が止めるのか。
入金遅延先は誰が交渉し、誰が判断するのか。

連携が壊れるのは、いつも境界である。
だから境界に役割を置かなければ、連携は掛け声で終わる。

強い組織は、部門同士が仲良しな会社ではない。
違う情報を持ったままでも、同じ判断ができる会社である。

--

結果

連携が機能している会社では、部門間の摩擦が減る。

ただし、意見がなくなるわけではない。
むしろ、違う意見は出る。

だが、その意見がぶつかって止まるのではなく、判断材料として機能する。

営業の顧客感覚が、開発の優先順位に反映される。
CSの継続危機感が、営業の動き方を変える。
管理部門の数字が、部門横断の優先順位に反映される。
社長の判断が、各部門の持ち場の言葉に翻訳される。

すると、会社の動きが変わる。

会議で同じ衝突を繰り返さなくなる。
現場の「またあの部門が」が減る。
例外対応が減る。
重要顧客への対応が深くなる。

そして、限られた資源が本当に必要なところへ寄り始める。

逆に連携が壊れている会社では、
部門ごとの正しさがどんどん強くなる。

営業は営業の危機だけを見る。
開発は開発の限界だけを見る。
CSはCSの違和感だけを見る。
管理部門は数字だけを見る。

結果として、全員が正しいのに会社としては負ける。

危機時に差がつくのは、個々の部門の強さだけではない。
部門間で現実を接続できるかどうかである。

--

構造説明

なぜ連携はここまで重要なのか。

理由は、
危機時の経営課題が、ほとんどすべて部門横断だからだ。

売上改善は営業だけでは解けない。
継続率改善はCSだけでは解けない。
粗利改善は管理部門だけでは解けない。
資金改善は経理だけでは解けない。
開発優先順位の修正も、開発だけでは決められない。

つまり危機時の論点は、
どれも部門の境界にまたがっている。

だから部門内最適のままでは、絶対に解けない。

ここで必要なのは、仲良くすることではない。
情報の非対称を前提にして、それでも判断を揃える構造である。

前回の記事の会議ともつながる。

議題設計が悪い会議では、部門ごとの情報が並ぶだけで終わる。
何を共有し、何を決めるかが切れていないと、非対称は解消されない。

むしろ、互いの正しさを確認し合って終わる。

会社を止めるのは、対立そのものではない。
部門ごとの現実が接続されないまま意思決定を続けることである。

--

締め

部門間の壁は、仲の悪さではなく情報の非対称が作っている。

危機時の経営で必要なのは、きれいごとのチームワークではない。

営業が見ている現実。
開発が見ている現実。
CSが見ている現実。
管理部門が見ている現実。
それらをつなぎ、同じ判断に変える構造である。

連携が機能すれば、部門は違っても会社は一つになる。
連携が壊れれば、全員が正しくても会社は前に進まない。

つまり連携とは、人間関係の話ではない。
危機時の経営を成立させる接続設計である。

次の記事では、その連携不全が最もシビアな形で表面化する論点である資金を扱う。

キャッシュが尽きる前に経営者が見るべき数字は、利益ではなくタイミングだ、という話だ。

この記事が刺さったら、あとで見返せるようにスキで残しておいてください。

この連載では、危機時の経営を「CEOの右腕」の視点で、症状・判断・管理・実行に分けて言語化していきます。続きも追うなら、フォローしておいてください。

最後に残るべき言葉は、連携です。