こんにちは、大平です。
「顧客リストの最新版って、どれでしたっけ」。 スタートアップの現場で、この一言を聞いたことがない人はほとんどいないと思います。
笑い話で済んでいるうちはいいのですが、僕が技術顧問や開発支援で相談を受けていると、この手の「ヒヤリ」が数ヶ月後に本物の事故になったケースを何度も見てきました。
先に結論を言います。 データ管理の問題は、 ヒヤリハットの段階で直すのが一番安いです。
事故になってからの対応費用と信頼の毀損は、桁が2つ変わります。 この記事では、スタートアップで特によく見る4つのパターンと、どの順番で直すべきかを書きます。
ヒヤリハットは「事故の予告編」である
労働安全の世界には、1件の重大事故の背後に29件の軽微な事故があり、その背後に300件のヒヤリハットがあるという「ハインリッヒの法則」があります。 データ管理もまったく同じ構造です。
「あのメール、解約済みの会社にも送っちゃってました」「今の DELETE 文、WHERE 付け忘れるところでした」。 この種の小さなヒヤリは、重大事故と同じ原因から生まれています。
つまりヒヤリハットが観測できている時点で、事故の条件はすでに揃っています。
一方で、スタートアップがデータ管理を後回しにすること自体は、責められる話ではありません。 プロダクトが当たるかどうかわからない段階で、データ基盤に投資するのは合理的ではないからです。
問題は「後回しにしたこと」ではなく、 事業が立ち上がったあとも創業期の運用のまま走り続けることにあります。 切り替えのタイミングを逃した会社から順に、ヒヤリが事故に変わっていきます。
パターン1：顧客リストが3つあって、どれが正かわからない
営業はスプレッドシート、カスタマーサクセスは Notion、プロダクトは本番データベース。 三者がそれぞれ「自分の顧客リスト」を持っていて、微妙に食い違っている。 これが一番よく見るパターンです。
ヒヤリとする瞬間は、たとえば解約済みの企業にアップセルの案内を送ってしまったとき。 あるいは投資家向け資料の顧客数と、管理画面の数字が合わないことに提出直前で気づいたときです。
原因は誰かの怠慢ではなく、「どれが正か」を決めていないことにあります。 信頼できる唯一の情報源、いわゆる SSOT（Single Source of Truth）を1箇所決めて、他はそこから写す運用に変えるだけで、この問題の大半は消えます。
逆にここを放置したまま事業が伸びると、経営会議の数字が毎回食い違い、 意思決定そのものがずれたデータの上で行われるようになります。
数字が合わない会社は、外からの見え方も悪くなります。 資金調達のデューデリジェンスで顧客数や解約率の根拠を求められたとき、突き合わせに数週間溶かすのは典型的な失点です。
パターン2：「とりあえず動く」で作ったデータベースが、半年後に牙をむく
創業期のデータベース設計は、たいてい「とりあえず動く」で作られています。 それ自体はいいのです。
問題は、その場しのぎの判断が積み重なったまま、誰も棚卸しをしないことです。 よく見るのは、中身が何でも入る JSON カラムに重要データが押し込まれている、外部キー制約がなく孤児レコードが溜まっている、削除フラグの意味がテーブルごとに違う、そして本番データベースに手作業の SQL で直接変更が入っていて、マイグレーション履歴と実態が一致していない、という状態です。
この負債は、静かに開発速度を削ります。 新機能を作るたびに「このカラム、触っていいんだっけ」の調査から始まり、集計を出すたびに数字の検算が要る。
最近はもう1つ、見逃せない影響があります。 AI にコードを書かせる開発では、スキーマがそのままコンテキストになります。 構造が汚れたデータベースは、人間だけでなく AI の生産性も下げるのです。
全面リファクタリングは要りません。 まず「マイグレーションを通さない本番変更を禁止する」という運用のルール1本から始めるのが現実的です。
パターン3：全員が admin で、退職者のアカウントが生きている
権限管理は、スタートアップで一番「ヒヤリ」と「事故」の距離が近い領域です。 よく見るのは、本番環境の管理者権限を全員が持っている、顧客情報入りのスプレッドシートが「リンクを知っている全員が閲覧可」で共有されている、業務委託の方の契約が終わったのにアカウントが残っている、という状態です。
ヒヤリとする瞬間は、退職した元メンバーの Slack アカウントがまだ顧客チャンネルにいると気づいたとき。 この時点では実害ゼロですが、個人情報の漏えいに変われば、対応費用・行政対応・顧客への通知と謝罪で、 事業計画に数ヶ月単位の悪影響をもたらします。
そして漏えいまで行かなくても、実害は先に来ます。 エンタープライズ企業との商談で出てくるセキュリティチェックシートです。
「退職者のアカウントは何営業日以内に削除されますか」に答えられない会社は、そこで商談が止まります。
直し方は地味で、admin を役割ごとの最小権限に分ける、退職・契約終了時のアカウント削除をオフボーディング手順に入れる、共有リンクを棚卸しする。 どれも今週から着手できる作業です。
パターン4：バックアップは「取っている」、でも一度も戻したことがない
「バックアップはクラウドの自動スナップショットがあるので大丈夫です」。 相談の場でこう聞いたとき、僕は必ず「最後にリストアの練習をしたのはいつですか」と聞き返します。
答えられた会社は、ほとんどありません。
バックアップの価値は、取った瞬間ではなく戻せた瞬間に初めて確定します。 戻す手順が文書化されておらず、戻す訓練をしたことがなく、戻すのにかかる時間を誰も知らないなら、それは「バックアップがある」のではなく「バックアップがあると信じている」だけです。
事故は、誤った DELETE 文や、条件を間違えたマイグレーション、あるいはたった1人しか触れない本番環境でのオペミスから起きます。 そのとき問われるのは「データはあるか」ではなく「何時間で戻せるか」です。
復旧に3日かかれば、その3日間サービスは止まり、顧客への説明はすべて経営者の仕事になります。
やることはシンプルで、ステージング環境に本番バックアップを戻してみる訓練を、四半期に一度やる。 初回は半日かかりますが、この半日が事業継続の保険になります。
どの順番で直すか：取り返しがつかない順
4つ全部を同時に直す必要はありません。 優先順位は「事故になったときに取り返しがつかない順」で決めるべきです。
僕の推奨は、①権限管理、②バックアップの復旧検証、③SSOT の設定、④スキーマ負債の返済、の順番です。
前の2つを先にするのは、漏えいとデータ消失が非可逆な事故だからです。 顧客の信頼とデータは、失ったら戻りません。
しかも直すのに必要なのは技術投資ではなく、棚卸しと手順書という運用の整備です。
後の2つは、事業を殺しはしないが確実に速度を削る負債で、こちらは仕組みづくりに多少の時間がかかります。
まず今週、非可逆リスクの2つに蓋をして、その上で SSOT とスキーマに計画的に取り組む。 この順番なら、経営としての説明もつきます。
まとめ
- ヒヤリハットが見えた時点で、事故の条件は揃っている：笑い話のうちに直すのが一番安い
- 4つのパターンには共通の型がある：SSOT 不在、スキーマ負債、権限の空白、未検証バックアップ
- 直す順番は取り返しがつかない順：権限とバックアップが先、SSOT とスキーマは計画的に
- 必要なのは大規模投資ではなく運用の切り替え：創業期のやり方を卒業するタイミングの見極め
自社に当てはまるパターンが1つでもあったなら、それはまだヒヤリハットの段階だということです。 予告編のうちに手を打ちましょう。