Taku | 六本木アナリティクスエンジニア

六本木の某企業で働くAnalytics Engineer。LINE、リクルートなどでデータ分析経験。dbt/snowflakeなど、モダンデータスタックの実践知識を発信しています。

[高橋光 | 著書『データ分析力を高める ビジネスパーソンのためのSQL入門』 @light940]

kubellによるデータ民主化を整理した内容。AIでSQLの壁が消えた今だからこそ「ヒトと環境の噛み合わせ」の設計がより重要になるという視点がとても参考になる。
https://t.co/tKHRmFlo2V

・ローデータ開放による野良ダッシュボード乱立など4��のアンチパターンを整理
・AIを正しく機能させるセマンティックレイヤーの構築とアナリティクスエンジニアリングが民主化の土台になる

[たくまん @takumanken]

Text2SQL vs セマンティックレイヤーの網羅的な検証記事。Text2SQLの精度進化の恩恵をより多く受けるためのデータモデルの整備と、ガードレールとしてのセマンティックレイヤーの整備がしばらくの定石になりそうな印象。
https://t.co/GNjD2tsBcC

[Taku | 六本木アナリティクスエンジニア @aelabdata]

EasyよりもSimpleな設計。

社内の公式ダッシュボードのソースにOne Big Table（OBT）を使うか議論。
OBTは何でも入っていて一見「イージー」。でも、使っていないカラムのエラーの影響を受けたり、保守性がわるい。
ダッシュボードに必要な最小限のdim/fctに絞る「シンプル」な設計に。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

AIで設計や実装がラクになっ��分、正直「自分でやり遂げた感」が薄れてモヤモヤしていた。

自分のドーパミンは、人とディスカッションして予期せぬ気づきを得た瞬間にこそ出る。

作業はAIに任せ、人ともっと熱く議論して、前に進むことにやりがいを求めていこう。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

予実ダッシュボードのデータ整備を言語化。

・dim/fctをOBT化してJOIN
・発生日別集計で粒度を統一
・横持ちで指標を整理し、計算指標作成
・最後は「縦持ち＋Window関数」で予算・前年比を並べる

���の「縦持ち変換」をすることでunion allを減らせるし、予実・前年比較が柔軟に可視化できる。

[ikki / stable代表 @ikki_mz]

名前出していただけたので、紹介！
https://t.co/Gped5otJdk
#DataEngineeringStudy

[harry @gappy50]

書きました📝
AIに分析のためのデータエンジニアリングしてもらう未来はもう来てます🪄

Claude Code Agent Teamで実現するAIのためのデータ品質向上プロセス｜harry https://t.co/AX1aSNNqC6 #zenn

[ikki / stable代表 @ikki_mz]

いい事例。

・コードでデータ可視化できること
・Snowflakeにデプロイできること
・最近のリリースでアクセス制御もしやすくなったこと

により、Streamlit in Snowflake が最強になっていっている感がありますよね��ツールに限らず、データ集計・可視化の仕事は人間の仕事ではなくなってきている。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

dbtでData Vaultを実装するなら、パッケージ選びが最初の大きな分岐点。

主要な「AutomateDV」と「datavault4dbt」の違いを、設計思想とアプローチの観点で整理。

迅速な立ち上げならAutomateDV、厳格な全社統制ならdatavault4dbt。

[Jun Naito / 内藤 純 @njun_data]

ダッシュボードを自然言語で作れるようにするのはめちゃ低コストでもうできますよ、という話を書きました　Evidence今のところ良さそうです　プロダクトの名前もいいですよね

ダッシュボードの保守がつらすぎて、全部AIに投げたら戻れなくなった - 今日もデータで飯を食う。 https://t.co/NuL6udlYi0

[Taku | 六本木アナリティクスエンジニア @aelabdata]

1つのファクトに対して複数の値を持つ（多値属性）場合のモデリング手法。ブリッジテーブルを活用しよう。

患者の診断の場合：
1回の来院（ファクト）に複数の診断コードが付く（多値Diagnoses）

❌ ファクトに複数の診断キーを直接持たせる
✅ ブリッジテーブルを活用する

#データモデリング

[Taku | 六本木アナリティクスエンジニア @aelabdata]

「dbtで綺麗なモデルを作ったのに使われない」

この悲劇を避けるには、アナリティクスエンジニア（AE）が「データスチュワード」の役割を兼任する覚悟が必要。環境整備（システム）だけでなく、DAの悩み相談やカタログ整備（組織）まで横断してこそ、データは初めて価値を生む。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

モダンデータスタックが普及した今こそ、Kimballの古典が輝く。

OLAPキューブの概念は、単なる「多次元」ではなく「ビジネスをどう切り取るか」のフレームワーク。データに「意味（セマンティクス）」を与える。

ディメンションを整理することで、初めて指標は信頼に足るものになる。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

90カラム超のOBTを設計中。カラム名の「命名規則」を徹底したら、使い勝手がよくなる予感。

🔹ドメインで固める（mkt_, sale_）
🔹型を語尾で保証（_amt, _at, _date, _count）
🔹英単語は徹底ダイエット（mgmt, mkt, comp）
#データモデリング #アナリティクスエンジニア

[Taku | 六本木アナリティクスエンジニア @aelabdata]

Factは役割ごとに3種類を使い分ける

モデリングの巨匠Kimballが提唱した、Factの3つの型：
1️⃣ Transactional: 「���つ、何が起きたか」のイベントログ。
2️⃣ Periodic Snapshot: 「一定期間の残高や累計」を定点観測したもの。
3️⃣ Accumulating Snapshot: 「開始から終了まで」の全工程を1行に。

[Taku | 六本木アナリティクスエンジニア @aelabdata]

DimとFactを「なんとなく」決めていませんか？

データソースにあるテーブルをそのままFactに変換するのは、「設計を放棄した」のと同じ。ビジネスのライフサイクルをどう切り出すか。

その設計思想が最も現れるのが「Factの3分類」の使い分けです。
#AnalyticsEngineering #dbt #データモデ���ング

[Taku | 六本木アナリティクスエンジニア @aelabdata]

dbtやSnowflakeの運用で「速度とガバナンス」の板挟みになったら、GitLabのハンドブックが参考になる！

✅Ad-hoc：速度優先、プロトタイプ用
✅Trusted：テスト、レビュー、カタログ登録が必須

最初はAd-hocでクイックに、価値が見えたらTrustedへ
https://t.co/sg7fmFyeMs

[Taku | 六本木アナリティクスエンジニア @aelabdata]

ダッシュボード制作で一番やってはいけないのが「いきなりBIツールで作���始める」こと。

✅いきなり作り込まない
✅まずはモックで期待値を調整
✅利用者の「欲しい」を可視化する

モック作成はhttps://t.co/DnMhe5itr1 が無料版でもプロトタイプが作れて便利！

[Taku | 六本木アナリティクスエンジニア @aelabdata]

ガイドラインは「作る」ことより「守り続け、浸透させる」ことの方が100倍難しい。

dbt project evaluatorのデータを可視化して、ベストプラクティスへの適合率を「定点観測」できるようにしました。データは仮想です。
#dbt #アナリティクスエンジニア

[Taku | 六本木アナリティクスエンジニア @aelabdata]

アジャイルデータモデリングのBEAM*手法で、ビジネスサイドと対話。現状のテーブルはカラム過多でカオスだったが、7Wで解体すれば、シンプルに整理できた。

「システムにあるから作る」のではなく「共通言語で対話して設計する」。