24日間、誰も気づかなかったデータの空白。『動く』と『動き続ける』の違いを甘く見ると経営判断を間違える
前回の記事(「問い合わせの94%は、契約前に消えていた」)で、ファネルの中間が見えていない問題を書きました。今回はその続きで、可視化の前提となる計測基盤そのものに、どんな落とし穴があるかを書きます。
ファネル可視化に取り組み始めた経営者が、次に必ず直面するのが「データが信用できない」という問題です。ツールを導入して、ダッシュボードを作って、いざ毎月の経営会議で見ようとしたとき——「この数字、本当に正しいの?」という疑問が、現場のあちこちから上がってくる。
そしてその疑問は、ほぼ正しいんです。多くの場合、データの一部が気づかないうちに止まっていることがあります。
最近、自社の業務で実際にこの問題に遭遇しました。新しい仕組みに移行したのに、一部のデータパイプラインが24日間、誰にも気づかれずに止まっていたんです。気づいたきっかけは、ダッシュボードを作る過程で「直近月の数字が異常に少ない」と気づいたから。調べると、移行漏れという典型的な構造的問題が原因でした。
この記事では、その経験から見えた「動くと、動き続けるは違う」という原則と、中小企業の経営者が計測基盤の管理で押さえるべきポイントを整理します。
何が起きていたのか
まず、起きていた出来事をシンプルに説明します。
ある時、私の関わる業務で、データを動かす仕組みを新しいクラウドサービスに移行する作業が走りました。技術的な詳細は省きますが、要するに「これまでツールAでデータを取り込んでいたものを、より安定したツールBに切り替える」という典型的なシステム移行です。
移行作業自体は順調に進み、現場では「新しい仕組みでデータが入ってきている」ことが確認できていました。担当者も「移行完了」として、別のタスクに移っていきました。
ところが、それから24日後——可視化のためにデータを見直したとき、一部のテーブルだけ、24日前で時計が止まっていたことが発覚したんです。
具体的にはこういう構造でした。
- メインのデータ(顧客の問い合わせ情報)は、新しい仕組みに正しく移行されていた
- ところが、そのメインデータから派生して作られていた集計テーブル(成約集計用)は、移行作業の対象に含まれていなかった
- 派生テーブルを更新する仕組みは、旧ツールに組み込まれていて、移行で旧ツールが止まったら、派生テーブルも止まった
つまり、親(メインデータ)は新システムで動いているのに、子(派生テーブル)が孤児になっていた状態。経営会議で「成約数が伸びていない」と言われていた数字は、実は4月14日以降の成約が一切記録されていないだけの話だったんです。
なぜ24日間も気づかなかったのか
これだけ大事な数字が止まっていたのに、なぜ24日間も誰も気づかなかったのか。理由を分析すると、3つあります。
理由1: 「動いている」と「正しく動き続けている」を混同していた
移行作業の完了確認で行うのは、ほとんどが「動作確認」です。新しい仕組みでデータが流れ始めたか、エラーが出ていないか、件数は妥当か。これらは全て、「今この瞬間に動いているか」のチェックです。
でも、システムの本当の品質は「長期的に動き続けているか」で測られます。初日に動いていることと、3週間後も動いていることは、別の問題なんです。
今回の事例では、移行直後の動作確認では「動いている」と判定されました。なぜなら、その時点では旧システムが完全に停止しておらず、派生テーブルもまだ最後の更新が残っていたから。翌日、その次の日、と日が経つにつれて、徐々にデータが古くなっていったけれど、それを継続的に監視する仕組みがなかった。
理由2: 「派生データ」の存在が組織で把握されていなかった
これが構造的な問題です。データには、直接取り込んだ「生データ」と、それを元に作られた「派生データ」があります。
生データの管理は、誰でも意識します。問い合わせフォームの送信、広告データの取得など、入口に近い部分は誰もが目を向けやすい。
ところが、派生データは見過ごされがちです。「成約集計テーブル」「月次サマリー」「カテゴリ別ランキング」など、生データから後で計算して作るデータは、誰がいつ作ったか分からないまま、組織の中でひっそりと使われ続けることがあります。
そして移行のとき、派生データの作り手は、もう辞めているか、別の業務に移っていることが多い。引き継ぎリストに「派生データの管理」が乗っていないので、移行作業からも漏れる。気づいたときには、派生データが孤児になっている——これが典型的な構造です。
理由3: 「異常検知」の仕組みが無かった
3つ目は技術的な問題です。データが止まったとき、自動で警告が飛ぶ仕組みが無かった。
普通、健全なデータ運用では「直近24時間にデータが入ってきていない場合、アラートを出す」という監視を入れます。これがあれば、移行翌日に異常を検知できる。今回、この監視の対象に派生テーブルが含まれていなかったため、24日間誰にも気づかれずに止まっていました。
これも、ある意味では「派生データの存在が把握されていなかった」ことの裏返しです。監視対象に登録されていないものは、止まっても誰にも分からない。
「動く」と「動き続ける」の違い
この経験から、データ基盤の管理に関する重要な原則が見えました。
「動く」が指すもの
「動く」とは、今この瞬間、システムが期待通りに振る舞っている状態です。データが流れている、計算が実行されている、画面に表示されている。これは、システム導入時や移行時にチェックする項目です。
ただし「動く」ことの確認には、根本的な限界があります。それは、未来の保証にならないこと。今日動いているシステムが、明日も動いているかは別問題なんです。
「動き続ける」が指すもの
「動き続ける」とは、継続的に正常状態が維持されていることが、構造的に保証されている状態です。これは大きく違います。
具体的には:
- 異常があれば自動でアラートが飛ぶ仕組みがある
- 異常を放置しても、誰かが気づく仕掛けがある(月次会議のアジェンダに数字が乗っているなど)
- 派生システムも含めて、依存関係が文書化されている
- 担当者が変わっても、引き継ぎが回る
「動く」は一時点の状態、「動き続ける」は時間軸を含んだ運用設計の話です。
中小企業で起きがちな誤解
中小企業の現場で頻繁に見るのが、「動いたから完了」という認識です。新しいシステムを導入したら、テストして動作確認したら、それで完了。後は使い続けるだけ、という捉え方。
この認識のままだと、今回のような「サイレントに止まる」事故が必ず起きます。なぜなら、システムは生き物で、外部環境の変化(API仕様変更、認証期限切れ、サービスの仕様変更)で勝手に止まることがあるから。動かし続ける運用設計を意識的に作らないと、いつか必ず壊れる。
経営者として押さえるべき計測基盤の管理原則
ここまでの話を、中小企業経営者が今日から自社で使える原則として整理します。
原則1: データの「依存関係マップ」を可視化する
自社で使っているデータが、どこから来て、どう変換されて、最終的にどこに表示されているかを1枚の図にまとめる。これが第一歩です。
最初は不完全でも構いません。むしろ、不完全な図を作ろうとしてみると、「あれ、このデータの出所、誰も知らないぞ」という発見が必ず出ます。それが孤児データの候補です。
依存関係マップを作る作業自体が、組織の知識を顕在化する効果を持ちます。
原則2: 「派生データ」を意識的に減らす
派生データは便利ですが、メンテナンスコストの源泉でもあります。可能な限り、派生データは「元データから自動計算される仕組み」に置き換えるべきです。
具体例で言えば、「集計済みのテーブル」を別途作って保存するのではなく、必要な時に元データから直接集計する設計にする。こうすると、元データさえ動いていれば、派生データも自動的に最新の状態になります。孤児になり得ない構造です。
技術的には「VIEW」「マテリアライズドビュー」などの仕組みを使うのですが、概念だけ理解していれば実装は専門家に依頼できます。経営者としては、「派生データが孤児になり得ないか」を意識して設計を依頼することが重要です。
原則3: 「データ鮮度」を月次会議の固定アジェンダに入れる
月次会議で必ず「先月、各データソースの最終更新日はいつだったか」を確認するアジェンダを入れる。ダッシュボードに、各データの「最終更新日」を表示する場所を作っておくのも効果的です。
この習慣があると、データが止まっていても遅くとも1ヶ月以内には気づける。24日も気づかない事態は防げます。
これは前回シリーズの記事「能動ルール」で書いた、ルールを構造に組み込む発想そのものです。
原則4: 「動作確認」と「継続監視」を分けて発注する
外部の業者にシステム構築を依頼する場合、「動作確認まで」と「継続監視まで」は別の契約として明確に分ける。
多くの中小企業では、システム構築を依頼するとき、「動作確認まで」しか発注していないのが実態です。納品時のテストで動いていたから完了、後は自社で運用してください、という形。
これだと、サイレントに止まったときに誰も気づかない構造が出来上がります。継続監視を含めて発注するか、内部で監視の仕組みを作るか、どちらかは必須です。
原則5: 経営者が「データの全体像」を理解する努力をする
これが最も重要です。多くの中小企業経営者は、「データのことは技術担当者に任せている」という姿勢を取りがちです。でも、これがリスクの源です。
技術担当者は技術視点でデータを見ますが、「経営判断にとって重要なデータは何か」を判断するのは経営者の仕事です。経営者がデータの全体像を理解していないと、技術担当者が「移行作業」をしているとき、「派生データも含めて移行しているか?」という適切な質問ができません。
完全に理解する必要はありませんが、「自社の経営判断に使っているデータが、どこから来て、どう作られているか」を1枚の図で説明できる程度の理解は、これからの経営者の必須スキルです。
「動かす」より「動かし続ける」が10倍難しい
最後に、原則を超えた、経営者として持つべき認識を書きます。
データシステムを「動かす」のは、実はそれほど難しくありません。最近のクラウドサービスは充実していて、専門家に頼めば数日〜数週間で構築できます。
でも、それを「動かし続ける」のは、桁違いに難しい。なぜなら、動かし続けるためには:
- 環境変化に追従するメンテナンス
- 異常検知の仕組み
- 担当者交代時の引き継ぎ
- 関連データの整合性管理
- 派生データの孤児化防止
——これらすべてを、長期的に運用する組織能力が必要だからです。
中小企業の経営者が「データドリブン経営をやろう」と考えるとき、つい「ツールを入れること」が目的化しがちです。でも本当は、ツールを入れた翌月、翌年、3年後もデータが信用できる状態を維持できるかどうか、が勝負です。
そして、これを実現するためには、経営者自身がデータ基盤の管理に関心を持ち続けることが必要不可欠です。技術担当者が孤独に運用していると、ある日突然、組織の中でデータが孤児になります。経営者が定期的に「データは健全か」と問いかける文化だけが、サイレントな停止を防ぎます。
私自身、今回の経験で、データ基盤に対する見方が根本的に変わりました。「動いているはず」という思い込みが、最も危険です。「動き続けているか?」と問い続けることが、データドリブン経営の入口だと、痛感しました。
もし読者の方で、自社のデータ基盤について「最終更新日を即答できない」状態なら、それは黄色信号です。今週、技術担当者と一緒に、最低限の依存関係マップを作ってみることをおすすめします。