部署をまたいだExcel台帳の重複、統合前にやるべき突き合わせ作業

社員が100人を超えるあたりから、多くの会社で「気づいたら似たような台帳が複数の部署に存在していた」という状態が発生します。営業部の顧客リスト、カスタマーサポートの問い合わせ管理、経理の取引先台帳、人事の異動管理表。それぞれの部署が、それぞれの必要に迫られて独自に育ててきたExcelファイルです。10〜30人規模であれば「部署は3つ、担当者も数人」という規模感で突合作業を進められますが、100〜300人規模になると事情が変わります。部署の数そのものが増え、拠点も複数になり、台帳を作った本人がすでに異動・退職しているケースも珍しくありません。突合の対象となるレコード数も、10-30人規模の数百件レベルから、数千〜数万件レベルに膨らんでいることが多くあります。このガイドでは、この規模で台帳統合に着手する際、システム選定より前に済ませておくべき突き合わせ作業の進め方を解説します。

この記事で分かること

100〜300人規模の会社が、複数部署に分散した類似台帳を統合する前に行うべき突き合わせ作業の手順を扱います。具体的には、対象台帳の棚卸し、突合基準の設計、部署をまたいだ合意形成の進め方、データクレンジングの分業体制という4つの観点で解説します。統合先システムの選定そのものは扱いません。移行先の選び方はチーム体制での移行先選定・承認フローに譲ります。

なぜ100-300人規模の突合は「桁違いに」難しいのか

10〜30人規模の会社で部署間の顧客管理Excelを統合する場合、関係する部署はせいぜい2〜3つ、レコード数も数百件程度に収まることが多く、担当者同士が顔の見える距離で「このお客さん、どっちが正しい情報ですか」と直接確認し合える規模感です。

100〜300人規模になると、この前提が崩れます。関係する部署は5つ、6つに増え、拠点も本社・支社・工場のように複数に分かれ、台帳を作成した本人がすでに退職している、あるいは異動して別の業務についているというケースが頻繁に発生します。突合作業の当事者が「この行の情報はなぜこうなっているのか」を本人に直接聞けない状態から始めることが、この規模の突合作業を難しくしている最大の要因です。

さらに、部署の数が増えるほど、同じ対象物（顧客・取引先・システムなど）に対する部署ごとの「見え方の違い」も増幅します。営業部にとっての取引先と、経理部にとっての取引先と、法務部にとっての契約先が、微妙に異なる粒度・異なる範囲でそれぞれの台帳に記録されている状態は、部署数が増えるほど整理の難易度が跳ね上がります。

• 部署数の増加に比例して、突合すべき台帳の組み合わせ数が増える（3部署なら3組の突合で済むが、6部署では最大15組の突合が発生しうる）
• 拠点をまたぐ場合、同じ部署名でも拠点ごとに運用ルールが異なっていることがある
• 台帳作成者の退職・異動により、「なぜこの記載になっているか」の背景情報が失われている行が一定数存在する

統合対象の台帳をまず全て洗い出す

突合作業に着手する前に、対象となる台帳をすべて洗い出すところから始めます。この段階を省略して「知っている台帳から手をつける」と進めてしまうと、後になって「実は別の部署にも似た台帳があった」という事態が発覚し、突合作業をやり直すことになりかねません。

洗い出しの際は、次の観点で対象を特定していきます。

1. 関係しそうな部署へのヒアリング: 情シス側で把握している台帳だけでなく、各部署に「顧客・取引先・案件などの一覧を独自にExcelで管理していないか」を直接確認する
2. 既存のシステム管理台帳との突合: すでに台帳運用を仕組み化している場合、そこに記載のあるシステム・ファイルの中から、統合対象になりそうなものを抽出する
3. 拠点ごとの確認: 本社で把握しているつもりでも、支社や工場が独自の台帳を運用しているケースは非常に多い。拠点責任者への確認を必須とする

この洗い出しシートは、後の突合作業全体の設計図になります。すべての台帳を一覧化した時点で、「思っていたより関係する台帳が多かった」と気づくことも珍しくありません。この気づきを統合プロジェクトの早い段階で得られるかどうかが、後工程の見積もり精度を大きく左右します。

突合基準を「誰が決めるか」を先に決める

台帳の突合で最も時間がかかるのは、実は機械的なデータ比較の作業ではなく、「何をもって同一のレコードとみなすか」という基準を決める合意形成のプロセスです。100〜300人規模になると、この基準決めに関わる利害関係者の数も増えるため、あらかじめ「誰が最終的にこの基準を決めるのか」を明確にしておく必要があります。

• 表記ゆれ（全角/半角、法人格の位置など）をどこまで自動的に同一とみなすか
• 住所・電話番号など一部の項目だけが一致する場合に、同一レコードと判断してよいか
• 複数の部署で異なる情報が記録されている場合、どちらを正とするか（あるいは両方を残すか）

これらの基準を、突合作業を実際に手を動かすメンバーだけの判断で決めてしまうと、後になって「うちの部署のデータの扱いに納得できない」という異議が出て、作業のやり直しにつながります。基準決定には、各部署の代表者を交えたレビューの機会を設けることをお勧めします。ただし、全部署の全員を巻き込むと合意形成そのものが停滞するため、各部署から1名程度の代表者を選び、その代表者が持ち帰って部署内の合意を取るという二段構えにすると現実的です。この意思決定の体制設計については、チーム体制での移行先選定・承認フローでさらに詳しく扱っています。

「最初は情シス側だけで突合ルールを決めて進めていましたが、経理部から『取引先コードの持ち方が営業部の基準では困る』という指摘が後から入り、やり直しになりました。各部署の代表者に基準案をレビューしてもらう工程を先に入れておけば防げたはずです」

重複判定の実務: 完全一致・部分一致・要目視確認の3段階

実際のデータ突合作業では、すべてのレコードを一律の基準で機械的に処理しようとすると、精度が落ちるか、逆に時間がかかりすぎるかのどちらかに陥りがちです。実務的には、判定の確実性に応じて3段階に分けて処理することをお勧めします。

100〜300人規模で扱うレコード数を考えると、すべてを目視確認するのは現実的ではありません。完全一致の範囲をできるだけ広げつつ、部分一致・判定不能に分類されたレコードだけを人手で確認する、という段階的な絞り込みが、限られた工数の中で精度を確保する現実的なアプローチです。

判定不能に分類されたレコードについては、データクレンジングの作業として、該当部署の担当者に個別に確認を依頼することになります。この確認依頼の数が想定以上に多くなることは珍しくないため、後述する依頼の出し方・優先順位のつけ方もあわせて検討しておく必要があります。複数部署から同時に確認依頼への対応が求められる状況の捌き方は、複数部署の脱Excel要望を同時に抱えたときの優先順位付けで扱っています。

突合作業の分業体制: 誰が何を担当するか

100〜300人規模の突合作業は、情シス担当者だけで完結させることはほぼ不可能です。データ量・部署数の多さから、各部署の協力が不可欠になります。分業体制を設計する際の基本的な役割分担は次のとおりです。

1. 突合ルールの設計・統括: 情シス担当者が中心となり、突合基準の原案作成、進捗管理、最終的な統合作業を担う
2. 部署内データの一次チェック: 各部署の担当者が、自部署の台帳に含まれるレコードについて、判定不能となった項目の確認・補足を行う
3. 代表者による基準レビュー: 各部署の代表者が、突合ルールの妥当性について部署を代表してレビューする
4. 最終承認: 情シス部門の責任者、あるいはそれに準ずる立場の人物が、統合後のデータを本番運用に移す前の最終確認を行う

この分業体制を機能させるには、各部署の担当者に「なぜこの作業に協力する必要があるのか」を丁寧に説明することが欠かせません。部署側からすると、突合作業は自分たちの本来業務ではなく、協力を依頼される立場です。統合後にどのようなメリットがあるか（二重入力の解消、情報の一元化による検索性向上など）を具体的に伝えることで、協力を得やすくなります。

突合結果の保存とレビュー記録を残す

突合作業を進める過程で下した判断は、その場限りのものにせず、記録として残しておくことを強くお勧めします。理由は、後になって「なぜこのレコードはこう統合されたのか」という疑問が出た際に、判断の根拠を追跡できるようにするためです。

• どのレコードとどのレコードを同一と判断したか（突合の対応表）
• 判定不能として個別確認に回したレコードと、その確認結果
• 部署間で意見が分かれた際、最終的にどちらの情報を採用したか、その理由

これらの記録は、統合作業が完了した後のシステム台帳の一部として位置づけると、単発の作業記録で終わらせず、継続的な資産として活用できます。台帳を「作って終わり」にせず運用に乗せる考え方については、100人を超えたら属人化台帳をどう運用に乗せるかで詳しく解説していますので、突合結果の記録もこの運用サイクルに組み込むことをお勧めします。

統合後にすぐ元のExcelに戻らないための布石

突合・統合作業がどれだけ丁寧に行われても、統合後に部署ごとのローカルExcelが復活してしまっては意味がありません。この「シャドー台帳の再発」は、100〜300人規模で特によく見られる現象です。突合作業の段階から、統合後の運用ルールをあらかじめ設計しておくことが、この再発を防ぐ最も効果的な手立てになります。

具体的には、統合後に各部署が「自分たちの使い勝手のためにローカルでExcelを作り直す」動機を減らすため、統合先のシステムで各部署固有のニーズ（独自の集計軸や表示形式など）にどこまで対応できるかを、突合作業と並行して確認しておくことが有効です。この再発防止の運用ルールについては、部署ごとのローカルExcelが復活する問題で具体的に扱っています。

突合作業のスケジュール感

100〜300人規模で複数部署にまたがる台帳統合の場合、突合作業だけで数週間から数ヶ月を要することが一般的です。関係部署の数、レコード数、判定不能レコードの割合によって大きく変動するため、一律の目安を示すことは難しいですが、次のような段階を踏んで進めるとスケジュールを立てやすくなります。

• 第1段階（台帳の洗い出しと突合ルール設計）: 関係部署へのヒアリングと基準案の作成
• 第2段階（機械的な突合）: 完全一致・部分一致・判定不能への自動分類
• 第3段階（人手による確認）: 部分一致・判定不能レコードの個別確認
• 第4段階（最終レビューと統合）: 代表者・責任者によるレビューを経て本番データとして確定

各段階の間に、部署代表者によるレビューのタイミングを挟むことで、後戻りのリスクを減らせます。急いで一気に進めようとすると、後の段階で「やっぱりこの基準はおかしい」という指摘が出て手戻りが発生しやすくなるため、段階ごとに小さく合意を積み重ねる進め方をお勧めします。

ツール選びより先に「突合の型」を決めておく理由

台帳の突合作業というと、つい表計算ソフトの重複削除機能やRDBのSQLクエリといった「ツール」の話に意識が向きがちです。しかし100〜300人規模の突合作業で本当に重要なのは、ツールの選定よりも先に「突合の型」、つまりどのような手順とチェックポイントで進めるかという型を固めておくことです。

型を決めずにいきなり作業へ着手すると、担当者ごとにやり方がバラバラになり、Aさんが担当した部分とBさんが担当した部分で、重複判定の粒度が異なってしまうという事態が起きます。100〜300人規模では、突合作業自体を複数人で分担することが多いため、この「型のばらつき」は結果の品質に直結する問題になります。

• 突合作業に着手する前に、簡単な手順書（どの項目をどの順番で確認するか）を1ページ程度でよいので作成する
• 最初の数十件は、複数の担当者が同じデータを突合してみて、判定結果が一致するか摺り合わせる「キャリブレーション」を行う
• キャリブレーションで意見が割れた判定基準は、その場で解消せず、部署代表者を交えたレビューに持ち込む

このキャリブレーションの工程は一見遠回りに見えますが、100〜300人規模の大量データを扱う際には、後から判定基準のばらつきに気づいて全件をやり直すよりも、はるかに少ないコストで済みます。

拠点をまたぐ突合で追加的に確認すべきこと

複数拠点を持つ会社の場合、部署間の突合に加えて、拠点間の突合という追加の論点が発生します。同じ部署名であっても、拠点ごとに運用の細かいルールが異なっていることは珍しくなく、この違いを見落とすと、統合後に「本社のルールでは正しいが、支社の実態には合わない」という不満が出やすくなります。

1. 拠点ごとの運用ルールの違いを事前に洗い出す: 同じ「顧客管理」でも、拠点によって必須入力項目が異なる、独自の分類コードを使っているといった違いがないか確認する
2. 拠点責任者を突合プロセスに巻き込む: 本社主導で突合を進めると、拠点側が「勝手に決められた」と感じやすくなる。拠点ごとに最低1名は突合作業のレビューに関わってもらう
3. 拠点間の時差・稼働日の違いを考慮したスケジュールを組む: 支社や海外拠点がある場合、確認依頼への回答に想定より時間がかかることを見込んでおく

複数拠点の台帳統合に固有の課題は、部署間の突合以上に複雑になりがちです。拠点ごとにシステムが散らばっている状態そのものの整理手順は、拠点数が多い会社では特に重要な検討事項になります。

突合作業でありがちな見落としポイント

実際の突合作業では、事前に想定していなかった細かい見落としが後から見つかることがよくあります。あらかじめ次のようなポイントに注意しておくと、手戻りを減らせます。

これらは突合作業の初期段階では見えにくく、実際に手を動かしている途中で気づくことが多いポイントです。気づいた時点で記録に残し、他の担当者にも共有することで、同じ見落としが別の部署の突合作業でも繰り返されることを防げます。

突合作業の工数をどう見積もるか

100〜300人規模で突合作業に着手する前、多くの担当者が悩むのが「どれくらいの工数がかかるのか」という見積もりです。正確な見積もりは実際に着手してみないと分からない部分もありますが、あらかじめおおよその見当をつけておくことは、チームの体制やスケジュールを組む上で欠かせません。

工数の見積もりでは、次のような要素を掛け合わせて概算を立てます。

1. 対象となる台帳の総レコード数: 部署ごとの台帳を合算したおおよそのレコード数を把握する
2. 完全一致で自動処理できる割合の見込み: 過去の類似プロジェクトの経験があれば参考にする。初めての場合は、サンプルデータで試験的に突合を行い、割合の目安をつける
3. 目視確認・個別確認が必要なレコードの割合: この割合が高いほど、工数は大きく膨らむ

例えば、全体で1万件のレコードのうち7割が完全一致で自動処理でき、残り3割の3,000件が目視確認・個別確認を要するとすれば、その3,000件をどの程度のペースで処理できるかによって、必要な期間が見えてきます。1人が1日に処理できる件数の目安を立て、そこから逆算してスケジュールと必要な人員を検討します。

この見積もりは、確認依頼を送る相手部署の対応スピードにも左右されるため、情シス側の作業時間だけでなく、部署側の回答待ち時間も加味してスケジュールに余裕を持たせておくことをお勧めします。

突合プロジェクトの進捗をどう共有するか

複数部署が関わる突合プロジェクトでは、進捗状況を関係者全員が把握できる状態にしておくことも重要です。情シス側だけで進捗を抱え込んでしまうと、要望元の部署は「今どうなっているのか分からない」という不安を抱えたまま待ち続けることになります。

• 週次または隔週で、簡潔な進捗共有（完了した突合の件数、残っている確認依頼の件数など）を関係部署に送る
• 大きな課題やスケジュールの変更が生じた場合は、都度、早めに共有する
• 進捗共有の内容は、後から振り返れるよう記録として残しておく

このような定期的な進捗共有は、プロジェクトの透明性を高めるだけでなく、関係部署からの協力を得やすくする効果もあります。自分たちの依頼がどう扱われているかが見えることで、部署側も確認依頼への回答を後回しにしにくくなる、という副次的な効果も期待できます。

突合作業をやり切った後にやるべき最終確認

突合・統合の作業自体が終わったとしても、それで台帳統合プロジェクトが完了したとみなすのは早計です。本番運用へ移行する前に、次のような最終確認を行うことをお勧めします。

• 統合後のレコード総数が、想定と大きく乖離していないか: 統合前の各部署の台帳のレコード数の合計と、統合後の重複排除済みレコード数を比較し、極端に減りすぎていたり、逆にほとんど減っていなかったりしないかを確認する
• 重要な項目に欠損が生じていないか: 突合の過程で、複数の台帳のうちどちらか一方にしかなかった項目が、統合後に失われていないか確認する
• 関係部署による最終レビューを経ているか: 情シス側だけで完結させず、各部署の代表者に統合後のデータを実際に見てもらい、違和感がないか確認してもらう

この最終確認の段階で問題が見つかった場合、本番運用への切り替え前に修正できるかどうかが、その後の混乱の大きさを左右します。切り替え後に問題が発覚すると、現場の業務に直接影響が及ぶため、切り替え前の最終確認には十分な時間を確保しておくことが望ましいといえます。

突合作業で使えるツールの選択肢

突合作業を効率化するツールについても触れておきます。100〜300人規模のレコード数になると、手作業での目視比較には限界があるため、いくつかの手段を組み合わせて機械的な処理範囲を広げることが現実的です。

• Excel・スプレッドシートの関数機能: VLOOKUP・XLOOKUPやCOUNTIF系の関数を使い、完全一致・部分一致の候補を洗い出す。追加のツール導入が不要で、既存のスキルセットで対応できる利点がある
• Power Automateなどの自動化ツール: 定型的な突合ルールをフロー化できれば、繰り返し作業の手間を減らせる。ただし複雑な条件分岐には向かない場合もある
• 専用のデータクレンジングツール: 表記ゆれの自動検出や、あいまい検索によるマッチングに特化したツールも存在する。レコード数が非常に多い場合や、表記ゆれのパターンが多岐にわたる場合は検討に値する

どのツールを選ぶ場合でも、機械的な処理はあくまで「候補の絞り込み」までにとどめ、最終的な同一性の判断は人手で確認する工程を残しておくことをお勧めします。ツールの判定精度を過信すると、誤った統合によって本来別々に扱うべきレコードが一つにまとめられてしまうリスクが残ります。

突合完了後、情シスチームに残る役割

台帳統合が完了し、突合作業そのものが終わった後も、情シスチームには継続的な役割が残ります。統合作業を「プロジェクトの終了」で区切ってしまうと、せっかく整えたデータが再び分散していく事態を招きかねません。

• 統合後のデータ品質を維持する仕組みを運用に乗せる: 新規レコードの登録時に、突合で使った重複判定の基準をそのまま入力ルールとして定着させる
• 統合作業で得た知見をドキュメント化し、次の統合プロジェクトに活かす: 100〜300人規模から300人以上の規模へとさらに拡大していく過程で、同様の統合作業が再び必要になる可能性は十分にある
• 統合されたデータが、当初の目的どおりに活用されているか確認する: 統合の目的が「二重入力の解消」であれば、実際に二重入力が解消されたかを確認する。「検索性の向上」であれば、実際に検索・参照の頻度が上がったかを確認する

突合・統合という作業は、それ自体が目的ではなく、その先にある「正確で使いやすいデータに基づいて業務が回る状態」を作るための手段です。この目的を見失わないよう、統合後も継続的に効果を確認していく姿勢が、情シスチームに求められます。

まとめ: 統合の成否は「突合」で決まる

システムを選ぶこと自体は、実はそれほど難しい作業ではありません。100〜300人規模の台帳統合プロジェクトの成否を分けるのは、その前段階である突合作業をどれだけ丁寧に、かつ関係部署を巻き込みながら進められるかにかかっています。台帳の洗い出し、突合基準の合意形成、段階的な重複判定、分業体制の設計。これらを飛ばして統合作業を急ぐと、統合後にかえって混乱が増えるという本末転倒な結果を招きます。

急がば回れという言葉がそのまま当てはまる作業です。まずは対象となる台帳を漏れなく洗い出すところから、時間をかけて着実に進めてください。