経営数字を毎朝そろえるデータ基盤
複数の業務サービスに散らばった数字を毎朝8時に1か所へ集約し、経営・PM・経理が同じ正しい数字を見られる基盤です。
拡大表示（別タブで原寸を開く）Supabase Edge Functions (Deno) / PostgreSQL 17 / pg_cron
案内役のデジコと、約3分のノベルゲームで要点をつかめます（読むのは苦手という方に）。
このPoCから得た実装知
- 1アプリから各SaaSを直接叩かず、raw/martの基盤を1つ挿むと壊れにくくなる
- 2同期は失敗前提。自動リフレッシュ＋3回リトライ＋Slack通知で自己回復させる
- 3機密データ（給与・売上）は基盤側のRLS・ロールで閉じ、アプリ実装に依存させない
判断材料
- AI 権限レベル
- 見るだけAI
- 想定対象部門
- 経営管理部門
このPoCが向いている会社
以下に1つでも当てはまる会社では、効果が大きい。
- 業務データが freee/board/Backlog など複数SaaSに分散している
- 役割ごとに「正しい数字」を出すのに毎回手集計している
- 経営・PM・経理が別々のスプレッドシートを見ている
- 給与・売上など機密データを含み、誰が何を見られるかを厳密に管理したい
経営インパクト
業務データが各SaaSに分散し、役割ごとに正しい数字を出せなかった
朝8時までに4サービスからデータを集約し、各役割へ正確な数字を配信
- 削減時間
- 月次の手集計 → 毎朝自動更新
- 減ったリスク
- 数字の食い違い・手集計ミスの低減、機密データのアクセス制御
- 判断の改善
- 月次PL・案件health・キャッシュフローを毎朝の判断に使える
このデータがあれば、これができる
- ▸1つのSaaSのAPIキー/OAuth（例: Backlog）
- ▸Supabaseプロジェクト
- ▸日次自動同期
- ▸1つのmail・mart（例: 開発ベロシティ）
- ▸同期状況の可視化（sync_status）
- ▸freee会計/人事労務・board・Backlog のOAuth
- ▸Slack Webhook
Pain：どんな痛みがあったか
- 月次PLやキャッシュを見るのに集計待ち
- リアルタイムに数字が分からない
- 案件の予算・進捗・遅延が board/Backlog に分かれて全体が見えない
- freeeとboardの突合が手作業
- 給与など機密データの取り扱いに気を遣う
- 各SaaSのAPI・OAuth・同期失敗対応が属人化していた
Intent：なぜ作ったか
各SaaSに分散したデータを1つに集約し、役割ごとに「正しい数字」を毎朝届ける。用途別アプリは個別にAPIを叩かず、この基盤だけを見ればよい状態にする。
最初の1週間でやること
- 接続する1サービス（例: Backlog）を決める
- OAuth/APIキーを発行し日次同期を回す
- 1つのmail・mart（例: 開発ベロシティ）を作る
- sync_statusで同期の成否を毎朝確認する
やらないこと
- いきなり全サービスを繋がない（1つずつ）
- アプリから各SaaSを直接叩かない
- 給与など機密をアプリ側のRLS頼みにしない（基盤で閉じる）
- クライアントにservice_roleを露出しない
費用対効果の考え方
- 役割別の手集計にかかる工数
- 数字の食い違いによる手戻り・不信
- 月次締めの遅れ
- 機密データ漏洩リスク
業務データ基盤の代表事例 — 1つ集約すれば、多くのアプリが正しい数字を見るだけになる
各SaaSに散ったデータを毎朝1つに集約。経営・PM・経理が同じ正しい数字を見る。
導入前チェックリスト
商談前に、自社側でこの 5 点を確認しておくと検討がスムーズに進む。
対象となるデータは、自社のどこにあるか
この PoC が扱うデータ: freee会計 / freee人事労務 / board / Backlog / Supabase
そのデータの更新頻度はどれくらいか（毎日 / 週次 / 不定期）
人間の承認が必要な操作は何か
この PoC は閲覧・通知のみで、書き込みは行わない
想定どおり動かないとき、止める方法はあるか
この PoC の止め方: ソース（freee/board/Backlog）からは読み取りのみ。書き込みは自社Supabaseに限定。同期を止めてもデータ更新が止まるだけで、源泉のSaaSには影響しない
社内の担当者は誰か（運用・データ・承認の窓口）
想定担当: 情シス・データ担当 / 各SaaSの管理者（freee/board/Backlog）