社長が毎日使うTableauダッシュボードを作ってみた
DATA Saberに取り組んでいる流れで、自分が社長として毎日使うTableauダッシュボードを考え、まずはワイヤーフレームを作ってみました。
エクスチュアは普段から、クライアント企業のデータ活用やBI構築を支援しています。Tableauの機能を知らなかったから試した、という話ではありません。
ただ、自社の数字を毎日見る立場で考えると、ダッシュボードの難しさはグラフを作ることではないと改めて感じます。
売上、粗利、商談、パイプラインを並べれば、それらしい画面は作れます。
でも、画面を見た後に「今日は何をするべきか」が分からなければ、社長が毎日使うものとしては弱い。
自分の中には、「アクションをしないデータ分析は、何もしていないのと同じ」という考えがあります。
もちろん、経営ダッシュボードを見た結果、「今日は特に何もしなくてよい」と判断する日もあります。それも立派なアクションです。問題がないことを短時間で確認し、余計な確認や会議を増やさずに済むからです。
一方で、注意すべき変化があったなら、誰に確認するのか、どの案件を見るのか、何を止めるのか、何を進めるのかまで考えられなければならない。
今回作りたかったのは、数字を眺めるための画面ではなく、判断とアクションにつながる経営コックピットです。
Morning Snapshot、Executive Cockpit、Detailを分ける
毎朝、すべての経営情報を読み込むつもりはありません。
Morning Snapshotでは、売上・粗利、年度着地、パイプライン、警告シグナル、データ更新状態だけをSlackで確認します。20秒で大きな異常がないと分かれば、そのまま一日を始めればよい。
一方で、気になるシグナルがあったときや、週次で会社の状態を確認するときに開くのが、今回作ったExecutive Cockpitです。
さらに、Cockpitで「営業ヨミが怪しい」「採算が悪化している」と分かった後に、定型的に確認すべき原因候補までを見る画面をExecutive Cockpit Detailとして作りました。
レイヤー | 役割 |
|---|---|
Morning Snapshot | 毎朝20秒。Slackで正常か、警告があるかを確認する |
Executive Cockpit | 財務、営業、コスト、顧客、組織、R&D、データの全体状態を見る |
Executive Cockpit Detail | 各領域で、アクションを決めるために定型的に確認すべき要因を見る |
Detailは、何でも自由に分析するための画面ではありません。
たとえば営業であれば、今月と来月のどちらに不足があるのか、確度別にどの商談が足りないのか、Next Stepが更新されていない案件はどれか、といった毎回同じ切り口を確認する二段目の画面です。
最初の叩き台は、売上監視員の画面だった
最初にAIへ「社長が毎日見るTableauダッシュボード」の叩き台を出させてみました。
出てきたのは、かなり売上・パイプライン中心の画面です。会社なので、営業数字を見ること自体は当然です。
ただ、見ていて違和感がありました。
これでは、会社全体というより営業の状態を見ているだけです。
売上が伸びていても、粗利が悪ければ手放しでは喜べません。粗利が出ていても、固定費が膨らんでいれば注意が必要です。顧客との関係や組織の状態、次の商材につながる取り組みまで含めて見なければ、会社が健康に回っているかは分かりません。
そこで、売上・パイプライン中心の叩き台に、コスト・採算、顧客との関係、組織の状態、R&D、そして集計信頼性を加えていきました。
Executive Cockpitで見る7つの領域
最終的に、Cockpitでは次の7領域を確認する構成にしました。
領域 | Cockpitで確認すること |
|---|---|
財務実績 | 売上・粗利・利益が計画どおりか |
パイプライン・営業進捗 | 今月・来月の見込みに変化がないか |
コスト・採算 | 固定費を吸収できているか、採算面で確認が必要なことはないか |
顧客との関係 | 顧客の声やプロジェクト状況に注意すべき変化がないか |
組織の状態 | 組織運営上、確認すべき負荷やサーベイの変化がないか |
R&D進捗 | 次の商材・サービスにつながる取り組みが停滞していないか |
集計信頼性 | 今日の数字をどこまで判断材料として使えるか |
トップ画面で重要なのは、情報量を増やすことではありません。
売上が計画どおりか。年度着地の見込みに変化がないか。固定費を吸収できているか。顧客や組織の状態に確認すべきシグナルがないか。
こうしたことを、毎回同じ場所で確認できることが大事です。
そして、Action Queueには、注意が必要な論点だけを出します。
「年度着地予測が前回から悪化している」
「固定費吸収倍率が下がっている」
「顧客の声や組織サーベイに確認が必要な変化がある」
「原価・工数の未処理が多く、数字の前提に注意が必要である」
問題がなければ、何もしないという判断でよい。気になるシグナルがあるときだけ、確認し、必要なアクションを決める。これがCockpitの役割です。
Exture Executive Cockpit
Tableau Dashboard Wireframe v12 / 表示整理版
上段にKPI、中央に主要領域、下段にAction Queueと集計信頼性を配置。Tableauでは各領域をシートとして作成。
KPI・主要領域・Action Queue行をクリックして詳細ダッシュボードへ遷移。画面上に詳細ボタンは置かない。
グラフ本体は基本グレー。色は意味がある場合だけ使用。緑=良好/達成、アンバー=注意、赤=未達/リスク。カテゴリ識別だけの色分けは禁止。グラフ内には説明文を置かず、軸・凡例・ツールチップ・下部KPIで補足。
Detailでは、アクションを決めるための原因候補を確認する
Cockpitで異常を見つけた後、いきなり何でも自由に分析するのではなく、まずは定型的に確認すべきものを見ます。
たとえば、営業ヨミに不足があった場合です。
Executive Cockpit Detailでは、今月と来月のどちらに影響があるのか、確度別にどの商談が不足しているのか、Next Stepが更新されていない案件はどれか、売上見込みに対して粗利面の懸念はないかを確認します。
ここまで分かれば、「この案件を担当者に確認する」「この顧客への提案状況を聞く」「この案件の条件を見直す」といったアクションにつながります。
ダッシュボードは、状態を見せるだけでは弱い。
確認すべき対象を絞り込み、次のアクションを決められて初めて経営の道具になります。
Exture Executive Cockpit – Detail Dashboards
Tableau詳細ダッシュボード ワイヤー v4 / 営業活動率・Next Step現実化版
財務実績詳細
売上・粗利・営業利益の着地を、月次・部署・顧客・案件の順に深掘る。
月次推移
売上・粗利・固定費・営業利益を同じ時間軸で確認する。
事業別 売上・粗利
どの事業が計画差分を作っているかを見る。
顧客別 売上・粗利 Top/Bottom
増減に効いている顧客を確認する。
顧客 | 売上 | 粗利 | 前年比 | 状態 |
|---|---|---|---|---|
顧客A | ¥XXM | ¥XXM | +XX% | 伸長 |
顧客B | ¥XXM | ¥XXM | -XX% | 要確認 |
顧客C | ¥XXM | ¥XXM | -XX% | 低下 |
顧客D | ¥XXM | ¥XXM | +XX% | 通常 |
案件別 粗利率アラート
粗利を押し下げている案件を特定する。
案件 | 部署 | 売上 | 粗利率 | 理由 |
|---|---|---|---|---|
案件A | DG | ¥XXM | XX% | 外注費増 |
案件B | CX | ¥XXM | XX% | 追加工数 |
案件C | ME | ¥XXM | XX% | 通常 |
営業パイプライン詳細
今月・来月・3か月・6か月の売上/粗利ヨミ、Next Step未更新、営業活動量を特定する。
期間別 営業ヨミ 売上
今月・来月・3か月・6か月を、営業ヨミ別の縦積み棒で見る。
期間別 営業ヨミ 粗利
同じヨミを粗利ベースで見る。売上は大きいが粗利が弱い商談を見逃さない。
今月/来月Close Next Step未更新
Closeが近いのにNext Stepが未更新の商談。古いNext Step内容と最終更新日を出す。
商談 | Close | ヨミ | 古いNext Step | 更新日 |
|---|---|---|---|---|
商談A | 今月 | Almost | 見積送付 | YYYY/MM/DD |
商談B | 来月 | Commit | 契約確認 | YYYY/MM/DD |
商談C | 今月 | Upside | 提案日程調整 | YYYY/MM/DD |
商談D | 来月 | No Commit | 状況確認 | YYYY/MM/DD |
営業担当別 ヨミ 売上/粗利
担当者ごとにCommit/Almost/Upside/No Commitの売上・粗利を見る。
営業活動・請求化管理
請求化・見積化は率で見る。商談実施数と新規商談作成数は件数で見る。
指標 | 定義 | 今月 | 来月 |
|---|---|---|---|
請求化率 | ステージ請求 ÷ Almost Commit以上の商談数 | XX% | XX% |
見積化率 | ステージ見積 ÷ その月の商談数 | XX% | XX% |
商談実施数 | 活動履歴/イベントから集計 | XX件 | XX件 |
新規商談作成数 | 商談作成日で集計 | XX件 | XX件 |
過去30日リード商談化率 | 過去30日獲得リードの商談化数 ÷ 獲得リード数 | XX% | – |
コスト/採算詳細
固定費吸収倍率、外注費率、SaaS/クラウド費、販売SaaS仕入原価を分解する。
費目別 月次推移
固定費・変動費・案件原価の増加傾向を見る。
コストカテゴリ別
どの費目が予算/基準を超えているかを見る。
外注費/業務委託費 アラート
粗利を押し下げている案件原価を確認する。
案件 | 外注費 | 売上比 | 状態 |
|---|---|---|---|
案件A | ¥XXM | XX% | 超過 |
案件B | ¥XXM | XX% | 注意 |
案件C | ¥XXM | XX% | 通常 |
社内利用SaaS/クラウド費
会社で使っているコストを棚卸しする。
サービス | 月額 | 契約更新月 | 解約通知月 | 状態 |
|---|---|---|---|---|
Tool A | ¥XXXK | YYYY/MM | YYYY/MM | 更新確認 |
Cloud B | ¥XXXK | 従量 | – | 増加 |
Tool C | ¥XXXK | YYYY/MM | YYYY/MM | 通常 |
販売SaaS仕入原価
販売SaaS売上と仕入を対応させ、粗利を確認する。
製品 | 売上 | 仕入 | 粗利率 | 状態 |
|---|---|---|---|---|
SaaS A | ¥XXM | ¥XXM | XX% | 確認 |
SaaS B | ¥XXM | ¥XXM | XX% | 正常 |
SaaS C | ¥XXM | ¥XXM | XX% | 低粗利 |
顧客満足・継続詳細
高売上/高粗利なのに満足度が低い顧客、継続率リスク、改善対象を特定する。
顧客満足度 × 売上/粗利
1ドット=1取引先。高売上/高粗利かつ低満足の顧客を特定する。
高売上低満足 顧客リスト
対応優先度の高い顧客を確認する。
顧客 | 売上/粗利 | 満足度 | 担当 | 状態 |
|---|---|---|---|---|
顧客A | ¥XXM | X.X | 担当A | 優先 |
顧客B | ¥XXM | X.X | 担当B | 注意 |
顧客C | ¥XXM | X.X | 担当C | 通常 |
NPS推移
調査回ごとのNPS変化を見る。継続率はKPIで確認する。
満足度低下顧客
前回調査から悪化した顧客。
顧客 | 前回 | 今回 | 差分 |
|---|---|---|---|
顧客D | X.X | X.X | -X.X |
顧客E | X.X | X.X | -X.X |
改善要望カテゴリ
顧客から出ている改善要望の傾向。
カテゴリ | 件数 | 傾向 |
|---|---|---|
品質 | XX | 増加 |
速度 | XX | 横ばい |
提案 | XX | 改善 |
従業員満足・負荷詳細
高負荷低満足の社員/チーム、稼働過多、ES低下、離職リスクを特定する。
従業員満足度 × 負荷
1ドット=1社員または1チーム。高負荷かつ低満足を特定する。
高負荷低満足リスト
マネジメント上、優先して確認すべき対象。
対象 | 負荷 | 満足度 | 部署 | 状態 |
|---|---|---|---|---|
社員/チームA | XX% | X.X | DG | 優先 |
社員/チームB | XX% | X.X | CX | 注意 |
社員/チームC | XX% | X.X | ME | 通常 |
部署別 ES / 稼働
部署単位の組織状態を見る。
高稼働者
上限を超えている社員/チーム。
対象 | 稼働率 | 残業 | 状態 |
|---|---|---|---|
A | XX% | XXh | 高 |
B | XX% | XXh | 注意 |
ES低下項目
満足度低下の内訳。
項目 | スコア | 前年差 |
|---|---|---|
成長実感 | X.X | -X.X |
評価納得度 | X.X | -X.X |
負荷感 | X.X | -X.X |
R&D詳細
新規開発、海外ツール調査、PoC、商談化準備、販売開始のステージ別に進捗を見る。
R&Dステージ別パイプライン
次の商材・サービスが、どのステージに何本あるかを見る。
R&D案件リスト
各案件のステージ、次アクション、商談化見込みを確認する。
案件 | タイプ | ステージ | 次アクション | 状態 |
|---|---|---|---|---|
R&D A | 自社開発 | PoC中 | 検証 | 通常 |
Tool B | 海外ツール | 商談化準備 | 価格確認 | 確認 |
R&D C | パートナー | 検証中 | 提案化 | 進行 |
ステージ移行予定
次に検証・PoC・商談化へ進める予定の案件を見る。
案件 | 現ステージ | 次ステージ | 予定 |
|---|---|---|---|
R&D A | 検証中 | PoC | YYYY/MM |
Tool B | PoC中 | 商談化準備 | YYYY/MM |
投下工数/コスト
R&Dにかけている工数とコストを見る。
案件 | 工数 | コスト | 見込み |
|---|---|---|---|
A | XXh | ¥XX | 高 |
B | XXh | ¥XX | 中 |
商談化候補
営業活動に乗せられる候補を確認する。
候補 | 想定顧客 | 予定 |
|---|---|---|
候補A | 既存顧客 | YYYY/MM |
候補B | 新規市場 | YYYY/MM |
集計信頼性・締め状態詳細
このダッシュボードの数字が、今日の経営判断に使える状態かを確認する。
品質項目別 未処理件数
どの品質項目が経営数字の信頼性を下げているかを見る。
未処理明細
処理すべき対象を一覧化する。
区分 | 対象 | 影響 | 担当 | 状態 |
|---|---|---|---|---|
工数 | 未承認 | 採算 | 担当A | 未処理 |
原価 | 外注費 | 粗利 | 担当B | 確認中 |
SaaS仕入 | 仕入紐づけ | 粗利 | 担当C | 確認中 |
月次締めステータス
確定月・速報月の状態を確認する。
月 | 売上 | 原価 | 工数 | 状態 |
|---|---|---|---|---|
YYYY/MM | 完了 | 完了 | 完了 | 確定 |
YYYY/MM | 完了 | 確認中 | 未承認 | 速報 |
部署別 未処理
どの部署に確認が必要かを見る。
対応優先順位
経営数字に影響が大きい順に対応する。
優先 | 区分 | 理由 |
|---|---|---|
1 | 工数未承認 | 採算/負荷に影響 |
2 | 原価未紐づけ | 粗利に影響 |
3 | CS/ES未回収 | 品質指標に影響 |
売上だけでなく、粗利と固定費まで見て初めて経営数字になる
財務実績では、売上、粗利、営業利益を分けて見ます。
売上が計画を達成していても、粗利率が悪ければ見方は変わります。粗利が出ていても、固定費を吸収できていなければ、継続的に安心できる状態とは言えません。
案件や顧客の採算を見るときは、売上に直接ひも付く原価だけでなく、外注費、業務委託費、販売SaaSの仕入原価、社員工数も含めて確認します。
ただし、Cockpitで明細を全部並べる必要はありません。
Cockpitで「粗利が想定より弱い」「固定費吸収が下がっている」と気付き、Detailで案件や費目を確認する。この役割分担にしています。
コスト詳細で見るのも、単なる支出額ではありません。削減や見直しを検討すべきもの、契約更新前に確認すべきもの、採算への影響を確認すべきものです。
SaaSやクラウド費については、金額だけでなく契約更新月と解約通知月も見えるようにしたいと考えています。更新後に「やっぱり要らなかった」と言っても、少し遅いので。
顧客との関係は、点数を眺めるために見るものではない
顧客満足も、平均点を眺めるために置くものではありません。
「平均満足度は4.2です」と分かっても、それだけではアクションにつながりません。
顧客との関係を見る画面では、顧客の声、プロジェクトの状況、取引状況などを組み合わせ、注意すべき変化がないかを確認します。
散布図を使う場合も、顧客を機械的に評価・選別するためではなく、営業やプロジェクト責任者が状況を確認するための入口です。
ダッシュボードで違和感を見つけた後、担当者が背景を確認し、必要に応じて対話や改善につなげる。顧客満足を扱うなら、ここまで含めて設計する必要があります。
組織の状態は、個人を監視するためではない
従業員サーベイや負荷に関する情報も、経営上の重要なシグナルです。
売上が伸び、粗利も出ているとしても、組織に無理がかかっている状態を放置すれば、持続的な成長は難しくなります。
一方で、こうしたデータを個人監視や人事評価に使うべきではありません。
Cockpitで確認するのは、適切に集計・匿名化されたチームや組織単位の傾向です。少人数の回答結果や個人が推測できる粒度は表示しない。アクセス権も限定する。サーベイ結果だけで、誰かを評価したり処遇を決めたりしない。
Cockpitで組織面の注意シグナルが見えたら、マネージャーや人事が現場の状況を確認し、業務量、アサイン、支援体制などを見直す。
数字は対話を始めるきっかけであって、答えそのものではありません。
R&Dは、未来の売上を見るために入れる
短期の売上と粗利だけを見続けると、将来の成長が見えなくなります。
R&Dについては、調査中、検証中、PoC中、商談化準備、販売開始といったステージで進捗を確認する設計にしました。
見るべきなのは案件総数ではなく、次のステージへ進めるものは何か、判断待ちで止まっているものは何か、営業につなげる準備ができているものは何かです。
今月の売上にならないものでも、半年後や1年後の選択肢には関係します。今月カネになるものだけを見ていると、未来が細ります。
数字を信じてよいかも、Cockpitの一部
集計信頼性は地味ですが、ダッシュボード全体の土台です。
原価や外注費が未紐づけだったり、工数が未承認だったりすれば、粗利や採算の数字は判断材料として限定的です。
そこで、最新確定月、速報対象月、原価・外注費の未紐づけ、販売SaaS仕入の未紐づけ、工数未入力・未承認、CS・ESの回収状況などを確認できるようにしました。
目的は、今日の数字をどこまで信じてよいかを把握することです。
数字の前提に未処理が多ければ、分析を深める前に、まずデータを整える必要があります。
色は装飾ではなく、判断のために使う
今回のモックでは、グラフ本体を基本グレーにし、色は意味がある場合だけに絞りました。
緑は達成・良い状態、アンバーは注意、赤は未達・リスクです。カテゴリを区別するためだけの色分けは、できるだけ使いません。
色が多いとダッシュボードらしく見えます。ただ、それっぽいだけで見やすいとは限りません。
見る側が「この色には何の意味があるのだろう」と考え始めたら、その色はノイズです。
AIでたたき台を作り、人間が使える形に直す
今回、AIには叩き台とモックの壁打ちを手伝ってもらいました。
最初の形を出すスピードはかなり速いです。ただ、そのまま使えることはほぼありませんでした。
自社の運用で出せるデータか。既存の定義と矛盾していないか。見た後にアクションにつながる指標か。顧客や従業員のデータを不適切に扱う設計になっていないか。
こうした確認と修正を重ねて、ようやく毎日使う画面の形になってきました。
AIは初速を上げるには便利です。ただ、業務の実態、データの信頼性、扱うデータへの配慮、見た後のアクションまで設計することは、人間側の仕事だと思います。
次は、本当に毎日使えるかを検証する
今回作ったのは、Tableau実装前のワイヤーフレームです。
ただ、設計として一番大事にしたいことは決まりました。
Morning Snapshotで短時間に状態を確認する。Executive Cockpitで会社全体の変化を捉える。Executive Cockpit Detailで、アクションを決めるために必要な原因候補まで見る。
売上だけではなく、粗利、コスト、顧客との関係、組織の状態、未来の種、そして数字の信頼性まで確認する。
次は、このワイヤーフレームを実際にTableauで作り、本当に毎日開くか、見た結果として次のアクションが明確になるかを検証していきます。
