「共有＝編集可」で荒れるスプレッドシート、今日から止める権限設計の基本
Googleスプレッドシートの共有運用で「列が勝手に増える」「フィルタが崩れる」といった”荒れ”が起きるのは、見る人と直す人の境界が曖昧だからです。 本記事では、ツールを乗り換えずに荒れを防ぐ方法として、ファイルを「マスタ（正本）」「閲覧用」「入力（受付）」の3つに分離する運用設計を解説します。編集権限は役職ではなく責任で決め、変更依頼はフォーム化して流れを一本化することで、現場の利便性とデータの安全性を両立できます。
スプレッドシート共有で必ず起きる「荒れ」の正体
「気づいたら列が増えている」「フィルタが外れて全員の画面がぐちゃぐちゃ」「誰かが上書きして履歴が追えない」──Googleスプレッドシートや共有ドキュメントで顧客管理・案件管理をしていると、こうした”荒れ”はほぼ必ず起きます。原因はシンプルで、見る人と直す人の境界が曖昧だからです。
本記事では、ツールを乗り換えずに、Googleスプレッドシート（やDrive上のファイル）で「共有できるのに荒れない」状態を作るための運用設計を、最小構成でまとめます。
なぜ「共有＝編集可」にすると必ず荒れるのか
編集権限を広く配ると、善意でも事故が起きます。荒らすつもりがなくても、日常業務の動きが「破壊的変更」を生むからです。
たとえば、営業担当が”見やすさ”のために列を並び替えると、他の人の参照式が壊れます。担当者がフィルタや並び替えをして、そのまま共有状態で保存されると全員が迷子になります。コピペで貼った値に余計な改行やスペースが混ざれば名寄せが崩れ、数式セルを上書きしてしまえば集計が死にます。
つまり、「編集できる人を増やすほど、壊れる確率が指数的に上がる」のが共有ファイル運用の宿命です。これは誰かが悪いわけではなく、構造の問題なのです。
ゴールは「見えるけど触れない」を当たり前にすること
荒れない運用の基本は、二層構造を作ることです。多くの人が見て判断するための閲覧層と、限られた人だけが変更責任を持って直す編集層。この二つを明確に分けます。
ここで重要なのは、「編集できないと仕事にならないのでは？」という反発を先回りして潰すことです。編集を止めるのではなく、編集の入口を”フォーム化・申請化・予約化”して、変更の流れを一本化します。現場は「書ける」体験を失わず、データは「壊れない」状態を保てる。この両立が設計のポイントです。
最小構成：荒れないための”3つのファイル分離”
いきなり大げさな仕組みは不要です。まずは、ファイルを3つに分けるだけで事故が激減します。
1. マスタ（正本）：編集者だけが触る
顧客マスタ、会社マスタ、案件の正本がここに当たります。編集権限を最小人数にし、ここを触る人は「変更責任者」という位置づけにします。ルールを理解し、例外時に判断でき、ミスしたときに戻せる人だけがアクセスする場所です。
2. 閲覧（配布用）：みんなが見る
現場が日々参照するのはここです。基本は閲覧のみの権限を付与します。必要な列だけに絞って読みやすくし、「見せるための形」に整えましょう。閲覧用は”見るためのプロダクト”と考えると、どこまで整備すべきかが見えてきます。
3. 入力（受付）：みんなが追加・依頼する
現場が情報を足したいときは、マスタに直接触らず、ここに入れてもらいます。Googleフォームでも、シートの入力タブでも構いません。「直したい」という要望をここに集約することで、編集の流れが一本化されます。
この3分離ができると、現場は「書ける」体験を失わず、データは「壊れない」状態になります。
編集権限の設計ルール：誰に、どこまで渡すか
編集者は”役職”ではなく”責任”で決める
よくある失敗が「管理職だから編集可」「全員が少しずつ直せる方が早い」という発想です。しかし編集権限は権威ではなく、変更の品質を担保する責任です。
編集者に求める最低条件は3つあります。変更ルール（命名・必須項目・名寄せ）を理解していること、例外が起きたときに判断できること、ミスしたときに戻せること（履歴・復旧手順を知っていること）です。この3つを満たす人を「編集者」として任命します。
編集範囲を”シート単位”ではなく”タブ・範囲単位”で絞る
「編集者が必要だから、ファイル全体を編集可」は強すぎます。Googleスプレッドシートは範囲保護ができるので、構造（列、ヘッダー、集計、数式）は触れないようにし、データ行の一部だけを触れるように設定します。それでも事故るなら入力は受付に寄せるという考え方で、編集の自由度は必要に応じて段階的に削っていくのが安全です。
閲覧者が困らないための「編集できない代替動線」
編集を絞ると必ず出る不満が「直したいのに直せない」です。ここで詰むと運用が形骸化します。対策は、“直したい”を吸い上げる入口を用意することです。
変更依頼のテンプレを用意する
入力（受付）に、最低限の項目を設けましょう。対象（会社名・担当者名・案件IDなど）、依頼内容（追加・修正・統合・削除）、理由（なぜ必要か、何が困っているか）、期限（いつまでに必要か）、依頼者（質問の戻し先）の5つがあれば回ります。
これを入れてもらえば、編集者は判断できます。逆に、これがないまま編集権限を渡すと、判断できない変更が混ざって壊れます。
“急ぎ”だけは別レーンにする
現場の反発は「緊急時に困る」なので、ここだけ逃げ道を作ります。今日中に直す必要がある変更はチャットで依頼（テンプレ必須）、翌営業日以降は受付へ（入力で残す）というルールにします。緊急レーンを作ることで、編集権限のばら撒きを防げます。
荒れないための「保護」と「監査」の最低ライン
運用はルールだけだと守られません。仕組みで守ります。
構造破壊を防ぐ：列・ヘッダー・数式は保護する
最初に壊れるのは、ほぼ数式セルです。集計列、ステータスの自動計算、重複チェックなどは、編集ミスの被害が大きいので「触れない領域」にします。Googleスプレッドシートの「シートと範囲を保護」機能を使えば、特定のセルや列を編集不可に設定できます。
編集の見える化：変更ログを残す
「誰が何を変えたか」が見えないと、編集者も怖くて権限を絞れません。最低限、変更依頼は入力（受付）に残し、編集者は「対応済み」「対応日」「対応者」を記録します。これだけで、トラブル時に原因が追えます。逆にログがない状態で編集権限だけ絞ると、現場の不満が溜まって抜け道が増えます。
つまずきポイントと、よくある失敗パターン
「閲覧だけ」なのに各自がコピーして”勝手版”が増える
閲覧専用にした結果、現場が自分用にコピーして管理し始めることがあります。これが起きると、結局「最新がどれか分からない」問題が再発します。
対策は、閲覧用を「使いやすい形」に整えることです。現場がコピーしたくなるのは、必要な列が足りない・見づらい・探せないからです。フィルタビューを活用したり、よく使う検索条件を事前に用意したりすることで、コピーする動機を減らせます。
受付が機能せず、依頼が口頭・チャットに散る
受付に入らないとログが残らず、編集者が疲弊します。受付が機能するかどうかは、入力の面倒さで決まります。
対策は、受付の項目を増やしすぎないこと。「必須は3つ、あとは任意」くらいから始め、回り始めたら少しずつ整備します。最初から完璧を目指すと、誰も使わない受付が出来上がります。
導入手順：明日から荒れを止める最短ステップ
Step1：編集者を2人決める（最低2人）
1人だと詰みます。休み・退職・多忙で止まります。「担当」と「副担当」を置きましょう。この2人が変更の品質を担保し、トラブル時に対応できる体制を作ります。
Step2：マスタを複製し、閲覧用を作る
閲覧用は列を減らし、フィルタビュー前提で見やすくします。閲覧用は”見るためのプロダクト”です。現場が「これだけ見れば分かる」状態を目指して整備します。
Step3：入力（受付）を用意する
フォームでも入力タブでも構いません。「直したい」をここに集めます。項目は最小限から始め、運用しながら調整していきます。
Step4：構造を保護し、編集範囲を絞る
壊れやすいところから保護します。全員編集可をやめるのは、最後でいいです。段階的に切り替えることで、現場の反発を抑えながら移行できます。
まとめ：権限分離は「運用コストを下げるため」にやる
共有権限と編集権限を分けるのは、管理を厳しくするためではありません。むしろ逆で、現場の混乱・手戻り・確認コストを減らし、仕事を前に進めるための設計です。
ポイントは、編集を奪うのではなく、編集の入口を整えて流れを一本化すること。「正本（編集者）」「閲覧（全員）」「受付（全員）」の三分離だけで、スプレッドシート運用の寿命は一気に延びます。
この権限分離とセットで「”最新がどれか分からない”問題を解決する運用ルール（命名・更新・履歴）」や、「”活動ログ”を残す最小実装（メール・予定・メモの統合）」まで整えると、顧客管理の再現性が一段上がります。まずは今日、編集者を2人決めるところから始めてみてください。