ダッシュボードは作った瞬間がゴールではありません。むしろ、指標の定義が曖昧なまま画面だけ先に作ると、「この売上、どの定義？」という問いが会議のたびに湧き、数字への信頼がゆっくり崩れていきます。順序が逆なのです。先に決めるべきは、どの指標を追うか(KPIツリー)、その指標は誰のものか(RACI)、そして定義をどこで一元管理するか。本稿では、営業の現場が動かす先行指標と経営が見る結果指標を切り分ける設計から、Snowflakeのセマンティックビューによる定義の一元化、AWS基盤でのアクセス統制までを、現場の実装目線でつなげて解説します。

01ダッシュボードを作る前に：指標定義の分裂という落とし穴

ダッシュボード案件でまず起きるのは、技術的な問題ではなく定義の問題です。営業部門の「売上」は受注ベース、経理の「売上」は計上ベース、経営会議の「売上」は内示込み——同じ言葉が三通りに散らばったまま、それぞれの部署が別々のクエリで別々の数字を出す。画面を先に作るほど、この分裂は固定化します。順番を逆にするのが鉄則です。KPIを構造化し(何を追うか)、各指標の責任者を決め(誰のものか)、定義を一箇所に集約し(どこが正か)、最後にダッシュボードとして実装する。ダッシュボードは設計の出力であって、設計そのものではありません。

現場のコツ：最初のスプリントではSQLを一行も書かず、KPI定義書を1枚にまとめて関係部署の合意を取ることに時間を使います。「売上＝どのテーブルの、どの状態の、いつ時点の値か」を言語化できない指標は、実装しても必ず揉めます。

02KPIツリー：先行指標(営業)と結果指標(経営)を構造化する

KPIツリーの本質は、経営が見る「結果指標(遅行指標)」を、現場が操作できる「先行指標」まで因果で分解することにあります。売上高や営業利益は結果です。経営層はそこを見ますが、直接ダイヤルを回せるわけではありません。回せるのは、商談数・商談化率・提案数・活動量といった手前の打ち手——すなわち営業KPIです。ツリーで因果を辿れるようにしておくと、「結果が悪い」で終わらず「どの先行指標がボトルネックか」まで一気に降りられます。営業KPIは打ち手、経営KPIはその積み上がりの成果、という役割分担を図で共有しておくことが、後のダッシュボード作り分けの土台になります。

▲ 結果指標＝経営KPI（社の成果・遅行） 経営KPI｜結果指標 売上高・営業利益 受注金額（結果） 受注件数 平均受注単価 商談化率 商談数・活動量 提案・見積数 値引率・単価維持 ▼ 先行指標＝営業KPI（現場が動かせる打ち手・先行）
図1：KPIツリー。経営が見る結果指標を、現場が操作できる先行指標へ分解する。営業KPIは打ち手、経営KPIはその積み上がりの成果。

03RACIで各指標のオーナーを決める

ツリーで指標を並べただけでは、運用に入ると必ず「誰も面倒を見ない指標」が生まれます。そこでRACI——Responsible(実行)、Accountable(最終責任・承認)、Consulted(相談)、Informed(報告)——を、指標ごとに割り当てます。ポイントは、Accountableは各指標に必ず一人だけ置くこと。売上・営業利益の最終責任は経営層、商談化率の最終責任は事業部長、といった具合に、「その数字が悪いとき責任を持って動く人」を一意に決めます。実行者(R)は多くの場合、指標を計算し配信するデータチームです。この割り当てを頭の中や口約束に留めず、後述する指標カタログとセマンティックビューの定義に紐づけて記録することで、「オーナー不在の指標」を構造的に無くせます。

指標 経営層 事業部長 営業マネージャ データチーム 売上高・営業利益 商談化率（先行） 受注予測・パイプライン データ鮮度SLA 指標定義の一元管理 A R C I I A R C I A C R I C I A・R I C C A・R A最終責任・定義承認 R実行 C相談 I報告 A・R＝定義と運用を同一チームが担う
図2：指標×役割のRACIマトリクス。Accountableは各行に一人だけ。データ鮮度SLAや指標定義そのものは、データチームが定義と運用を一体で担う。

04営業ダッシュボードと経営ダッシュボードの作り分け

KPIツリーとRACIが決まれば、ダッシュボードは自然と二系統に分かれます。営業ダッシュボードは、個人・案件・週の粒度で、更新頻度は日次から準リアルタイム寄り、目的は「次に何をすべきか」というアクション誘導です。停滞案件のアラート、活動量の消化率、商談化率のファネルなど、現場が今日動くための画面です。一方、経営ダッシュボードは、全社・事業部・月の粒度で、更新頻度は週次から月次、目的はトレンドと予実差異の把握です。重要なのは、両者を別々のクエリで作らないこと。粒度と頻度は違っても、参照する指標定義は同一でなければ、経営会議と営業会議で数字がずれます。同じ定義から異なる集約・異なる視点で切り出す——ここが次のセクションの一元管理につながります。

現場のコツ：営業向けは「行動を促すか」、経営向けは「意思決定を助けるか」で指標を取捨選択します。経営ダッシュボードに個人別の活動ログを載せても意思決定には効かず、営業ダッシュボードに全社粗利率だけ載せても現場は動けません。載せない勇気が作り分けの半分です。

05Snowflakeセマンティックビューで指標定義を一元管理する

指標定義がBIツールのデータセットや各アナリストのSQLに散らばると、同じ「売上」が実装ごとに微妙にずれます。Snowflakeのセマンティックビューは、この定義の分散に対する native な回答です。セマンティックビューはスキーマレベルのオブジェクトで、CREATE SEMANTIC VIEW の FACTS・DIMENSIONS・METRICS 句によって、行レベルの事実、切り口となるディメンション、そして SUM や AVG などで集計される業務指標(メトリクス)を一箇所に定義します。売上や商談化率といったKPIの集計式をここで一度だけ定義すれば、BIも、Cortex Analyst 経由の自然言語質問も、同じ定義から答えを返します。つまり「ダッシュボードの数字」と「チャットで聞いた数字」が構造的に一致する。定義は一度、適用はどこでも、というのが要点です。定義はコードとしてバージョン管理・レビュー・CI/CDに載せられるため、変更履歴と承認の証跡も残ります。

KPI設計で特に事故りやすいのが「足してはいけない指標を足してしまう」ケースです。パイプライン残高、在庫金額、月末人員数のような時点スナップショット(半加法的な指標)は、月を跨いで単純合算すると実態の何倍にも水増しされます。セマンティックビューでは NON ADDITIVE BY 句でこうした半加法メトリクスを宣言でき、指定したディメンション(例：月)方向には合算せず、最新スナップショットを採る挙動に定義できます。指標の性質を定義そのものに埋め込めるので、誰がクエリを書いても同じ正しい集計になります。

現場のコツ：PoC・検証環境で、パイプライン金額(時点スナップショット)を月次でSUMした試作ダッシュボードが実態を大きく上回る値を出す事象を先に踏み抜きました。原因が半加法性の見落としだと切り分けたうえで、本番向けの定義には NON ADDITIVE BY を適用。結果として、本番の経営ダッシュボードには誤集計が一度も表示されませんでした。落とし穴は検証で踏み、本番では踏まない——これが設計の勝ち筋です。

06集計・鮮度・コスト：Dynamic Tablesとウェアハウス設計

先行集計の実体を持たせる手段として有力なのが Dynamic Tables です。ソースの変更分だけを増分更新でき、KPIの事前集計テーブルを宣言的に維持できます。ただし増分更新が効くのは、新しい行の結果を単独で計算できる操作が中心で、結合と集約や窓関数を一枚のテーブルに詰め込むと増分性が崩れます。公式のベストプラクティスに沿って、一つの増分 Dynamic Table には非行単位の操作を一つだけ置き、結合は前段、集約は後段、と役割を分けて段組みするのが安定します。GROUP BY はグルーピングキーで変更が局所化されるほど効率が上がるため、キーでの整列(データローカリティ)も意識します。

鮮度とコストは表裏一体です。TARGET_LAG(目標鮮度)を短くするほど再計算が頻発し、ウェアハウスの稼働時間が伸びます。ここは業務要件から逆算するのが正解で、営業ダッシュボードは分〜十数分、経営ダッシュボードは日次、というように、必要な鮮度に指標ごとで差をつけます。SnowflakeはAWS上で動くため、ソースはS3の外部ステージ、認証・鍵管理はIAMとKMS、といった構成要素とも自然につながります。

現場のコツ：検証環境で、多数のKPI用 Dynamic Table に一律で極端に短いラグを設定すると、ウェアハウスがほぼ常時稼働し想定外にクレジットを消費すると分かりました。そこで本番では鮮度を業務要件に合わせて段階化し、ダッシュボード集計専用の小さめウェアハウスに短いAUTO_SUSPENDを設定。検証段階でコスト挙動を踏んでおいたことで、本番の請求に驚くことはありませんでした。

07配信とアクセス制御：BI・QuickSightとAWS基盤、そして運用

最後は「誰にどこまで見せるか」です。営業マネージャは自部門の案件まで、事業部長は事業部全体まで、経営層は全社まで——役割ごとの可視範囲を、配信レイヤーで統制します。AWS基盤側では、SnowflakeとBIの接続をPrivateLinkで閉域化し、認証はIAM、格納データはKMSで暗号化するのが定番です。BIレイヤーでは、たとえばAmazon QuickSightの行レベルセキュリティ(RLS)で、ユーザーやグループごとに見える行を絞れます。さらにSnowflake側でも行アクセスポリシーを併用し、データソースとBIの二重で制御しておくと、BIをすり抜けた直接クエリでも越境が起きません。プッシュ型の配信が要る場合は、しきい値超過をLambdaとAPI Gatewayで検知して通知する、といったAWSサービスとの組み合わせも取り回しが利きます。

運用面では、KPIツリー・RACI・セマンティックビューの定義を三点セットで管理台帳(指標カタログ)に束ね、変更はプルリクエストとレビューを通す軽い変更管理プロセスに載せます。指標の追加・改定が「誰の承認で、いつ、なぜ」行われたかが追える状態を保てば、ダッシュボードは作って終わりではなく、育てられる資産になります。低コストの小規模導入から最大規模の運用まで、複数業種で構築・運用してきた経験からも、最終的に効くのは派手な可視化ではなく、この定義と責任の一貫性だと感じています。

参考情報（一次情報）

EMWはAWS×Snowflakeで、KPI設計から指標定義の一元管理・ダッシュボード実装・アクセス統制までを一貫してご支援します。まずはお気軽にご相談ください。

相談する
← ブログ一覧へ戻る