スプレッドシートがボトルネックになるとき:Excelから社内アプリへ

どの会社にも、「システムになるはずではなかった」スプレッドシートが少なくとも1つあります。最初はただのリストでした。やがて2枚目のタブが増え、マクロが追加され、「40行目は触らない」という意味の色分けルールが生まれます。5年後、そのファイルは生産計画を回し、請求を管理し、オンボーディング業務全体を支えています。

スプレッドシートがその役割を担うのは当然の成り行きです。まだ完全には理解していない業務をモデル化するには、最速の道具だからです。問題はチームがシートを使うことではありません。「モデル化の段階は終わり、シートはいつの間にかインフラになった」と判断する人が誰もいないことです。

スプレッドシートが「システム」になるまで

ライフサイクルは予測可能です。共有ファイルが実際の問題を解決するので、使う人が増えます。誰かが手作業を減らすためにLOOKUPやマクロを足します。隠し列、命名規則、「編集禁止」タブといった構造が積み上がります。最終的に、たいていは最初の作成者である1人だけが、全体の仕組みを理解している状態になります。

その人は今や、業務プロセスの単一障害点です。休暇中は変更が止まります。退職すれば、ファイルは「恐怖による読み取り専用」になります。全員が使うのに、誰も保守しない。しかもこの状況はどのリスク管理台帳にも載りません。公式には、そのスプレッドシートはシステムとして存在しないからです。

サインのチェックリスト

すべてのシートを移行する必要はありません。移行すべきは、次のサインが出ているシートです。

同時編集の競合。 2人がお互いの変更を上書きする。あるいは、誰かが必要なときに限ってファイルがロックされている。

バージョン名のファイル。 共有ドライブの `計画_最終_v3_本当.xlsx` は、バージョン履歴がシステムではなくファイル名の中にあることを意味します。

手作業のコピー&ペースト。 誰かがシートとERP、CRM、メールの間でデータを転記している。それも定期的に、業務の一部として。

誰も触れない数式。 元のロジックを編集するのが危険に感じられるため、古い列の隣に新しい列を足すことで変更している。

監査・権限の要件。 誰がいつ値を変更したかを知る必要がある。あるいは給与、利益率、顧客データの閲覧者を制限する必要がある。Excelはどちらも得意ではありません。

唯一の番人。 1人の不在が、プロセスそのものの変更を止めてしまう。

1つなら摩擦です。業務が依存するシートで2つ以上当てはまるなら、それは期限付きのボトルネックです。

シートに残すもの、アプリに移すもの

すべてを移行しようとするのは典型的なやり過ぎです。スプレッドシートはワークフローの置き場所としては不適切ですが、アドホック分析の道具としては今も最強です。

スプレッドシートに残すもの:

アドホック分析と単発の問い。 ピボットし、グラフ化し、答えを出し、捨てる。

What-ifモデル。 数式そのものが成果物である予算やシナリオ。

個人のメモ用シート。 どの業務も他の誰も依存していないもの。

社内アプリに移すもの:

状態を持つワークフロー。 行が「発注済 → 承認済 → 出荷済 → 入金済」のように段階を移動するすべて。

人から人への引き継ぎ。 行の担当者が変わるなら、必要なのはセルの色ではなく、割り当てと通知です。

検証ルール。 1つのセルの誤入力が後工程でお金を失わせるなら、入力時点でチェックすべきです。

ロールと権限。 人によって見られるもの・編集できるものが異なるべき場合。

境界線は簡単に言えます。シートが「問いに答える」ならそのまま残す。シートが「プロセスを回している」なら、プロセスを移す。

2〜4週間のスプリントの進め方

業務シート1つを社内アプリに変換するのは、範囲を明確に区切れるプロジェクトです。だからこそ、終わりの見えないプラットフォーム構築ではなく、固定スコープのスプリントとして実施します。有償PoCの構造がほぼそのまま当てはまります。

Week 1 — シートをソースコードとして読む。 すべての数式、マクロ、隠し列はビジネスルールを符号化しています。ファイルの保守者と一緒にそれらを文書化し、スコープを書面で確定します。どのタブをアプリにし、どれをExcelに残すか。

Week 2 — コアワークフローとデータ取り込み。 主要フローをカバーする動くアプリ(通常はReact + FastAPIまたはNodeバックエンド)を構築し、既存のスプレッドシートのデータを履歴ごと取り込みます。空のデータベースで稼働開始するのは、移行が失敗する典型パターンです。

Week 3 — 検証、ロール、エッジケース。 色分けルールと「触るな」の行を、明示的なルール、権限、状態に変換します。実ユーザーとの週次デモが、数式には書かれていなかったことを浮かび上がらせます。

Week 4 — 引き渡し。 ドキュメント、監査ログ、管理者アクセス、そして旧シートを読み取り専用に退役させる前の短い並行運用。

明確なワークフローが1つのシートなら2週間のQuick DX PoC($12,500-$18,000)に収まります。複数人のプロセスを外部連携込みで回しているシートなら4週間のMVP Automation Sprint($25,000-$35,000)です。詳細はパッケージページにあります。いずれの場合も、Week 1にシートを読み解いたシニアエンジニア本人がアプリを構築します。スプレッドシートの考古学は、営業、アナリスト、外注チームの間の引き継ぎでは生き残れません。

隠れた効果

チームが移行に投資する動機は、目に見える痛みの解消です。競合、コピー&ペースト、唯一の番人。しかし複利的な価値は、スプレッドシートには決してできなかったことから生まれることが多いのです。

入力時の検証。 誤った日付、重複ID、ありえない数量は、月末に発覚するのではなく、入力した瞬間に弾かれます。

デフォルトで残る履歴。 すべての変更に「誰が・何を・いつ」が記録されます。「この数字を変えたのは誰だ」という論争は単純に消滅します。

API。 データがAPIの背後に置かれた瞬間から、ERP、レポート層、次の自動化が直接読めるようになります。コピー&ペースト業務は速くなるのではなく、消えます。

ツールがプロセスを教える。 新入社員は、シートの番人による口伝の伝承会ではなく、画面そのものからワークフローを学びます。

どこから始めるか

それが1週間使えなかったらチームが回らなくなる——そんなスプレッドシートを1つ選んでください。上のチェックリストに照らします。2つ以上のサインが当てはまるなら、そのシートが週に何分の手作業コピー&ペーストを生んでいるかを測ってください。多くの場合、その数字だけでスプリントの投資が回収できるかどうかの結論が出ます。

その後の準備は、どのPoCでも同じです。責任者を決め、業務の流れを短く書き出し、実ファイルの安全なサンプルを用意する。「レガシーシステム」が.xlsxである場合でも、DX PoCチェックリストはほぼそのまま使えます。