データ分析の勉強方法を聞いてみた。

大塚「こんにちは、テクニカルトレーナーの大塚です。よろしくお願いします。」

下佐粉「こんにちは、アナリティクス スペシャリスト ソリューションアーキテクト の下佐粉です。よろしくお願いします。」

大塚「データ活用が広がる中で　アナリティクス スペシャリスト ソリューションアーキテクトとして、そして週刊 AWS の発信と活躍されている下佐粉さんですが、下佐粉さんのこれまでのキャリアに関して聞かせていただけますか ?」

下佐粉「SIer でネットワーク系機器やモデムを制御するプログラムを書くプログラマーとしてキャリアをスタートしました。そこでお世話になったおかげで、TCP/IP やUNIX/Linux、C/C++ のスキルを身につけました。」

大塚「元々データベースではなかったんですね。」

下佐粉「はい。データベースはたまたまで、管理アプリケーションを作らなくてはいけなくなり、フロントエンド UI と管理データのリポジトリが必要になり、Visual C++ でフロントを作り、バックエンドは Oracle でデータベースを実装して運用していました。」

大塚「それがデータベースとの出会いだったんですね。」

下佐粉「はい。最初は何もわからないまま Oracle をインストールするところから触ることになりました。結果として、それが自分のキャリアになっていくので、何がキャリアのきっかけになるのか分からないと感じました。」

大塚「ほんと、出会いは突然に。ですね。」

下佐粉「データベースの勉強、検証のため、検証用の PC には PostgreSQL をインストールして使っていました。当時は無料なのに速いな〜と思いましたね。」

大塚「なるほど、データベースにそこで関わるようになって、次のキャリアにステップアップされていくわけですね。」

下佐粉「次は外資系 IT ベンダーに移り、データベースのプリセールスエンジニアからスタートしました。途中からデータベースに限らないアーキテクトロールにロールチェンジし、製造業や金融業のお客様をご支援してきました。そこで、色々な業界知識やアーキテクティングのスキルを得たのが資産になっていますね。」

大塚「そういった資産が現在の AWS でのソリューションアーキテクトというロールに繋がっていそうですね。」

下佐粉「それだけでなく、当時、データベース製品のコミュニティ活動も 10 年ほどしていまして、それも含めて AWS での現在のロールに繋がっています。」

大塚「当時所属されていた会社はコミュニティ活動が活発だったのでしょうか ?」

下佐粉「いえ、あまり活発とは言えませんでした。会社の評価基準にコミュニティ活動は入っていませんでしたし、そのような活動をする人は多くなかったです。それでも情熱のある人はいたのでその人達の熱意でなんとか続いていた感じですね。」

大塚「活動が評価されるかどうか、今回の勉強方法にも繋がりそうな話ですね。」

下佐粉「情報発信もあまり活発ではなかったので、なんとかして発信したいなとコミュニティ活動を 10 年くらい続けていました。」

大塚「そこでデータベースに関する本も執筆されていますよね ?」

下佐粉「はい。本を書いたのも、情報発信したいという理由からですね。」

大塚「情報発信、コミュニティ活動をされるモチベーションはどういったものでしょうか ?」

下佐粉「だんだんと世の中がオープンコミュニティの中でモノが作られて、そこから派生品が出てビジネスに繋がっていく流れの中で、閉じていてはダメで、自社製品もオープンコミュニティの中で自然にスキルが醸成されるような環境であってほしい、という意識でした。」

大塚「たしかに、今回のデータ活用・ビッグデータ分野のソフトウェアはほとんどオープンソースソフトウェア (OSS) から始まっていますよね。」

下佐粉「はい、まさに OSS が中心ですよね。」

大塚「AWS に出会ったのもこの頃でしょうか ?」

下佐粉「2 回くらいショックがあったんですけど、データベースのエンジニアやっていたので、最初に Amazon RDS というものがあることを知りました。ビビったんですけど、ポチっとボタンを押すだけで、複数のアベイラビリティゾーンに分散配置された DB クラスターがたつじゃないですか。マジかと思って・・・。これまでだったら設計に 1〜2 ヶ月かけてやっていたことが、ボタン押して数分ほっておいたらデータベースが出来上がっているんで、こりゃもう自分の仕事がなくなるかもしれないと思ったのが第 1 ショックでした。」

大塚「第 1 ショック (笑)」

下佐粉「第 2 ショックが Amazon Redshift で、AWS re:Invent から帰ってきた人の話を聞いて、これはヤバいと思って調べたら本当にヤバくて。」

大塚「笑」

下佐粉「当時データウェアハウスは安くても 2〜3 千万円していたけど、Amazon Redshift は 1 時間 100 円とか言っているし、いらんかったら捨てられるし、足らんかったらノード増やせるし、メンテもいらんし、壊れたら裏で AWS が勝手に直してくれるのかって。こりゃ自分の仕事がなくなるかもしれないと思ったのが第 2 ショックでした。」

大塚「第 2 ショック (笑)」

下佐粉「スキルセットとしても物理的なインフラ構築の価値が小さくなり、仕事の仕方を変えていかないといけないのではと思っていました。構築を失敗してもやり直せるし、机上の設計を入念に練るよりも手を動かした方が早いなと感じました。」

大塚「実際の環境で試行錯誤できるところって魅力ですよね。」

下佐粉「ですね。それから AWS に移り、エンタープライズの ソリューションアーキテクトとして、製造業、金融のお客様を担当し、その後現在の アナリティクス スペシャリスト ソリューションアーキテクト にロールチェンジしました。」

大塚「アナリティクス スペシャリスト ソリューションアーキテクトにロールチェンジされたきっかけはなんでしょうか ?」

下佐粉「お客様担当のソリューションアーキテクトはお客様視点で、お客様と一緒に設計をしていけて楽しいですし、自分の苦手領域も含めて担当するので非常に勉強になりました。5 年くらい担当した後、自分のスキルを横に広げるのではなく、縦に深めてやってみるのも面白いかなと思いました。元々データベース、データウェアハウス畑で仕事をしてきたこともあり、アナリティクス スペシャリスト ソリューションアーキテクト として自分のこれまでの知見も活かしやすくご支援できる機会も増えるのではないかと考えてロールチェンジしました。」

大塚「アナリティクス スペシャリスト ソリューションアーキテクト といっても範囲は広いかと思いますが、ご専門領域はどこでしょうか ?」

下佐粉「ここ最近はデータレイクを中心にご支援させていただいています。」

大塚「では、ここからデータ活用・分析について、お伺いしていきたいと思います。まず、データ活用を導入する、あるいは進めていく上で必要なことはなんでしょうか ?」

下佐粉「私が一番重要だと思っているのは、データ活用・分析の敷居を下げて、誰もがデータに触れ、活用できるようにしていくことです。敷居を下げて、裾野を広げることが私がこれまでずっとやってきたテーマで、クラウドはそれを後押ししてくれるものです。ただ、もっともっと敷居を下げなればいけないと思っています。」

大塚「どうすればもっと敷居が下がりますか ?」

下佐粉「敷居を下げるのは色々と要素があって、例えばセットアップを楽にするとか、価格を下げるとか、あるいはコードが書けなくても自分がやりたい分析ができる、ということが敷居を下げてくれます。」

大塚「AWS の Analytics サービスはまさにそういった形で敷居をどんどん下げてくれますね。」

下佐粉「一方で、敷居を下げるだけではどうしようもない部分もあって、ロジカルにデータをみながら作戦をたてる、というのは人間が考えないといけない。機械がなんでもかんでも勝手にやってくれるということはないので。」

大塚「人間もレベルアップしないといけない。」

下佐粉「はい、敷居を下げることと、人間も組織をあげて教育を充実させていく、という両面でやっていかなければいけないと思います。」

大塚「ちゃんと積み重ねていかなければいけない。」

下佐粉「予測ができる、モデリングができるということは、まずは仮説がなくてはいけない。ということは、過去のデータを参照できて、視点を変えながら分析できなければ、仮説も立てられない。過去のデータを参照・分析できるというのがどういうことかというと、平たく言うと、データのダッシュボードを持っているという意味です。誰かに断りなく、誰でもポチッとすれば過去のデータが全部見られる状態というのが最低限の状態です。ということは、もっと言うと、過去のデータを全て蓄積していなければ始まりません。」

大塚「確かに、データを蓄積していないと何も始まりませんね。」

下佐粉「これって人間も一緒です、というのを常に言っています。機械だけピラミッドの上にいっても人間がついてこなければ意味がないです。」

大塚「なるほど、私もいつもトレーニングの冒頭に、受講者の方に現時点でどこまでデータ活用を進めていらっしゃるかお伺いする際、1. データの蓄積までという方、2. データの可視化までされている方、3. 分析までされている方 となんとなくこのフェーズでお伺いしていたのですが、その裏にこんな一歩一歩踏んでいかなくてはいけないピラミッドがあるということを意識していませんでした。」

下佐粉「これって文化作りなんですよね。」

大塚「文化 ? ピラミッドだけに、古代エジプト文明ですか ?」

下佐粉「いえいえ。(素で答える) データを見てモノを喋る文化、データを見て会社の戦略を決めていく文化、というものを作る必要があります。なぜかと言うと、誰か一人でデータ活用するぞ、と意気込んでもビジネスは進んでいきません。一方で文化作りはジワジワと進めていくしかありません。まずはみんなでデータ見えるようにしよう。次はみんなで KPI を設定して、 達成しているかどうかもちゃんとデータ見て判断しよう。というピラミッドの下から 2 段目、3 段目ができてくると、組織の中で予測モデルを立てる人が生まれてきます。2 段目、3 段目を飛ばしていきなり予測モデルを立てるエキスパートを外から引っ張ってきても、文化がついてきていないとその人が浮いてしまって、結局組織を抜けていくことになります。」

大塚「なるほど、データ活用のためのツールとか揃えても、組織の考え方や意識が変わっていなければダメということですね。」

下佐粉「まさに。文化の醸成、組織の醸成が重要です。とはいえ、いきなり組織全員の意識を変えることできないですよね。どこから始めるかという作戦が重要で、まずは小さいグループから始めるといいです。例えば Web マーケティング部門が Web ログを見ながらデータで判断して KPI を設定し、データを分析してそこまでの取り組みを検証する、というサイクルをぐるぐる回せる癖をつけていきます。」

大塚「スモールスタートですね。」

下佐粉「組織論に近いですが、こういうのができると、だんだん横に広がっていくんですよ。Web マーケティングチームがうまくいっているのをみると、隣の別のマーケティングチームが Web マーケティングチームの取り組みに興味を覚える。これでじわじわと文化が広まっていきます。」

大塚「じわりじわり。」

下佐粉「経営層にお勧めしたいのは、こういうタイミングを見計らって教育プログラムに投資することですね。とはいえ、組織には色々な要素あがりますから、そのようにしたからといってすぐに人が増える、人がみんな勉強してくれるとは保証できないのが難しいところなのですが。」

大塚「確かに、これまでと違うことをやっていく、となると抵抗もありそうで、なかなか難しそうですよね。」

下佐粉「経営層の方にデータレイクの話をさせていただいたときに、その方に私の話が一番伝わったと感じる瞬間があるんです。その方に『データレイクという技術の話を聞きにきたけど、これは人とか組織の話なんですね。』と言っていただけたときに、これはもう全部伝わったなと確信が得られる瞬間です。」

大塚「深いぃ。」

下佐粉「これはとても重要で、データレイクの促進はツールを入れるだけではだめで、人が変わる必要があります。ただこれはとても難しい。そうなると、どう組織を変えるのか。ちゃんと評価する仕組みを作れるか。例えばデータ活用を推進している人のボーナスアップしたり、昇進したり。そういう組織作りができないとデータ活用は中々進んでいかないと思います。」

大塚「たしかに、最終的に評価に繋がらないと、新しい取り組みは広がっていかないですよね。先程お伺いしたコミュニティ活動が活発化するかどうかの話と同じですね。」

下佐粉「評価に繋がるのであれば、奨励しなくても勝手にデータ活用の勉強をしていく流れになると思うんですよね。エンジニア向けの builders.flash のインタビューで経営層に向けたメッセージになっていますが、これは私の正直な思いです。」

大塚「では、エンジニアのキャリアの観点で、どのような勉強をしていけばいいでしょうか ?」

下佐粉「Analytics 領域では次々に新しい技術やサービスが登場しています。そういった最新技術を勉強して使えるようにすることと、基礎・原則論を学習することの両方が大事です。」

大塚「最新技術と基礎・原則論のどちらから勉強していけばいいでしょうか ?」

下佐粉「どちらを重要視するかというと、まずは基礎・原則論の方を押さえていただくのがキャリアの観点で重要です。なぜかと言うと、最新技術はすぐに古びるからです。」

大塚「またまた深いぃ。」

下佐粉「例えば 6 年前に戻ったとして、Python が機会学習で最もポピュラーな言語になる事を正確に予測していた人がどれ位いたでしょうか ? もしかしたら R だったかもしれないですし、また他の言語が業界スタンダードになっていたかもしれません。何を言いたいかというと、自分の使う最新技術は廃れてあまり使われない技術になる可能性もあるということです。」

大塚「私、学生時代に結構 R 使っていました・・・。」

下佐粉「まあ、それを恐れて勉強しなかったり、使わなかったらどうしようもないので、勉強して使うんですけど。それと一緒に、やはり古くならない、基礎・原則論を学習することが重要です。例えば、機械学習で Python のライブラリを理解し、使いこなすことも重要ですが、機械学習がどのようなもので、その土台にある統計の考え方を学習することが重要です。なぜなら、基礎的な仕組み・原理の理解があれば、今後色々変わっていっても応用が利くからです。」

大塚「確かに、IT 技術に関わらず、スポーツなどでも基礎が大事で、それを押さえておかないとその後うまくいかないことも多いですからね。」

下佐粉「でも、基礎をしっかりと押さえるだけでもダメで、最新技術と基礎を両立しなければいけないという難しい話です。例えば、初学者でこれからデータウェアハウスの Amazon Redshift を使わなくてはいけなくなったエンジニアの方がいらっしゃったとします。データウェアハウスの基礎ということで、データベース概論と MPP (Massively Parallel Processing) の勉強に専念したら、Amazon Redshift 使えるようになるまでどれだけ時間かかるんだ、という話になりますから。」

大塚「初学者にとっては、データベース概論と MPP だけでお腹いっぱいになりそう。」

下佐粉「そんなことより、早く Amazon Redshift のトレーニング受けて使えるようになれ、というのもビジネス的にはもっともで、やっぱりバランスが大事ですね。」

大塚「今、初学者の方という話がでましたが、最近トレーニングを実施していると、これからデータ分析・活用に関わっていくという方が多くいらっしゃいます。これまでまったくデータ分析・活用に関わってこなかった方が、これからデータエンジニア・データサイエンティスト・データアナリストに転身して活躍していくことは可能でしょうか ?」

下佐粉「はい、可能だと思います。「学習 → 試す」というループが大切なのですが、例えば機械学習でもこれまでは学習・開発環境を作るのが大変でしたが、今でしたら 無料で使える Amazon SageMaker Studio Lab でボタン押せばすぐに Notebook が使えるので Python さえ書ければ誰でも機械学習を始めることができます。データの規模が大きくなっても、簡単に性能をあげて学習や分析ができるので、敷居はかなり下がっています。」

大塚「最初にお話しいただいた、敷居の話ですね。確かに、誰でもデータ活用ができるように、という話でしたので、初学者の方がこれから、という点でも一致しますね。」

下佐粉「これも先ほどお話しした点ですが、いきなりジャンプアップしなくても、インフラを担当してきた方が少しずつデータレイクの設計を学習・担当していくとか、ずっとデータウェアハウスを運用してきた方がデータウェアハウスに格納されているデータを使って機械学習に手を出してみるとか。」

大塚「これまでの担当・仕事から少し横に手を出してみるところから始めるということですね。」

下佐粉「はい。その際「学習 → 試す」というループが重要です。学んだことを手を動かして試す、というのがとてつもなく重要ですが、AWS をご利用いただくと簡単にできますよね。トレーニングやフリーのハンズオントレーニングも Web にたくさんありますので。」

大塚「AWS のサービスによって、データ分析・活用の敷居が下がるというお話に関連しますが、データ活用に関わるロールで、データエンジニア、データサイエンティスト、データアナリストといった分類分けがよくされますよね。データエンジニアはデータ分析基盤・インフラ部分を担当するロールですが、そこは AWS がサービスとして提供するものが多いので、だんだんデータサイエンティスト、データアナリストという少し横のロールに手を出して、「学習 → 試す」というループを回しながら勉強していくということが必要になりますか ?」

下佐粉「データエンジニアが今後何をやっていくか、というのは実は大きな関心ごとです。アナリティクスまでやるとそれはデータアナリストなんですよ。データアナリスト・データサイエンティストもできるデータエンジニアというポジションもありですが、データ管理の領域を深く詰めていくというのもありです。」

大塚「なるほど、横に手を出すのではなく、縦に深めていくんですね。」

下佐粉「インフラの準備は AWS がやってくれるので、どうやってデータアナリスト・データサイエンティストの方々が使いやすいデータを準備できるかということを突き詰めるんです。例えば、ビジネスデータが結合できる状態で揃っているとか、セキュリティレベルがしっかりと分かれていて、データの活用方法がルールを含めて統制がとれている状態にする。こういった統制がとれていないと、データアナリスト・データサイエンティストの方々が安心してデータを利用できません。分析基盤の構築・運用ではなく、現場で使いやすいデータの統制を実現していくのが、今後データエンジニアにとっての重要な仕事になっていくと思います。」

大塚「たしかに、重要な仕事ですね。」

下佐粉「そうなってくると、IT 技術だけではなく、データに対する統制の考え方とドメイン知識、つまり、この業界としてどのようなデータがあって、何に使えるかを知っていることが重要です。」

大塚「AWS Lake Formation というサービスを使うと統制が取りやすくなるので、データエンジニアを支えるサービスになりそうですね。」

下佐粉「統制という意味で AWS Lake Formation は便利ですね。その上で、どのようにデータを分けるのか、タグ付けをするのか、匿名化、どのデータを組み合わせればいいのか、といったところをエンジニアが使いこなすか、というところが大事です。」

大塚「具体的にお客様のご支援をされている中で、データ統制で難しい点やポイントはありますか ?」

下佐粉「例えばよくあるのは、個人情報をどうするのか。あとは、お客様がコングロマリットで、同じ会社でも業種ごとに分かれているときに、他の部署にこのデータ見せてもいいのか、といった組織の壁がある場合もありますね。」

大塚「データエンジニアの方がこれからどのように勉強を進めていけばいいかという話はお伺いできましたが、データサイエンティストやデータアナリストはいかがでしょう ?」

下佐粉「こちらも先ほどの話と似ていますが、自分の専門領域から少しずつ近接領域に知見を広げていっていただくのがよさそうに思います。ザックリですが、「(データソース) → 蓄積 (データレイク設計) → 加工 (前処理) → データウェアハウス＆BI → 機械学習」 の順でデータ活用は繋がっているので、自分の担当しているところの前後に手を伸ばすとか。一方で、－つの領域だけでも十分深みはあるので、深めていくのも良いと思います。」

大塚「下佐粉さんご本人はどのように専門領域から広げてこられたのでしょうか ?」

下佐粉「キャリアのところでお話ししたとおり、最初はネットワークのプログラマーでした。当時、若い人は何でもやっておけ、という雰囲気で、たまたまリレーショナルデータベースを触るようになり、データベース自体、そしてSQLも勉強しました。それからデータベースのエンジニアになりましたが、データベース製品の周辺サービスも扱うようになり、だんだんデータウェアハウスや BI にも膨らんできたので、そこでも勉強しました。AWS に移ってからも Amazon Redshift の技術支援や Amazon QuickSight の立ち上げなどを担当していたのですが、徐々にデータレイクがバズワードでなくなってきた頃に、ちょうど担当していたお客様でデータレイク構築の話がありました。データレイクも資料を漁って勉強して、体系立てて捉えられるようになると、データレイクはデータ活用における考え方の基礎になり、普及していくという確信が持てたので、それからはデータレイク、データレイクと言い続ける感じになっています。」

大塚「なるほど、当然ですが、勉強しながら少しずつ広げてこられたのですね。そんな中でオススメの本はありますか？」

下佐粉「本はどうしても古びるのが早いので、原則論とか基礎を本でかためて、あとは最新機能を手を動かしながら、というのがおすすめです。では、最初にどの本か、というところでどうしようか迷ったんですが、「イノベーションのジレンマ」はオススメです。本の中で「データにあわせてしっかり仕事を進めてもイノベーションに負けることがある」とあって、これまで言ってきたことを覆すことを言っている本なんですけど (笑)。」

大塚「笑」

大塚「アナリティクスに関連するところではいかがでしょう ?」

下佐粉「何から勉強したらいいかというときに、まずは SQL といってもいいと思います。SQL 本たくさんありますが、「達人に学ぶSQL徹底指南書」はオススメですね。」

大塚「Amazon Redshift も Amazon Athena も Apache Hive も Apache Spark も SQL 使いますからね。」

下佐粉「これも古典ですが、「The data warehoue toolkit」 は素晴らしい本ですね。データウェアハウスの考え方の本でオススメです。古典ではありますが、データウェアハウスの基本は変わっていないので。」

下佐粉「私は機械学習の専門ではないのですが、「機械学習のエッセンス」という本は、私のように「アナリティクス畑だし、学校で習った数学とか忘れちゃったけど、機械学習の事も少し理解しないと応用範囲が広がらないよね」と思っている人にエッセンスを把握するために良い本だと思います。」

下佐粉「Apache Spark は、これからの分散処理・ビッグデータ処理では避けて通れない技術なのですが、本はなぜか案外少なく、しかも Apache Spark の進化が早いためになかなかお勧めの本というのは難しいのですが、一冊挙げるとすれば、Spark: The Definitive Guide がオススメです。」

下佐粉「データ管理をしていく上で、どこから手を付ければ、という方向けには データマネジメントが 30 分でわかる本 がよいでしょう。本当にコンパクトに DMBOK が要約されているのが良いです。」

下佐粉「自著 (共著) をお勧めするのもアレですが、 Why data lake ? という日本語の本が無いため、AWSではじめるデータレイク という本を書いたところがあり、これからデータレイクを導入・検討される方にオススメしたいです。」

大塚「本などの資料による勉強方法に加えて、ハンズオンの勉強方法についてもお話させてください。AWS の Analytics サービスを体系的に学習できる本や資料はありますか ?」

下佐粉「本では原則の理解、最新情報は Web で追いつつ、手を動かすという流れがおすすめです。これはどのレベルの方でもそうですね。まずは、AWS サービス別資料の Analytics シリーズ を見てもらうのがいいと思います。」

大塚「どれもコンパクトにまとまっていて初学者にもオススメですよね。」

下佐粉「最新情報は 日本のお客様向け AWS のデータ分析サービスのご紹介  からブログ記事などにもアクセスできます。」

大塚「私からも紹介させてください。AWS のサービスを活用してこれからデータ活用を始める方向けの無料のデジタルトレーニングで Data Analytics Fundamentals (Japanese) 日本語吹き替え版 を提供しています。構造化データ、半構造化データ、非構造化データの比較説明や、行指向・列指向フォーマットなど、データ分析・活用の基礎から AWS Lake Formation や Amazon Redshift などのAWS Analytics サービスまで学習いただけます。」

下佐粉「手を動かすハンズオンは沢山ありますが、AWS Hands-on for Beginners 手を動かしながら学ぶ Analytics サービス入門 がまずオススメですね。

下佐粉「あとは可視化から体験されたいのであれば、日本語で取り組んでいただける Amazon QuickSight のハンズオン もオススメです。」

下佐粉「AWS の Workshop サイト にたくさんのワークショップがありますが、中でも Serverless Data Lake Day がオススメです。データの収集から ETL 、カタログ化、分析・可視化まで通して体験いただけます。そうすると、もっと深掘りたい部分・サービスが見えてくるので、その部分のワークショップをさらにやって見るといいと思います。全体感を知れるということろでオススメのワークショップです。」

大塚「たしかに、全体感をまず掴むというのは重要ですよね。」

下佐粉「お客様とデータレイクプロジェクトの進め方をよくお話しさせていただきますが、お客様が最初に色々なところを決めようとしすぎるところがあるんですよね。」

大塚「最初に決めすぎてはいけないんですか ?」

下佐粉「それってうまくいかないですよって必ず言うんです。データレイクってなんのために作るかというと、世の中先が分からないので、どういう仕組みが必要になるか分からないから、データレイクという仕組みができてきているんです。」

大塚「最後にまたまた深いぃ。データレイクだけに。」

下佐粉「数年後にどうなっているかなんて分からない、という前提なんです。データレイクはそれに合わせて変化できるのがいいところなんです。なので、数年後を目指して何が必要かを全部洗い出して構築するのはデータレイク的ではないんです。」

大塚「なるほど。では、どうしたらいいのでしょうか ?」

下佐粉「データを収集して、変換して、前処理して、データウェアハウスにロードして、BI で可視化して、というデータ活用の End to End を小さくてもいいので一つやってみるのがいいです。そうすると、自分たちに必要なデータや足りないパーツが見えてきます。そこから広げていくのがデータレイク構築のコツです。」

大塚「そのお話、データレイクに限らず、クラウド活用のコツですよね。」

下佐粉「はい、計画に時間をかけすぎず、まずは小さく使ってみて、失敗したら消してやり直せばいいという考え方ですね。」

大塚「本日はどうもありがとうございました ! 勉強方法だけでなく、データ活用を進めていく上での組織文化の醸成や、データレイク構築のコツといった IT 技術ではない話までお伺いできて非常に面白かったです。」

下佐粉「ありがとうございました !」