結論:複数人共有で壊れるのは「人のミス」ではなく「構造」
複数人で使うスプレッドシートが壊れるのは、誰かが不注意だからではありません。誰でも全セルを編集できる構造のまま人を増やしていることが根本原因です。同時編集での誤上書き、行挿入による参照ズレ、権限の事故は、運用ルールだけでは防ぎきれません。
結論を先に言うと、対策は2層で考えます。まず今すぐの応急策として、シート保護・入力規則・編集権限の最小化・「閲覧用」と「入力用」の分離を行う。そのうえで、人が増えても壊れないようにするならフォーム入力+データベース(アプリ化)へ移すのが根本解決です。本記事では応急策の具体手順から、どこで限界が来るかまでを実務目線で解説します。
なお「共有すると重くなる」問題は原因が別軸(データ量や関数負荷)なので、スプレッドシートが重い原因と軽量化で補完してください。本記事は「壊れる・崩れる」に絞ります。
なぜ複数人共有で壊れるのか:4つの構造的な原因
実務でスプレッドシートのトラブル相談を受けると、原因はほぼ次の4つに集約されます。いずれも「気をつける」だけでは再発します。
原因1:同時編集での誤上書き・入力の取り違え
Googleスプレッドシートは複数人が同じシートを同時に編集できますが、これは「セルごとの排他ロック」ではありません。同じセルを別々の人がほぼ同時に触れば、後から確定した入力が残ります。隣の行を編集していたつもりが、画面スクロールのズレで別の行を上書きしてしまう事故も典型です。
さらに、同時アクセスには上限があります。Google公式では1つのファイルを同時に閲覧・編集・コメントできるのは最大100人までとされ、100人を超えると編集できるのはオーナーと一部の編集者のみになります。大人数運用が前提なら、この上限自体が構造的な天井です。
原因2:行の挿入・削除で数式や参照が崩れる
「数式が壊れる」相談で最も多いのが、行挿入・削除による参照ズレです。通常のA1形式(例:=SUM(B2:B10))は相対参照のため、参照範囲の外側に行が挿入されると集計範囲が追従せず、新しい行が合計から漏れます。逆に範囲内の行を削除すると #REF! エラーになり、その瞬間に依存する全セルが連鎖して壊れます。
複数人運用ではこれが厄介です。Aさんが集計表を作り、Bさんが「ただ1行足しただけ」でも、Aさんの数式は静かにズレます。誰も悪くないのに数字が合わなくなる、という事故の正体はこれです。
原因3:権限の事故(誰でも編集できて壊れる)
共有相手のロールは「閲覧者」「閲覧者(コメント可)」「編集者」の3種類です。よくある事故は、手軽さを優先して「リンクを知っている全員」を編集者にしてしまうケース。これは、リンクが転送された誰もが全セルを書き換えられる状態を意味します。集計式が入ったセルまで素手で触れるため、壊れて当然の設計になっています。
原因4:人が増えるほど崩れる「閲覧と入力の未分離」
多くのシートは「入力する場所」と「集計・参照する場所」が同じ1枚に同居しています。少人数なら回りますが、人が増えると入力者が集計セルや見出し行まで触れてしまう確率が上がります。1人あたりの事故率が同じでも、人数が増えれば全体の事故は確実に増える。これが「人が増えるほど崩れる」構造的な理由です。
スプレッドシートの同時編集で特に注意したい3つの点(競合・履歴・権限)
複数人での同時編集を始める前に押さえておきたい注意点は、「競合」「変更履歴」「権限」の3つに整理できます。仕組みを知っておくだけで、事故の発生率も、壊れたときの復旧速度も大きく変わります。応急策の設定に入る前の前提知識として確認しておいてください。
注意点1:同時編集の競合は「最後の確定が勝つ」(セル単位のロックはない)
Googleスプレッドシートの同時編集は、セルごとに排他ロックがかかるわけではありません。同じセルをほぼ同時に別々の人が編集すると、最後に確定した入力だけが残り、先に入れた値は警告なく上書きされます。上書きされた側は「入力したはずの値が消えた」としか気づけず、原因の特定に時間がかかります。とくにオフラインで編集した内容が後からオンライン同期されると、その間に他の人が入れた値と競合し、意図せず古い値で塗り替わることがあります。対策の基本は同じ範囲を複数人が同時に触らない運用(担当行・担当列を分ける)ですが、人数が増えるほどこのルールは緩みます。競合そのものを起こさせたくないなら、入力を1件ずつ送信する形(フォーム化)に寄せるのが確実です。
注意点2:変更履歴は「誰が・どこを」の証跡になるが過信しない
[ファイル]→[変更履歴]→[変更履歴を表示]から、いつ・誰が・どのセルを変えたかを版単位でたどり、以前の状態に復元できます。同時編集で「誰が壊したか」を追える頼りなので、重要なシートでは復元手順を全員が知っている状態にしておきます。ただし過信は禁物です。編集者は版に名前を付けて整理できますが、大量の編集が入ると細かい単位の履歴は自動でまとめられ、狙った一手まで戻せなくなることがあります。監査や復元が業務上重要なら、履歴任せにせず、いつ・誰が・何を入れたかがレコードとして残る仕組みに責務を移すのが安全です。表をまたいだ二重入力や転記が絡んで履歴が追いにくくなっている場合は、Excelの二重入力をなくして転記の重複・不整合を一元化する考え方も合わせて見直すと、そもそも同じ値を何か所も編集する状況自体を減らせます。
注意点3:共有ロールと共有範囲は「編集できる人を最小に」
共有相手のロールは閲覧者/閲覧者(コメント可)/編集者の3つで、同時編集の事故の多くは編集者を配りすぎたことが原因です。「リンクを知っている全員を編集者」は避け、編集が本当に必要な人だけを個別招待にします。さらに、閲覧者・コメント者によるダウンロードや再共有を制限する共有設定を併用すると、シートの持ち出しや無断コピーからの派生事故も抑えられます。運用ルールと権限設計だけで同時編集の事故を抑え続けるのは、人数が増えるほど負担が大きくなります。シート全体の管理がそろそろ限界だと感じたら、スプレッドシート管理が限界に来たサインとアプリ化の判断基準の観点で、応急策で粘るか仕組みごと変えるかを切り分けてください。
同時編集を始める前に決めておく運用ルール(注意点チェックリスト)
仕組みを理解したら、次はチームで先に決めておくことです。事故の多くは機能の問題ではなく、決めていなかったことから起きます。人数が5人を超えたあたりから、下のチェックリストを一度そろえておくと復旧に追われる時間が減ります。
決めておくこと | 決めないとどうなるか | 具体的な決め方 |
|---|---|---|
誰が編集者か | 「リンクを知っている全員が編集者」になり、誤操作の母数が最大化する | 編集が業務上必要な人だけ個別招待。それ以外は閲覧者 |
誰がどの範囲を触るか | 同じセルを同時に触り、後から確定した値が黙って上書きする | 担当行・担当列を分ける。分けられないならフォーム入力に寄せる |
行や列を増やしてよいか | 行挿入・削除で他シートの参照がずれ、集計だけ静かに狂う | 構造変更は担当者1名に限定し、変更前に版に名前を付ける |
絞り込みの仕方 | 通常のフィルタは全員の画面に反映され、他の人の作業を止める | 各自は「フィルタ表示」を使う(自分だけに適用される) |
壊れたときの戻し方 | 誰も復元手順を知らず、気づいた人が手で打ち直す | 変更履歴からの復元手順を全員に共有し、節目で版に名前を付ける |
締めのタイミング | 集計中に入力が入り、出した数字と後の数字が合わない | 締め時刻を決め、締め後は入力範囲を保護して読み取り専用にする |
人数が増えたときに追加で効く3つの注意点
関わる人数が二桁になると、5人までのやり方がそのままでは通用しなくなります。実務で効くのは次の3つです。
- 同時に開ける人数には上限がある:Googleのヘルプでは、ドキュメント・スプレッドシート・スライドを同時に閲覧・編集・コメントできるのは最大100人とされ、それを超えるとオーナーと一部の編集権限を持つ人しか編集できなくなります。1ファイルを共有できるメールアドレスは最大600件です。全社に配る前提の表は、この上限を最初から織り込んで設計します(Google ドライブ ヘルプ)
- 絞り込みは「フィルタ表示」に統一する:通常のフィルタは共同編集者全員の画面に反映されます。自分だけに適用したいときはフィルタ表示を使います。症状と直し方は自分の絞り込みが他の人の画面まで変えてしまう時の対処にまとめました
- オフライン編集の扱いを決める:オフラインで編集した内容は後からまとめて同期されるため、その間に他の人が入れた値と競合します。外出先で触る担当がいるなら、オフライン編集を使う範囲を限定するか、入力をフォーム経由に寄せておくのが安全です
ここまでの注意点は、いずれも「人が表を直接触る」前提が残っている限り、運用ルールで抑え込み続けるしかないという共通点があります。人数と項目が増えるほどルールの維持コストは上がるので、どこかで仕組み側に責務を移す判断が必要になります。
同時編集で見落とされやすい注意点(入力が消える・シートごとの権限・オフライン)
ここまでのルールを決めても、実際の現場で問い合わせが多いのは次の3つです。いずれも「操作を間違えた」のではなく、仕様を知らないまま使っていることが原因で起きます。
注意点:入力が消えるのは「上書き」だけではない(3つのパターン)
「さっき入れた数字が消えている」という相談の中身は、実は3通りに分かれます。原因が違うので、対処も戻し方も変わります。
- 同じセルをほぼ同時に確定した:セル単位のロックは無いため、あとから確定した入力だけが残り、先に入れた値は警告なく置き換わります。担当する行・列を分けるのが基本の対策です。
- 他の人が行を挿入・削除・並べ替えしている最中に入力した:自分の画面で見えていた行の位置がずれ、意図した行とは別の行に値が入ります。値そのものは消えていないのに、探しても見つからないので「消えた」と感じるのはこのパターンです。
- 通信が切れたまま編集していた:同期されないまま入力が積み上がり、復帰時に破棄されることがあります。この場合は「変更内容を同期できません」を直す7手順のとおり、タブを閉じる前に画面に残っている入力を控えるのが先決です。
戻すときは、セルを右クリックして「編集履歴を表示」を選ぶと、そのセルが誰にいつ変えられたかを1セル単位で確認できます。ファイル全体を戻す前に、まずここで犯人の当たりを付けるほうが速いです。
ただしGoogleの公式ヘルプは、一部の変更は編集履歴に表示されない場合があると明記しており、その例として行または列の追加・削除、セルの形式の変更、数式による変更を挙げています(ファイルの変更内容を確認する|Google公式ヘルプ)。つまり、上の2番目のパターン——行の挿入・削除で値がずれた事故は、履歴で追いきれないことがあるということです。「あとで履歴を見れば分かる」を前提に運用を組むと、いちばん困る事故で証跡が残りません。
注意点:シートごとに編集権限を分けられる範囲と、分けられない部分
「1つのファイルの中で、営業チームにはA表だけ、経理にはB表だけ触らせたい」という要望はよくあります。結論から言うと、編集は分けられますが、閲覧は分けられません。
編集を分けるには「データ」からシートと範囲を保護を開き、「この範囲を編集できるユーザーを制限する」を選びます。公式ヘルプによると、ここでは「自分のみ」「ドメインのみ」「カスタム」から指定でき、シート全体を保護しつつ「特定のセルを除く」で入力欄だけ開けておくこともできます(シートを保護する、非表示にする、編集する|Google公式ヘルプ)。
分けられないのは次の2点です。ここを誤解したまま「権限を分けた」と思っている運用が、いちばん危険です。
- 保護は編集者なら解除できる:ファイルに編集権限がある人は、保護の設定そのものを外せます。保護は誤操作の防止であって、悪意やうっかりの越権を止める壁ではありません。
- シートを非表示にしても隠せない:公式ヘルプは「スプレッドシートの編集者は誰でも、これらのシートを再表示したり表示したりできます」と明記しています。単価や人件費を別シートに置いて非表示にする、という隠し方は成立しません。
本当に見せてはいけない列があるなら、ファイルそのものを分け、見せてよい列だけを別ファイルへ渡すしかありません。同じファイルの中で権限を細かく割ろうとした時点で、表計算ソフトの守備範囲を超えています。
注意点:オフラインとモバイルからの編集は、戻ったときに競合する
外出先のスマートフォンや、電波の弱い現場から入力する運用が混ざると、事故の質が変わります。オフラインで編集した内容は端末側に溜まり、オンラインに戻った瞬間にまとめて同期されます。その間に事務所側で同じ行が編集されていれば、当然ぶつかります。
やっかいなのは、ぶつかったことが入力した本人には見えない点です。本人の画面では自分が入れた値が表示され続けるため、消えたことに気づくのは月末の集計が合わないときになります。現場入力が混ざる運用では、そもそも同じ表を直接触らせない——入力はフォームなど1件ずつ送る形に寄せる——のが、ルールで縛るより確実です。
絞り込みの取り合いが同時に起きているなら、フィルタが他の人にも影響する時の対処もあわせて直しておくと、現場の混乱がひととおり収まります。
応急策:今すぐできる「壊れにくくする」5つの手順
アプリ化の前に、まず標準機能でできる対策を尽くします。順番に設定するだけで事故は大きく減ります。
手順1:集計セル・見出しを「シートと範囲を保護」でロックする
[データ]→[シートと範囲を保護]で、数式や見出しの入った範囲を保護します。編集権限を「自分のみ」または「カスタム」に絞れば、入力担当者は集計式を触れなくなります。シート全体を保護して「特定のセルを除く」で入力欄だけ開放する設計が実務では使いやすいです。
注意点(正直なデメリット):保護には「警告を表示する」オプションもありますが、これは編集をブロックせず確認メッセージを出すだけです。本気で守るなら警告ではなく権限制限(自分のみ/カスタム)を選んでください。また保護はセキュリティ機能ではなく、編集権限を持つ人が保護自体を解除できる点も理解しておく必要があります。
手順2:入力規則(データの入力規則)で不正な値を弾く
入力欄には[データ]→[データの入力規則]でルールを設定します。プルダウン(リスト)にすれば表記ゆれ(「東京」「東京都」「トウキョウ」)が消え、日付・数値などの形式チェックで想定外の入力を減らせます。条件を満たさない入力は「拒否」に設定すれば、そもそも壊れる値を入れさせない運用にできます。
手順3:編集権限を最小化する(編集者を絞る)
「リンクを知っている全員・編集者」は原則やめます。本当に編集が必要な人だけを個別に編集者として招待し、それ以外は閲覧者にします。閲覧でよい人を編集者にしないだけで、誤操作の母数が一気に減ります。
手順4:「閲覧用」と「入力用」を物理的に分ける
集計・レポート用のシート(または別ファイル)と、入力専用のシートを分けます。入力用はプルダウン中心の最小構成にし、集計用は IMPORTRANGE やクエリで入力用を参照する一方向の流れにすると、入力側を触っても集計ロジックが壊れにくくなります。「触る場所」と「計算する場所」を分離するのが応急策の肝です。
手順5:変更履歴と通知で「誰が壊したか」を追える状態にする
事故ゼロは無理なので、戻せる体制を作ります。[ファイル]→[変更履歴]→[変更履歴を表示]で過去の版を確認・復元でき、編集者ごとに色分けで「誰が・どこを」変えたかを追えます。重要な範囲には保護の「警告表示」を併用し、運用ルールとして列の追加・削除は管理者に依頼と決めておくと、参照ズレ系の事故を未然に止められます。
壊れ方 | 応急策 | 残る限界 |
|---|---|---|
誤上書き・同時編集の取り違え | 入力用シート分離・編集者最小化 | 同一セルの競合は完全には防げない |
行挿入で数式・参照が崩れる | 集計セルの保護・列操作を管理者に限定 | 運用ルール頼みで属人化する |
権限事故(誰でも編集) | 編集者を個別招待に限定 | 編集者なら保護も解除できる |
表記ゆれ・想定外の値 | 入力規則(拒否設定) | セル単位の制御が限界 |
応急策の限界:どこまでいっても「人が手で表を触る」前提が残る
上記の応急策は有効ですが、本質的な限界があります。スプレッドシートは「自由に編集できる表」であることが価値であり、同時に弱点でもあります。保護をかけても編集者なら解除でき、入力規則はセル単位の制御が中心で、行・列構造そのものの破壊は止めきれません。
そして最大の問題は属人化です。「この列は触らない」「追加は管理者に頼む」といったルールは、人が増え・入れ替わるほど守られなくなります。運用でカバーするほど、結局は誰か一人がメンテナンスを背負う構造になりがちです。シート全体の管理が限界に来ているサインについては、スプレッドシート管理の限界とアプリ化も参考になります。
根本解決:フォーム入力+データベースで「壊れない仕組み」にする
人が増えても壊れない状態にするなら、発想を変えます。「みんなで1枚の表を直接いじる」から「決まった入力フォームから入れて、データはデータベースに溜める」へ移すのが根本解決です。
この形にすると、構造的に壊れにくくなります。理由は明確です。
- 入力者は表本体を触らない:フォーム経由なので、集計式や見出し行を直接壊しようがありません。
- 参照ズレが起きない:データはレコード(行)単位で追加されるため、「行挿入で数式がズレる」という事故が原理的に発生しません。
- 権限が項目単位で設計できる:誰がどの項目を入力・閲覧できるかを、シートのセル保護より細かく制御できます。
- 同時入力に強い:各自が自分の入力を送信する形なので、同一セルの取り合いが起きません。
正直なデメリットも書きます。フォーム+DB化は初期の設計・構築コストがかかり(費用感の目安は脱エクセル・業務システム化の費用相場で解説しています)、その場でセルを書き換えるような自由な即時編集はしにくくなります。少人数・短期・形が固まっていない用途なら、無理にアプリ化せずスプレッドシートの応急策で十分なこともあります。「壊れたら困る」「人が増える」「長く使う」業務こそアプリ化の費用対効果が出ます。
今の運用を活かしてアプリ化する
Mihataでは、複数人運用で壊れてしまうスプレッドシートを、入力フォーム+データベース(アプリ)へ受託でアプリ化しています(スプレッドシートを社内管理アプリにする「スプシ de 社内アプリ」にサービス内容と管理画面のサンプルをまとめています)。ゼロから業務を作り変えるのではなく、今あるスプレッドシートの項目や運用フローを活かしたまま、壊れない仕組みに置き換えるのが基本方針です。まずは「どこが壊れているか」「アプリ化すべきか応急策で足りるか」の切り分けからご相談いただけます。
アプリ化で「同時編集の事故」を断つ実務ステップ
ここからは、実際に壊れているスプレッドシートを「同時編集で事故らない形」に移すときの手順を、Mihataが受託でアプリ化するときの流れに沿って具体化します。いきなり全部を作り替えるのではなく、事故が起きている入力から順に表本体から切り離していくのがコツです。
ステップ1:壊れている入力を「フォーム化」して表本体から切り離す
まず、複数人が直接触っている入力欄を、フォーム(入力画面)に置き換えます。入力者は表本体のセルを一切触らず、決められた項目を送信するだけになるため、集計式の誤上書きも、スクロールのズレによる別行への打ち間違いも構造的に起きなくなります。プルダウンや必須・形式チェックをフォーム側に持たせれば、応急策のときにセルごとにかけていた入力規則を、入力の入口でまとめて担保できます。受注情報の入力もこの形に寄せれば、複数人が同時に受発注を書き込んでも取りこぼしが起きにくくなります。具体的なやり方はAIで受注管理表を作る方法で解説しています。
ステップ2:データを「レコード追加型」に変えて参照ズレを消す
フォームから送られたデータは、1件=1行のレコードとしてデータベースに追記されます。人が表の途中に行を挿入することがなくなるため、「行を足したら数式がズレた」「削除したら #REF! で連鎖して壊れた」という事故が原理的に発生しません。件数が増え続ける業務ほど効果が大きく、たとえばスプレッドシートの在庫管理をアプリ化するケースでは、複数人が同時に入出庫を追記してもセルの取り合いになりません。こうして入出庫が正確に蓄積されると、その先の発注点をAIで予測する取り組みもしやすくなります。AI在庫発注予測で欠品と過剰在庫を防ぐ方法で解説しています。
ステップ3:権限を「誰が・どの項目を」単位でロックする
応急策で最後まで残る穴は、「編集者なら保護そのものを解除できる」という点でした。アプリ化すると、閲覧・入力・編集・削除といった操作単位、さらに項目(列)単位で、利用者ごとに権限を設計できます。集計ロジックはそもそも利用者の画面に出さないため、「保護を解除されて壊される」という事故の入口自体がなくなります。誰がどこまで触れるかを、セル保護より一段細かく固定できるのがアプリ側の強みです。
ステップ4:集計と可視化を自動化して「手で触る集計表」をなくす
最後に、これまで手作業で更新していた集計表やレポートを、データベースからの自動集計・自動可視化に置き換えます。溜まったレコードから必要な数字がリアルタイムに表示されるため、「集計シートを誰かが触って壊す」余地そのものが消えます。スプレッドシートのまま集計を見せる方法はスプレッドシートでダッシュボードを無料で作る方法にまとめていますが、複数人で壊れる段階まで来ているなら、集計そのものをアプリ側へ寄せてしまう方が安定します。
この4ステップで、冒頭に挙げた4つの壊れ方(誤上書き・参照ズレ・権限事故・閲覧と入力の未分離)は、運用ルールで我慢するのではなく仕組みそのもので塞がれます。どこから着手すべきかは業務によって変わるので、まずは一番事故が多い入力ひとつをフォーム化するところから始めるのが現実的です。
複数人で開いている最中に「接続が不安定です」が出る場合は、権限や参照ズレではなく通信側の問題です。誰か1人だけに出ているのか全員に出ているのかで切り分けが変わるので、接続が不安定ですの原因を切り分ける表を使ってください。
「スプレッドシートが壊れた」ときの復旧手順
数式が消えた、数字が全部エラーになった、誰かが並べ替えて行がずれた——実際に壊れてしまった直後は、あわてて上書きを重ねるのがいちばん危険です。手を止めて、次の順番で戻します。
手順1:まず「これ以上触らない」状態にする
編集を続けると、後述の変更履歴が長くなり、どこまで戻せばよいか分からなくなります。関係者に一度手を止めてもらい、必要なら共有権限を一時的に閲覧のみに落とします。コピーを1部作ってから作業すると、復旧に失敗しても現状には戻れます。
手順2:変更履歴から壊れる直前の版に戻す
Googleスプレッドシートは「ファイル → 変更履歴 → 変更履歴を表示」で過去の状態を時系列で確認でき、任意の時点を復元できます。ポイントはいきなり復元せず、まず履歴上で内容を確認することです。壊れた時刻の直前の版を選び、消えた数式が生きているかを見てから復元します。復元しても、そのあとさらに別の版へ戻すことは可能です。
手順3:全部戻すか、一部だけ戻すかを決める
壊れた後にも正しい入力が入っている場合、全体を復元するとその入力まで消えます。この場合は、復元ではなく「履歴上の古い版をコピーとして開き、必要なシート・列だけを現行ファイルへ貼り戻す」ほうが安全です。数式列だけを戻す、というのが典型的な使い方です。
手順4:原因を特定して、同じ壊れ方を止める
復旧して終わりにすると、同じ事故が翌月また起きます。上の変更履歴には「誰が」「どのセルを」変えたかが残るので、犯人探しではなく壊れた経路の特定に使います。行の挿入で参照がずれたなら参照の書き方を直す、集計セルが上書きされたならシートの保護をかける、と原因ごとに手当てが違います。
そもそも戻せないケースもある
Excelファイルをやりとりしている場合や、共有ドライブから完全に削除された場合は、履歴が残っていないことがあります。「壊れたら戻せる」のはクラウド上で共有し続けている場合の話で、ローカル保存とメール添付の運用に戻ると、この安全網はなくなります。復旧のたびに半日が消えているなら、それは運用の限界を示す合図で、入力をフォームに切り出してデータ本体を人が触らない構造へ移すほうが、結果的に早く楽になります。
そもそも相手がファイルを開けないという段階でつまずいている場合は、共有リンクが開けないときの原因の切り分けを先に確認してください。共有範囲・ログイン中のアカウント・組織ポリシーのどれかに当たります。
複数人でシートを触ると壊れる問題は、そもそも人が手で打ち込む回数を減らすと軽くなります。注文メールからの転記を自動化する方法は受発注メールの転記自動化を参考にしてください。
個別のトラブルは、症状別に切り分けたほうが早く直ります。編集が保存されないときは「変更内容を同期できません」を直す7手順、共有したのに相手が開けない・編集できないときは「権限がありません」と出て共有できない時の対処、自分の絞り込みが他の人の画面まで変えてしまうときはフィルタが他の人にも影響する時の対処を参照してください。
同じ「複数人で使うと止まる」でも、Excelファイルを共有フォルダで回している場合は排他ロックが原因です。「他のユーザーが編集中」で開けないときの解除手順はエクセルが他の人が編集中で開けない時の対処を参照してください。
複数人で使う表では、壊れ方が「機能単位」で出ることもあります。担当者のチェックが集計に乗らないならチェックボックスが反映されない原因と対処、追加した行が月次集計に入らないならピボットテーブルが更新されない原因を確認してください。
よくある質問
シートを保護すれば誰も壊せなくなりますか?
いいえ。保護は入力担当者の誤操作を防ぐのには有効ですが、編集権限を持つ人は保護自体を解除できます。また「警告を表示」オプションは編集をブロックせず確認を出すだけです。完全な保護にはなりません。
同時に編集できる人数に上限はありますか?
あります。Googleのヘルプでは、1つのファイルを同時に閲覧・編集・コメントできるのは最大100人までとされ、100人を超えると編集できるのはオーナーと一部の編集者のみになります。1ファイルを共有できるメールアドレスは最大600件です。
行を足しただけで数字が合わなくなるのはなぜですか?
相対参照(A1形式)の数式は、参照範囲の外に行が挿入されても自動では範囲を広げないためです。集計セルを保護し、行・列の追加は管理者に限定するか、レコード追加型のデータベースに移すと根本的に解消します。
同時編集で他の人の入力が消えるのを防ぐにはどうすればよいですか?
同じセルをほぼ同時に編集すると、最後に確定した入力だけが残り、先に入れた値は警告なく上書きされます。担当行・担当列を分けて同じ範囲を複数人が触らない運用にするのが基本で、人数が増えて守れなくなったら入力を1件ずつ送信するフォーム形式に寄せるのが確実です。
自分の絞り込みが他の人の画面まで変わってしまいます。
通常のフィルタは共同編集者全員の画面に反映される仕様です。自分だけに適用したい場合は「フィルタ表示」を使ってください。複数人で使うシートでは、絞り込みはフィルタ表示に統一しておくと作業の取り合いが起きません。