ツール移行の前にやるべき「データ構造の棚卸し」— 11テーブルのうち実体は2つだけだった話

先日、ある営業会社のCRM移行プロジェクトを支援した。ノーコードDBで運用していた顧客管理を、別のCRMに移行する案件だ。最初にDBの中身を見せてもらったとき、テーブルが11個並んでいた。「これ全部移行するんですか」と聞いたら、「はい、全部使ってます」と。

ところが、1時間かけて構造を調べたら、実体のあるテーブルは2つだけだった。残り9つは、同じデータを別の切り口で表示しているフィルタービュー。これを知らずに移行を始めていたら、9つの不要なテーブルを新ツールに再構築する無駄が発生していた。

実際のデータ構造：11テーブルの正体

このDBには、担当者700件超、企業450件超、代理店数十件のデータが入っていた。テーブル名を一覧にするとこうなる。

見ての通り、データの実体は「営業担当者」と「取引先企業」の2テーブルだけ。残り9つは、同じデータに対して条件フィルタをかけた「見え方の違い」にすぎない。ノーコードDBのビュー機能を使って、営業チームが用途別に表示を切り替えていたわけだ。

リレーション構造：1企業 : N担当者

2つの実体テーブルの関係はシンプル。1つの取引先企業に対して、複数の営業担当者が紐づく1:Nのリレーション。取引先企業450件超に対して、担当者700件超。平均すると1社あたり約1.6人の担当者がいる計算になる。

営業活動の単位は「担当者」。アポを取る、メールを送る、提案する — これらは全て担当者レベルのアクション。一方で、契約や請求は「企業」単位。この構造を理解せずにツールを移行すると、担当者と企業のデータが混在したフラットなテーブルを作ってしまう。

棚卸しの手順：3ステップで構造を把握する

ステップ1：テーブル一覧を書き出して「実体」と「ビュー」を分類する

まず全テーブルを一覧にして、それぞれが「独自のデータを持っているか」を確認する。判定基準は単純で、「このテーブルを消したら、他のテーブルには存在しないデータが消えるか？」。消えるなら実体テーブル、消えないならビュー。今回の案件では、この作業に約30分かかった。

ステップ2：実体テーブルの列を全て書き出して、移行要否を判定する

実体テーブルが特定できたら、次はその列（プロパティ）を全て書き出す。今回の「営業担当者」テーブルは35列あった。この35列を1つずつ確認して、移行先に持ち込むかどうかを判定する。

今回の案件では、35列のうち「必須」が18列、「任意」が9列、「不要」が8列だった。不要と判定した8列には、旧ツール固有の自動採番IDや、過去に一度だけ使ったキャンペーンフラグなどが含まれていた。

ステップ3：営業ステータスの定義を文書化する

データ構造の棚卸しで最も重要なのが、実は「ステータスの定義」。今回の担当者テーブルには営業ステータスという列があり、選択肢が8つ設定されていた。ところが、各ステータスの定義（どの条件を満たしたら次のステータスに進むか）が明文化されていなかった。

「アポ取得」と「商談中」の違いは何か。初回アポの段階で「商談中」にしている営業担当もいれば、提案書を出すまで「アポ取得」のままにしている担当もいた。この定義のブレは、旧ツールでは「なんとなく運用」で回っていたが、新ツールに移行するタイミングで必ず問題になる。

棚卸しをやらないとどうなるか

棚卸しをスキップしてツール移行を始めた場合、典型的には以下の3つの問題が起きる。

まとめ：移行の8割は「設定」ではなく「棚卸し」

ツール移行のプロジェクトで工数を見積もるとき、多くの人が「新ツールの設定」に時間がかかると思っている。実際にはそうではない。時間がかかるのは、今あるデータの構造を理解し、何を移行して何を捨てるかを決める「棚卸し」の作業だ。

今回の案件では、棚卸しに半日、実際の移行作業に1日。棚卸しをせずに11テーブル×35列をそのまま移行していたら、移行作業だけで3〜4日はかかっていた。しかも移行後に「この列いらなかった」「このテーブルはビューだった」という手戻りが発生する。

新しいツールの機能を調べる前に、まず今のデータを全部テーブルに書き出して、「実体」と「ビュー」を分ける。それだけで、移行プロジェクトの見通しが一気に良くなる。