Snowflakeという名前を、最近よく聞く。
企業のデータを集めて分析するための、すごい何からしい。
ただ、説明を読んでも「クラウドデータプラットフォーム」とか「データウェアハウス」とか、分からない言葉がさらに増えていく。
困ったので、詳しそうな後輩に聞いてみることにした。
「先輩、Snowflakeって知ってます？」
後輩にそう聞かれて、一瞬だけ考えた。
「……雪？」
「違います」
即答された。
「じゃあ、あれだ。最近よく聞くITのやつ」
「急に解像度が下がりましたね」
「データベースみたいなもの？」
「かなり雑に言えば、まあ」
「じゃあOracleみたいな？」
「違います」
「どっちなんだよ」
どうやら私は、まだ入口にも入っていないらしい。
Snowflakeは「レジ」じゃなくて「作戦会議室」
「先輩、居酒屋を経営してると思ってください」
「なんで居酒屋なんだ」
「先輩でも分かりそうだからです」
「言い方」
後輩によれば、Oracleのようなデータベースをものすごく単純化すると、「高性能なレジ」だと思えばいいらしい。
客がビールを3杯飲んだ。焼き鳥を5本食べた。会計は4,280円だった。
そういう日々の取引を、間違えずに記録していく。
「じゃあSnowflakeは？」
「作戦会議室です」
「急に偉くなったな」
各店舗の売上、在庫、会員データ、Webサイトへのアクセス履歴。
あちこちに散らばっているデータを集めて、
「去年の夏、雨の日には何が売れた？」
「この商品を買った人は、その後何を買っている？」
みたいなことを考える場所だという。
「だったら、最初からレジのデータを分析すればいいじゃない」
「先輩がレジ締めしてる横で、僕が過去5年分の全店舗の売上を集計し始めてもいいですか？」
「やめてくれ」
「そういうことです」
「なるほど」
これは分かった。
日々の業務を動かす場所と、大量のデータを使って考える場所は分けたほうがいい。
Snowflakeは、後者のための場所なのだ。
そんな巨大な作戦会議室、本当に必要なのか
ただ、まだ腑に落ちない。
「でもさ。普通の会社に、そんなもの本当に必要なの？」
「じゃあ航空会社を考えてみましょう」
「飛行機？」
「飛行機は速くなりませんよ」
「まだ何も言ってない」
「言いそうだったので」
航空会社には、予約、運航、顧客、空港、機内サービスなど、とにかくいろいろなデータがある。
しかも、それぞれ別の仕事から生まれてくる。
日本航空（JAL）も、長年使ってきたデータウェアハウスをSnowflakeへ移行した。
従来の基盤には1,000を超えるテーブルがあり、長年の運用でかなり大きくなっていたという。
「テーブルって？」
「Excelのシートみたいなものだと思ってください」
「1,000枚？」
「ものすごく雑に言えば」
「閉じたい」
「閉じちゃダメです」
私ならそっと閉じる。
でも会社は閉じるわけにはいかない。
しかもデータは、保存しておけばいいわけではない。
仕事で使えなければ意味がない。
ANAでは「みんなで同じ数字を見る」
「似た話はANAにもあります」
「ライバルもやってるのか」
「そこは普通にANAって呼んでください」
ANAグループには「BlueLake」というデータ活用基盤がある。
予約や運航などのデータを、ダッシュボードで見たり、分析したりするための場所だ。
以前は必要なデータを現場でExcelに取り出し、加工してグラフを作るような仕事もあった。
考えてみれば、これは会社では珍しくない。
誰かがExcelを作る。
メールで送る。
別の誰かが直す。
「最新版.xlsx」ができる。
さらに直す。
「最新版_最終.xlsx」ができる。
「ありますね」
「あるだろ」
「最新版_最終2.xlsx」
「ある」
「最新版_最終2_修正版.xlsx」
「もうやめろ」
問題はファイル名ではない。
同じ会社なのに、みんなが少しずつ違うデータを見ていることだ。
BlueLakeのような共通基盤があると、同じデータを共通のダッシュボードから見られる。
言葉にすると大げさだが、やっていることは意外に素朴だ。
みんなで同じ数字を見る。
まずはそこからなのだ。
で、俺はSnowflakeを使えるの？
ここまで聞いて、もっと根本的な疑問が出てきた。
「Snowflakeに会社中のデータが入ったとしてさ」
「はい」
「俺、それ使えるの？」
後輩が黙った。
「なんで黙るんだ」
「SQL書けます？」
「書けない」
「Pythonは？」
「ヘビなら知ってる」
「だと思いました」
「先輩を何だと思ってるんだ」
でも、これは大事な話だ。
どれだけ立派なデータ基盤を作っても、それを使えるのが一部の専門家だけなら、普通の社員にとっては巨大な倉庫が遠くにできただけだ。
「じゃあ結局、専門家に『この数字出してください』って頼むの？」
「それだと、あんまり変わってないですよね」
「確かに」
「だから、もう一個出てきます」
「まだあるのか」
「Streamlitです」
「また知らないやつが出てきた」
そこでStreamlitが出てくる
Streamlitは、Pythonを使ってデータ分析用のWebアプリを比較的簡単に作るための仕組みだ。
「Webアプリって？」
「ブラウザで開いて、条件を選んだらグラフとか数字が出てくるやつです」
「それなら使える」
「先輩は使う側です」
「作る側じゃないの？」
「Python、ヘビなんですよね？」
「さっきの覚えてたのか」
Snowflakeには「Streamlit in Snowflake」という仕組みがあり、Snowflakeにあるデータを使ったアプリを作って共有できる。
そしてJALも、これを実際に導入している。
本部のKPIを見えるようにしたり、機内サービスを分析したり、空港ラウンジで必要になる飲食物の量を予測したりするアプリを作っている。
「それって、普通のシステム開発と何が違うの？」
「現場の人がかなり近いところにいるんです」
現場が「こういうものが見たい」と課題を出す。
DX部門がデータとつなぐ。
まず動くものを作って、現場に見てもらう。
そして直す。
「昔だったら？」
「要望をまとめて、システム部門にお願いして、作ってもらって……」
「できた頃には、俺が何を頼んだか忘れてそうだな」
「先輩の場合はありそうですね」
「一般論として言ったんだよ」
Snowflakeにデータがあるから、毎回データ探しから始めなくていい。
Streamlitがあるから、そのデータを人が使える「画面」にしやすい。
ここでようやく、SnowflakeとStreamlitが一本につながった。
変わっているのは、データベースではないのかもしれない
最初、私はSnowflakeを「ものすごく高性能なデータベース」だと思っていた。
でもJALやANAの使い方を見ていると、少し違うものに見えてくる。
昔なら、
「この数字が欲しいんですけど」
と誰かに頼んでいた。
担当者がデータを取り出す。
Excelにする。
メールで送る。
そこから分析が始まる。
Snowflakeのような共通基盤ができると、まず同じデータを見られるようになる。
そしてStreamlitのような道具が加わると、そのデータを現場の仕事に合わせた小さなアプリにできる。
データを「持っている会社」から、
データを「使える人が多い会社」へ。
起きている変化は、案外そちらなのかもしれない。
「分かった？」
後輩が聞いた。
「分かった」
「じゃあSnowflakeとは？」
少し考えた。
「会社のでっかい作戦会議室」
「……まあ、いいでしょう」
「偉そうだな」
「じゃあStreamlitは？」
今度は少し考えた。
「作戦会議室の情報を、現場の人でも使えるようにする道具」
後輩が少し黙った。
「……ちゃんと分かってるじゃないですか」
「だろ？」
「最初から普通に聞けばよかったのに」
それは言わない約束である。
参考にした資料
JALおよびANAの事例、Snowflake、Streamlitについては、以下の公開情報を参照した。
コメント