導入
顧客管理表や案件管理台帳、契約管理表を運用していると、同じ顧客や案件が複数行に分かれて登録されていることがあります。「A商事」「A商事(株)」「株式会社A商事」が別行として入っていて、連絡履歴がどれに紐づいているか分からなくなる。これは入力時の確認不足ではなく、何をもって同一データとみなすか（重複キー）が管理表に組み込まれていないことが原因です。
本記事では、顧客・案件・契約管理を3〜50人で運用している現場を対象に、重複キーを決めて二重登録を防げる状態にするための準備が、自分の管理表にどこまで必要かを20分で診断する手順を紹介します。
この記事で解決すること
| 項目 | 内容 |
|---|---|
| 解決する課題 | 同じ顧客や案件が複数行に分かれて登録される |
| 主な原因 | 同一データを識別する重複キーが決まっていない |
| 診断方法 | 重複キー候補の有無、候補列の一意性、新規登録時のチェック、過去データの統合方針の4観点で確認する |
| 対象業務 | 顧客管理・案件管理・契約管理 |
| 対象人数 | 3〜50人 |
| 難易度 | ★★☆☆☆ |
| 診断時間 | 20分 |
| 診断でわかること | 重複キーの整備対象と、二重登録防止の打ち手の優先順位 |
| 向かないケース | 重複の存在自体が情報になる一時的な記録メモ |
重複行を一気に統合する内容ではなく、どこから整備に着手すべきかを切り分けるための診断手順です。
なぜその管理表はうまくいかないのか
重複データが混ざる管理表には、共通する状態があります。
- 顧客や案件を一意に識別する列（顧客ID・案件番号）が決まっていない
- 会社名や担当者名で識別しようとして、表記揺れ（株式会社／(株)／㈱）で別データ扱いになる
- 新規登録時に既存データを検索するルールがなく、毎回新規行を作ってしまう
- 同じ案件が異なる担当者によって別行で登録され、片方は更新されない
- 過去データの統合が後回しになり、複数行が並んだまま運用されている
- 「重複かどうか」を判定する列や条件付き書式が、表側に組み込まれていない
担当者を責めても重複は減りません。同一データの識別ルールが管理表に組み込まれていないことが原因なので、見直しは「いま、何を重複キーの候補にできるか」を切り分けるところから始めます。
診断手順
20分ほどで、4つの観点を順に確認していきます。各ステップで、チェック項目のうち1つでも該当があれば、そのステップを ✗1個 として数えます。
ステップ1. 重複キーの候補列を書き出せるか確認する
「顧客ID」「案件番号」「メールアドレス」「電話番号」「契約番号」のように、一意性を持たせやすい列を候補として書き出します。
チェック項目: – [ ] 一意性を期待できる列を3つ以上書き出せない – [ ] 候補にできそうな列が「会社名」「氏名」だけしかない – [ ] 顧客IDや案件番号の列はあるが、空欄行が多い、または採番ルールが決まっていない
判定の目安: チェックが付いた管理表は、重複キーの候補列そのものを整備する必要がある。ID列を新設するか、既存列の入力ルールを決めるかの判断から始める。
ステップ2. 候補列の一意性を測定できるか確認する
書き出した候補列について、実際に重複がどの程度あるかを =COUNTIF(列,セル) で計測できる状態かを確認します。
チェック項目: – [ ] 候補列にCOUNTIFを当てても、重複件数を測れない（空欄が多すぎる／表記揺れで実態が見えない） – [ ] 同じ顧客の電話番号やメールアドレスが、半角/全角や大小文字のばらつきで別値扱いになっている – [ ] 電話番号・メールアドレスのように、業務上変わりやすい列しか候補がない
判定の目安: チェックが付いた候補列は、表記正規化（LOWER・TRIM・ASC）と組み合わせないとキーとして使えない。固定的なID列の新設も検討対象。
ステップ3. 新規登録時の重複チェックが表側にあるか確認する
新規行が追加されたときに、重複が登録段階で見えるかを確認します。
チェック項目:
– [ ] 重複検知の列（=IF(COUNTIF(...)>1,"重複","")）や条件付き書式が、候補列に入っていない
– [ ] 新規登録時に既存データを検索する手順が、文書化されていない
– [ ] 重複が見つかったときに、どちらの行を残すか（採用ルール）が決まっていない
判定の目安: チェックが付いた管理表は、登録時に重複が見える仕組みを表側に組み込む必要がある。表側で気付けないと、後からの統合作業が雪だるま式に増える。
ステップ4. 過去データの統合方針を決められるか確認する
すでに発生している重複行の扱いを切り分けます。
チェック項目: – [ ] 重複行をどう統合するか（最新行に寄せる／古い行をarchive扱いにする）が決まっていない – [ ] 統合作業の担当者と、業務関係者の合意ルートが決まっていない – [ ] 統合した結果、別表（連絡履歴・案件履歴）から見たときに整合性が保たれるかが確認できていない – [ ] 統合作業のバックアップと、影響範囲のテスト方法が決まっていない
判定の目安: チェックが付いた管理表は、統合段取りそのものの設計が必要。新規分の重複対策と並行して、過去分の整理計画を別タスクとして切り出す。
診断結果の読み方
ステップ1〜4でいくつ ✗ が付いたかで、次に進むべき範囲を判断します。
✗が0個 → 重複検知列を追加するだけで足りる段階 候補列・一意性・登録チェック・統合方針のすべてが揃っています。表側にCOUNTIFと条件付き書式で重複検知を組み込むだけで、運用が安定します。 → Excel管理表で重複判定キーの決め方とCOUNTIFチェック列を入れる手順
✗が1〜2個 → キー候補の整備または登録時チェックの追加が必要な段階 ID列・メール列の整備や、新規登録時の重複検知列の追加が必要です。業務に合った候補を選び、表側の検知に置き換えます。 → Excel管理表で重複判定キーの決め方とCOUNTIFチェック列を入れる手順 → 顧客重複を電話・メール・氏名の3点で判定する手順 → メールアドレス重複をLOWER+TRIMで検知する手順
✗が3〜4個 → 採番ルールと統合運用を同時に設計する段階 候補列の不足、表側チェックの欠落、過去重複の放置が重なっています。案件番号・顧客IDの採番ルールから設計し直し、集計側でも重複検知を入れる必要があります。 → 案件二重対応を防ぐ採番ルールの設計手順 → 集計時の重複キー検知をCOUNTIFで組み込む手順 → Excel管理表のWeb化を判断する手順
実務での注意点
- 重複の存在自体が情報になる一時的な記録メモ（複数チャネルからの問い合わせログなど）には、この診断は不要です。同じ問い合わせ者が複数経路から来た事実を残したい表では、重複は許容する設計のままで構いません。
- 重複キーは「完全に一意な列」でなくても構いません。電話番号＋メールアドレス＋氏名の3点組み合わせのような「ほぼ一意」なキーで実務上は十分機能します。
- 重複キーを決めても、表記揺れがあると別データ扱いになります。LOWER・TRIM・ASCなどで正規化した「比較用列」を別に作ると判定が安定します。
- 過去データの統合は影響範囲が広いので、関連する別表（連絡履歴・契約履歴・請求履歴）への波及を確認してから進めます。
- 重複検知の条件付き書式は、データ件数が数千行を超えると動作が重くなることがあります。重い場合は数式列で
重複フラグを立てる方式に切り替えます。
まとめ
Excel管理表に重複データが混ざる原因は、同一データの識別ルールが管理表に組み込まれていないことです。次の一歩は、自分の表で重複キーになり得る候補列を3つ書き出し、=COUNTIF で重複件数を測ってみることです。整備対象が見えたら重複判定キーの決め方の手順で表側の検知を組み込み、顧客重複を電話・メール・氏名の3点で判定する手順で表記揺れにも強い判定に発展させれば、二重登録が起きにくい最初の枠組みが整います。
