日次で数字が自動更新される仕組みを、
一人でゼロから

着手前の状態

この仕組みを作る前は、こんな状態でした。

• アプリにデータは日々溜まっていくのに、それを見る手段がない
• 売上や注文の集計は、必要になるたびに手作業
• 社内にデータ担当はいないので、誰かに任せることもできない

規模の大小を問わず、多くの事業で起きているのと同じ状態です。

構成の全体像

なぜこの構成にしたか — 3つの設計判断

1. 01

   BIツールを使わず、HTML＋静的配信で見せる

   「見る側の負担ゼロ」と「壊れにくさ」を優先しました。

   グラフと数値を埋め込んだHTMLを生成し、S3＋CloudFrontで配信。閲覧はブラウザで開くだけです。 BIツールのライセンス費が発生せず、操作を覚える必要もなく、壊れる部品が少ない。 そのぶん、市販のデータ基盤と比べて大幅に低い費用で運用できています。

2. 02

   dbt＋elementaryで、数字の品質を常時監視する

   「数字が出る」より「数字が信用できる」を優先しました。

   データの変換はdbtで管理し、約60本のテストで整合性を常時チェック。 さらにelementaryで品質と更新の鮮度を監視し、どこかが壊れたらすぐ気づける状態を先に作っています。 数字を見て判断する以上、その数字が信用できることが最低条件だからです。

3. 03

   生データをそのまま残す層（S3）を挟む

   取り込みと変換を切り離し、あとから再処理も引き継ぎもできるようにしました。

   仕様変更があっても生データから再処理でき、担当が替わっても追跡できます。 さらに、データ元が変わっても影響は取り込み層で止まるため、 基幹システムでもSaaSでもファイルでも、Snowflake以降の仕組みはそのまま使い回せます。

規模と稼働実績

データモデル	dbtモデル 約110本／テスト 約60本
オブジェクト	全 約75（SRC〜MARTの階層構成）
データ量	約25万行・約10ヶ月分
更新頻度	日次バッチ（1日1回）
稼働	約2ヶ月連続稼働・成功率 約99.7%

※ 数値は掲載用に丸めた実測値です。

いちばん詰まった所と、その解き方

テナント（店舗）を追加するたびに手動作業が入る設計には、したくありませんでした。 手動オペレーションは、いつか必ず事故と属人化の原因になるからです。

そこで、アプリ側に新しいWebAPIを用意してもらい、それを呼び出して内容を検証し、 Snowflake側のテーブル作成まで自動で行う仕組みを作りました。 テナントが増えても、人手を介さずスキーマが払い出されます。

これは技術だけで閉じる話ではなく、先方に実装をお願いし、仕様をすり合わせる調整も含めた設計でした。 「手動オペレーションを入れない」を原則に据えると、そうしたコミュニケーションまでが設計の一部になります。 大変でしたが、この構成の壊れにくさを支える要になっています。

この構成から提供できること

このケーススタディと同じ考え方で、次のようなことができます。

• 毎月のレポート作成の自動化
• 複数のツールに散らばったデータの統合
• データ担当を雇えない規模での、データ基盤の構築と運用

データの置き場所は、基幹システム・各種SaaS・スプレッドシート／CSVなど、お使いのものに合わせます。 業種を問わず、規模に合わせて同じ考え方で組めます。

← トップへ戻る