Looker Studio も Notion もやめた。Cloudflare Workers で自作した「経営KPI + カンバン」オールインワンダッシュボード

はじめに：「開かれないダッシュボード」問題への終止符

月末の進捗会議で「今月の目標達成率はどうなっている？」と聞かれ、慌ててLooker StudioのURLを探す。あるいは、毎日Slackの指定チャンネルに送られてくる自動レポートの数値を、誰一人として見ていない（既読スルー状態になっている）。

こうした「ダッシュボードの形骸化」に悩むテックリードや開発責任者の方は多いのではないでしょうか。私たちもかつては同じ悩みを抱えていました。 「データは見えないといけない」という号令のもと、Looker Studioで美麗なグラフを作り、Notionでタスクを管理し、Slackで数値を通知する。しかし、いくらツールを整備しても、結局「誰もダッシュボードを開かない」「数値と行動が結びついていない」という状態に陥ってしまったのです。

結論から申し上げますと、この課題を解決する最適解は**「数字（KPI）」と「タスク（カンバン）」を1つの画面に統合し、超高速で起動する内製ダッシュボードを作ること**でした。

本記事では、既存BIツールやNotion運用に限界を感じていた私たちが、Cloudflare Workersを活用して「経営KPI＋カンバン」オールインワンダッシュボードを自作したプロセスを公開します。 ゴールから逆算した要件定義から、技術選定の理由、BigQueryやGA4との自動連携、そして失敗を経てUIを再設計した泥臭い試行錯誤まで、実務家エンジニアの皆様の参考になれば幸いです。

1. 既存ツールの限界と「オールインワン」の要件定義

なぜ既存のツールは使われなくなるのか？

自社専用のダッシュボードを開発する前に、まずは「なぜ既存ツールではダメだったのか」をチームで振り返りました。それぞれのツールには以下のような明確な課題（アンチパターン）がありました。

1. Looker Studio（BIツール）の課題：開く習慣がつかない グラフや表をリッチに表現できる反面、「ただ数字を見るだけの場所」になりがちです。アクションを起こす機能がないため、月末の報告用ツールに成り下がり、日常業務の中で能動的に開かれることがありませんでした。
2. Notionの課題：API連携が重く、運用コストが肥大化する タスク管理やカンバンとしては優秀ですが、GA4やBigQueryから最新の数値をAPI経由で定期更新しようとすると、Notion APIのレート制限や動作の重さがネックになります。手動更新の余地を残すと、今度は「誰が数値を入力するのか」というメンテンスの属人化が発生しました。
3. Slackの課題：タイムラインで情報が流れる 「開かないなら通知すればいい」とSlackへの自動ポストを実装しましたが、情報がフローとして流れてしまうため、時系列の推移や「昨日の数値との差分」が直感的に把握できません。また、通知を受け取った後、誰がどう動くのかという「タスクの文脈」が途切れてしまいます。

要件：「数字（KPI）」と「行動（タスク）」を1箇所に集約する

これらの反省を踏まえ、私たちがたどり着いた結論は**「これだけ見ればすべて目視できてタスク管理もでき、履歴が残るオールインワンの場所が欲しい」**というものでした。

そこで、まずは最終的な事業ゴールから逆算したKPIツリーを再定義しました。 最終ゴールを「お問い合わせ件数を増やし、受注を獲得すること」と置き、そこから以下のような指標をブレイクダウンします。

• 自動取得できる定量KPI：サイトのPV数（GA4）、広告クリック数、システムの稼働率
• 手動で管理すべき定性タスク：各見込み顧客の商談フェーズ、営業担当のアクション、開発チームの改善タスク

新しいダッシュボードの要件は、「この自動化された定量指標（数字）」と「手動で動かすカンバン（行動）」が同じ画面に並んでいることです。 数字がショートしていれば、その場で隣にあるカンバンのタスクを「To Do」から「In Progress」へ引き上げる。この「気づきから行動までの物理的な距離をゼロにする」ことこそが、ツールを形骸化させない最大のポイントでした。

2. システム設計：なぜ Cloudflare Workers を選んだのか？

サーバーレスかつ保守ゼロのエッジ環境

「数字とタスクが連動するダッシュボードを内製する」と決めた際、インフラの技術選定で真っ先に挙がったのが Cloudflare Workers でした。

中小企業の限られた開発リソースにおいて、社内ツールのためにわざわざEC2インスタンスを立てたり、コンテナの運用保守を行ったりするのは本末転倒です。その点、Cloudflare Workersには以下の圧倒的なメリットがありました。

• インフラの保守コストが実質ゼロ：サーバーレス（エッジコンピューティング）であるため、アクセススパイクやサーバーダウンを気にする必要がありません。
• フルスタック開発が1箇所で完結：Honoなどの軽量Webフレームワークを組み合わせることで、APIエンドポイントの作成から、HTMLのSSR（サーバーサイドレンダリング）までを1つのプロジェクトで記述できます。
• ランニングコストの安さ：Cloudflare Workersの無料枠（または月額$5の有料プラン）で十分に収まるため、お財布にも優しいです。

また、データを保存するためのデータベースには、同じくCloudflareが提供するエッジSQLiteの D1 と、キーバリューストアの KV を採用しました。これにより、AWS等の外部DBへ通信するレイテンシも削減できます。

「Slackはサマリ、詳細はHTML」のハイブリッド設計

ダッシュボードを作っただけでは、結局「開かれない問題」は解決しません。そこで、Slackを「詳細を見る場所」から**「ダッシュボードへ誘導するためのトリガー」**へと役割を明確に変更しました。

具体的には、Cloudflare Workersの Cron Triggers（定期実行機能）を活用し、毎朝決まった時間にSlackへ通知を飛ばします。しかし、通知する内容は「昨日の注力KPIのハイライト（達成/未達）」のみに留めます。 そして、メッセージの最後に必ず**「詳細と本日のアクション決定はこちら」というダッシュボードのURL**を配置しました。

URLをクリックすると、エッジで高速レンダリングされた静的HTMLベースのダッシュボードが0.1秒で立ち上がります。 「Slackで概要を掴み、気になったら即座に超高速なHTML画面を開いてタスクを動かす」というハイブリッドな情報設計により、メンバーが日常的にダッシュボードを開く習慣が自然と根付きました。

3. 実装の勘所：自動連携と手入力の現実解

BigQuery・GA4からのデータ自動集約

実装において最も重要だったのは、各データソースからの情報集約です。 Google Analytics Data API（GA4）や BigQuery REST API に対して、Cloudflare Workersから直接HTTPリクエスト（fetch）を送信し、データを取得します。

エッジ環境（Node.jsの完全な互換環境ではない場合がある）からGoogleのAPIを叩く際、サービスアカウントのJSONキーを使ってJWT（JSON Web Token）を生成・署名する必要があります。現在は jose などの軽量な暗号化ライブラリを使用することで、Workers上でも簡単にGoogle APIの認証トークンを生成し、BigQueryのクエリ結果やGA4のPV数を取得できます。

工夫したポイント：キャッシュ戦略 APIを都度叩くと、Google側のAPI制限に引っかかったり、ダッシュボードの表示が遅くなったりします。そこで、Workers KVをキャッシュ層として利用しました。 「1時間に1回だけGoogle APIを叩いてKVに結果を保存し、ユーザーがダッシュボードを開いた時はKVのデータを返す」という設計にすることで、外部APIのレイテンシに依存しない爆速のダッシュボードを実現しています。

手入力指標との共存とカンバン連携

一方、商談の進捗や「次に誰がどのアクションをするか」といったタスク情報は、自動取得することができません。 これらは画面上に実装したカンバンボード（TrelloのようなUI）で管理します。

カンバンのタスクデータは、Cloudflare D1（リレーショナルデータベース）に保存しています。 ブラウザ側から「タスクを『商談中』から『受注』にドラッグ＆ドロップした」というアクションが起こると、WorkersのAPIエンドポイントに非同期リクエスト（Fetch APIやhtmxを利用）が送られ、D1のレコードが更新されます。

**「自動集計される客観的な結果（BigQuery/GA4）」を見ながら、「自分たちが今取り組んでいる手動のタスク（D1のカンバン）」**を操作できる。これこそが、既存のBIツールにはマネできない内製オールインワンダッシュボードの真骨頂です。

4. 開発時のつまずきとUIの再設計

順調に開発が進んだように見えますが、実は初期段階で大きなUI/UXの失敗を経験しています。

1画面詰め込みの失敗

当初、「情報は1箇所にまとまっている方が一覧性が高くて良いだろう」と考え、KPIの折れ線グラフ、GA4のテーブルデータ、そして営業フェーズごとのカンバンボードを、すべて1枚の巨大な画面に詰め込みました。

結果はどうだったか。 「これだけ見ればすべてわかる」はずが、**「情報が多すぎてどこを見ればいいか全くわからない」**という最悪のUXを生み出してしまったのです。 グラフは小さくなり、カンバンはスクロールしないと見えず、メンバーからは「前のLooker Studioの方が見やすかった」という残酷なフィードバックをもらう羽目になりました。

「複数ページ＋左サイドバー構成」への刷新

この失敗から、「情報を集約すること」と「1つの画面に押し込むこと」は別問題だと学びました。 すぐにUIの再設計を行い、**「左サイドバー＋複数ページ構成」**へと大幅に刷新しました。

具体的には、画面左側にナビゲーションバーを固定し、以下のように目的別のページを用意しました。

• 「サマリ（ダッシュボード）」：全社の主要KPIの現在地だけを大きく表示
• 「マーケティング」：GA4の流入データや広告成果の詳細グラフ
• 「営業カンバン」：商談フェーズと各案件のタスク管理
• 「開発カンバン」：機能改善やシステム運用のタスク管理

Cloudflare WorkersとHonoのルーティング機能を使えば、マルチページ構成にしてもページの遷移は一瞬です。 各画面の役割が明確に分かれたことで、「今日はマーケの数字が悪いからマーケティングのタブを見よう」「数字の確認が終わったから営業カンバンに切り替えてタスクを動かそう」というように、ユーザーの思考に沿ったスムーズな運用が可能になりました。

5. 運用成果とまとめ

週次PDCAが定着するまでの組織の変化

この「Cloudflare Workers製オールインワンダッシュボード」を導入してから、チームの動きは劇的に変化しました。

朝、Slackに送られてくるサマリ通知を見て、気になったメンバーが自発的にダッシュボードのURLを開く。 週次のミーティングでは、Looker StudioとNotionをいったりきたりする無駄な時間がなくなり、全員が同じダッシュボード画面を見ながら議論するようになりました。 「この数字（KPI）が足りないから、このタスク（カンバン）を優先しよう」という意思決定がその場で完結し、組織のPDCAサイクルが確実に回るようになったのです。

ツールを統合したことによる業務効率化はもちろんですが、「形骸化しない仕組み」を自分たちの手で構築できたことは、開発チームにとっても大きな自信に繋がりました。

おわりに：内製ツール開発やダッシュボード構築でお悩みの方へ

「ダッシュボードを作ったけれど誰も見ない」「KPI管理とタスク管理が分断されている」 こうした課題は、多くの企業が抱える共通の悩みです。本記事でご紹介したように、Cloudflare Workersを活用することで、インフラ保守の手間をかけずに、自社の業務プロセスに完璧にフィットした「生きたダッシュボード」を構築することが可能です。

もし、「自社でも同じような課題があるが、内製するリソースや知見が足りない」「要件定義から一緒に考えてほしい」という方がいらっしゃいましたら、ぜひGrandreamへご相談ください。 AIと開発を軸にしたプロフェッショナルチームが、貴社の課題に寄り添い、現場で「本当に使われる」業務システムや社内ダッシュボードの開発をご支援いたします。