Frosty Fridayでの学び合いを見ていて、「こんな関数あったんだ！」という発見が共有されている場に触れました。コミュニティっていいなと。

ここまで11本書いてきました。Snowflakeの機能を調べ、Cortex Code CLIを触り、BigQueryとの比較もした。でも振り返ると、一番大事なのは技術じゃなかった。

シリーズの振り返り

11本を通じて見えたことを整理してみます。

記事技術的な学びそれより大事だったこと
①②③ DWH・Snowflake概要DWHの仕組みと設計思想「なぜデータを整理するのか」の言語化
④ Cortex Code CLI自然言語でSQL「何を聞けばいいか」は人間が決める
⑤ Time Travel / Cloningやり直せる安心感「壊しても大丈夫」が始める勇気になる
⑥⑦ 地味な機能群SEARCH、HyperLogLog等地味な改善が現場を変える
⑧ AI Readyなデータデータ整備の重要性AIの前にデータ整理が9割
⑨ dbt壊れないデータ基盤属人化の解消
⑩ BigQuery vs Snowflake両者の比較「どっちでもいい」が本音
⑪ Icebergオープン形式「やめられる自由」が信頼

本当に必要だったもの

自治体・中小企業のデータ活用で見えた「本当に必要なもの」は3つです。

① 「何を見たいか」を言語化できる人

CDO的な役割です。フルタイムのCDOじゃなくていい。

「売上を見たい」じゃなくて、 「売上の何を、なぜ見たいか」 を言えるかどうか。この問いを立てられる人が一人いるだけで、データ活用の方向が定まります。

② 週1回でいいからデータを見る習慣

高機能なダッシュボードより、 週1回見る習慣 の方が100倍大事です。

月次レポートを年1回作るより、簡易ダッシュボードを毎週見る方が成果が出る。「習慣」はツールでは作れない。人がやるしかない。

③ 「わからない」と言える文化

「このデータの意味がわからない」と言える環境。「この数字、おかしくない？」と疑問を持てる環境。

あるお客さんの会議後に、担当の方が自分でNotebookLMを触り始めていました。好奇心がある人は伸びる。大事なのは環境と文化です。

ダッシュボードを作ったのに誰も見なかった話

過去に経験した失敗があります。

綺麗なダッシュボードを作りました。データも正確、更新も自動化。でも3ヶ月後に確認したら、 ログインした人が3人しかいなかった 。

なぜ見られなかったか：

  • 「何を見るべきか」が共有されていなかった
  • ダッシュボードの使い方のレクチャーだけして、「なぜ見るのか」を伝えていなかった
  • 見なくても業務が回ってしまう環境だった

技術的に完璧でも、使われなければ意味がない。 「作る」の前に「なぜ見るか」を一緒に考える時間が必要 だと学びました。

コミュニティの力

一人で全部わかる必要はない。

Frosty Fridayでは毎週金曜にSnowflakeのチャレンジ問題が出題されて、「こんな関数あったんだ！」という発見が共有されている。dbt Tokyoではdbtユーザーの日本コミュニティが活発に情報交換している。

AIとコミュニティの知恵を組み合わせる時代です。ビジネス要件からデータベーススキーマを設計するプロンプトを共有している人もいて、こういう知識の共有が全体の底上げになる。

まとめ

12本書いてきて、一番の学びは 「技術は手段」 ということです。

SnowflakeもBigQueryもdbtもMetabaseも、使う人がいなければただのインフラ。

必要なのは：

  • 「何を見たいか」を考えられる人が一人
  • 週1回データを見る習慣
  • 「わからない」と言える文化

その上で、ツールはちゃんと選ぶ。安心して使えて、やめたくなったらやめられて、壊しても戻せるもの。

そういう基盤を一緒に作れるパートナーを見つけてもらえたら嬉しいです。

このシリーズは、BigQueryメインのデータエンジニアがSnowflakeを触りながら書いた記録です。データ活用について相談したいことがあれば、気軽にご連絡ください。

横関 哲 — 株式会社DataBake