同一指標に3種類のアルゴリズム：口径辞書、バージョン凍結、データ取得監査の実施方法

経営会議で最も気まずい場面：営業は回収が入ったと言うのに、財務はまだ入っていないと言い、オペレーション部門が三つ目の表を取り出す——同じ指標に三種類の計算方法。皆が議論するのは業務ではなく、基準だ。レポートツールが高度になるほど、基準の分裂はより巧妙に隠される：一人ひとりが独自のSQLを持ち、その結果はどれも“筋が通る”ように見える。

まずは基準の辞書を整備してから、ダッシュボードの見栄えを語ろう

経営側におけるデータガバナンスの最小クローズドループは：

1. 指標定義：業務上の意味、分子・分母、時間粒度、通貨／税込、除外ルール
2. バージョンの凍結：基準の変更にはバージョン番号を付し、過去のレポートは再計算可能か「旧基準」と明記する
3. データ取得の入口：唯一認証による照会またはセマンティックレイヤーを利用し、業務データベースへの直接接続や散在化を禁止する
4. 監査：誰がいつどの基準で数値を算出したのか

辞書がなければ、ミドルプラットフォームはさらに大きなデータ沼へと変わってしまう。辞書があってもデータ取得の入口を強制しないなら、辞書は飾りにすぎない。

設計

業務オーナーが指標を定義し、データマネジャーが実現可能性を審査。アナリストは公開済みの指標のみ利用し、財務は法定基準に対して否決権を持つ。テーマドメイン（販売、在庫、資金）は別々に管理し、跨ドメインの指標は必ず既に公開された原子指標を参照しなければならない。

• 指標対象：コード、名称、基準文書、オーナー、ステータス
• 計算ロジック：SQL／セマンティック式、依存関係の血縁情報
• 公開バージョン：発効日、変更内容、互換性戦略
• 消費側：レポート、サブスクリプション、APIで、基準のバージョンを記録する

会議資料をエクスポートする際には、自動的に基準のバージョン番号と更新時刻を添えることで、スクリーンショットによる口伝を防ぐ。

比較：個人用SQL vs 基準プラットフォーム

導入と検証

まずは経営指標上位20項目を整備し、いきなり全社の指標ライブラリに手を出すべきではない。各指標には必ず業務オーナーの署名が必要だ。セマンティックレイヤーが稼働したら、業務データベースの読み取り専用アカウントを回収する（例外は承認を得て短期間の場合）。

検証：同一指標の二つのダッシュボードの数値が一致しているか、基準変更後に旧サブスクリプションが通知されるか、バージョン番号のないレポートを外部に送れるか（できないはず）、そしてレポートから元のテーブルまで血縁関係を追跡できるか。

データインテリジェンスの前提は、数字が説明可能であることだ。説明不能な精度は、ただ高価な言い争いにすぎない。

失敗パターン

指標の同名異義：コードは必ず一意で、名称には別名を許可する。アナリストがセマンティックレイヤーを迂回する：監査で直結が発覚すれば権限を回収する。基準変更時の無連絡：変更通知を消費側に伝え、並行期間を設ける。

四週間後に何を見るか

基準に関する論争の件数、重複指標の数、直結データベースアカウントの数、経営会議で“数値が合わない”と中断した回数。これら四つの項目が減少したら、AIによるデータ取得アシスタントを拡充する——ただしアシスタントも公開済みの指標のみ読み取り可能で、未整備のSQLを自由に生成することはできない。

指標の階層：原子、派生、テーマ

原子指標（例：注文行金額）を先に整備し、派生指標（粗利益、コンバージョン率）は依存関係を明示。テーマ指標はシーン向け（回収健全度）で、原子／派生の組み合わせによって作られる。テーマ指標が原子層を迂回して裸のSQLを直接書くことは禁止する。

同名指標の統合申請プロセス：コードは残し、別名を追加。廃止指標には退役期間を設定し、消費側が移行後はオフラインにする。血縁図は影響分析に活用され、原子指標を一つ変更すると、すべての派生やレポートを一覧できる。

対外規制用の基準と内部管理用の基準が併存する場合、ラベルで区別し、会議資料にはどちらを使用したかを明記して混用を防ぐ。

AIによるデータ取得の境界線

自然言語による質問は、すでに公開された指標と管理対象の次元のみを対象とする。モデルが生成したSQLが指標コードにマッピングされていない場合、デフォルトで実行を拒否する。質問ログは監査に組み込まれ、当時使用した基準のバージョンを容易に再現できる。

業務担当者に「質問術」を指導する：まず指標コードまたは標準名を述べ、次に時間と組織範囲を説明する。モデルに「利益」がどの種類かを推測させるよりも、こちらの方が安全だ。

データ品質ルールは指標に紐づけられる：空値率、変動閾値、照合差。品質に赤信号が点灯した場合、ダッシュボードは「不可用」と表示し、誤った数字を示すよりも責任ある対応をする。

組織の導入

指標委員会は大規模である必要はない：業務オーナー、データプラットフォーム、財務それぞれ一人いれば十分。論争の昇格ルートは制度に明記し、グループチャットでの永続的なもめ事を避ける。四半期ごとにゾンビ指標と重複ダッシュボードを整理する。

新しいダッシュボードの立案には必ず既存の指標コードを引用すること。新規指標はなぜ既存では足りないのかを説明する。これは事後整備よりもはるかに安価だ。

経営陣向け報告書には「基準脚注」を一ページ添える：今期使用した指標コードとバージョンを記載する。会議で数字を巡る議論がある際は、まず脚注を確認してから業務を議論し、無駄な表の切り替えを減らす。

レポートプラットフォームとの役割分担

レポートツールは表示と権限を担当し、指標プラットフォームは定義とバージョンを担当する。ダッシュボード作成者は指標コードを選択し、計算式をコピーしない。レポートが勝手に計算式を改変した場合、プラットフォームは警告を出して、経営会議の議題への掲載を阻止すべきだ。

指標変更通知のサブスクリプション：消費側（レポート、API、メール配信）は依存関係を登録し、基準アップデート時には自動的に変更説明と移行期限を送信する。

基準論争の終結方法

論争票の記録：提出者、現在使用中のアルゴリズム、要求されるアルゴリズム、業務シーン、影響を及ぼすレポートの一覧。委員会の裁定後はバージョン説明と発効日を記載し、裁定前は外部資料として旧版を凍結し、各自が勝手に書き込むことを禁止する。

財務の決算期には基準変更を一時的にロックし、次の開放窓まで順番待ちとなる。開放窓外の緊急修正には優先ルートを設け、全員に公告する。

ディーラーやフランチャイジー向けの指標は、独立した命名空間を設け、内部管理基準の漏洩や契約基準と誤解されるのを防ぐ。

データ取得監査の結果は内部監査に提出される：誰がいつどのバージョンの指標でどの表を計算したのか。行レベルの権限と連携し、基準は正しいがデータが越権しているのを防ぐ。

試行部門では、まず辞書とバージョンの凍結を確立し、その後全社に問数機能を展開する。全員が同時に問数機能を開始すると、口径の混乱がさらに拡大するだけである。

口径およびバージョン番号は会議録の添付ファイル名に明記し、事後の責任の擦り付け合いを減らす。