スプレッドシートについての、居心地の悪い真実
多くのチームが気づくのが遅すぎる、居心地の悪い真実があります。最初に助けてくれたスプレッドシートは、いずれ静かにコストを生み始めるということです。
私はAIを使った社内ツールを作ることを仕事にしています。つまり、スプレッドシートが人の役に立たなくなるその瞬間を、いつも最前列で見ているわけです。そしてそれは、劇的な爆発として起きることはほとんどありません。じわじわとした出血です。ここでセルが一つずれ、あそこで誤クリックが一回起き、壊れたデータが誰にも気づかれないまま、ずっと後になって問題を引き起こす。多くのチームから相談が来る頃には、被害はもう何か月も積み上がっています。
ですから、本当の問いに答えましょう。あなたのチームは、いつスプレッドシートをやめるべきなのか。「理屈のうえでシステムがあった方が快適なのはいつか」ではなく、スプレッドシートに留まることがいつから自分の足を引っ張り始めるのか、という問いです。
すでに限界を超えているサイン
私の経験では、危険信号は驚くほど同じ形で現れます。一つのファイルに複数人が入り、物事が壊れ始めた時点で、あなたはもうスプレッドシートを超えています。触ってはいけないセルを誰かが書き換える。データが上書きされる。そして決定的な証拠が、私が日常的に目にするバージョンの墓場です。Sales_Tracker_v1、Sales_Tracker_v2、Sales_Tracker_FINAL、Sales_Tracker_FINAL_actually。
このファイル名の並びに思わず顔をしかめたなら、答えはもう出ています。
このパターンがもっともはっきり出るのは、在庫を管理している、あるいは売上を記録している会社です。正直なところ、何かを売っているのなら、その売上を追いかける本物の仕組みがいずれ必要になります。スプレッドシートが特に厳しくなるのは、次の三つが同時に重なったときです。
- 複数人での共同作業 — 同じファイルを何人もが触る
- 本当の量 — 何千件もの記録が年々積み上がっていく
- 失うわけにいかない履歴データ
共同作業と量と履歴が一つのファイルに同居したとき、そのスプレッドシートは借り物の時間で動いています。
壊れるまで待たないこと
この件についての私のいちばん強い意見であり、もっと多くのチームに知ってほしいことがあります。大半のチームは、何かが壊れてから乗り換えます。それは間違いです。
災害を待ってしまうと——データが壊れ、売上が消え、顧客の前でミスが出てから動くと——必要なツールを混乱のただ中で作る羽目になります。火を消しながら、同時に消防署を建てているようなものです。乗り換える正しいタイミングは、混乱が起きる前です。まだすべてがそれなりに動いていて、冷静に考え、落ち着いて作れるうちに動くということです。
先手は毎回、後手に勝ちます。うまくいくチームは、スプレッドシートがまだ「面倒くさい」段階、致命的になる手前で動きます。
事例：Oscarの10年もののスプレッドシート
具体的な話にしましょう。ホンジュラスで事業を営むOscarと一緒に仕事をしました。彼は10年間、事業のすべてを一つのExcelファイルで回してきました。10年分の改良と回避策と、文書化されていない暗黙知が、たった一つのファイルに詰まっていたわけです。
そしてそれは機能していました——機能しなくなるまでは。事業が伸びるにつれ、スプレッドシートはついていけなくなりました。オペレーション全体をExcelで回すことは年々難しくなり、かつて成長を支えていたものが、今度は成長の天井になっていました。
彼のいちばんの不安は、費用でもデータでもありませんでした。本物のシステムを自分では作れないのではないか、ということでした。以前に開発者を雇ったことがあり、多くの人と同じように痛い目を見ていたのです。欲しかったものが作られないか、途中から要望に応えてもらえなくなるか。その経験から彼は、自社向けのシステムを持つということは、事業を理解していない誰かに主導権を渡すことだと思い込んでいました。
彼にとって意外だったのは、結局その製品をノーコードツールで自分自身で作り上げたことでした。行き詰まったときにはいつでも、私たちの人によるサポートが後ろに控えていました。壁にぶつかればメッセージをくれて、私たちが一緒に解きました。彼は主導権を手放しませんでした。自分のオペレーションについての知識も手元に残りました。壊れやすいスプレッドシートを、壊れにくい仕組みに置き換えただけです。
結果は？ 毎日2時間半が浮きました。 2時間30分が日々の作業から消えたのです。自分のオペレーションの実際の動き方に合わせて作られた仕組みに、スプレッドシートを置き換えただけで。これを1年分掛け算してみれば、そのスプレッドシートが本当はいくら払わせていたのかが見えてきます。
正しいやり方
Oscarの話に思い当たるところがあり、乗り換えを考えているなら、痛い目を見て学んだ助言が二つあります。
1. 小さく始める
いちばんよく見る失敗は、一度に作りすぎようとすることです。すべてを一つの巨大な万能システムで置き換えようとして、複雑さに溺れてしまう。やめましょう。
一つの本当の課題を解く、小さなシステムを一つ作ってください。複数の機能が必要なら、果てしない怪物を一体作るのではなく、小さなシステムを複数作る。モジュール型は一枚岩に勝ちます。特に始めたばかりのうちは。
2. とにかく試してみる
自社向けのシステムは高すぎる、作るのに時間がかかりすぎると思って迷っているなら、その計算はもう古くなっています。開発者との間でOscarを苦しめた壁は、ほぼ消えました。AgentUIのようなノーコードツールなら、座って午後のうちに本物のものを作れます。AI以前なら開発者と何週間もやり取りしていたような種類のものが、です。
事業をまるごと賭ける必要はありません。まず試して、自分に何が作れるかを見てみてください。
で——いつやめるべきか
スプレッドシートがあなたのために働かなくなる前に、スプレッドシートをやめてください。ファイルに複数人が入った瞬間、バージョンが増え始めた瞬間、売上や在庫のデータが誤クリック一回で吹き飛びそうに感じた瞬間——それが合図です。壊れた日ではありません。きしみを初めて感じた日です。
Oscarは10年待ちました。やめたその瞬間に、1日2時間半を取り戻しました。あなたはそこまで待つ必要はありません。
AgentUIを開いて、静かにあなたを苛立たせ続けてきた業務を一つ選び、今日の午後に作り直してください。小さく始め、主導権は手放さず、混乱に見つかる前に抜け出しましょう。