スプレッドシート管理の限界はどこか｜人材紹介がCRMに移行する判断基準

スプレッドシート管理の限界はどこに来るか

スプレッドシート管理の限界とは、データが上限に達することではなく、記録を維持するための作業が営業活動を圧迫し始めた状態のことです。求職者が何名になったら、案件が何件を超えたら、といった閾値で線を引きたくなりますが、その線を裏づける統計は存在しません。実際、同じ登録者数でも、単一職種に特化した1人運用の会社と、複数職種をRAとCAで分業している会社では、限界の来かたがまったく違います。

判断の軸になるのは、次の問いです。「その情報を1回書けば済んでいるか、それとも複数の場所に書き写しているか」。求職者の連絡先を面談メモとリストの両方に書いている、進捗をシートに書いたうえでチャットにも報告している、月末にKPIを別シートへ手で集計している——これらはすべて、同じ事実を2回以上人が運んでいる状態です。運ぶ回数は、扱う件数ではなく管理の設計で決まります。だから人数では測れないのです。

「まだ回っている」が最も長引く

スプレッドシートは壊れません。動作が重くなることはあっても、ある日突然使えなくなるわけではないので、限界は事故という形でしか可視化されません。推薦したはずの求職者に連絡が行っていなかった、古い希望条件のまま企業に紹介してしまった、退職した担当者のシートにしかない情報を探して1日を使った。こうした一件が起きて初めて、限界はとっくに来ていたと分かります。

限界のサイン8つ｜チェックリスト

実務で観測できる症状の形に落とします。3つ以上当てはまるなら、管理コストがすでに営業時間を削っていると考えて差し支えありません。5つ以上なら、移行を検討する段階です（この本数はあくまで読み取りの目安であり、統計にもとづく基準ではありません）。

8つを眺めると、どれも「情報が1か所にない」ことから派生しているのが分かります。①②は同じ情報が複数箇所にある問題、③④⑥は必要な情報がどこにもない問題、⑤は情報が集計可能な形で入っていない問題、⑦⑧は情報の見え方と壊れやすさの問題です。移行の目的は機能を増やすことではなく、この分散を止めることにあります。

仕様上の上限と、実務上の限界は別物

「重くなってきたら考える」という判断をよく聞きます。しかし容量を理由に移行が必要になる紹介会社は、ほとんどいません。Google スプレッドシートの上限は、Google ドライブ ヘルプ「Google ドライブに保管可能なファイル」に公開されています。

1,000万セルは、仮に1人あたり50列を使っても20万人分に相当します。つまり容量は、事業として現実的な範囲では尽きません。先に尽きるのは、その1,000万セルを正しい状態に保つために人が払う時間のほうです。「まだ入るから大丈夫」という判断が危ういのは、測っている対象がそもそも違うからです。

先に効いてくるのは表の下2行

実務で先に触れるのは、むしろ同時編集と版の扱いです。上限そのものに紹介会社が到達することはまずありませんが、複数人が同じシートを触ると「今この行を誰が編集しているか」が分からないという問題が起きます。並び替えやフィルタの操作は他のメンバーの表示にも影響するため、閲覧と編集が同じ画面で混ざります。また、名前を付けて残せる版は15個までで、それ以外は自動保存された連続的な記録として扱われます（ヘルプには「ファイルの版が統合されることがあります」と記載されています）。「いつ誰がこの値を書き換えたか」を数か月後に特定する用途には、もともと設計されていないということです。

スプレッドシートでは越えられない一線｜個人情報と権限

ここまでは程度の問題でした。工夫と根性で先延ばしにできます。しかし1か所だけ、工夫では埋まらない構造的な隙間があります。求職者の個人情報に、誰がアクセスできるかという問題です。

職業安定法5条の5第2項は、職業紹介事業者等に対して求職者等の個人情報を適正に管理するために必要な措置を講じなければならないと定めています。その中身を示しているのが厚生労働省「職業紹介事業の業務運営要領」第9で、正確かつ最新のものに保つ措置／漏えい・滅失・毀損を防止する措置／正当な権限を有しない者によるアクセスを防止する措置／収集目的に照らして保管する必要がなくなった個人情報を破棄又は削除するための措置が挙げられています。

このうち3つ目と4つ目が、スプレッドシートの仕様と正面からぶつかります。Google の公式ヘルプは、シートや範囲の保護について「スプレッドシートの内容を他のユーザーが変更できないようにする場合は、内容を保護できます」と説明しています。保護は編集を止める機能であって、閲覧を止める機能ではありません。同じヘルプは「シートを非表示にすることと、シートを保護することは異なります」「スプレッドシートの閲覧者は、非表示になっているシートのコンテンツにアクセスできます」とも明記しています。

つまり、1つのファイルを共有した時点で、そのファイルの中の個人情報は共有相手の全員に見えていることになります。担当者ごとにファイルを分ければ見える範囲は絞れますが、今度は事業所全体の求職者を横断して検索できなくなり、①②のサイン（同じ情報が複数箇所にある）を自分で作り出すことになります。見える範囲を絞ることと、情報を1か所に集めることが、スプレッドシートでは両立しません。これが「越えられない一線」の正体です。

退職時にいちばん現れる

この隙間が最も見える形で現れるのは、担当者が辞めるときです。共有を外せばファイルへのアクセスは止まりますが、在職中にダウンロードされた、あるいは個人のドライブへコピーされた複製までは追えません。Google のヘルプも、保護されたスプレッドシートについて「他のユーザーは、保護されているスプレッドシートのコピーに対して、印刷、コピー、貼り付け、読み込み、書き出しなどの操作を行えます」と明記しています。破棄・削除の措置を講じたと言えるかどうかは、原本を消したかではなく、複製の所在を把握できているかで決まります。

それでも粘ってよいケースと、移すべきケース

反対側も書きます。移行が常に正しいわけではありません。システムに移せば、入力の自由度は必ず下がります。項目が決まっている、決まった順に入れる、というのがシステムの利点であり制約でもあるからです。運用がまだ固まっていない段階でそれを入れると、変化に追随できずに現場が別のシートを作り始め、結局データが二重化します。

左列に大半が当てはまるなら、今はスプレッドシートを磨くほうが投資対効果は高いはずです。項目を整理し、入力規則を設定し、1ファイルに集約するだけで、当面の摩擦はかなり減ります。右列が3つ以上なら、磨いても戻ってくる問題になっています。

併用は「どちらが正か」を決めてから

スプレッドシートとシステムを併用する構成そのものは可能で、実際に移行の途中では必ず併用期間が発生します。危ないのは、どちらを正とするか決めないまま併用が定常化することです。求職者データが両方に存在し、片方だけ更新された状態が続くと、二重入力と突き合わせの工数が恒常的に発生します。併用するなら、正はどちらか、シートに残すのは何か（たとえば集計用の一時的な作業表だけ）を先に決めます。

移行の手順とつまずきどころ

「移行が大変そう」で止まっている場合、実際に重いのはツールの操作ではなくその前のデータ整理です。順番に見ていきます。導入プロセス全体（要件整理からベンダー選定まで）は人材紹介システムの選び方に譲り、ここではスプレッドシートからの移行に固有の論点だけを扱います。

• 1. 移すデータと捨てるデータを決める：全件を移す必要はありません。何年も接触のない求職者、成約済みで追跡の必要がない案件、テスト行や個人のメモ行は、移行の対象から外します。ここで判断を先送りすると、汚れたまま新しい箱に入れることになり、移行後に「システムにしたのに探せない」という不満が出ます。なお、法令上の保存義務がある管理簿の記録は削除できません。破棄してよいかの線引きは、収集目的に照らして保管の必要がなくなったかで判断します。
• 2. 列を「項目」にする：スプレッドシートで最も多いつまずきがここです。1つのセルに「希望年収500万〜／リモート可／9月以降」のように複数の情報が入っていると、そのままでは検索も絞り込みもできません。移行前に、1セル1情報の形へ分解します。日付の表記ゆれ（2026/9/1 と 令和8年9月1日 が混在するなど）も、この段階でそろえます。
• 3. 重複を1件にまとめる：サイン②で挙げた「同じ人が複数行に存在する」状態は、そのまま移すと重複レコードとして再生産されます。氏名とメールアドレスで名寄せし、どの行の情報を正とするかを決めます。ここが移行作業でいちばん時間を使う工程で、件数よりも重複の多さが所要時間を決めます。
• 4. CSVで取り込み、少量で試す：いきなり全件を投入せず、まず数十件で取り込んで、意図した項目に入っているかを確認します。文字コード（UTF-8）と、改行を含むセル（面談メモなど）の扱いが、失敗しやすい2大要因です。
• 5. 並行運用の期間と終わりを決める：移行直後は不安からシートも更新し続けがちですが、期限を決めずに併用すると二重入力が定着します。「この日からシートへの新規入力は停止し、閲覧のみにする」という日付を先に決めます。旧シートは削除せず、閲覧専用にして残すのが安全です。
• 6. 入力ルールを1枚にする：システムは項目を用意しますが、どこまで書くかは決めてくれません。ステータスをいつ動かすか、面談メモに何を残すかを1枚にまとめて共有しないと、人によって粒度が変わり、集計に使えないデータが溜まります。

所要期間は、件数よりも2と3にどれだけ手を入れる必要があるかで決まります。列がすでに整理されていれば数日で終わることもありますし、複数人が別々の形式で作ったシートが何枚もあるなら、整理だけで数週間かかることもあります。ベンダーの移行支援がどこまで含まれるかは製品によって差が大きいため、自社データの一部を実際に取り込んでみるところまでをトライアルで確認するのが確実です。

移行で何が変わるか｜Emproの位置づけ

移行して変わるのは、機能が増えることではなく同じ事実を人が運ばなくなることです。サイン8つと対応させると、次のようになります。

右列は人材紹介CRM一般の設計思想であり、特定の製品の話ではありません。この右列を満たさない製品もありますので、製品を見るときは機能名ではなく「求人企業をマスタとして持てるか」「1人の求職者を複製せず複数求人に紐づけられるか」で確認します。企業向けの採用管理システム（ATS）との構造的な違いは採用管理システム（ATS）と人材紹介CRMの違いで詳しく扱っています。

Emproの場合

本メディアを運営するEmproは、人材紹介会社専用のワンストップ型CRM/MAです。スプレッドシートからの移行という文脈で関係する範囲だけ、実装済みの機能を書きます。

• CSVでの一括取り込み：既存データはCSVで一括登録できます。他社システムからの移行と、スプレッドシートからの取り込みの両方をこの経路で行います。詳細は求人・求職者管理機能にまとめています。
• 求職者・求人・選考ステータスの一元管理：求職者の登録情報（レジュメ・希望条件・面談履歴）と求人情報をそれぞれ管理し、求職者別の選考進捗を時系列で表示します。求職者と求人の紐付けは一括でも行えます。
• メール・LINEが同じ記録に載る：メール（Gmail／Outlook）・LINE・Facebookを標準連携し、メッセージを自動で取り込みます。サイン⑥（やり取りの履歴がシートの外にある）に対応する部分です。
• KPIの可視化とレポート出力：面談数・紹介数・成約率などの主要KPIをダッシュボードで表示し、CA別・求人別の選考状況レポートを出力できます。月末の手集計を前提にしない形になります。
• 休眠求職者の掘り起こし：休眠している求職者へのメール／LINEの自動配信と、求人要件に該当する新規登録者を企業へ自動配信するシナリオを備えています。スプレッドシートでは実行者の記憶に依存していた部分です。

AIマッチングとAIワークフロー（求人票・面談録画からの自動入力）はβ版として提供している段階です。機能の全体像は機能一覧、料金は料金ページにまとめています。

最後に、もう一度反対側を置いておきます。サインが1つ2つしか当てはまらないなら、今は移行の時期ではありません。スプレッドシートを1ファイルに集約し、列を整理するだけで済む段階かもしれません。そして、その整理はいずれ移行するときの下準備にそのままなります。どちらに転んでも無駄にならない作業から始めるのが、いちばん損の少ない進め方です。

よくある質問