スプレッドシートをシステムに置き換える：社内管理画面が割に合うとき

要点

オーダーメイドの社内管理画面とは、自社の特定の業務のために作る小規模な Web システムで、データベース、個人ごとのログイン、システムが自動で適用するルールを備えたものです。共有スプレッドシートで複数の人が同じデータを編集するようになり、ミスが金銭的な損失につながる段階になったときに検討する価値があります。スプレッドシートは大きくなったから壊れるのではありません。壊れるのは4つのポイントです。同時編集、何も説明してくれない履歴、人を区別できない権限、そして入力時に誰も確認しない業務ルールです。オーダーメイドのシステム開発のハブページでは、この管理画面がほかのプロジェクトとの関係でどこに位置づけられるかを紹介しています。切り替えの基準は売上や従業員数ではありません。同じスプレッドシートに何人が書き込んでいるか、そして誤った値が後工程に流れたときにいくらかかるかです。以下では、それぞれの破綻ポイントの見分け方、切り替えの判断基準、管理画面を依頼する前に整理しておくべきことを説明します。

Excel の代わりになるシステムは？

どの会社でも Excel を置き換えられる、単一のソフトウェアがあるわけではありません。業務プロセスの場合、代わりになるのはたいてい、オーダーメイドの社内管理画面か、データベース、ユーザー管理、権限設定を備えた既製ツールです。どれを選ぶかは、適用すべきルール、すでに使っているシステム、そして各担当者が自分の役割に関係するデータだけを見る必要があるかどうかで決まります。

Excel は、分析、インポート、エクスポートのためのスプレッドシートとしては引き続き役に立ちます。正式なデータの出どころとして適さなくなるのは、同じレコードが営業、在庫、経理、出荷を経由するようになったときです。セルは業務全体を表していないからです。この段階では、システムが中心となるデータを保持し、無効な組み合わせを防ぎ、誰がどの変更をしたかを記録するべきです。

1. 共有スプレッドシートが破綻する4つのポイント

スプレッドシートは、一人で考えるための道具としては非常に優れています。問題が始まるのは、それが業務プロセス全体のシステムになり、異なる部署の人が一日中書き込むようになったときです。Googleスプレッドシートにも Excel にも、以下の問題それぞれに対応する機能はあります。足りないのは機能ではありません。その機能が必須になっていて、編集する人の善意に頼らないことです。

この表の各行が、以下のそれぞれのセクションになります。どのセクションでも問いは同じです。ルールが守られなかったとき、誰が、いつ気づくのか。

2. 同時編集：問題はファイルではなく操作

共同編集によって、昔の「ファイルが編集のためロックされています」という問題は解決しました。今では複数の人が同じスプレッドシートを開き、同時に入力できます。Excel の場合、Microsoft のドキュメントでは、ファイルを OneDrive または SharePoint Online に保存し、共同編集に対応したバージョンを使うことが条件とされています。Googleスプレッドシートでは、これが標準の動作です。

共同編集が解決しないのは、業務プロセスがひとつのセルで完結することはほとんどない、という点です。「注文をピッキングする」という作業は、ステータス、引当数量、出荷日、そして場合によっては別シートの在庫残高まで変更します。スプレッドシートは各セルを個別に同期します。その4つのセルがひとつの操作を構成していることを、スプレッドシートは知りません。

日々の業務ではこう現れる

• 在庫残高は数式が再計算されるまで更新されないため、2人が同じ商品の最後の1個を、それぞれ別の行で引き当ててしまう。
• 誰かが入力している最中に別の人がシート全体を並べ替え、入力した値が間違った行に入ってしまう。
• ある人がかけたフィルタが、別の人が確認中の行を隠してしまい、確認作業が「未処理なし」で終わってしまう。
• 列の最後までドラッグしてコピーした数式が、上からデータを貼り付けた人によって消される。

どのケースも、特定の誰かの不注意ではありません。トランザクションという概念を持たない構造に複数の人が書き込めば、予想どおりに起きる結果です。

データベースは何が違うのか

リレーショナルデータベースを使った管理画面では、「注文をピッキングする」はひとつのトランザクションです。すべての変更が反映されるか、何も反映されないかのどちらかです。2人が最後の1個を同時に引き当てようとすると、データベースは2つの試みを順番に処理し、2人目には、在庫が黙ってマイナスになる代わりに明確なエラーが返ります。並べ替えやフィルタは各自の画面上の操作になり、他の人のデータを変えることはありません。

3. 履歴：変わったとわかることと、理由がわかることは違う

Googleスプレッドシートの版の履歴では、以前の版と編集した人を確認でき、復元もできます。起きてしまった損害を元に戻すには良い機能です。しかし業務プロセスを回すうえでは、2つの限界があります。

1つ目は粒度です。ある版を復元すると、その後に起きたことがすべて取り消されます。他の人が正しく行った作業も含めてです。実際には誰も復元せず、誰かが手作業で版を見比べ、セルをひとつずつ修正することになります。

2つ目は文脈です。履歴には、セルが「未払い」から「支払済み」に変わったことは記録されます。しかし、どの注文について、どの証憑にもとづいて変更したのか、変更した人に入金を消し込む役割があったのかは記録されません。「誰がこれを承認したのか」と問われたとき、スプレッドシートが答えられるのは「誰が入力したか」だけです。

役に立つ履歴とは

役に立つ履歴は、誰も古い版を開かなくても4つの問いに答えられます。何が変わったか、どの値からどの値へ変わったか、誰が変えたか、そしてシステムのどの操作によるものか。これはデータベース上の監査テーブルになります。PostgreSQL の PL/pgSQL のドキュメント自体に、追加、更新、削除のたびにユーザーと日時を別テーブルに記録するトリガー関数の例が載っています。

CREATE TRIGGER auditar_pedidos
AFTER INSERT OR UPDATE OR DELETE ON pedidos
FOR EACH ROW EXECUTE FUNCTION registrar_auditoria();

スプレッドシートの履歴との違いは、記録が変更と同時に、同じ入口から生まれることです。システムを通じてデータを編集すれば、定義上、必ず痕跡が残ります。

4. 個人ごとの権限：セルを保護することはアクセス制御ではない

Googleスプレッドシートでは、シートや範囲を保護して編集できる人を選ぶことも、編集しようとした人に警告を表示するだけにすることもできます。Excel にはパスワード付きのシート保護があります。どちらも、誰かが誤って数式を消すのを防ぐには役立ちます。しかし、どちらも一人ひとりが見られる範囲を分けるために作られたものではありません。

Microsoft はドキュメントではっきり述べています。Excel のシート保護はセキュリティ機能ではなく、ロックされたセルの変更を防ぐだけのものです。Googleスプレッドシートでも、保護が制御するのは編集であり、ファイルにアクセスできる人はシートの内容を引き続き閲覧できます。

問題になる場面

• 営業担当は自分の注文だけ見られればよいのに、スプレッドシートはひとつしかなく、全員の歩合が見えてしまう。
• 経理は入金を消し込む必要があるが、同じスプレッドシートで在庫担当も「支払済み」欄を編集できてしまう。
• 外部の委託先が配送ステータスを更新する必要があり、そのために顧客データを含むファイル全体へのアクセス権を受け取っている。

3つ目のケースには法的な重みがあります。ブラジルの個人データ保護法 LGPD は第46条で、個人データを不正アクセスから守るための技術的および管理的な措置を求めています。1列を編集してもらうためにスプレッドシート全体を共有することを、適切な措置だと説明するのは困難です。

管理画面ならどう解決するか

管理画面では、権限は役割ごとに、必要なら行ごとに設定します。営業担当は自分の注文を見て、経理は支払欄だけを見て、委託先は自分に割り当てられた配送だけを見ます。PostgreSQL はこれをデータベース自体で Row Level Security（行レベルセキュリティ）として実現しており、ドキュメントでは、ポリシーが定義されていない場合の既定の動作を「a default-deny policy」と説明しています。つまりデータベースは既定で拒否し、明示的に許可されたものだけを通します。すべてを開放したうえで一部だけを守ろうとするスプレッドシートとは逆の発想です。

5. 入力時の業務ルール：警告するだけの入力規則

Googleスプレッドシートのデータの入力規則には、無効なデータに対して2つの選択肢があります。警告を表示するか、入力を拒否するかです。業務で使われている多くのスプレッドシートは警告に設定されています。どこかの時点で誰かが「このケースだけ通したい」となり、拒否が邪魔になったからです。そこから先、ルールはただの提案になります。

拒否に設定していても、入力規則が効くのはセル単位です。日付が日付であるか、値がリストに含まれているかは確認します。しかし、納品日が注文日より前であってはならないこと、一定の上限を超える値引きには承認が必要なこと、キャンセルされた注文には入金消込ができないことは知りません。こうしたルールは担当者の頭の中にあり、運がよければ誰も開かない文書に書かれています。

ルールを正しい場所に置く

管理画面では、業務ルールを2か所に置きます。入力する人を導くための画面と、どの経路で画面を通り抜けたものであっても拒否するためのデータベースです。経路とは、インポート、連携、手作業での修正などです。PostgreSQL のドキュメントは明快で、制約に違反する値を書き込もうとすると「an error is raised」と書かれています。

ALTER TABLE pedidos
  ADD CONSTRAINT entrega_depois_do_pedido
  CHECK (data_entrega >= data_pedido);

これで、ルールは誰かが覚えているかどうかに左右されなくなります。誤ったデータは入らず、エラーメッセージがその理由を示します。

6. 判断基準：何人が編集し、ミスにいくらかかるか

会話でいちばんよく出る基準は規模です。「会社が大きくなったらシステムを作ろう」というものです。規模は良い指標ではありません。大企業でも、経理責任者だけが編集するスプレッドシートなら問題なく機能します。小さな会社でも、営業、在庫、出荷、経理が編集する注文スプレッドシートがあれば、それはすでにボトルネックです。

判断により役立つのは、次の2つの変数です。

1. 同じデータに何人が書き込むか。 1人が編集して複数人が閲覧するのは、スプレッドシートの健全な使い方です。複数人が同じ行に書き込むところで、4つの破綻ポイントが一斉に現れます。
2. 誤った値が後工程に流れるといくらかかるか。 誰かがすぐに気づいてその場で直せるミスは安く済みます。誤った内容での請求、実在庫と合わない在庫数、入金消込の二重処理、顧客データの流出につながるミスは高くつき、しかも発覚が遅れがちです。

表の最後の行こそ、管理画面が投資を回収できるところです。誰かが数字で約束できる生産性向上のためではありません。そこで防いだミスの一つひとつに、会社自身が直接測れるコストがあるからです。取り消した請求書、手配し直した配送、顧客への返金、確認作業にかかった時間などです。

スプレッドシートが限界に来ている7つのサイン

1. 非公式の役割が「スプレッドシートを直すこと」になっている人がいる。
2. 部署ごとにスプレッドシートのコピーがあり、会議がコピー同士の突き合わせに使われている。
3. 誰かが「これを変えたのは誰か」と尋ね、その答えを出すために古い版を見比べたことがある。
4. スプレッドシートに「触らないで」という名前のシートがある。
5. 数式やフィルタを1つ変えると、全員の結果が変わってしまう。
6. 同じ注文を複数のファイルに入力しなければならない。
7. どの版が正式なデータなのか、誰も説明できない。

企業向けの社内システム：管理画面に入れるもの

「管理画面」は、グラフを並べたダッシュボードと混同されることがあります。ここでの意味は違います。業務そのものが行われる道具であり、グラフはその結果として出てくるものです。よくできたオーダーメイドの社内管理画面には、少なくとも次のものがあります。

• リレーショナルデータベース：業務ルールを制約として持たせ、画面からでも、インポートからでも、連携からでも、無効なデータをデータベースが拒否する。
• 個人ログインと役割（営業、在庫、経理、外部）：画面ごと、項目ごと、必要なら行ごとに権限を設定する。
• 自動の監査証跡：何が、何から何へ、誰によって、いつ変わったか。
• テーブル単位ではなくタスク単位の画面：「注文のピッキング」「入金消込」「返品の登録」など、それぞれがそのタスクに必要な部分だけを変更する。
• スプレッドシートへのインポートとエクスポート：スプレッドシートは単発の分析には今でも最適だからです。違いは、スプレッドシートがデータの出どころではなく出力先になることです。

費用と期間は開発範囲によって決まり、特に他システムとの連携、権限の細かさ、監査の要件が大きく影響します。管理画面が公開サイトのフロントエンドにもデータを供給する場合は、ヘッドレス WordPressの記事が、業務と表示を切り分ける参考になります。

スプレッドシートをシステムに置き換える費用は？

業務を知らないまま、責任をもって価格を示すことはできません。開発範囲を大きく変えるのは、画面の数よりも、連携、権限、監査、データ移行です。記事「オーダーメイドの Web システム開発にかかる費用」では、見積もりを約束に変えてしまうことなく、提案内容と運用コストを比較する方法を詳しく解説しています。

8. 管理画面を依頼する前に業務を整理する

誠実な見積もりにとっていちばん役に立つ材料は、今のスプレッドシートと、その周りの業務を説明したものです。開発者と話す前に、次のことを書き出しておくとよいでしょう。

• 誰が何を編集するか。 人または役割の一覧と、それぞれが日常的に変更する列。
• 今は頭の中にしかないルール。「一定額を超える値引きには承認が必要」「キャンセルされた注文は消し込めない」「支払済みにできるのは経理だけ」など。
• すでに起きたミス。 具体的な事例をいくつか、それぞれいくらかかったかとあわせて。どこでデータベース側のルールが必要かがわかります。
• スプレッドシートが何とつながっているか。 ERP、ネットショップ、銀行、メール、別のスプレッドシート。連携はひとつひとつが開発範囲になります。
• 編集はせず閲覧だけが必要な人。 経営陣、会計士、外部の委託先。

これが揃えば、最初のバージョンに欠かせないものと、後回しにできるものを分けられます。社内管理画面は、最初から業務全体をカバーする必要はありません。複数の人が書き込み、ミスが高くつく部分から始めるだけで、スプレッドシートを業務のクリティカルパスから外せます。

よくある質問

Apps Script やマクロを使って、スプレッドシートの中で解決できないのですか？

作業を自動化したり、一部のルールを強化したりはできます。ただし限界は変わりません。ファイルの編集権限を持つ人はセルを直接編集してルールを回避でき、スプレッドシートにはトランザクションも行単位の権限もないままです。スクリプトは、問題が繰り返し作業である場合には良い応急処置です。問題が、複数の人が同じデータに書き込み、ミスが高くつくことである場合には解決になりません。

ノーコードツールで同じ問題を解決できませんか？

多くの場合はできますし、オーダーメイドの管理画面の前に検討する価値があります。データベースを備えたノーコードツールには、個人ログインとある程度の権限管理がすでにあります。限界が出てくるのは、業務ルールがツールにとって特殊すぎる場合、権限を行単位まで細かくする必要がある場合、ツールが対応していない ERP やネットショップとの連携がある場合です。

チームはスプレッドシートの柔軟性を失いますか？

失うのは、誰にも知られずにプロセスを変えられる柔軟性です。それこそがミスを生む原因です。分析の柔軟性は残ります。管理画面はスプレッドシートにエクスポートでき、誰でも、今度は信頼できるデータをもとに好きなピボットテーブルを作れます。

管理画面は ERP の代わりになりますか？

それが目的ではありません。管理画面が担うのは、ERP がカバーしていない、あるいはうまくカバーできていないために、スプレッドシートに流れ着いた業務です。ERP がある場合、管理画面はマスタデータを二重に持つのではなく、連携によって ERP のデータを読み書きします。

まとめ

共有スプレッドシートがボトルネックになるのは、会社が大きくなったときではなく、複数の人が同じデータに書き込み、ミスが高くつくときです。症状は繰り返し現れます。上書きされる編集、何も説明しない履歴、人を区別しない権限、警告するだけのルールです。オーダーメイドの社内管理画面は、ルールを担当者の記憶ではなくデータベースに置くことで、この4つを解決します。もし当てはまるなら、oailton.dev/ja/contato から、今スプレッドシートで回している業務と、何人がそのスプレッドシートを編集しているかを送ってください。管理画面にすべきケースか、スプレッドシート自体の調整で足りるか、既製のツールで済むかをお伝えします。

オーダーメイドのシステム開発を、要件の洗い出しから保守までどう進めるかはシステムのページにまとめています。納品事例はポートフォリオでご覧いただけます。