脱スプレッドシート：顧客管理が壊れる理由と、移行せずに延命する方法（現場で回る”最低限の型”つき）
スプレッドシートで顧客管理をしていると、最初のうちはうまく回ります。少人数で案件も限られているうちは、むしろ手軽で便利な道具です。ところが、人数が増え、案件が増え、問い合わせが増えた瞬間から「壊れる兆候」が出始めます。
それでも現実には「いまCRM（顧客関係管理）に移行する余裕はない」「まず目の前の運用を止めたくない」というケースがほとんどではないでしょうか。予算も時間も足りないし、移行プロジェクトを回す体力もない。そんな声をよく聞きます。
この記事では、スプレッドシート顧客管理が壊れる”構造的な理由”を整理したうえで、移行せずに延命するための運用設計（最低限の型）を具体的に解説します。「いつか移行したい。でも今は無理」という方に向けた、現実的な処方箋です。
スプレッドシート顧客管理が壊れるのは「運用」ではなく「構造」が原因
「ちゃんと入力して」「ルール守って」と言い続けても、だいたい崩れます。毎週のように同じ注意をして、それでも改善しない。この繰り返しに疲れている方も多いはずです。
理由はシンプルで、スプレッドシートは”表”であって、顧客管理のための仕組みではないからです。Excelやスプレッドシートは汎用的な表計算ツールとして設計されています。何でもできる反面、顧客管理に特化した機能は持っていません。
顧客管理で本当に必要なのは、次の3つです。まず、誰が見ても「最新」が一つに定まること。次に、過去のやり取り（活動履歴）が残り、追えること。そして、担当や期限が明確になり、抜け漏れが起きにくいこと。
スプレッドシートは、この3つすべてが弱い。だから壊れます。運用の問題ではなく、構造の問題なのです。
顧客管理が壊れる理由1：同じ顧客が増殖する（重複・名寄せ不能）
スプレッドシート運用で最初に起きる事故は、同一顧客が複数行に分裂することです。
たとえば会社名の表記揺れがあります。「株式会社ロゴラボ」「ロゴラボ」「LogoLabo」「（株）ロゴラボ」。これらが別々の行として登録され、同じ会社なのに4つのレコードが存在する状態になります。取引先の部署や担当者が変わったタイミングで新規登録されるケースも多いですし、既存顧客なのに「新規」として登録されることも珍しくありません。
この状態が増えると、現場では「どれが正しい？」という確認が毎回発生します。検索しても複数ヒットするので確信が持てません。結果として、誰も更新しなくなり、表が”墓場”と化します。古いデータと新しいデータが混在し、どれを信じていいか分からない。そんな状態です。
延命の型：名寄せの”最小ルール”だけ決める
延命のポイントは、完璧な統合を目指すことではありません。重要なのは、判定の優先順位を固定することです。「この情報が一致していれば同一顧客とみなす」という基準を明確にしておくだけで、状況はかなり改善します。
たとえばBtoBの場合、優先順位は以下の順番で十分です。まず連絡先メールアドレスで個人の同一性を判定します。次に会社ドメインで企業の同一性を確認します。電話番号は補助的な判断材料として使い、会社名は最後の参考情報として扱います。
そして、会社名は「表示名」と「正規化名」を分けて管理します。表示名は現場が使いやすい名称を自由に入れてかまいません。ただし、正規化名の列には揺れを潰した統一表記を入れる。これだけで重複の発生スピードが目に見えて落ちます。
顧客管理が壊れる理由2：「最新がどれか分からない」問題が必ず起きる
スプレッドシートは編集が簡単です。クリックすればすぐ書き換えられる。この手軽さが魅力ですが、裏を返すと、変更の責任が曖昧になりやすいという弱点があります。
複数人が触ると、こんなことが起きます。Aさんは古い情報を見つけて更新する。Bさんは別の行にある同じ顧客の情報を更新する。Cさんはそもそも該当レコードを探しきれず、新規行を追加してしまう。
こうして「最新がどれか分からない」状態が常態化します。さらに厄介なのは、これが起きても誰も悪くないことです。それぞれが善意で作業しているのに、結果として混乱が生まれる。構造がそうさせているのです。
延命の型：「更新責任者」を顧客単位で決める
運用で効くのは、ルールを増やすことではありません。責任を決めることです。
顧客（会社）ごとに「オーナー（更新責任者）」という列を設けます。情報の更新はオーナーが最終確定する。他のメンバーは直接編集せず、コメント欄や追記欄に情報を残す。この運用にするだけで、「誰の情報が正しいのか」という混乱がなくなります。
この”最終確定の一手”があるだけで、最新情報の所在が一気に安定します。オーナーが不在のときは代理を立てるか、一時的に保留にする。そういったルールも自然と生まれてきます。
顧客管理が壊れる理由3：活動履歴が残らず、追客漏れが起きる
顧客管理で売上に直結するのは「顧客データ」よりも、実は活動履歴（いつ・誰が・何をしたか）です。どんなに正確な顧客情報があっても、前回の商談で何を話したか、いつフォローの約束をしたか、これが分からなければ意味がありません。
ところがスプレッドシートは、活動履歴を運用で積み上げるのがとにかくつらい構造になっています。メールのやり取りはGmailにあります。会議の記録はカレンダーにあります。メモはチャットや個人のドキュメントに散らばっています。
情報が分断されているので、担当者の引き継ぎ時に毎回事故が起きます。「前回何を話しましたっけ？」とお客様に聞くわけにもいかず、追客のタイミングを逃してしまう。これは売上に直結する損失です。
延命の型：履歴は”書く”のではなく”貼る”
ここで「活動ログ列を作って毎回詳細に書こう」という気合いの運用は、だいたい失敗します。最初の1週間は続いても、忙しくなると真っ先に省略される作業だからです。
延命のコツは、文章で残すより先にリンクで残すことです。該当するGmailスレッドのURLを貼る。GoogleカレンダーのイベントURLを貼る。見積書や提案資料（Googleドライブ）のURLを貼る。
最低限、「URLを1本貼る」だけでも、後から経緯を追える状態になります。活動履歴の粒度は、この運用が定着してから上げればいい。最初から完璧を求めると、何も残らなくなります。
顧客管理が壊れる理由4：権限と共有が地獄になる（退職・異動・外部共有）
スプレッドシートは共有が手軽です。リンクを送れば誰でもアクセスできる。この便利さが、実は権限事故を呼び込みます。
退職者の個人ドライブにファイルが残っているケースは珍しくありません。外部の協力会社やフリーランスへの共有が増えて、いったい誰が見られる状態なのか把握できなくなることもあります。編集権限が広がりすぎて、列の設計や数式が壊れることも頻繁に起きます。
この状態になると、セキュリティ的に怖いだけでなく、運用の改善ができなくなります。「触ったら壊れる」という恐怖から、誰も手を入れられない。レガシーシステムと同じ状態です。
延命の型：閲覧と編集を分ける
全員が編集できる設計は、長期的に必ず崩れます。これは断言できます。
対策として、閲覧用と編集用を分けてください。閲覧用は全員が見られる状態にして、共有範囲は広めで構いません。編集用は担当者だけがアクセスできるようにして、変更できる人を絞ります。
もし1ファイルで運用したいなら、シートを分けて編集対象を限定する方法もあります。マスタシートは管理者のみ編集可、入力シートは担当者が編集可、という具合です。
地味な対策ですが、延命効果は非常に大きいです。
移行せずに延命するための「最低限の再設計」5ステップ
ここまでの内容を、すぐ手を動かせる形にまとめます。ポイントは「作り直す」ではなく、壊れている原因だけを潰すことです。全面的なリニューアルは必要ありません。
ステップ1：顧客の”単位”を決める（会社／人物／案件を混ぜない）
よくある失敗は、1枚のシートに全部詰め込むことです。会社情報も担当者情報も案件情報も、全部同じ行に入っている。この設計では、更新のたびに混乱が起きます。
最低でも次の3つは別シート（または別ファイル）に分けてください。会社（取引先）、人物（担当者）、案件（商談・プロジェクト）です。
これらを混ぜると、「会社情報を更新したいのに案件情報まで触らないといけない」「同じ会社の別担当者を追加するのに行が増える」といった問題が起きます。分けることで、更新のルールが明確になります。
ステップ2：ID列を足す（ユニークキーを持たせる）
スプレッドシート延命で一番効くのがこの対策です。
会社ID（例：C-000123）、人物ID（例：P-000456）、案件ID（例：D-000789）といった形式で、それぞれにユニークな識別子を割り振ります。
会社名や担当者名は揺れますが、IDは揺れません。「株式会社ロゴラボ」と「ロゴラボ」は別の文字列ですが、会社ID「C-000123」は一つだけです。これがあるだけで、後からデータを結合したり、整理したりする作業が格段に楽になります。
ステップ3：入力項目を減らす（必須を絞る）
入力が重いほど、運用は壊れます。これは経験則として間違いありません。
必須項目は最低限にして、まず”最新が一つ”という状態を守ることを優先してください。あれもこれも入力させようとすると、結局どの項目も中途半端になります。
会社マスタなら、最小構成はこれで十分です。会社ID、正規化会社名、ドメイン、オーナー（更新責任者）、最終更新日。まずはこの5項目だけを確実に運用して、余裕ができたら項目を増やす。この順番が大事です。
ステップ4：「追記欄」を用意して、更新の衝突を吸収する
複数人が同じレコードを触る以上、編集の競合は避けられません。競合をなくすのではなく、吸収する構造にするのが現実的です。
具体的には、「更新提案（追記）欄」と「確定情報欄」を分けます。追記欄は誰でも書ける。確定情報欄はオーナーだけが反映する。この二段構えにすることで、「勝手に直されて困る」「誰が変えたか分からない」という問題が大幅に減ります。
ステップ5：活動履歴はリンクから始める
繰り返しになりますが、活動ログを文章で書く運用は継続しません。
まずは「関連リンク」という列を1つ作り、URLを残すだけにしてください。Gmailのスレッド、カレンダーの予定、ドライブの資料。これらへのリンクが1本でも残っていれば、後から経緯を追うことができます。完璧な議事録より、確実に残るリンク1本のほうが価値があります。
「延命」が限界に近いサイン（この段階なら移行検討が現実的）
延命は万能ではありません。あくまで「今すぐCRMに移行できない」という状況への対処療法です。次のような状態になったら、延命より移行を検討した方が合理的です。
サイン1：重複統合に毎週時間が取られる
名寄せが人力のままだと、顧客数が増えるほどコストが雪だるま式に膨らみます。毎週のように「この会社とこの会社は同じですか？」という確認作業に時間を取られているなら、それは構造的な限界に達しているサインです。
サイン2：活動履歴が追えず、引き継ぎが成立しない
担当者が変わるたびに商談が失速するなら、それはデータ構造の問題というより履歴管理の問題です。スプレッドシートでは根本的に解決が難しい領域なので、CRMへの移行を真剣に検討すべきタイミングです。
サイン3：誰が何を変えたか追えず、監査できない
事故が起きたときに原因が特定できない運用は、組織としてのリスクになります。「いつ、誰が、何を変えたか」が追えない状態は、内部統制の観点からも問題です。この段階まで来たら、変更履歴が自動で残るシステムへの移行が必要です。
まとめ：移行しないなら「ルール」ではなく「型」で延命する
スプレッドシート顧客管理が壊れるのは、担当者の努力不足ではありません。壊れる前提の構造で、運用だけで耐えようとしているからです。「もっとちゃんと入力して」と言っても解決しないのは、問題がそこにないからです。
移行せずに延命するなら、次の3点だけは外さないでください。
まず、名寄せの最小ルール（判定優先順位）を決めること。メールアドレス、ドメイン、電話番号、会社名の順で判定する、といった基準を明確にします。
次に、更新責任者（オーナー）を決めて最新情報を確定させること。誰が正しい情報を持っているかを明確にするだけで、混乱は大幅に減ります。
そして、活動履歴は”リンクで残す”ことから始めること。完璧な記録より、確実に残る1本のリンクを優先してください。
これだけで、スプレッドシートは「いつ壊れるか分からない爆弾」から「当面は運用できる道具」になります。
おまけ：無料テンプレ（たたき台）を自作するなら、この列から始めてください
最後に、すぐ作れる”延命用の列”のたたき台を載せておきます。完璧に作り込むより、まずこの形に寄せるのが近道です。
会社マスタ（例）
会社ID、正規化会社名、表示会社名、ドメイン、オーナー、最終更新日、関連リンク（メールスレッドや資料へのURL）。この7列があれば、最低限の運用は回ります。
人物マスタ（例）
人物ID、会社ID（どの会社に紐づくか）、氏名、メールアドレス。電話番号と役職は任意項目として、入力できるときだけ入れる形で構いません。
案件マスタ（例）
案件ID、会社ID、ステータス（商談中・受注・失注など）、金額（任意）、次アクション、次回期限、関連リンク（議事録や見積書へのURL）。
まずはこの構成で作ってみて、運用しながら必要な列を足していく。その順番が、延命を成功させるコツです。