社内のデータは、たいてい部門ごとに分かれている。営業は顧客と案件のデータを、在庫は商品と倉庫のデータを、経理は売上と入金のデータを、それぞれ別のシステムで持っている。日々の業務はそれで回るが、いざ「この顧客は全体でいくら買っているのか」「この商品は仕入れから販売まででどれだけ利益が出ているのか」を見ようとすると、データがつながっておらず突き合わせられない。

本記事は、部門ごとに分かれたデータをどう統合するかを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当である。統合というと技術的に難しく聞こえるが、発注者として「どの部門の、どのデータを、何でつなぎたいのか」を整理できれば十分である。つなぎ方の設計は、開発会社と一緒に詰めていける。

結論：共通の鍵を決め、つなぐ範囲を絞って始める

部門横断のデータ統合は、全部を一度につなごうとすると終わらない。GXOが統合の進め方で重視するのは、次の3点である。

  • 部門をまたいでデータをつなぐ「共通の鍵」（顧客IDや商品コードなど）を先に決める
  • 顧客・商品などのマスタを整理し、表記のゆれを揃える
  • 最初から全部署をつながず、見たい一つの問いに必要な範囲だけを統合する

統合の目的は、データを一か所に集めること自体ではない。部門をまたいだ問いに答えられるようにすることである。だからこそ、答えたい問いから逆算して、つなぐ範囲を絞るのが現実的である。

なぜデータはサイロ化するのか

部門ごとにデータが分断された状態を、サイロ化と呼ぶ。これは怠慢の結果ではなく、業務が部門単位で進む以上、自然に起こる。

  • システムが部門ごとに導入された：営業支援、在庫管理、会計が、それぞれ別の時期に別の都合で入った。
  • 同じ対象を別の呼び方で持っている：ある部門は「取引先」、別の部門は「顧客」として、同じ会社を違うコードで管理している。
  • 部門の外に出す前提で作られていない：自部門で使う分には十分だが、他部門と突き合わせる想定がない。

サイロ化そのものは悪ではない。問題は、横断的に見たいときにつなげないことである。全社の課題は部門をまたいで現れることが多いため、つなぐ仕組みがないと、判断に必要な全体像が見えない。データの棚卸しについては社内データ活用・データ基盤の始め方｜データの棚卸しも参照されたい。

つなぐための共通の鍵を決める

部門をまたいでデータをつなぐには、両者に共通する目印が要る。これを共通の鍵と呼ぶ。代表的なのは顧客IDや商品コードである。

つなぎたい対象共通の鍵の例よくある問題
顧客顧客ID・取引先コード部門ごとにコードが違う、同じ会社が二重登録
商品商品コード・JANコード旧コードと新コードが混在
取引・案件受注番号・案件番号部門間で番号がつながっていない
拠点・倉庫拠点コード名称表記がゆれている

鍵が部門ごとにバラバラだと、機械的に突き合わせられない。まずは「どの鍵でつなぐか」を決め、鍵が揃っていない部分をどう揃えるかを検討する。鍵を新たに作るのか、既存のどれかに寄せるのかは、発注前に方向性を決めておきたい論点である。

鍵が完全に揃っていなくても、つなぐ手立てがないわけではない。会社名と住所、商品名と型番といった複数の項目を組み合わせて、同じ対象かどうかを推定できる場合もある。ただし、推定には誤りが混じりうるため、どこまで自動で突き合わせ、どこから人が確認するかの線引きが要る。この線引きは、つなぐ対象の重要度によって変えると現実的である。誤って別の顧客と取り違えると影響が大きいデータは、人の確認を厚くしておきたい。

マスタを整理して表記のゆれを揃える

共通の鍵を決めても、肝心の顧客名や商品名の表記がゆれていると、つなぐ精度が下がる。ここで効いてくるのがマスタの整理である。マスタとは、顧客や商品といった「台帳」にあたるデータである。

  • 二重登録をまとめる：同じ会社が複数のコードで登録されていれば、一つに統合する。
  • 表記を揃える：全角と半角、株式会社の前後、部署名の有無などのゆれを統一する。
  • どこを正とするか決める：複数の部門で同じ項目を持っているとき、どの部門の値を正式版とするかを決める。

マスタの整理は地味だが、横断分析の精度を左右する土台である。ここが曖昧なまま統合を進めると、同じ顧客が別人として集計され、数字が信用されなくなる。マスタ整備は一度で終わらず、運用の中で維持していくものでもある。新しい顧客や商品が日々追加される以上、整理した状態を保つには、登録のルールを決め、ゆれが入り込まないようにする運用が要る。

なお、マスタをどこまできれいにするかは、横断して見たい問いに必要な範囲で判断したい。すべての項目を完璧に揃えようとすると終わりが見えない。最初に答えたい問いに関わる項目から優先して整えるほうが、成果までの距離が縮まる。

つなぐ範囲を絞って段階的に広げる

全部門のデータを一度に統合しようとすると、調整が膨らみ、なかなか成果が出ない。現実的なのは、答えたい問いを一つ決め、それに必要な範囲だけをつなぐことである。

進め方内容利点
問いを一つ決める「顧客ごとの全社売上を見たい」などつなぐ範囲が定まる
必要な部門だけつなぐその問いに関わる部門のデータに絞る調整が小さくて済む
成果を見て広げる次の問いに合わせて統合範囲を拡張する過剰投資を避けられる

最初の統合で成果が見えれば、次に広げる判断もしやすい。逆に、全社一斉の統合は、関係者が多く合意形成に時間がかかり、途中で止まりやすい。スモールスタートの設計は社内データ活用・データ基盤の始め方｜スモールスタートの設計で詳しく扱う。

統合したデータをどう見せるか

部門横断で統合したデータは、最終的に誰かが見て判断に使う。統合の出口として、ダッシュボードでの可視化を想定しておくと、統合の目的が具体化する。どの数字を、誰が、どの単位で見たいのかが決まれば、統合に必要な範囲も自然に定まる。可視化の進め方はBIダッシュボード導入ガイドが参考になる。

統合は手段であって目的ではない。出口の見せ方から逆算すると、「とりあえず全部つなぐ」という過剰な統合を避けられる。

導入前チェックリスト

  • 横断して答えたい問いを、具体的に一つ挙げたか
  • その問いに必要な部門・データを特定したか
  • 部門をまたいでつなぐ共通の鍵を決めたか
  • 顧客・商品などのマスタに二重登録や表記ゆれがないか確認したか
  • 同じ項目を複数部門が持つとき、どこを正とするか決めたか
  • 最初につなぐ範囲を、問いに必要な分に絞ったか
  • 統合したデータをどう見せるか（出口）を想定したか

開発会社に確認する質問

質問確認したいこと
部門ごとに違うコードをどう突き合わせますか共通の鍵の扱い
二重登録や表記ゆれはどう整理しますかマスタ整備の進め方
最初は一部の部門から始められますか段階的な統合
同じ項目が複数部門にあるとき、どう一本化しますか正とする値の決め方
統合したデータをダッシュボードで見られますか出口の可視化
後から部門を追加するとき、作り直しになりませんか拡張のしやすさ

「全システムを一気に統合します」という提案には、調整負荷と期間の見積もりを確認したい。範囲を絞って始められるかが、成果までの距離を左右する。

相談前に整理しておくとよい情報

  • 横断して見たいこと（顧客ごとの全社売上、商品ごとの利益など）
  • 関係する部門と、それぞれが使っているシステム
  • 顧客や商品を、各部門が何のコードで管理しているか
  • 同じ顧客・商品が二重登録されていそうな心当たり
  • マスタの整備を担当できる人がいるか

これらが整理されていなくても相談は可能である。横断して見たいことと、関係する部門が見えていれば、つなぎ方を一緒に設計できる。

関連記事

よくある質問

Q1. 部門ごとにシステムが違っても統合できますか

できる。むしろ別々のシステムをつなぐことが統合の主な目的である。重要なのはシステムを揃えることではなく、部門をまたいでデータをつなぐ共通の鍵を決めることである。

Q2. マスタの整理は誰がやるべきですか

最終的な「どれを正とするか」の判断は、業務を分かっている社内の担当が行うのが望ましい。表記ゆれの統合作業は開発側で支援できるが、業務上の正解は社内にしか分からないためである。

Q3. 全部門をつながないと意味がないのではないですか

そうではない。答えたい問いに必要な部門だけつなげば、その問いには答えられる。全部門を一度につなぐより、一つの問いで成果を出してから広げるほうが、確実に前へ進む。

部門ごとに分かれたデータを、横断して見られるようにしませんか

GXOでは、営業・在庫・経理など部門ごとに分かれたデータを統合する前に、共通の鍵やマスタの整理、つなぐ範囲の絞り込みを一緒に整理します。答えたい問いから逆算し、スモールスタートでの統合をご支援します。

データ統合について相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。