前提と想定読者

本記事の私見以外の情報に関しては、一般に公開されている資料のリンク集のようになっています。
取り組んでいる内容は、私が現在勤務している会社に関連していますが、その詳細には触れません。

以下に類する方は参考になるかもしれません。

データエンジニアやBIエンジニアのように、データ基盤を構築しようとしている方
データアナリスト、データサイエンティスト、マーケッターなど、データ基盤を利用する方々で、なぜそのシステムが選ばれているのか考えられるようになりたい方
データエンジニアリングチームをマネジメントしており、チームメンバーのスキル向上のための教材を探している方

背景

WEB業界で新卒からデータエンジニアとしてキャリアをスタートし、現在はデータストラテジスト/BIエンジニアとして活動中のやすです。現在、私は5-10名規模のチームをマネジメントしており、チームメンバーのほとんどは20-30代前半のデータアナリスト/BIエンジニアで構成されています。これからチームをスケールするためには育成が不可欠です。「知識」については既存のコンテンツが豊富であるため、自分自身の「知恵」の部分を言語化し、継承していく必要があると考えました。

特に、データ基盤に関連する領域の技術の進歩は、近年Modern Data Stackとグルーピングされるなど、目覚ましいものがあると思います。データアナリスト/BIエンジニアとして、ただ提供されるシステム/ツールを使うだけになったり、「最新の技術だから」という近視眼的な判断軸だけではなく、以下を考慮して開発/利用して欲しいと考えました。

データ基盤に関する新しい技術に関して

「なぜ新しい」のかわかるようになる
「どのだけの価値を提供」するのか考えられるようになる
「将来何が変わり、何が変わらないのか」想像できるようになる（正誤はわからないのであくまでも想像することが重要）

上記3点を考えられる能力を「データ基盤技術の審美眼」と呼称し、育てていこうと考えて社内でチーム向けの勉強会を始めました。全3回予定で、記事執筆時点では1回目が終了しました。「データ基盤技術の審美眼」の名前は以下スライドのリスペクトが入っている。

speakerdeck.com

勉強会に参加するメンバーのミッション

「次の10年で何が変わり、何が変わらないかを想像しながら聞いてみてください」 とお伝えています。後述しますが、データ基盤に関する技術では、変わるものと変わらない要素（永久にではなく数年ごとに変動するもの）があります。これが想像できないと、他人やネットの情報を盲目的に受け入れ、状況に応じた技術選択に制約をかけてしまったり、経験豊富なエンジニアと意見を共有できない可能性があるからです。データ基盤の構築に直接携わらない人々にとって、これを想像するのは難しいかもしれませんが、情報システム部門やエンジニアとコミュニケーションをとる際に、この視点で議論や意見交換を行うだけでも、共通の理解が深まるでしょう。

勉強会の構成

最初の30分では、勉強会のテーマに関する内容を説明し、残りの30分はディスカッションの時間を設けます。（初回はスタートが遅れ、十分なディスカッションの時間が取れなかったことがありました。）ディスカッションの際の留意事項として、念頭に置いておくべきことは「メンバーがデータ基盤技術の審美眼を育てるために、何が変わらず、何が変わりそうか想像する」ことであり、私自身がどう考えているかはメインではないので、基本的には傾聴の姿勢を持つことが重要です。

また、資料の作成時間を短縮するため、コンテンツの中身は一般に利用可能な資料やコンテンツの要約となっています。そのため、紹介している動画や記事を閲覧することで、提供している内容よりも詳細な情報を得ることができます。皆さんもぜひ、それらをご覧ください。

第1回：データ管理の歴史

第1回では、リレーショナルデータベース（以下、RDB）とSQLが誕生した経緯、そしてデータ管理の歴史について話しています。以下、話した内容の中で特に重要な点をピックアップしています。 ※ かなりざっくりです。

1970年代：RDBが先にできたのではなく、データの関係モデルが先に提唱された。そして操作言語のSQLが提唱され、その後にシステム化したRDBが生まれた。
1990年代前半：データウェアハウス（DWH）は、データを削除せずに保持することで、過去と現在のデータを比較できるようにするために提案され、システム化されました。
1990年代後半：Web系データベースは、インターネットの発展に関連し、大量のアクセスを処理し、管理する技術が必要とされ、生まれました。
2000年代：Hadoopなどの並列分散システムは、ビッグデータなど大量のデータや、関係モデルでは表現できないデータを処理するために生まれた。
2010年代：NoSQLは、RDBで管理が難しい非構造的なデータに対して、素早くリクエストを処理するために生まれた。

この回では「なぜ新しいのか」&「これまでとどのくらい違う価値を提供したか」を知識としてインプットすることに努めました。データ管理の課題の中心になっているのは「関係モデルで表現できるかどうか」、「データ管理の規模/範囲の変遷」、「リクエストの処理速度」に関連しており、これらを踏まえると将来の技術進化を想像する手助けになると考えます。

第1回の勉強会の感想/議論/質問内容

感想

「50年でこんなに進化しているのであれば、これからもっと変わりそう」
「古いDBよりも今のDBの方が利用できる関数など増えているので、SQLは進化している印象であったが、確かにリレーショナルという点は変わらない」
「どのアプリケーションやデバイスが流行ったかと比較しながら時代を見ると、さらに面白そう」

質問

「DWHで過去のデータは基本的に書き換えないと聞きましたが、実際はかなりのレコードが変更されていることもあるのはなぜですか？」という話題が出ました。その場では議論する時間がありませんでしたので、この問いについては後日以下の資料を読んでから別の場所で議論することにしました。個人的には、取り込むアプリケーションなどのデータ設計が以下資料中の「イベント」と「リソース」を混在して管理されているものを取り込んでしまうことが原因であると考えます。

イミュータブルデータモデルの極意

利用した資料について

SnowVillageというSnowflakeコミュニティが公開している動画を参考にさせていただき、ほぼそのまま（流用）使用させていただきました。準備にかかる時間を大幅に削減し、非常に助かりました。上記の内容は、私が書いている内容はすべてこの動画で詳しく紹介されています。詳細を知りたい方は、ぜひご覧ください。

資料コンテンツ

SQL/DBの歴史

DWHの歴史

今後

第2回：2000年~現代の分析基盤
第3回：これからの分析基盤 ~Modern Data Stack~

を予定しています。第2回もSnowVillageさんの動画コンテンツ流用しています。

第3回の準備はこれから

おわりに

この勉強会だけで、チーム全体がデータ基盤技術の洗練された視点を育てるのは難しいと考えています。実際に自分で選定し、失敗と成功を繰り返す経験を積まなければ、この思考パターンは身につかないと思います。上述した観点には、客観性を考慮していますが私の主観が多分に含まれているとも思います。ですが、このような機会を積み重ねることで、成長の入り口を作ることにはつながるのではないかなと考えます。その道を歩むかどうかは、個々の選択次第かなと思います。

また執筆しながら歴史から導けるのはボトムアップ的な思考であり、非連続的な成長を予測するのには不十分だと感じました。例えば、大規模言語モデルの成長がデータ基盤に影響を与える可能性があると思います。他の分野の進化における成長や進歩は、歴史を研究するだけでは想像が難しいと思いました。

今、私たちが目の前にある課題と捉えてない当たり前を、新たな課題と気づかせてくれるような技術の進化が楽しみですね

お読みいただき、ありがとうございました。

※ 今回はデータ基盤を中心に紹介しましたが、データメッシュ、CQRS、イベントソーシングなども重要だと考えています。ただし、データを生成する視点と、生成されたデータを管理する視点が曖昧な領域であると考え、今回の勉強会では扱わないことにしました。

ann-toque’s diary

@YASU11552288 の思うことをつらつらと

チームのデータ基盤技術の審美眼を育てるために取り組んでいること