「スプレッドシート 限界」で検索する人の多くは、表そのものが壊れて困っているわけではありません。行が増えて重くなったから調べた、という人よりも、返信したのかどうかが分からなくなった、誰が担当するかが決まらない、この表を新しく入った人に見せてよいのか判断できない、という詰まりを抱えている人のほうが圧倒的に多いのが実際のところです。つまり限界は、行数が上限に届く前に、運用のほうから先に来ます。この記事では、受付をひとりで回している担当者が、いまの手作業のどこが詰まっているのかを見極めて、次に何を変えればよいのかを決められるように、見るべき物差しを3つに絞って整理します。同時に触る人の数、列の増え方、誰が見てよいか。この3つです。
限界を行数で測ろうとすると判断を間違える
表計算ソフトには、扱えるセルの数やシートの数に上限があります。ただし、受付や問い合わせの管理でその上限に届く窓口はほとんどありません。1件が1行なら、1日に30件届く窓口でも1年で1万行あまりです。行数の上限に当たるより先に、別の理由で表が回らなくなります。
具体的な上限の数値は、使っている表計算サービスの公式の案内で確かめてください。仕様は改定されますし、契約している種別によっても変わります。この記事で数値を挙げても、読んだ時点で古くなっている可能性があります。
そして、上限の数値を調べても運用の判断材料にはなりません。「まだ上限の1割も使っていないから大丈夫」という結論に至ってしまうからです。実際には、上限の1割どころか1%も使っていない段階で、返し忘れや二重返信は起き始めます。
表計算は記録の道具であって、進行の道具ではない
表計算ソフトが得意なのは、確定した事実を並べて、計算して、集計することです。売上の一覧、在庫の数、経費の明細。これらはすべて「もう起きたこと」の記録です。表計算はこの用途では他に代えがたい道具で、限界という言葉はまず当てはまりません。
受付の管理が難しいのは、扱う対象が「まだ終わっていないこと」だからです。届いた申し込みは、受け付けた時点では未完了です。誰かが読み、判断し、返信し、場合によっては書類をもらい、日程を決め、ようやく完了になります。この途中の状態は、時間とともに動きます。動くものを表に載せると、載せた瞬間から実態とずれていきます。
ずれを埋めるために、人が手で列を更新します。更新できているうちは回ります。更新が追いつかなくなった瞬間に、表は「何が本当か分からない場所」になります。ここが限界です。行数ではなく、手で更新できる速度が限界の正体です。
「重い」と感じたら、それは行数ではなく式のせいであることが多い
表が重くなったから限界だと判断する前に、何が重くしているのかを確かめてください。受付管理の表が重くなる原因は、行数そのものよりも、列に入れた数式であることが大半です。
別のシートを丸ごと参照する検索の式、条件付き書式を表全体に掛けたもの、他のファイルを参照する外部連携の式。こうした仕組みは1行ずつでは軽くても、行が増えると掛け算で効いてきます。数式を値に変換する、条件付き書式の範囲を必要な列だけに絞る、外部参照を減らす。この3つを試すと、体感が戻る例は珍しくありません。
重さが解消しても、返し忘れも二重返信も直りません。重さは表面の症状であって、限界の本体ではないからです。
限界を見分ける3つの物差し
行数の代わりに見るべきものが3つあります。この3つは、どれか1つでも境目を越えると運用が壊れ始めます。逆に3つとも境目の内側にいるなら、行が何千行あっても表で回せます。
物差しを先に並べます。1つ目は、同時にその表を触る人の数。2つ目は、列がどう増えていくか。3つ目は、誰がその表を見てよいか。以下、それぞれについて、何が起きるのか、どこが境目なのか、境目を越えたときに何を決めればよいのかを順に見ます。
同時に触る人の数
いちばん早く来る限界がこれです。表を更新する人が1人のうちは、表計算は驚くほどうまく機能します。自分の記憶と表の中身が一致しているので、多少雑に運用していても事故になりません。
更新する人が2人になった時点で、性質が変わります。相手が何をしたのかは表を見ないと分からず、表に書かれていないことは存在しないのと同じになります。表が「作業の記録」から「引き継ぎの手段」に変わるわけです。この転換に気づかないまま、1人のときと同じ運用を続けると必ず事故が出ます。
列の増え方
2つ目は列です。受付表の列は、放っておくと必ず増えます。増えること自体は悪くありませんが、増え方には健全な増え方と、破綻に向かう増え方の2種類があります。
健全なのは、受け付けた事実を書く列が増えるときです。項目を1つ聞くようにしたから列を1つ足す。この増え方は表の構造を壊しません。破綻に向かうのは、「進行の状態」を表現するために列が増えていくときです。対応済みチェック、一次返信済み、書類受領済み、二次確認済み、完了。状態のたびに列が生えていく表は、遠からず横に長くなりすぎて画面に収まらなくなります。
誰が見てよいか
3つ目が、いちばん見落とされます。受付の表には、氏名、連絡先、勤務先、経歴、体調に関わる備考など、他人に見せてよいとは限らない情報が入ります。表計算ファイルの共有は、原則としてファイル単位です。ファイルを見せるということは、そこに書かれているすべてを見せるということになります。
新しく入った人に受付を手伝ってもらいたい、他部署の人に一部だけ確認してほしい。こうした要望が出たときに、ファイル単位の共有では「全部見せる」か「見せない」の二択しかありません。ここで詰まって、担当者が自分だけで抱え込む状態に固定されている窓口は少なくありません。
同時に触る人が増えたときに起きること
物差しの1つ目を掘り下げます。ここで起きる事故は、種類がはっきり決まっています。
二重返信と返し忘れ
もっとも多いのがこれです。返信したかどうかが表に残らない運用では、二重返信と返し忘れは必ず起きます。「必ず」と言い切れるのは、防ぐ仕組みが無いからです。人の注意力に頼っている限り、忙しい日には抜けます。
二重返信は、受け取った相手から見ると「連携が取れていない」と映ります。返し忘れは、それより深刻です。返していないことに気づくのは、たいてい相手から催促が来たときで、そのときにはもう相手の期待は一度裏切られています。
対応済みのチェック列を1つ足せば防げそうに見えますが、これだけでは足りません。チェックを付けるのを忘れる、という新しい抜けが増えるだけだからです。返信という行動と、記録という行動が別々になっているのが原因なので、この2つが分かれている限り抜けは残ります。返信した事実が自動で記録される場所に移すのが根本の解決になります。
上書きと、消えたものが戻らないこと
複数人で同じ表を開いていると、同じセルを別々に書き換える場面が出ます。多くの表計算サービスには変更履歴の機能があり、たどれば復元できます。ただし、これが有効なのは「消えたことに気づいたとき」だけです。
現場でよく起きるのは、行の削除と貼り付けです。誰かが不要だと思って削除した行が、実は別の人が対応中の案件だった。誰かが別の場所からコピーした50行を貼り付けたら、既存の行の並びがずれて、担当の列と氏名の列の対応が全部1行ずれた。こうした事故は、起きた瞬間には誰も気づきません。気づくのは数日後で、そのときにはどの版に戻せばよいのかが分からなくなっています。
範囲の保護をかけて、更新してよい列だけを編集可にすると、事故はかなり減ります。並べ替えは通常のフィルタではなくフィルタ表示を使う、というルールも効果があります。それでもゼロにはなりません。表計算は、複数人が同時に構造ごと書き換えられる道具として設計されているからです。
「いま誰が見ているか」が判断の材料にならない
共同編集の画面には、いま誰が開いているかが表示されます。ところが、この情報は受付の運用ではほとんど役に立ちません。開いているだけなのか、その案件を担当するつもりなのかが分からないからです。
必要なのは「この件は誰の担当か」であって「いま誰が画面を開いているか」ではありません。担当の列を作って名前を入れる運用にすると一歩進みますが、今度は誰が名前を入れるのかという問題が残ります。手が空いた人が自分で入れる運用は、忙しい時期に機能しなくなります。届いた時点で担当が決まる仕組みが要る、というのがこの物差しの結論です。
列が増えていくときに起きること
物差しの2つ目です。列の増え方は、その窓口が何に困っているかを正直に映します。
状態を表す列は、必ず増える
対応済みの列を1つ作ったところから始まります。しばらくすると、対応済みには「返信はしたが完了ではない」ものが混じっていることに気づきます。そこで一次返信済みの列を足します。次に書類の受領を追いたくなって列を足します。社内の承認を待っている件を分けたくなって、また足します。
こうして状態の列が5つを超えたあたりで、表は読めなくなります。ある行はチェックが3つ、別の行は1つ。どの組み合わせが「いまどの段階か」を意味するのかが、担当者の頭の中にしかありません。人が増えたときに引き継げないのはこのためです。
直し方は決まっています。状態を複数の列で表すのをやめて、1つの列に段階の名前を入れる形にします。未対応、確認中、返信済み、完了。この4つで足りる窓口が大半です。列を増やすのではなく、1つの列が取りうる値を決めるという発想に切り替えると、表は一気に読めるようになります。
表に入りきらない情報が、メールとチャットに散る
列の増え方に関して、もう1つ重い問題があります。やり取りの中身が表に入らないことです。
受付の1件について、実際には何往復もメールが飛びます。追加の質問、送り直してもらった書類、日程の変更。これらの内容を表のセルに書き写すのは現実的ではないので、「詳細はメール参照」で済ませることになります。すると、案件の全体像を知るには表とメールとチャットの3か所を突き合わせる必要が出てきます。
担当者本人はそれでも回せます。回せなくなるのは、休んだとき、辞めたとき、他の人が引き継ぐときです。引き継ぎ資料を作ろうとして、表には要点しか無く、経緯はすべて個人のメールボックスの中にあることに気づく。この状態を「属人化」と呼びますが、原因は人ではなく、記録が分かれている構造にあります。受付から対応までの記録が同じ画面に残るようになると、この問題は構造ごと消えます。
添付ファイルは表に載らない
列の話でもう1つ抜けやすいのが、添付ファイルです。応募書類、見積の依頼書、写真、申請の証明書類。受付には必ずファイルが付いてきます。表計算のセルにファイルそのものは入らないので、置き場所のリンクを貼るか、共有フォルダのどこに置いたかを文字で書くことになります。
ここから2つの困りごとが生まれます。1つは、リンクを貼っただけではその先の共有設定が別管理になることです。表は見せてよい相手でも、リンク先のフォルダは見えない、あるいは逆に、表は絞っているのにファイルのほうは誰でも見られる設定のまま、という食い違いが起きます。もう1つは、ファイル名の付け方が人によって変わることです。受付番号を頭に付ける人と、氏名を頭に付ける人が混ざると、フォルダを開いてもどれがどの案件のものか分からなくなります。
この2つは、運用ルールで抑え込めます。ファイル名は受付番号から始める、置き場所は1か所に限る、と決めるだけでかなり改善します。ただし、ルールで抑える限り、守られなかったときに気づく仕組みはありません。受け付けた案件とファイルが最初から結びついている場所に移すと、ルールを覚える必要そのものが消えます。
集計の列が真っ先に壊れる
列が増えた表では、集計用の数式が最初に壊れます。列を挿入したときに参照がずれる、条件が増えて式が長くなる、状態の値に表記ゆれが混じって数が合わない。
表記ゆれは特に厄介です。「完了」「済」「対応済み」が同じ列に混在すると、件数が正しく出ません。入力規則でリストから選ぶ形にすれば防げますが、リストの選択肢を後から変えると過去の行が古い値のまま残ります。集計の数字が信じられなくなった時点で、月次の報告に使えなくなり、表の存在意義が「一覧を眺める場所」まで縮みます。
誰が見てよいかで詰まるときに起きること
3つ目の物差しです。ここは事故が起きたときの影響がいちばん大きい領域です。
共有の単位がファイルであること
表計算ファイルの共有設定は、ファイルまたはシートの単位で決まります。行の単位で「この人にはこの行だけ」を厳密に管理する使い方は、フィルタ表示や別シートへの参照で近いことはできても、本来の設計から外れた使い方になります。参照元の権限が変わったときに意図せず見えてしまう、という穴も残ります。
受付の表には、応募者の経歴、相談者の困りごと、利用者の連絡先といった情報が入ります。個人情報の取り扱いについて、法律の解釈をここで断定することはしません。判断に迷う場面では、所管の窓口や専門家に確かめてください。そのうえで、法令が事業者に安全管理の措置を求めていることは、条文にはっきり書かれています。
個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。 出典: 個人情報の保護に関する法律（安全管理措置）e-Gov
「必要かつ適切な措置」が具体的に何を指すのかは、扱う情報の性質と量、事業の規模によって変わります。所管である個人情報保護委員会が考え方を示しているので、受付で何を集めているかを一覧にしたうえで確かめるのが確実です。ここで言えるのは、見せる相手を絞れない道具に個人情報を貯め続ける運用は、説明が難しくなるということです。
共有リンクは、渡した先が追えない
急いでいるときに使われがちなのが、リンクを知っている人なら見られる設定です。手軽で、その場は解決します。問題は、そのリンクがどこまで転送されたのかを誰も知らないことです。
社内のチャットに貼られ、そこから別のチャンネルに転送され、誰かが個人のメモに保存する。1度出たリンクを回収する方法はありません。共有設定を後から絞れば新しいアクセスは止まりますが、すでに手元に控えられた内容は戻りません。
人の入れ替わりのたびに棚卸しが要る
権限がファイルに付いている以上、担当者が異動したり退職したりするたびに、共有先の一覧を開いて外す作業が発生します。受付の表が3つや4つに分かれていれば、その数だけ確認が要ります。
この作業は、忘れても誰も困りません。困らないので、忘れられます。1年後に共有先の一覧を開くと、もういない人の名前が並んでいる、という状態はよく見かけます。人ではなく役割に権限を紐づけられる場所へ移すことが、この物差しに対する答えになります。
3つの物差しで、いまの状態を確かめる
以下の項目を読んで、当てはまるものを数えてください。判断のための材料であって、点数を競うものではありません。
同時に触る人の数について。表を更新する人が2人以上いる。誰かが更新したことに気づかず、同じ相手に2回返したことがある。行が消えた、または並びがずれた事故が起きたことがある。担当が決まらないまま数日置かれた件がある。休んだ人の担当分を、他の人が把握できなかったことがある。
列の増え方について。状態を表すチェック列が3つ以上ある。列が横に伸びて、画面をスクロールしないと右端が見えない。同じ意味の値が「完了」「済」のように混在している。案件の経緯を知るには、表のほかにメールを開く必要がある。使わなくなった列が残っているが、消してよいか分からない。
誰が見てよいかについて。表を見せたい相手がいるのに、全部見えてしまうので見せられない。リンクを知っている人が見られる設定になっている。共有先の一覧を、この半年で確認していない。もう関わっていない人が編集できる状態のままになっている。個人情報が入った表が、複数のファイルに分かれている。
3つの区分のうち、当てはまるものが多い区分が、いま最初に手を付けるところです。すべてを同時に直そうとすると必ず途中で止まるので、1つに絞ってください。
表を替えずに直せること、替えないと直らないこと
限界という言葉が出ると、すぐに乗り換えの話になりがちですが、その前にやることがあります。組み方が悪いだけの詰まりは、表のまま直ります。道具の性質による詰まりだけが、乗り換えの理由になります。
表のままで直せること
状態のチェック列を1つの列にまとめる。値は入力規則でリストから選ぶ形にして、表記ゆれを止める。更新してよい列以外に保護をかけて、うっかりの上書きを減らす。並べ替えはフィルタ表示で行い、全員が見ている並びを変えない。受付番号の列を作って、1件を一意に指せるようにする。次に誰が何をするのかを書く列を1つ作る。使っていない列を消す。ここまでは、道具を替えずに今日から着手できます。
これらを実施すると、多くの窓口で詰まりの半分ほどは消えます。消えなかった残りが、道具の性質に由来する部分です。
表のままでは直らないこと
返信という行動と記録という行動を1つにすること。これは表では実現できません。表は記録の場所であって、そこから返信を送る場所ではないからです。
届いた時点で担当を割り当てて、その人に知らせること。表には通知の仕組みがありません。誰かが表を見に行かない限り、新しい行が増えたことは伝わりません。
見せる範囲を人や役割ごとに変えること。ファイル単位の共有では限界があります。
誰がいつ何を変えたかを、案件ごとに読める形で残すこと。変更履歴の機能はファイル全体の時系列で残るので、1件分だけを追うのは現実的ではありません。
この4つのうち2つ以上が必要になっているなら、それは組み方の問題ではありません。道具を替える段階です。
乗り換えを決める前に、先に決めておくこと
道具を選ぶより先に決めておくべきことがあります。ここが決まっていないまま乗り換えると、新しい道具の上で同じ混乱を再現することになります。
受付から完了までの状態の名前を決めてください。数は4つから5つに収めます。多くしすぎると、どれを選ぶか迷う時間が毎回発生します。名前は動詞ではなく状態で書くと運用が安定します。「返信する」ではなく「返信済み」です。
誰が返すのかの決め方を決めてください。届いた順に自動で割り振るのか、種別ごとに担当を固定するのか、いったん全員が見て手を挙げるのか。この決め方が無いまま担当の列だけ作っても埋まりません。
過去の受付をどう持ち越すかを決めてください。全部を移すのか、未完了だけを移して完了分は表のまま保管するのか。多くの窓口では後者で足ります。未完了だけなら数十件で済むことが多く、移行作業が1日で終わります。
そして、回答する側に負担を増やさないことを条件に入れてください。回答者にアカウント登録を求めると、そこで応募や申し込みをやめる人が出ます。受け付ける側の管理が楽になっても、届く件数が減るなら意味がありません。
受け付けたあとの動きから見た、道具の選び方
受付の道具を並べて比べるとき、多くの人はフォームの作りやすさから見ます。設問の種類が多いか、見た目を変えられるか、埋め込みが簡単か。ところが、この記事で挙げた3つの物差しは、どれもフォームを作る場面ではなく、送信されたあとの場面で効いてきます。
比べる観点を4つに絞ってください。届いた回答に状態を持たせられるか。担当を割り当てて知らせられるか。対応の履歴が自動で残るか。その画面から返信できるか。この4つがそろっていれば、表でやっていた運用のほとんどをそのまま移せます。ここがそろっていない道具に移ると、結局また表を作ることになり、限界が来る場所が変わっただけになります。送信されたあとの道具が同じ画面にそろっているかどうかが、乗り換える価値の中身です。
いま使っている道具のままで足りるのかどうかを見極めたいときは、比較の記事から読むと判断が速くなります。フォームの回答を表計算で受ける構成の得意なところと苦手なところはGoogleフォームとの比較に整理してあります。自社サイトにフォームを埋め込んでいて、送信されたデータの保存や対応の記録で困っているならContact Form 7との比較が近い話になります。社内の道具でそろえていて、社外からの回答を受けるときの扱いが気になる場合はMicrosoft Formsとの比較を見てください。いずれも、どういう使い方なら乗り換える理由が無いのかから書いています。
限界の来かたは、受付の種類によって違います。応募者の書類を受け取って選考の状況を追う流れは採用の応募受付に、締切があって申請の要件確認が入る流れは助成金・公募の受付にまとめています。窓口に届く一般的な相談は問い合わせの受付、定員と出欠が絡むものはイベントの申し込み、回数や期の管理が入るものは講座の受講申し込みが近い形です。予約の空きと使用日を管理するなら施設利用の申請、入会の審査と会員情報の更新が続くなら会員の入会申し込み、製品ごとの対応履歴を追うなら修理・サポートの受付を参照してください。自分の受付に近いものを開くと、いまの表に足りていないものがどれなのかが具体的に見えます。
必要な部品がそろっているかはできることの一覧で確かめられます。機能の名前だけでは実物と結びつかないので、動くところを見るで実際の画面を触ってから一覧に戻ると、言葉と動きの対応が取れます。費用の目安は料金に、移行のときに出る細かい疑問はよくある質問にまとめてあります。
最後に、表計算をやめる必要はないという点を書いておきます。集計と分析は表計算のほうが得意です。月ごとの件数、種別ごとの割合、返信までにかかった時間の分布。こうした数字を出すなら、受付の記録を書き出して表計算に取り込むのがいちばん速い。受付を回す場所と、数字を作る場所を分ける。この分け方に落ち着けば、表計算は最後まで役に立つ道具として残ります。
行が増える前に、3つの物差しを当ててください。同時に触る人の数、列の増え方、誰が見てよいか。この3つのどこで境目を越えているのかが分かれば、次に何を変えればよいのかは自然に決まります。上限の数値を調べるより、こちらのほうが判断の役に立ちます。
Q1. スプレッドシートは何行くらいで限界が来ますか？
行数では決まりません。1件が1行なら、1日に30件届く窓口でも1年で1万行あまりで、行数の上限に届く前に運用のほうが先に詰まります。見るべきは、表を更新する人が2人以上いるか、状態を表す列が増え続けていないか、見せたい相手に一部だけ見せられるか、の3つです。上限の数値は使っている表計算サービスの公式の案内で確かめてください。
Q2. 二重返信と返し忘れを、表のままで防ぐ方法はありますか？
完全には防げません。対応済みの列を作っても、チェックを付け忘れるという抜けが増えるだけだからです。返信という行動と記録という行動が分かれているのが原因なので、返信した事実が自動で残る場所に移すのが根本の解決になります。表のままなら、朝と夕方に未対応の行だけを絞って読み合わせる運用で被害を減らせます。
Q3. 表を替えるかどうかは、何を基準に決めればよいですか？
表のままでは直らないことが2つ以上あるかで決めてください。届いた画面から返信すること、届いた時点で担当を割り当てて知らせること、見せる範囲を人ごとに変えること、案件ごとに変更の履歴を読めること。この4つは表計算の設計から外れているため、組み方の工夫では解決しません。
Q4. 乗り換えるとき、過去の受付データは全部移す必要がありますか？
多くの窓口では未完了の分だけで足ります。完了した分は表のまま保管しておき、必要になったら検索する運用で困りません。未完了だけなら数十件で収まることが多く、移行の作業が1日で終わります。移す前に、受付から完了までの状態の名前を4つから5つに決めておくと、移しながら整理できます。