BIツールなしで経営ダッシュボードを作る—Googleスプレッドシートだけで始める見える化

「経営ダッシュボードを作りたいんですが、何を使えばいいですか？」

この質問をされたとき、まず確認するのは会社の規模と現状だ。従業員が50名以下で、まだ数字を一元管理できていない状態なら、答えはほぼ決まっている。スプレッドシートで十分だ、と。

BIツールを否定しているわけじゃない。ただ、導入の手間・コスト・社内への定着を考えると、「まず動かす」ことを優先すべき段階の会社に高機能なツールは要らない。このページでは、BIツールを一切使わずにGoogleスプレッドシートだけで経営ダッシュボードを作る方法を、実際に使える関数や設計の考え方まで含めて解説する。

ここで言う「スプレッドシートのダッシュボード化」は、すでに社内にある数字を、判断に使える1枚の画面にまとめ直す作業のことだ。現場では「スプシでダッシュボードを作る」と呼ばれることのほうが多いかもしれない。新しいツールを増やす話ではないので、デザインを凝るところからではなく、どの数字を誰がいつ見るかを決めるところから入る。

BIツールを導入する前に、まず数字の流れを整える

BIツールの料金・機能・契約単位はサービスやプランによって変わる。比較する際は、導入費用だけでなく、データ連携、権限管理、更新の担当者まで含めて公式情報と自社の運用体制を確認したい。

重要なのは、ツールを入れる前に「誰が、どの数字を、いつ確認して判断するか」を決めることだ。ここが曖昧なまま可視化の仕組みだけを増やすと、更新されないダッシュボードが残りやすい。

すでに利用しているGoogle Workspaceやスプレッドシート環境があれば、まずはそこで数字の定義・入力・更新の流れを試せる。目的はツール選びではなく、「まず経営の数字を見える状態にする」ことだ。

データ量が増え、複数ソースの統合・リアルタイム性・監査可能な権限管理が必要になったら、BIツールへの移行を検討する段階だ。その判断は従業員数ではなく、必要な更新頻度とデータ運用の複雑さで行う。

スプレッドシートダッシュボードの設計原則

「とりあえず作った」ダッシュボードが使われなくなる原因のほとんどは、設計の問題だ。どれだけ数字が正確でも、見にくければ誰も開かなくなる。作る前に3つの原則を頭に入れておきたい。

原則1. 1画面に収める（スクロール禁止）

ダッシュボードは「一瞬で状況が把握できる」ことが本来の目的だ。スクロールしないと全部見えない設計は、ダッシュボードではなくレポートになってしまっている。

画面サイズは13〜15インチのノートPCを基準に考えると、縦方向に表示できる行数はおよそ30〜35行。この範囲に収まらない情報はダッシュボードには載せず、詳細シートに分けるか、別レポートとして管理する。「全部乗せたい」という気持ちはわかるが、情報が多すぎるダッシュボードは何も伝えない。

原則2. 色は3色まで（赤・黄・緑のシグナル）

色を使いすぎると、どこを見ればいいのかわからなくなる。経営ダッシュボードに使う色は、赤（要対応）・黄（注意）・緑（正常）の3色に絞るのが基本だ。

この3色を条件付き書式で自動的に割り当てる。たとえば粗利率が目標の20%を超えていれば緑、15〜20%なら黄、15%未満なら赤、というルールを設定しておけば、数字を読み込まなくても一目でどの指標が危険水域かわかる。色の意味を統一しておくことで、ダッシュボードを初めて見る人でも直感的に状況が把握できる。

原則3. 更新は自動（手入力を排除する設計）

ダッシュボードが使われなくなる最大の理由は「更新が面倒」だ。誰かが毎週手でデータを転記しなければならない設計では、担当者が忙しくなった途端に止まる。

設計の方針は「ローデータを入力するだけで、ダッシュボードが自動で更新される」ようにすること。QUERY関数やIMPORTRANGEを使えば、別シートや別ファイルのデータを自動で取り込んで集計できる。手入力が必要なのはローデータシートへの入力だけ、という状態を目指す。

ただし自動化を進めるほど、IMPORTRANGEや揮発性関数が積み上がってファイルが重くなる。開くのに時間がかかるようになったら、行を削るような対症療法ではなく設計側を疑ったほうが早い。切り分け方はスプレッドシートが重いを「設計」で直す｜消すべき数式と、残していい手入力に整理してある。

実際に作ってみる—3枚構成の設計

スプレッドシートダッシュボードの構成は、役割が明確な3枚のシートに分けるのが鉄則だ。「ローデータ」「計算」「ダッシュボード（表示）」の3層に分離することで、保守しやすく、壊れにくい構造になる。

1枚目: ローデータシート（入力層）

ローデータシートは、生の数字を入力する場所だ。ここには加工や集計は一切行わない。列の構成は「日付・カテゴリ・金額（または数量）・担当者・備考」の5列が基本形で、行を追加するだけでデータが蓄積していく設計にする。

注意点は、セルの結合を絶対に使わないことだ。見た目を整えたくてセルを結合したくなるが、結合があるとQUERY関数やSUMIFSが正しく動かなくなる。ローデータシートはとにかくフラットな表構造を保つ。

また、日付列は必ず「2026/04/01」のような日付形式で入力する。「4月1日」や「4/1」といった文字列で入力してしまうと、後で月別集計をするときに手間がかかる。入力規則（データの入力規則機能）で日付形式を強制するのもおすすめだ。

この「入力規則を先に決める」話は、ダッシュボードに限らず複数人で使う台帳すべてに効いてくる。作った直後はきれいでも、数ヶ月で列が増えて表記がばらけていくのが典型的な壊れ方だ。崩れ方の型と、配る前に決めておく列・入力規則は顧客管理のスプレッドシートが3ヶ月で崩れる理由｜テンプレを配る前に決める列と入力規則にまとめている。

2枚目: 計算シート（ロジック層）

計算シートは、ローデータを集計・変換する場所だ。ここで使う関数が3つある。

QUERY関数は、ローデータから条件に合う行を抽出したり、グループ別の合計を計算したりするのに使う。たとえば「今月の部門別売上合計」を出したい場合、次のように書く。

SUMIFS関数は、複数条件での合計に使う。「4月の営業部の売上」を出すなら次の形だ。

SPARKLINE関数は、セル内に小さな折れ線グラフを表示するための関数だ。計算シートで月別の推移データを並べておき、ダッシュボードシートからSPARKLINEで参照する構成にすると、コンパクトにトレンドが表示できる。

3枚目: ダッシュボードシート（表示層）

ダッシュボードシートは、計算シートの結果を参照して表示するだけの場所だ。このシートには計算式を書かない。すべて「=計算!B3」のような参照式のみにすることで、ダッシュボードの見た目を変えたくなっても計算ロジックに影響しない。

条件付き書式はこのシートに設定する。たとえば粗利率のセルに対して「20%以上なら緑・15〜20%なら黄・15%未満なら赤」というルールを設定しておけば、数値が更新されるたびに自動で色が変わる。設定は「書式」→「条件付き書式」から、「カスタム数式」を使うと柔軟に条件を組める。

SPARKLINEもこのシートに配置する。計算シートで作った月別推移データをSPARKLINEで参照することで、KPIの数値とトレンドグラフを同じ行に並べた、見やすいレイアウトが完成する。

この3枚構成は、載せる中身を変えればそのまま別の用途に使える。経営者が毎月見る財務指標に絞るならKPI管理スプレッドシートの作り方—中小企業の経営者が見る5つの財務指標、営業の商談を追いかけるなら営業の案件管理シートを1枚で回す—ステータス・次回アクション日・COUNTIF集計の設計が、それぞれ何を列に置くかまで書いてある。

よく使う関数トップ5

スプレッドシートダッシュボードを作るうえで、使用頻度が高い関数を5つまとめた。最初からすべてを覚える必要はないが、この5つを知っておくと設計の幅が大きく広がる。

この中で最初に習得しておくと効果が大きいのはQUERYとSPARKLINEだ。QUERYは集計のほぼすべてを担えるし、SPARKLINEはグラフを別途作らなくてもトレンドが表示できる点でレイアウトの自由度が上がる。

IMPORTRANGEは少し注意が必要で、初回アクセス時に「アクセスを許可」の確認が出る。また、参照先のファイルが変更されるとリフレッシュに時間がかかることがある。大量データを頻繁に参照すると処理が重くなるため、参照列は必要最小限に絞るのが実用上のコツだ。

ARRAYFORMULAは、計算シートで「売上×粗利率」のような列計算を全行に適用したいときに便利だ。1行目にARRAYFORMULAで数式を書くだけで、新しい行が追加されたときも自動的に計算が適用される。毎行コピーする手間が省ける。

スプレッドシートのダッシュボードを自動更新する

作った直後は毎日開くのに、1ヶ月後には誰も見ていない。ダッシュボードでいちばん多い失敗はこれで、原因はたいてい「更新が手作業のまま残っている」ことにある。Googleスプレッドシートで自動更新を実現する方法は、大きく3つに分かれる。どれか1つが正解というより、更新頻度とデータの置き場所で選ぶ。

1. IMPORTRANGEで引く

いちばん手前の選択肢。元データが別のGoogleスプレッドシートにあるなら、IMPORTRANGEで参照するだけで、元ファイルが更新されたタイミングでダッシュボード側も追随する。プログラムを1行も書かずに済むのが最大の利点だ。

注意点は2つある。1つは参照範囲を列単位（A:E）で固定すると、参照先で列が挿入されたときに中身がまるごとズレること。もう1つは、IMPORTRANGEが1本エラーになるとそこから先の計算がすべて壊れて、画面全体がエラー表示になることだ。参照は計算シートの上部に集約して、どこから引いているかが1画面でわかる形にしておくと復旧が早い。

2. GASのトリガーで更新する

関数では表現できない更新が出てきたら、Google Apps Script（GAS）の時間主導トリガーを使う。毎朝9時に実行、1時間おきに実行、といった定期実行を設定できる。関数との一番の違いは、「その時点の値を記録として残せる」ことだ。関数は常に最新を映すので、先月時点でいくらだったかは残らない。月末残高や週次のスナップショットを蓄積したいなら、この方法しかない。

ただしGASは静かに止まる。実行が失敗しても画面上は先週の数字がそのまま表示され続けるので、見ている側は気づけない。最終更新日時をダッシュボードの右上に出しておく、失敗したらチャットに通知を飛ばす、といった「止まったことがわかる仕掛け」を最初から入れておきたい。

3. Looker Studioに接続する

表示の部分だけ外に出す選択肢もある。Looker StudioはGoogleスプレッドシートをデータソースとして接続でき、閲覧側はシートを触らずにグラフを見られる。見る人が増えてきて、誰かが数式を消してしまうリスクが出てきた段階では検討する価値がある。

とはいえ、これは「見せ方」を変える手段であって、元データの整理を代わりにやってくれるわけではない。ローデータがフラットになっていない状態で接続しても、思ったグラフは出ない。3枚構成でデータを整えるのが先で、Looker Studioはその後の選択肢、という順番は変わらない。

手入力に残していいものを決める

自動更新の話で一番大事なのは、実は「どこまで自動化しないか」を決めることだ。全部を自動化しようとしたダッシュボードは、たいてい途中で壊れる。自動化した箇所が増えるほど、壊れたときに直せる人が減るからだ。

判断軸はシンプルで、毎回まったく同じ手順で、同じ場所から、同じ形で持ってくる転記だけを自動化する。逆に、次の3つは手入力に残したほうが結果的に長持ちする。

• 発生源がスプレッドシートの外にあるもの（電話・訪問・紙で受け取る情報）。取り込みを自動化するより、入力する場所を1つに決めるほうが効く
• 月に数回しか変わらない値（目標値・単価マスタ・担当者名簿）。仕組みを作る手間が回収できない
• 人の判断が入る列（案件のフェーズ、確度、備考）。人が書くから意味がある情報を、無理に推定させると精度が落ちる

そして自動化した箇所については、「止まったときに誰が直すか」をセットで決めておく。ここを決めずに仕組みだけ増やすと、担当者が変わった瞬間に誰も触れないブラックボックスになる。自動化の設計は、技術の話より運用の話の比重が大きい。

スプレッドシートの限界と「次のステップ」

スプレッドシートで十分、と書いてきたが、もちろん限界はある。どのタイミングでBIツールや別のデータ管理の仕組みへの移行を検討すべきかを整理しておく。

シートが10枚を超えたら構造を見直す

「ちょっと集計が必要だから」とシートを追加し続けると、気づけば10枚以上になっていることがある。シートが増えれば増えるほど、どのシートにどのデータがあるかわからなくなり、管理コストが跳ね上がる。

シートが10枚を超えてきたら、まずデータを整理するタイミングだ。ローデータを1枚に統合できないか見直す、不要になった集計シートを削除する、といった棚卸しから始める。それでも管理しきれなくなったら、Google BigQueryやNotionデータベース、あるいはAirtableのような軽量なデータベースツールへの移行を検討する時期だ。

同時編集ユーザーが10人を超えたら競合リスクが上がる

Googleスプレッドシートはリアルタイム共同編集に対応しているが、同時に多人数が同じシートを編集すると、競合や意図しない上書きが起きやすくなる。特にローデータシートへの入力が複数人で行われる場合は注意が必要だ。

10人を超えてくるようなら、入力フォームをGoogleフォームに切り替えてスプレッドシートに自動連携する構成にするか、入力専用のSaaSツールを導入して集計だけスプレッドシートで行う、という分担が現実的だ。

顧客データを扱っている場合は、同じ判断がCRMを契約するかどうかの線引きにもなる。シートのままで足りる条件と、移行を決める3つのサインはCRMをスプレッドシートで代替する—限界の見極めと移行を決める3つのサインで整理している。

データソースが3つ以上になったらBIツールを検討する

売上データ・顧客データ・広告費データ、といった複数ソースを統合して分析したくなってきたら、スプレッドシートのIMPORTRANGEで頑張るより、BIツールのコネクタ機能を使ったほうが速くて正確だ。Looker StudioはGoogle系サービスとの連携が無料でできるので、まずそちらを試してみるのがおすすめだ。

ただし、統合したいソースに外部のAPIが混ざる場合は事情が変わる。BIのコネクタで直接叩くと認証や取得回数の制限で止まりやすいので、定期取得して保存する層を1つ挟み、BIは保存先だけを読む形にする。国土交通省の不動産情報ライブラリAPIを例にした構成は不動産情報ライブラリAPIをBIツールに繋ぐ手順で、スプレッドシート経由とBigQuery経由を比べながら整理している。

重要なのは、BIツールを使うにしても「データの構造を理解していること」が前提になる点だ。スプレッドシートで3枚構成を作った経験があれば、ローデータ・ロジック・表示の分離という概念はすでに身についている。BIツールへの移行もスムーズになる。

まとめ

経営ダッシュボードを作るのに、高価なBIツールは必要ない。Googleスプレッドシートだけで、経営判断に使える十分な質のダッシュボードは作れる。

設計の肝は3つだ。1画面に収める・3色シグナルで色を統一する・更新を自動化する。そしてシートの構成は、ローデータ・計算・ダッシュボードの3枚に分離する。QUERY、SPARKLINE、条件付き書式を使いこなせれば、見た目も機能も十分なダッシュボードが完成する。

完璧なものを最初から作ろうとしなくていい。まずローデータシートを1枚作って数字を入力し始めることが、経営の見える化への一番の近道だ。スプレッドシートが手狭になってきたとき、はじめてBIツールを検討する、という順番が現実的だと思っている。

よくある質問