業務システムの導入プロジェクトが始まると、半年もしないうちに部署間で「うちの業務が無視されている」「あちらの都合で押し切られた」と対立が起きる——中小企業の現場で繰り返されてきた構図です。技術選定が原因ではなく、全社最適と部署最適のものさしがズレたまま走ったことが本当の理由になっています。本記事では、なぜ部署間対立が起きるのか、どう調整すれば未然に防げるのかを、経営者目線で整理します。
この記事の結論（3行）
- 対立の本質は「全社最適」と「部署最適」の判断軸のズレで、技術選定の問題ではない
- 営業・経理・現場で「優先する数字」が違うため、要件定義の段階で衝突する構造になっている
- 経営者が「全社で守る数字3つ」を先に決め、部署要望はその下に位置付ければ対立は減る
なぜ業務システム導入で部署間が対立するのか
部署間対立は「人間関係」の問題に見えますが、構造を分解すると、各部署が背負っている数字や責任範囲が違うために起きる必然です。営業は受注スピード、経理は数字の正確性、現場は作業手数の少なさを優先します。同じ業務システムでも、どの数字を最優先するかで設計が変わってしまうため、要件定義の段階から議論がぶつかります。
- 営業は「受注を逃さないこと」、経理は「数字を正しく締めること」、現場は「作業を減らすこと」
- 部署ごとに評価制度・KPIが違うため、システム要件も自然と部署側に寄る
- 経営者が「全社で守る数字」を提示しないと、各部署の言い分が並列になり結論が出ない
技術選定が問題ではなく、判断の上位基準が共有されていないことが対立の出発点です。
営業・経理・現場で「優先する数字」が違う
営業部門は1件でも多く受注を取りたいので、入力項目を最小化し、見積もりから受注までの所要時間を短縮することを最優先にします。経理部門は月次の数字を正確に締めたいので、入力項目を増やしてでもデータの取りこぼしを防ぎたい。現場は作業時間を1秒でも減らしたいので、確認画面や承認フローを嫌います。3部署が同じ画面を見ても、評価する基準が全く違う構造になっています。さらにこの違いは「言葉」にも表れます。営業の言う「効率化」は受注時間の短縮、経理の言う「効率化」は仕訳作業の削減、現場の言う「効率化」は入力負荷の軽減を指していて、同じ単語を使いながら別のことを話しているケースが珍しくありません。
部署ごとのKPIが要件定義に直接持ち込まれる
各部署は自部署のKPIで評価されるため、システム要件にもKPIを反映させたくなります。営業が「受注率」、経理が「決算精度」、現場が「生産性」を要件に持ち込むと、優先順位を付ける役がいないかぎり全要件が「必須」になります。要件数が膨らみ、ベンダー見積もりが2倍、3倍に膨らみ、最後は予算オーバーで部署間の押し付け合いに発展します。中小企業の現場では、部署ごとのKPI設計と業務システム要件の関係が整理されていないことが多く、要件定義の議論が「自部署の評価をどう守るか」というゲームに変質してしまいます。
経営者の判断軸が事前に示されていない
中小企業のシステム導入で起きる対立の多くは、経営者が「全社で守る数字」を最初に提示していないことに起因します。「業務効率化」「DX推進」のような抽象的な目標だけが共有された状態だと、部署はそれぞれ自分たちの解釈で要件を作ります。経営者が「人件費を年300万円減らす」「月次決算を3日短縮する」のような具体的な数字を出していれば、部署はその数字に紐付く要件だけを並べるようになります。
部署間対立が起きやすい3つの典型シーン
業務システム導入で部署間対立が顕在化しやすいシーンを、3つの典型パターンで整理します。
| シーン | 対立の構図 | よく起きる結末 | |---|---|---| | 要件定義の打合せ | 営業 vs 経理 vs 現場で「最低限」が違う | 全要件「必須」になり予算超過 | | ベンダー選定 | 既存業者推し vs 新規業者推し | 派閥対立で意思決定が遅れる | | リリース直前 | 「うちの業務が反映されていない」と現場反発 | 稼働延期・追加開発で1.5倍コスト |
どのシーンも「合意形成のルールが事前に決まっていない」ことが共通項です。経営者がルール側を整えれば、対立そのものを減らせます。
シーン1: 要件定義の打合せで「最低限」が違う
要件定義の段階で、各部署が考える「最低限の機能」は全く違います。営業は「見積もりが3クリックで出せること」、経理は「仕訳データが自動でエクスポートされること」、現場は「在庫数が常にリアルタイムで見えること」を最低限と呼びます。優先順位の付け方を事前に決めていないと、全項目が「必須」扱いとなり、要件数が30〜50項目に膨らみます。結果としてベンダー見積もりが想定の2倍を超え、プロジェクトが頓挫します。
シーン2: ベンダー選定で「既存 vs 新規」の派閥が生まれる
ベンダー選定の場面では、既存のシステム業者を継続する派と、新しい業者を入れたい派で対立が起きます。情シスは保守の連続性を重視して既存業者を推し、現場部門は「現状を変えてほしい」気持ちから新規業者を推します。経営者が選定基準を先に明示していないと、議論が「派閥対立」に変質し、合意形成に半年以上かかるケースもあります。
シーン3: リリース直前に「うちの業務が反映されていない」と反発
リリース直前の受け入れテスト段階で、要件定義に参加していなかった部署から「うちの業務が考慮されていない」と反発が起きるパターンです。多くの場合、要件定義時に発言力の弱かった部署が後から声を上げる構図で、稼働時期の延期と追加開発で初期予算の1.5倍に膨らみます。発注前に「全部署のキーパーソンが要件定義に参加する」ルールを敷くだけで防げます。発言力の弱い部署とは、人数が少ない、社内序列が下、IT知識が薄いなどの理由で要件定義の場で意見が通りにくい部署を指します。物流・品質管理・倉庫といったバックヤード部署がここに該当しやすく、稼働後に「これでは現場が回らない」と表面化します。
部署間対立を未然に防ぐ調整ステップ
対立は完全には消えませんが、未然に減らすステップは存在します。経営者が主導して以下の4段階で進めれば、各部署の要望が「全社最適」の枠内に収まりやすくなります。
ステップ1: 経営者が「全社で守る数字3つ」を先に決める
業務システム導入の目的を、抽象的な言葉ではなく具体的な数字3つで表現してください。例えば「人件費を年300万円削減」「月次決算を3日短縮」「受注リードタイムを2日短縮」のような形です。この3つが上位にあると、部署からの要望は「この数字に紐付くか否か」で篩い分けられます。
ステップ2: 各部署のキーパーソンを要件定義から参加させる
リリース直前の反発を防ぐには、要件定義の最初の打合せから全部署のキーパーソンを参加させることです。「あとから声を上げる」余地をなくすため、要件定義の議事録は全部署の合意印を取って締めることをお勧めします。後から異論が出ても「合意済み」を根拠に交渉できます。
ステップ3: 優先順位を「必須・推奨・将来」の3段階で付ける
各部署から出た要望を、必須・推奨・将来の3段階に分けてください。必須は経営者が決めた数字3つに直結するもの、推奨は3年以内に効果が出るもの、将来はそれ以降に検討するものです。この3段階を全部署で合意してから発注すれば、見積もりが想定内に収まりやすくなります。
ステップ4: 全要件に「捨てる基準」を設ける
要件は積み上げるだけでなく「捨てる基準」を持つことが大事です。例えば「全社の数字3つに紐付かない要望は将来送り」「年に3回以下しか使わない機能は対象外」「他システムで代替できる機能は対象外」のような基準を発注前に共有しておくと、要件削減の議論が「誰の都合か」ではなく「基準に合うか」に置き換わります。これだけで部署間の感情的対立を大きく減らせます。
ステップ5: 部署横断の「調整役」を1人立てる
要件定義から運用開始まで、部署横断で調整できる担当者を1人置いてください。情シス出身者でも、業務改善担当者でも構いません。各部署の要望を集約し、優先順位を提示し、ベンダーと部署の間に入る役回りです。この担当者がいるかどうかで、プロジェクト成功率が大きく変わります。社内で適任者が見当たらない場合は、外部の調整役を期間限定で入れる手もあります。発注前に業務改善・システム見積もりAI適正診断で必要な調整体制を整理しておくと、後の手戻りが減ります。
経営者目線で考える「部署間対立を起こさないシステム導入」
ここからは経営の話です。部署間対立は、技術や運用の問題ではなく「合意形成の設計」の問題です。経営者が判断軸を提示し、調整役を置き、要件の優先順位を付ければ、対立は8割減らせます。逆にこの3つを欠いたまま走ると、どんなに優秀なベンダーを選んでも稼働後に部署同士の押し付け合いが続きます。
経営者が踏み込むべき判断は3つです。第一に、業務システムで「全社として守る数字」を3つに絞り、抽象的なDX目標ではなく具体的な数値で示すこと。第二に、各部署のキーパーソンを要件定義の最初から最後まで参加させ、合意印を取ること。第三に、部署横断の調整役を1人立てて権限を与えること。この3つを発注前に決めておけば、ベンダー選定や技術論で揉めても、最後には判断軸に立ち戻って結論を出せます。
部署間対立が起きるのは「部署が悪い」のではなく、合意形成の枠組みが整っていないからです。経営者が枠組み側を作れば、各部署は自分たちの専門知識を建設的に出してくれるようになります。逆に枠組みがないまま「各部署で話し合って決めて」と丸投げすると、声の大きい部署の要望が通り、声の小さい部署が稼働後に反発する構造ができあがります。中小企業ほど経営者の関与が結果を決める領域です。週1時間の判断会議を設けるだけで、対立の温度感は大きく下がります。
ぷらすわんの実例：ある製造業A社の場合
ぷらすわんが診断で関わった、ある製造業A社（従業員80名）の例をお伝えします。受発注・在庫・生産管理を統合する業務システムを2,000万円の予算で導入する計画でしたが、要件定義3か月目で営業と現場が対立し、プロジェクトが止まりかけていました。
原因を整理すると、営業は「受注スピード優先」で入力項目を減らしたい、現場は「在庫数の正確性」で入力項目を増やしたいという、根本的に方向の違う要望がぶつかっていました。経営者は「DX推進」という抽象的な目的しか示しておらず、各部署の要望は同列に並んだままでした。
ぷらすわんが提案したのは、経営者に「人件費を年400万円削減」「在庫差異を月10件以下」「受注から出荷まで1日短縮」の3つの数字を決めてもらうことでした。この3つに照らして要望を篩い分けたところ、当初50項目あった要件が必須20項目・推奨15項目・将来15項目に整理され、ベンダー見積もりも2,000万円の予算内に収まりました。営業の入力項目最小化と現場の在庫精度の両立は、双方の要望をそのまま並べると不可能ですが、「人件費削減」と「在庫差異10件以下」という上位の数字に照らすと、入力項目はバーコード読み取りで自動化する、確認画面は1段階に抑えるなど、解の方向性が見えてきました。経営者が判断軸を先に提示することで、対立は構造的に減らせます。判断軸の整理を診断することで、自社の状況に合った数字を具体化できます。
まとめ
業務システム導入で部署間が対立する本当の理由は、全社最適と部署最適の判断軸がズレたまま要件定義が走ることにあります。営業・経理・現場で「優先する数字」が違う構造を放置すると、要件数が膨らみ、予算超過と稼働延期につながります。
対立を未然に防ぐには、経営者が「全社で守る数字3つ」を先に決め、全部署のキーパーソンを要件定義に参加させ、優先順位を3段階で付け、部署横断の調整役を1人立てることです。技術論で対立しているように見えても、本質は合意形成の設計不足です。導入前に判断軸を項目別に整理してから動き出す流れをお勧めします。