SnowflakeをCCCグループ内で広げるためにやったこと
はじめに
皆さんがSnowflake導入したもしくは使用する目的の一つとして、自分たちの部署だけでなく、事業全体や会社全体、グループ全体で利用させたい。データ統合や共有を実現し、グループシナジーを上げるといったテーマがあると思います。
一方でそれを実現するためには様々な労力を伴います。経営層の強い権限でトップダウンで導入を一気に進めると言った事例はありつつも、現場に近いところから手探りで導入や拡大を進めるという事例もあり、どのように進めて行ったのか、なかなか語られる事は少ないのではないかと思います。
そこで弊社が数年を掛けてグループの主要な企業にSnowflakeを導入し、活用が始まった今、私自身の振り返りを兼ねて、現場からどのようにボトムアップをしていき、各社へ導入を進めて行ったかをお伝えしたいと思います。
CCCグループの全体像
カルチュア・コンビニエンス・クラブ株式会社
20年以上このグループにいますが、いくつの事業をやっているのか、全く分かりませんｗ
非常に多くの会社がありますが、その中でも以下の4社が主要な会社となります。
カルチュア・コンビニエンス・クラブ株式会社
弊社の親会社であり、蔦屋書店などのライフスタイル提案事業、地域公共サービス事業
CCCMKホールディングス株式会社
Vポイントおよびデータベースマーケティング事業
カルチュア・エクスペリエンス株式会社
TSUTAYA事業
株式会社Catalyst・Data・Partners
出版業界向けデータ事業
私が所属するCCCMKホールディングスは、CCCグループの中でVポイント事業を担う事業会社となります。
現在、弊社を中心に主要4社にSnowflakeが導入されており、データシェアも既に行い始めています。
必ず成功する方程式はない
参考にしてください！と言っておきながら、誰がやっても必ず成功する方程式はないと思います。
私自身はCCCグループ共通基盤から離脱した個別基盤の構築、その後のクラウド移行、さらにそのクラウドDWHのSnowflake化と、長年に渡るレガシー脱却とモダン化をファーストペンギンとしてやってきました。そのため、グループ内においてある意味自分が一番チャレンジャーとして認知されていたことや、また弊社自身がデータに対する感度が高い会社でもあり、それらのチャレンジを会社や組織や仲間が応援してくれる、恵まれた環境だったことがとても大きな要因だったなと思います。
そして基本的に諦めも悪いタイプなので、色んなところにぶつかりながらなんとかやり遂げた経験をもとにこの話をしていることもあり、多分に生存者バイアスもあるだろうと思います。
そのため、自分自身のやり方は決して正解とは思っておらず、それぞれの会社やグループとの関係や自分の立場、経験値によって、正解ルートは無数にあると思います。
ただ立場、組織構造、既存の環境や個人のスキルに差はあれど、いくつかの共通項はあると思いますので、一つぐらい参考になるものがあるかも？ぐらいで話を聞いていただければと思います。
必要なマインド、アクション
さて、私が考えるマインドやアクションは以下の5つです
ロジカルなビジネススキルもあるに越した事はないと思いますが、やはり熱量であったり、周りを巻き込めるかが重要だと思います。
１．自分がSnowflakeが好きだと自信を持って言えること
２．自分が先頭に立つこと、巻き込むこと
３．信頼を得ること
４．未来を想像した検討を行うこと
５．コストを把握すること
1. 自分がSnowflakeが好きだと自信を持って言えること
いきなり、それかよ？と思ったと思います。自分でも思います笑
ただ感情の本能的要素として好きなものを話すとき、ヒトは笑顔になります。好きなものを話すとき、自信をもって話すと思います。笑顔で話す内容はポジティブな印象を与えますし、自信をもって好きと言えることで相手の興味を引き、説得力も増します。
また好きなところをいう過程で、必ず具体的なエピソードや機能や特徴の話になり、それは結果として良質のプレゼンテーションになります。
恥ずかしがらず、ある意味キラキラと話せるぐらいになるのを目標としていただければと思います。
なお、私は社内外を問わず、「Snowflakeの営業マンかと思いました」と良く言われます笑
2. 自分が先頭に立つこと、巻き込むこと
言うだけなら、口八丁手八丁で何とかなりますが、実際に導入するとなると多くの人に手伝ってもらう事になります。その時に自分が一番仕組みを理解し、汗をかき、率先してやることが重要です。
自分の組織内であれば自分の関係者であり、指示系統や協力関係で進むかもしれませんが、組織外となると調整や交渉が入る、そもそもやろうとしていることを理解してもらう事から始まる事も多いと思います。
会社や組織によっては、上位者から落としてもらう必要があるかもしれません。ただ自分の経験上、上から落としてもらうのは手伝ってもらっている人を動きやすくするためであって、やはり自分が真摯に説明し、頭を下げて、その人たちが納得して手伝ってもらう以上の協力関係は存在しないと思います。（とはいえ、無理やり手伝わせてた可能性はあるかもしれません・・いつもありがとうございます）
私がやりたい事≒みんなが良くなること、つまり会社に貢献すること、というマインドが重要で、周りの人は、私が語る、その良くなる未来を期待して手伝ってくれるわけです。なので、私のためじゃなくて、自分たちを良くするためと信じて一票を投じるような選挙みたいなもんだなとも思います。
なので、自分が巻き込んで得た、その一票は無駄にしちゃいけません。やり切りましょう。
先頭に立つだけでは、ついてこれない人たちがいます。そのためには一緒にやるという事が大事です。
つまり巻き込んだ以上は、相手に巻き込まれる覚悟も必要です。
付き添い、一緒に考えてあげることを通じて、自分もその技術をより理解する事が出来るようになります。
優れたエンジニアであっても、初めて扱うデータベースについて不安を抱えない訳はなく、そこに寄り添ってアドバイスやフォローをするというのは彼らの精神衛生上にとても良い効果があります。
私も子会社の分析基盤構築時に性能課題が出た際にはオフショアのエンジニアとクラスタリングキーの調査や改善などを一緒に実施をしました。またコストについてもある程度落ち着くまでは監視とアドバイスを行いました。
いつまで寄り添うのか？の基準は少し難しいですが、ある課題が出た時に、これをこう使えばいいんじゃないか？このやり方を試してみます！と言い出した時だと思います。
自転車の練習と同じですね。自走し始めた彼らを見て、少しずつ、手を放してみて、自己解決が出来るかどうかを見定めたらお役御免です。
とはいえ、困ったときにはすぐにアドバイスできる関係も重要です。私自身は出社比率が高いので、少し時間がある時は、フロアをブラブラ歩いて、みんなの様子を窺ったりもしています。
ある日、新人メンバーが何か抱えていそうだったので「順調そう？」と聞いてみると、『SnowflakeのMFA対応の切替がうまく行かないんです』と悩んでいたので、一緒にODBCやネットワークの設定やら見てあげて、「こういう風に切り分けしてみて」、「次この辺調べてみよか」、「PrivateLinkだから、〇〇〇周りの設定見直してみよ」『あ、通りました！』「やったじゃん！」『お手間取らせてすいません！』「いいよー、ブラブラした甲斐があった！」といった感じで一緒に検証を手伝ってあげました。
話が長くなりましたが、セーフティネットがあるという事はとても安心感につながるので、自分の役職とか立場に関係なく、「困ったときは、いつでも相談して！」と伝えたり、それを態度や実際の行動でも示していきましょう。
3. 信頼を得ること
これは最も難しいテーマですが、これが得られている状態はとても物事を進めやすくなります。実際に信頼されるかどうかは本人ではなく、周りが決める事ですし、また過度の信頼は盲信となり、ブレーキを掛ける人もいなくなるので、自戒の念を忘れずに進めましょう。
また信頼は目に見えないものなので、それを証明するためにもPoCなどはしっかりと実施して可視化する事が大事です。そのPoCにて効果ありとしたものが、実際の移行結果でもほぼその通りの結果になれば、仮説、検証、実行、評価のプロセスをしっかりと回せる人と認知される事やそのプロセスを残す事で再利用も可能となります。
Oracle⇒Vertciaの時に立てたPoC計画書と結果報告書はその後のVertica・Synapse・Oracle⇒Snowflakeの計画にすべて再利用し、またグループ会社にも共有しました。
とはいえ、PoCですべての課題が洗い出せる訳ではないので、そのリスクは認識した上で移行後に起きた問題は陣頭に立ち、クロージングするまで立ち続ける事が何より重要です。
クラウド移行の際はどうやっても性能が出ず、逃げそうになる気持ちも正直ありましたが、それでも信頼し、協力してくれる周りの仲間が後押ししてくれて、色んな手管も使い、なんとかやり遂げることが出来ました。あんなにみんな苦労したのにSnowflakeを入れたいと無邪気に言っても協力してくれるのは、何があってもやり遂げるし、良くするために先陣を切っているという認知をしてもらえてるからかもしれません。
つまり、言った事を実現するために最後までやり遂げるかどうかが重要で、その積み重ねでしか信頼貯金は増えないと思います。問題が起きても逃げずに向き合う事が重要です。
でも多分、これが一番生存者バイアスだと思うので、ほんとに無理！と思ったら、ちゃんと関係者と協議して最小のダメージで撤退しましょう。
実際、私も「上手くいきませんでした！すいません！」とPoCを打ち切ったり、プロジェクトを中止した経験もあります。その際はなぜ上手くいかなかったのか、どうしたら上手くいく可能性があったかを報告し、なにもかも無駄にしないようにしましょう。
そのためには撤退基準を設けておくのが重要です。とくにノックアウト条件（これが満たせないなら他をOKでもダメ）を決めておくとより明確に判断が出来るようになります。
4. 未来を想像した検討を行うこと
これは少し幅広いテーマになりますが、事業の方向性、アーキテクチャのトレンド、今の現有資産の寿命など時間軸を意識して、基盤を考えましょう。
弊社の場合は、オンプレのレガシー資産が多かったので、それらをいつ更改するか、それに向けてどういうアーキテクチャを考えるかを意識して取り組んできました。またクラウドに移管したDBについてもリザーブドインスタンスの契約期間があり、例えば3年リザーブドの契約を更新するという事は向こう3年間のシステムアーキテクチャを固定する事と同義になります。
基本的には契約更新やハードウェアのEOLに合わせ、次のアーキテクチャを検討し、導入まで完了出来るように逆算のスケジュールを立てる必要があります。
この考え方は結構しんどいです。今やるべき事は常に山積みですが、それでも将来に向けた準備をすることを自分にもメンバーにも強いることになります。
ただそれに取り組まないと、その期限までに何も検討出来ず、ただ時間が足りず、インフラの単コンやリソースの増強だけを行い、事業を支えるべきデータドリブンな基盤を自分たちで陳腐化させる事になります。リーダーになれなばるほど、今やるべきことと将来に備えることをパラレルに考えることを求められます。
色々言いましたが、まとめると将来的な事業やITの周辺動向を踏まえたアーキテクチャの構想を立てつつ、自分たちのアーキテクチャのライフサイクルに合わせ、スムーズに移管出来るように計画を立てる事が重要です。
また環境によってはブラックボックスになったレガシーな基盤や歪な構成になっている基盤がある場合もあります。こういう場合、その担当者はとても辛い立場であり、どうしていいか分からない場合もあります。そういうシステムの場合、変える事へのハードルが高く、モチベーションが湧きづらいことがあります。
その状況を何とかしないのは、「あなたの問題だ」と言っても何も変わりません。どんなにブラックボックスであっても、「今なんとかしないと、数年後、自分の後輩や部下にこのシステムを引き継ぐことになるよ。それでも良いのか？」 と優しく聞いてあげましょう。おそらくハッと気づくと思います。
そういう顔になったら、「絶対に良くなるから今からでもやろう！手伝うよ。」 と伝えましょう。きっと前を向いて、改革へ歩き出してくれると思います。
実際、私の直下でも古い販売管理システムをコスト面で残すという判断をした部下に対し、私から上記のようなメッセージを伝えました。その際も気付きがあったようで、「もう一度再考します」と持ち帰り、利用部門とも「これを残す事で失うものはなにか」を再度検討し、業務自体を見直し、機能を最小化した上で既に構築していた業務システムへ統合する意思決定を会社全体で行う事になりました。
当初の残した方がコストが安いという判断も業務そのものを深く見直したことで移管対象が減った事もあり、統合したことでインフラコストは削減しつつ、移管コストはそこで吸収し、むしろ業務システムが一つになり、かつ最適化したことで業務効率が上がる結果となり、部下は「業務に踏み込んだ提案を出来る人材」、「利用部門も全体最適を考えられる部門」として評価を上げることになりました。
また契約面でも将来を予想して動くことも大事です。グループ会社あるあるかもしれませんが、子会社単体で契約するか、グループで契約するかの選択肢があります。
Snowflakeを最初にCCCMKで導入する際も、Snowflakeとの契約はCCC本体、つまりグループでの契約にしたいと進言しました。もちろん子会社単体で契約した方がスムーズなのですが、将来的にグループで使う可能性が高いのでCCCで契約すべきと判断しました。
契約や価格交渉などは私が中心となり、実施したのですが、最終的な契約手続きはCCC本体で実施をしてもらいました。我ながら無茶振りでCCC本体の各関係者は面倒だっただろうな。。と思いますが、結果的にグループ新会社のCDP社の基盤構築の際にすぐに利用できたので、この判断は正しかったと思っています。また子会社ではなく、グループでの契約というのは交渉面でも大きな効果があると考えられます。
何等かの導入においては必ず価格交渉をする事になると思います。グループで契約するということは将来的な売上拡大の見込みを営業は考えると思います。その情報は彼らが上位者へ報告する際にもダイレクトに使える表現です。個人的には営業交渉において伝えるべき情報は、直接的な値引要求ではなく、相対している営業が上位者へ伝えられる情報をインプットする事だと思っています。
その点では子会社ではなくグループで契約するというのは将来与件として考慮してもらえる情報となります。
また私は、PoCではコストまで評価するようにしています。これはどれぐらいのコスト以下になるのであれば導入が可能か？という営業が社内で交渉するにおいての有益な情報となるからです。
あまり書くと色んな担当営業から怒られそうなので、これぐらいにしておきましょう。
さて話を戻します。経営承認を得る際に、私は弊社がこれからデータ活用の次元を高める上で、データコラボレーションの基盤が必要と説明しました。
その後、SMCCとのデータ連携では、実際にSnowflakeを使ったクロスクラウドのデータシェアを実現することができました。ある意味、経営向けのメッセージでしたが、具体的に実現できたこと、かつそれがSnowflake社から見ても価値ある取組と映り、その年のSnowflake World Tour Tokyoで基調講演の登壇依頼をいただいたことは嬉しい限りでした。
そしてSnowflakeは、その取引企業数からデータコラボレーションの可能性をさらに感じさせる、大きなエコシステムになってきたと感じています。そしてこのような取組みをさらに増やし、自分が宣言したことの実現をもっと広げたいと考えています。
5. コストを把握すること
どこまでのコストを把握し、それがどう変動出来るかを理解すると取れる選択肢が大幅に変わります。いかに最新のアーキテクチャや未来志向とはいえ、コストメリットが見いだせないものは経営的に承認が出来ません。
オンプレの基盤のコストや次回更改する場合はいくらかかるのか、その保守費や人件費がどうなっているのか、クラウドであれば、リザーブドインスタンスのような契約期間の更新タイミングを踏まえた現状コストや再契約時のコスト、増強する場合のコストなどを把握しておくのが重要です。
それにより、いつリプレイスするのが最も財務上のインパクトが少ないかを十分に把握する必要があります。
つまりコストの把握は「4.未来を想像した検討を行うこと」と合わせて実施することが重要です。
また投資承認をどのように取るか企業文化によりますが、定量コストと定性コストは個人的に分けるべきだと思います。
定量コストとしては、実際の損益計算書などに乗るファクトの数値（償却費や保守費、クラウドであれば利用料金やリザーブドの前払い費用、エンジニア費用、また重複する期間のコスト）を出すのがよいでしょう。
一方、導入による定性的な効果として、業務効率化などのいわゆる工数削減などの効果は、業務委託を減らせるなどの具体的なキャッシュアウトや経費上の効果がないのであれば、定性的な表現に留めるのが良いでしょう。
実際、より良いアーキテクチャになる事で今まで出来なかった事や手が回らなかった事にアサイン出来るようになり、効率化よりも事業貢献度の向上の方がポジティブなメッセージになると考えています。
実際この辺りの費用対効果、投資対効果はグループ間でシェア出来ることで各グループ会社のロジックを組み立ても楽にしていきます。
またコストの観点を多数持つ事で、自分の自身の選択肢を増やすだけでなく、誰かがこのようなサービス導入時に悩んでいる時のアドバイスをしやすくなります。コストの種類や金額、場合によってより広いコストを把握することは自分がやりたいことをやる上で非常に強力な武器になります。
コスト把握の具体的アプローチ
さて私が考える分析基盤を想定したコスト比較対象とそのアプローチを説明したいと思います。
現状コストの整理
オンプレの場合
・現インフラの償却費（本体ハード以外のネットワーク機器なども）
・現インフラの保守運用費
・ラックなどのDC内設備費用
・DBソフトのライセンス費用
・DBソフトの年間保守費用
・バックアップ環境費用
・災害対策環境費用
・現行ハードの廃棄コスト（クラウドなら掛からないコスト）
クラウドの場合
・現状のリソースコスト（従量課金、リザーブドインスタンスコスト・定額コスト）
・ネットワーク転送量（クラウド間など）
・バックアップストレージコスト
・DR環境（AZゾーンなど）
将来コストの予測
オンプレ
・次回更改時に掛かるコスト（上述のコスト項目）
クラウド
・次契約時のクラウドコスト（契約内容に沿って、R/Iの場合はスペックアップなど）
・スペック不足の場合の拡張コスト
共通
・為替/価格上昇リスク（例えば、保守運用費は毎年8%UPなど）
・オーバースペックになるリスク（特にオンプレやリザーブド）
移行関連コスト
・アプリケーションの移行費
・連携先システムとの方式変更コスト
・アナリストや利用者の切替コスト
・ETLやパイプライン、各自の内製ツールの切替（たまにある野良ツール注意）
・並行期間コスト
・クラウドはカットオーバー前から一定コストが発生
・保守運用費もカットオーバー前に支払いが発生
・現行ハードなどの除却コスト（廃棄とは別に残存簿価の除却）
周辺コスト
・監視ソフトやセキュリティソフト
・保守運用のエンジニア工数
・IaasやPaasのバージョンアップ、メンテナンス工数（地味に発生するコスト）
・性能不足の際に追加コスト（R/I系だと上位スペック化によるアップコスト）
・教育訓練費、サポート費用（※イノベータで採用すると無償でしっかりサポートしてくれるｗ）
定性的効果
・DBパフォーマンス向上による業務効率化、迅速性向上
・DB安定化による障害対応工数の削減
・モダン化によるモチベーション向上
・エコシステム形成による生産性や外部連携の効率化
・クラウド特有の継続的なパフォーマンス向上（コミットは出来ないが）
上記を全て整理すれば、基本的には現新コスト比較で十分にコスト削減効果は見込めると思いますが、移行コストが重荷になる場合があります。
その場合も次の更改に掛かる予想コストとの比較をすると、かなりの確率で採算性は見込めるようになります。
コスト比較イメージ
ここまで箇条書きではイメージが付きづらいと思いますので、イメージを可視化してみました。
※金額はイメージです。定性的効果や周辺コスト、廃棄除却コストなどは除外
クラウド ：3年ごとにリザーブドインスタンスのスペック強化による運用費増
オンプレ ：5年ごとにインフラ更改とその際のスペック増加による運用費増
Snowflake：初期移行費用はかかるが、ランニングが事業成長に合わせて少しずつ伸びる
また上記の費用のち、初期費用として掛かるもの、毎年発生する費用を分けるとより精緻なP/L予想値が出せる事になり、財務部門に安心してもらいやすくなります。
具体的な数値を出す事は出来ませんが、上記のようなコストをリストアップすることで漏れなく費用を算出し、適切な費用比較をすることで、入れ替えメリットを出しやすくなります。
この辺り、コストから話が逸れますが。エンジニア部門であっても、他部門の言葉で説明できると非常に社内調整はスムーズになります。
・事業部門：分析がしやすくなる、ユーザーの満足度向上
・分析部門：クエリパフォーマンスの向上、BIツールなどとの親和性
・財務部門：コストダウン効果、P/L計画
・経営 ：事業戦略に沿った基盤戦略、モダン化による業務効率化や生産性向上
・人事 ：モダンアーキテクチャ化による募集要項や人材定着における副次的効果
導入サマリとキャリア
現在、僭越ながら本部長を拝命し、経営に近い立場にいる事もあり、キャリアと共に拡大の歴史をサマリしてみました。
CCCMK：CCCMKホールディングス
CDP：カタリスト・データ・パートナーズ
CX：カルチュア・エクスペリエンス
CCC：カルチュア・コンビニエンス・クラブ
| 年度 | 事業会社 | フェーズと対象 | キャリア |
|---|---|---|---|
| 2020 | CCCMK | PoC：分析ASP | 課長補佐 |
| 2021 | CCCMK | 導入：分析ASP Verticaリプレイス | 課長補佐 |
| 2022 | CDP | 導入：分析基盤新規構築 | 課長 |
| 2022 | CCCMK | PoC：分析基盤 AzureSynapse/Oracle | 課長 |
| 2023 | CCCMK | 拡大：分析基盤 AzureSynapseリプレイス | 部長 |
| 2023 | CX | 導入：分析基盤 Oracleリプレイス | 部長 |
| 2024 | CCCMK | 拡大：SMFGとのDataSharing | 本部長 |
| 2024 | CCCMK | 拡大：分析基盤 Oracleリプレイス | 本部長 |
| 2024 | CX | 拡大：分析基盤 新規サービス | 本部長 |
| 2024 | CCC | 導入：統合DB新規構築 | 本部長 |
| 2024 | CX | 拡大：加盟企業向け分析基盤構築 | 本部長 |
詳細年表
2020年以前の弊社の分析基盤の歴史はこちらの記事を参照ください。
2021年：Snowflake導入
最初のSnowflake導入として、分析ASPのDWHであるVerticaをSnowflakeへ移行
2020年にSnowflakeに出会い、そのアーキテクチャの可能性を認識し、どのように採用していくかを検討しました。まずは自社が社外に提供している分析ASPのハードウェアのEoLが近づいていたため、その入れ替え候補先としてPoCを開始し、十分な性能が出ることを確認しました。また分単位のクエリ数などを元にSnowflakeに置き換えた際にクラスタの稼働時間やクラスタ数をシミュレーションし、オンプレで単純リプレイスするよりもコストが安く、またコスト柔軟性も高くなると判断し、本導入を上程しました。
ハードウェアのEoLに合わせたデータベースのリプレイスとすることで重複コストを最小にしたこと、クラウドファーストのIT戦略も踏まえ、EoL前までに十分な期間でアーキテクチャを検討したこと、パフォーマンスだけでなく、コストメリットもあり、その根拠をPoCで詳細に評価したこと、またデータコラボレーション機能が弊社のビジネスにとっての可能性があるアーキテクチャであることを熱く補足し、大きな異論は出ることなく承認されました。
その後、構築や移行は無事に完了し、移行後のトラブルなどもプロジェクトメンバーの協力で解消し、弊社へのSnowflake導入は完了しました。そしてこの結果を元に分散していた他のDWHをSnowflakeに移行する準備に入りました。
このプロジェクトの詳細な内容はこちらの記事を参照ください。
マインド・アクション
１．自分がSnowflakeが好きだと自信を持って言えること
２．自分が先頭に立つこと、巻き込むこと
３．信頼を得ること
４．未来を想像して、今やるべきと理解してもらうこと
５．コストを把握すること
2022年：グループ会社への導入
新規事業会社CDP社でのSnowflake導入と、自社内でのOracle/SynapseからのPoCを開始
20年にPoCを行い、21年にVerticaで稼働していたシステムをSnowflakeに移行し、弊社でのSnowflake導入が完了しました。
課長補佐という立場でしたが、Snowflakeをいずれ全社に入れたいと漠然と思いながらもまずは自社の分析基盤を全てSnowflake化する事に注力していました。
ただオンプレミスのEOLやリザーブドインスタンスの終了期間を考えると23年、24年の後半の入れ替えとなるため、しばらく猶予がありました。
その頃、CCC本体のCIOから新しく出来たグループ会社の分析基盤を担当して欲しいと頼まれました。
日本を代表する出版社から出資を受け、出版データのオープン化を目指し設立された新たな事業会社である、カタリスト・データ・パートナーズ社（CDP）が提供するサービスをイチから構築するプロジェクトに参画して欲しいとの事で、CCCMKでの業務をしつつ、CDP社との兼務となりました。
CANTERA（出版業界を照らすデータサービス）
こちらのサービスで、現在Snowflakeでしっかり稼働しております。
が、私が参加した22年10月の段階では、何一つDBもサーバもそもそもデータもまだ連携されていない、まっさらな状態で、半年後の23年4月にβ版のリリースすることだけが決まっており、CDP社が従来出版社向けに提供していた 「TSUTAYA DB-WATCH」 と 日本出版販売株式会社が同じく出版社向けに提供していた 「WIN」 を統合するというミッションゴールが設定されていました。
えっと・・無理じゃない？？というのが赴任日当日の感想でした。
プロダクト開発体制とSnowflake導入
その時点のプロジェクト体制
・プロダクトマネージャー
・私
・過去に取引のあったSier（リードエンジニアとエンジニア数名）
・社長に紹介されたベトナムオフショア会社（ブリッジSE＋オフショアエンジニア数名）
プロダクトマネージャーは、長年付き合いのある信頼できるリーダーで、役割分担を取り決め、兼務で100％参加出来ない私は、バックエンドの基盤のアーキテクチャを考え、構築する役割で分担しました。
まずは分析基盤のアーキテクチャを決めないと始まらないので、分析サービスの基盤はSnowflake、ETLやデータレイクの役割はDatabricksに分ける構成で提案しました。
弊社グループがAzureメインという事もあり、Databricksは何となく知っていたようですがSnowflakeはみな初めてのようで、「Snowflakeってなんですか？？」という反応でした。
と言う訳で、エンジニアメンバー全員を集めて勉強会を実施しました。
・Snowflakeのアーキテクチャの説明
・データシェアリングなどのオープンでセキュアな機能
・ウエアハウスのサイズに比例した線形パフォーマンスでコストコントロールしやすいこと
・チューニングがほぼ不要なニアゼロオペレーション
・BIなどの可視化サービスとの親和性
ベトナムのエンジニアの皆さんも最初は懐疑的だったものの、ユーザーIDを渡してハンズオン企画をやり、サンプルデータであるTPCデータなどを触ったり、UIを実際に操作してもらうことで、使いやすい！、分かりやすい！、速い！、これなら出来るかも！ と好意的な反応でした。
またSnowflakeは公式ドキュメントが充実していることもあり、その安心感も含め、まったく未知のDBでイチからシステムを作れ！ と言われているにも関わらず、メンバーはこれなら何とかなるんじゃないか？とポジティブに取り組んでくれました。
この辺り、"百聞は一見に如かず、百見は一験に如かず"（造語）だなと毎度感じます
実際の構築を開始すると、TSUTAYA本体からのデータ連携と日販からのデータ連携について仕様の確認や取り決め、連携方式の決定を行い、それに伴う取込側の弊社の仕様を決め、３社の並行開発が始まりました。
この手の開発あるあるで実際にデータを取り込むと仕様が異なったり、想定外のケースが出たり、あるあるのIFごとに潰しこみながら、データセットを確定していきながら、場合によっては再送信してもらったりでデータレイクに保管し、データマートを生成して、Snowflakeへのロードを進めて行きました。
さて、UIのところは画面デザインを決め、各APIの設計も行い、スプリントを繰り返しながら、実装も着実に進んでいきました。
そして、UIからAPI,DBまでのUT工程が始まりました。短納期で開発しているので、一定のバグが出るのは致し方なし。このタイミングでレアなデータケースで追加対応が必要になったりとカオスになりかけた時期もありましたが、優先順位を付けて、着実にクロージングしていきました。
そして一通り開発が完了したころ、問題が見つかりました。
性能問題
「遅くない？？」
元々のシステムは自由度が低く、事前にマートを作成したり、バッチ集計出力だったのに比べ、新システムは、ローデータに対する自由度の高いリアルタイム検索機能としてリニューアルしたのですが、全体的に重い状況でウェアハウスを上げただけでは解消しないレベルでした。
さすがに分析ツールで数十秒は致命的なので、β版のうちに対応しようという事で改めてクエリプロファイリングを参照し、解析などを行いました。
クラスタリングキーに指定している項目の指定時に関数やプルーニングが効かなくなるような記述がないか、非効率なクエリ構文が存在していないかなど、いくつか改善箇所はありましたが、劇的な効果までは得られませんでした。
このサービスをSnowflakeで実現する事は、先々のグループ全体への導入に向けて重要なステップです。CCCMKでの本業がありつつも、クエリの傾向やテーブルの構造など性能改善につながる要素を一つずつ潰しこみました。
その中で、クラスタリングキーの課題仕様の一つであるVarchar型の5Byte問題が見つかりました。
この説明をすると長くなるので、以下の記事に詳しく書かれておりますので、参考にしていただければと思います。
簡単に言えば、日付フィールドについて、文字型で定義しているものがあり、
文字型の場合、5byteまでしかクラスタリングが効かず、適切にプルーニング出来ません。
項目定義の変更は影響範囲的に難しい事もあり、日付をSubstringし、”YYMMD”でクラスタリングキーを切り直す事で一定のパフォーマンス改善はされました。
ただそれでも遅い状態が解消された訳ではありません。
そこで今後はクラスタリングキー自体の見直しに着手しました。
分析サービスの特徴としてID-POSデータであるため、クラスタリングキーは、日付を設定することは一般的ですが、何となく会員IDを設定していたことも分かり、この構成の見直しを掛けました。
このサービスは出版社向けのサービスであることから、出版社は自社書籍を指定することが多く、またどの店舗にいくら卸したかといった観点で分析する事が多い事から、指定するキーを日付、店舗CD、ISBNコードに切り直しました。
結果的にこの判断は功を奏し、性能は劇的に改善されました。
これにより、β版でのユーザーフィードバック等が進み、約半年ほどの試用期間を経て、その後正式版としてリリースされ、旧システムは順次停止され、グループ会社であるCDP社へのSnowflake導入は完了しました。
またβ版リリースが完了したころ、CCCMKでの役職が課長に昇進したこともあり、兼務が終了し、表向きはCDP社から引き上げましたが、裏で支援をしながら、正式版のリリースまで見守りました。
CCCMKにおける利用拡大に向けたPoC
さて、CDP社の裏で、並行して本業のCCCMKでは分析基盤（Oracle/Synapse）のSnowflake統合のPoCを進めており、DB統合および移行コスト、性能面でSnowflake化に十分なメリットがあると判断が出来ました。
SynapseからSnowflakeへの移行にあたっては、分析業務で利用している100名近いアナリストやリサーチャーに自分たちのクエリを書き換えてもらう必要もあり、エンジニア主導のPoCと並行して、ユーザー部門へSnowflakeの勉強会を実施すると共に有志に対して、先行してSnowflake環境を提供しました。
勉強会については、Snowflakeの高田さんにレクチャーをしてもらうアジェンダでしたが、最初の20分をもらい、私自身がなぜ入れたいと思っているのか、みんなの業務にどういうメリットがあるのか、どう言う世界観のアーキテクチャなのかをプレゼンし、その上で高田さんのレクチャーについて、自分たちの何に貢献するのかを考えながら聞いて欲しいとお願いしました。
最初はSnowflake？なにそれ？という雰囲気でしたが、上記の前振りをした事で、今まで誰かのヘビークエリで待たされていたことが解消される、BIや機械学習などとの親和性が高くなり、業務効率が上がるといった自分たちの潜在的な不満や課題感を意識して聞いてくれたことで、活発な質問が飛び交い、盛況のうちに終わりました。その後のアンケートでもほぼ全員がSnowflake導入への期待を書いてくれていました。
この手の勉強会はファシリテーションが大事で、最初にアイスブレイクや勉強会の目的、場合によっては場を和ませるようなジョークや笑いを入れるのも効果的です。
あと、Snowflakeが大好きであれば、キラキラしながら笑顔で話しましょう！
その後、有志にユーザーIDを渡して、UIを実際に操作してもらったり、実際に集計データを入れてTableauなどと連携させたりするなかで、使いやすい！、分かりやすい！、速い！、これなら出来そう！ という好意的な反応でした。
この辺り、"百聞は一見に如かず、百見は一験に如かず"（造語）だなと毎度感じます（2回目）
そして、システム的なEOLタイミング、コスト/性能面での大幅な向上という一番分かりやすい投資承認のストーリーと共に、ユーザー勉強会の際に取ったアンケート結果、すなわちSnowflake導入を待ち望むみんなの回答サマリを元にレビューし、コスト〇性能〇ユーザー期待〇であると説明をしました。
また以前のクラウド移行時はリリースの遅延をした反省点も踏まえ、その対策としてアナリストの移行PoCも実施し、それらもアンケートに反映されている事も伝え、そこまで評価出来ているのであればという事で大きな異論もなく、承認されました。
これはクラウド移行が遅延させてしまった、自分にとってのリベンジでもありましたので、再度信頼してプロジェクトを任してもらえた事には感謝です。
そして、まずはPh1として、Synapse→Snowflake化の移行プロジェクトを開始し、24年の1月にSynapseを完全停止が完了し、Ph2であるOracleExadataの統合に着手しました。
その詳細は前述の分析基盤の歴史にて詳細を記載していますので、割愛します。
マインド・アクション
１．自分がSnowflakeが好きだと自信を持って言えること
２．自分が先頭に立つこと、巻き込むこと
３．信頼を得ること
2023年：自社利用の拡大とグループ内への更なる展開
TSUTAYAへの展開とCCCMKのSynapse移行
TSUTAYAへの浸透
CCCMKのSnowflake拡大の目途が立った事もあり、次のターゲットにしたのはTSUTAYA事業でした。こちらもTSUTAYAのビッグデータを扱いながらもOracleExadataを使い続けていた状況です。
一方で、CCCMK側ではOracleExadataからSnowflakeへの移行を進めている事などをシェアしていたこともあり、TSUTAYA事業のIT担当者からSnowflakeのPoC等の相談を受けたので、PoC費用はこちらの予算から充当していいから一刻も早くやろう！ と伝え、いくつかの調整のち、数ヵ月後にPoCが開始されました。
またそのシステムのベンダーがNTTデータさんだったこともあり、商流は違いますが、営業との面談時にSnowflake導入に向けて協力をお願いしました。その後、TSUTAYA事業へのSnowflake導入検討は比較的スムーズに進みました。
お金の心配をさせなかったこと が功を奏したのか、その後、性能やコスト面で良い評価結果が出て、TSUTAYAの分析基盤のSnowflake移行も始まりました。
自社内のSnowflake移行の進行
部長職を拝命したこともあり、投資承認などは私から経営に報告しましたが、プロジェクトは若手メンバーに委ね、任せる立場になりました。まずはSynapseからの移行について、23年3月からの着手後、半年ほどですべてのパイプラインの連携先にSnowflakeを追加し、並行稼働を開始しました。その後、100名近いアナリストユーザー全員にクエリを書き換えてもらい、予定よりも前倒しで24年1月に完了し、Synapseを完全停止しました。
パフォーマンスも問題なく向上し、またリザーブドのタイミングに合わせ最適に解約が出来ました。プロジェクトメンバーにはフォローする場面もありましたが、分析基盤の刷新だけでなく、世代交代にもつながったことは非常に良かったと思っています。
この辺りの詳細な内容はこちらの記事をご参照ください。
SMCCとの連携
三井住友ファイナンシャルグループ（SMFG）との業務提携およびポイント統合の発表後、お互いの理解を上げるために分析基盤で採用しているSnowflakeについてSMCC向けにレビューを行いました。
レビュー後に「Snowflakeの営業マン」みたいと弊社内から言われましたが、「ありがとうございます！導入したくなりました！」とSMCCさんよりもお言葉を頂き、その後、元々進められていた検討がさらに加速して、Snowflake導入が承認され、クロスクラウドのデータシェアの実装設計を進める事となりました。
Snowflakeの営業の方からお世辞だと思いますが、「タロウさんのおかげで導入進みました！」とお礼を言われました笑
マインド・アクション
１．自分がSnowflakeが好きだと自信を持って言えること
２．自分が先頭に立つこと、巻き込むこと
３．信頼を得ること
４．未来を想像して、今やるべきと理解してもらうこと
５．コストを把握すること
2024年：外部連携の開始と親会社への導入
SMCCへの連携とCCC本体への導入およびCCCMKにおけるOracleの廃止
本部長制の拡大に伴い、部長わずか1年で本部長になってしまい、慣れない業務に戸惑いながら、Vポイントの統合を乗り越え、一段落したのは7月でした。
Vポイント統合に伴い、SMCCとのデータ連携をSnowflakeで実現しました。
この辺りは、今年のSnowflake World Tour Tokyoの弊社と三井住友カードの基調講演で語られていますが、社内グループ内だけでなく、提携先とのデータ連携にもSnowflakeを採用出来たことは多くの方の協力があって実現したことですが、非常に嬉しい成果でした。
CCCMK内のOracle移行は順調に進んでおり、完了の目途が立ちつつある中で、CCC本体でもデータ活用組織が立ち上がり、分析基盤構築の相談が子会社の私の方に来ました。
まずしっかりと理解してもらおうと、Snowflakeのアーキテクチャや機能のプレゼンを行ったところ、すぐ使いたい！という話になり、グループ間共同利用データや不可データの精査を行い、新たなアカウントを作成し、そちらにデータシェアを行いました。
Snowflakeであれば、すぐに利用出来る環境を用意出来ますが、実際はプライベートリンクを作ったり、IDやセキュリティ関連の手順を踏む必要もあり、この辺りは確実に実施していく事が重要です。
まずはほとんど参照のみなので、データシェアしたDBに対する参照のみなので、ウェアハウスコストのみ、イチから基盤構築する事に比べれば圧倒的コスト削減です。
今度、CCC本体側での蔦屋書店やスターバックス事業などの分析が加速していくと良いなと考えています。
ちなみに弊社グループはスターバックス社との付き合いは古く、SB社の日本最大級のライセンス契約企業だったりします。
またそれと前後して、CDP社とも業務効率化の観点でデータ連携の精査後、データシェアを開始しました。
CDP社に参画した時は、弊社グループ内もまだまだSnowflake化が進んでおらず、全てETL連携で莫大なコストを掛けてCDP社へ連携していたことが、Snowflakeで10分程度でデータ連携が完了し、保守も運用もほぼなしとなりました。
改めてグループシナジーの加速を期待しながら、自分が選んだアーキテクチャがさらに好きになりました。
マインド・アクション
１．自分がSnowflakeが好きだと自信を持って言えること
２．自分が先頭に立つこと、巻き込むこと
５．コストを把握すること
2025に向けて
グループ内のデータシェアは今後ますます増えて行くと思います。またSMCCとの連携もさらに増えるなと思います。グループ内外に関わらず、様々なデータコラボレーションによるビジネスコラボレーションが生まれると良いなと考えており、そういう中で自分がSnowflakeを好きな理由を体現したいと考えています。
また私が"やりたい"、"導入したい"と言ったときにそれに賛同し、手伝ってくれた同僚や上司やメンバーは自身にとって本当に財産だなと感じますし、その期待にはもっと応えて行きたいと思います。
またこのような導入や活用の取り組みを通じて、社内でも新しいチャレンジをしようとするメンバーも増えてきており、イベントでも弊社メンバーが活躍し、自分がゲストになっていることを嬉しく思いつつ、そういう機会をより一層生み出すために自分が出来ることをもっと増やそうと思っています。
Snowflakeが好きだという気持ちと同じぐらい自分の会社も好きなので、自分の会社がもっと楽しく面白い会社になれるように自分が出来ることを増やし、一緒にやってくれる仲間を増やし、みんなで発信出来るようになれるように頑張って行きたいと思っています。
最後に
Snowflakeというプラットフォームが大好きですし、これをもっともっと活用したい。私と同じようにみなさんがSnowflakeを導入することで、会社にも同僚たちにも世の中にも自信を持って発信出来るようになってほしいですし、せっかく導入したのであれば、事業全体、会社全体、グループ全体で使いこんでもらえると良いなと思います！
そういったSnowflakeの導入やデータ活用の相談をたまにいただき、弊社の事例や活用を説明する事がありますが、その後、Snowflakeの採用や導入が進んだり、データコラボレーションの検討が進んだり、もしくは我々との取組になることがあったりします。
そういうお話を聞くと私も多少なりとも貢献出来たのかも？と嬉しくなりますので、気兼ねなく相談いただければと思います。また私もそのような機会を通じて、自分の"好き"を言語化出来てきたように思います。
エンジニアリングやテクノロジーや事業規模など、弊社より素晴らしい企業はたくさんあると思いますが、データコラボレーションの数なら日本一を目指してもいいんじゃないか？？と勝手ながら妄想しており、色んな取組みをしていきたいなと思っています。
皆さんも、もし弊社のVポイントのデータに興味があったり、自社のデータコラボレーションの検討に悩んでいたら、お気軽にご相談いただければと思います。
またSnowflakeのユーザーコミュニティであるSnowVillageには、様々な実績や経験をお持ちのエンジニアやプロジェクトリーダーが多数おられます。
そんな様々な学びや交流が得られる、SnowVillageに参加されていない方やもし興味がある方はぜひ一歩踏み込んでみてください。きっと良い経験が得られると思います！
最後に本記事が皆様のSnowflakeの導入や拡大に少しでもお役に立てれば幸いです。
Discussion