ダッシュボードの要件定義で、ほぼ必ず入ってくる言葉があります。「リアルタイムで表示できること」。私たちはこの要件を見るたびに、一度立ち止まることをお勧めしています。
その数字、リアルタイムで見て、何をしますか
リアルタイム表示が本当に効くのは、見た瞬間に打てる手がある場合です。イベント当日の誘導員の再配置、混雑への即時対応——これらは本物のリアルタイム用途です。
一方、行政の意思決定の多くは週次・月次・年度のサイクルで動きます。空間の再配分、施策の効果検証、予算要求——これらに要るのは「今この瞬間の数字」ではなく、問いが立ったときに、過去に遡って正確に集計できることです。この2つはまったく別の要件で、値段も別物です。
リアルタイム要件のコスト
「リアルタイム」と書いた瞬間に、システムには常時稼働の処理基盤・監視・障害対応・回線が付いてきます。導入費だけでなく保守費が恒常的に膨らみ、しかもその機能は多くの場合、導入後ほとんど開かれません。
さらに見えにくいコストもあります。即時性を優先した数字は、検証や補正を通す時間がないため、確からしさの検査を通ったあとの数字と食い違うことがあります。ダッシュボードの速報値と報告書の確定値がずれる——この説明に使う労力も、リアルタイム要件の隠れたコストです。
要件の言葉を変えるだけで、調達は健全になります。「リアルタイムで表示できること」→「集計は日次で更新され、任意の期間・断面で遡って再集計できること」。ほとんどの行政の問いには、後者で足ります。
「速報値」と「確定値」を分ける
それでも速い数字が欲しい場面はあります。そのときは、速報値と確定値を最初から区別する設計にしてください。
- 速報値: 未検証であることを明示して早く出す(イベント運営など、即時対応の材料)
- 確定値: 補正と検証を通してから出す(報告書・審議会・効果検証の材料)
両者が同じ画面に同じ顔で並ぶと、必ず混同が起きます。ラベルと見た目で分ける——このブログで繰り返してきた「確からしさに段階があるなら、見た目にも段階を」の原則そのままです。
要件定義のチェックリスト
- リアルタイムで見た瞬間に打てる手が、業務として具体的にあるか(なければ日次で十分)
- 「遡って再集計できること」が要件に入っているか(こちらの方が使用頻度は高い)
- 速報値と確定値の区別が仕様にあるか
- リアルタイム機能の保守費が、5年総額で見積もられているか
おわりに
「リアルタイム」は響きの良い言葉で、デモ映えもします。しかし要件は響きではなく業務から導くもの。削った要件の分だけ、本当に使う機能(遡れる・監査できる・比較できる)に予算を回せます。私たちがリアルタイムを売りにしないのは、売れないからではなく、多くのお客様にとってそれが最適解ではないからです。