我が社のデータエンジニアリング現場#Chatwork編_2024/05/22

by K.Mitsuhashi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

発表者：三ツ橋(みっつ) 3 ○業務経験 Chatwork入社以前はアド系ベンチャーのエンジニアとして、サーバ運搬から始まり、開発、新人育成と様々な役割を経験し、特に大規模データ処理の効率化に情熱を注ぐ。サービス拡大と比例して日々難度が増していくアド系データ処理にて、地獄の泥沼運用から生還した経験から、最先端のクラウド（マネージドサービス）を乗りこなして運用労力を最小化することに無上の喜びを感じている。 ○Twitter @kaz3284 ○Snowﬂake Data Superhero'24/'23, DataPolaris'22。

Slide 4

Slide 4 text

スモールスタートした新データ基盤、立ち上げることには成功したが... 4 ● シンプルな体制で進めることで成功した。 ● しかし、更にデータ利活用を推進するには、データエンジニアがボトルネックになる弱点が見えてきた直列型

Slide 5

Slide 5 text

並列型へ体制をアップデートして、進行中 5 データエンジニア ● 利活用現場で開発を進められる共通プラットフォームを整備していく ● データエンジニアがボトルネックにならない共通プラットフォームは、横串の機能を提供してデータ基盤開発をスケールさせる機能を持つ。直列型並列型

Slide 6

Slide 6 text

プラットフォームエンジニアリング・DataOps 6 プラットフォーム・エンジニアリング(cf. https://www.gartner.co.jp/ja/articles/what-is-platform-engineering) ● セルフサービス機能とインフラストラクチャ・オペレーションの自動化により、開発者のエクスペリエンスと生産性を向上させる。 ● 開発者だけでなく、オペレーションチームやビジネスチームなど、異なる役割の人々が技術的な作業に参加することにより、より効率的なプロセスと意思決定が可能になる。 ● ジェネレーティブAI（生成AI）もプラットフォームエンジニアリングの一環として活用される一つの手段となりより創造的で革新的な方法で技術的な作業に取り組むことができる。 DataOps(cf. https://www.montecarlodata.com/blog-what-is-dataops/ ) ● ソフトウェア開発のDevOpsと同様にデータを一連のフローで開発・運用していく仕組み ● 生産者と消費者が一丸となってデータ利活用を進めていく

Slide 7

Slide 7 text

開発の役割分担 7

Slide 8

Slide 8 text

データ基盤開発の状況 8 ● 様々なチームのメンバーが開発参加するようになった ● データ活用が爆進している ○ReverseETLを使った新機能を自ら実装。 →こういう使い方もしたいという話が続々と！ ○分析モデルを自ら実装・改善。 →取り込みデータ増えて、分析モデルが増加中！

Slide 9

Slide 9 text

'24/05時点の最新状況について 9 ○LT1「プラットフォームエンジニアリングの理想と現実　〜希望の光はTVP〜」　→ 従来比95%減を見込む自動化についてデータエンジニア飯島が語ります！ ○LT2「新米アナリストがデータ基盤開発って、無茶振りじゃないですか？」　→ 並列体制に積極参加するアナリスト小林が利用側視点の体験談を語ります！ ○LT3「我が社が考える最強のデータ基盤・開発体制！」　→ アナリスト田中が、本イベントで感嘆の声が多く上がった　アナリスト主導を実現した新機能開発について語ります！

Slide 10

Slide 10 text

Slide 11

Slide 11 text

AGENDA アジェンダ自己紹介プラットフォームエンジニアリングの理想と現実【事例1】データソース追加依頼のフォーマット化【事例2】テスト環境構築の自動化事例から見る共通点 1 2 3 4 5

Slide 12

Slide 12 text

自己紹介 12

Slide 13

Slide 13 text

自己紹介飯島知之 (Iijima Tomoyuki) 【略歴】 ● SIerでデータベース管理者としてキャリアをスタート ● データ基盤プロジェクトの企画から導入まで幅広く経験 ● 二人目のデータエンジニアとしてChatworkに入社【得意分野】 ● RDBMS/DWH, AWS, Terraform, dbtなどのデータ基盤技術【マイブーム】 ● notionで日記を書くこと（いつまで続くか…！？）アウトプット：https://zenn.dev/jimatomo 13

Slide 14

Slide 14 text

プラットフォームエンジニアリングの理想と現実 14

Slide 15

Slide 15 text

なぜプラットフォームエンジニアリングに取り組むのか？ボトルネック（くびれの部分）の解消が目的です！利用部門B アナリストチームデータエンジニアチーム利用部門C 利用部門A ・・・今後はここもボトルネックになるかもしれない直近はこのボトルネックの解消を進めている現状のデータ基盤開発に参加している範囲 ↑ ここを増やすためのプラットフォームエンジニアリング 15

Slide 16

Slide 16 text

プラットフォームエンジニアリングの理想と現実理想現実【体制】プラットフォームエンジニアリングの専任チームが設計・開発【機能の提供レベル】ガードレールと自由度のバランスよく提供できて、セルフサービス形式で利用できている（AWS的なXaaSが実現できている）【投資対効果】一度作れば長い間利用され続けて、投資回収できる【体制】データエンジニア（DRE）が日々の開発・運用作業の片手間でプラットフォーム機能の設計・開発【機能の提供レベル】時間が足りなくて、一定のスキルセットが前提となる最低限のものしか提供できていない（属人的なものが多く残っている）【投資対効果】最善の選択肢が変わるスピードが速く、投資回収できない場合もある 16

Slide 17

Slide 17 text

理想と現実のギャップに諦めそうになるが… （日々のタスクに追われてなかなか理想に近づけない） 17

Slide 18

Slide 18 text

希望の光はTVP (Thinnest Viable Platform) TVP (Thinnest Viable Platform) とは、（かなりざっくり解釈すると）「最低限のプラットフォーム」のこと最低限とは具体的に？ → ドキュメント（開発者向けのWikiなど）でOK （ハードルが超低い…！）参考：https://teamtopologies.com/key-concepts （本質的なところを見誤らなければ）こんな簡単なことでもいいんだ！と、一歩踏み出す勇気をくれる考え方 18

Slide 19

Slide 19 text

TVPだなぁという事例を2つほどご紹介します（dbtなどのデータ基盤のツールの説明は割愛します） 19

Slide 20

Slide 20 text

【事例1】データソース追加依頼のフォーマット化 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

データソース追加の際のペイン困りごと解決方法【データの詳細を知らない】データソースの特性やカラムの詳細な説明が分からず、依頼者に都度問い合わせが発生【データの詳細を知らない】データソースの特性が分かるドキュメントやカラムの詳細情報を依頼者に入力してもらうデータソースの追加の依頼（テーブル・カラム）データの調査セキュリティチェックデータソース追加の開発結合試験・リリースデータソース追加のフローここがペイン（ここも改善余地あり）パターンが決まっている 22

Slide 23

Slide 23 text

データソース追加依頼をフォーマット化こんな感じのスプレッドシートを用意して入力してもらう説明はしっかり書いておく（過去の入力例も参考にできる） 23

Slide 24

Slide 24 text

コードが自動生成されるように作り込む実は入力した情報をもとにdbtのSQLやyamlの設定コードが生成されます。パターンごとに少し違うコードが生成される（コピペして一部修正してコーディング完了）（現在も少しずつパターンを増やしていて、継続的にアップデートしています） 24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

【事例のサマリ】データソース追加依頼のフォーマット化効果 ● コミュニケーションコストの低減 ● コードの自動生成で開発スピード・品質を向上 ● メタデータもセットで集まるようになったどんな仕組みを提供したか ● 依頼の際に必要な情報をスプレッドシートに記入してもらえるように雛形を整備して提供 ● スプレッドシートの関数を利用してdbtのコードを自動生成できるようにした過去のシートを参考にすると新規の人も参加しやすい（説明コストを抑えるのがポイント）頑張りすぎないで小さく改善していけばいい（仰々しいアプリを作らなくてもスプシで十分） 26

Slide 27

Slide 27 text

開発のパターンが決まっているものをフレーム化 (スプシを整えるだけでもいい) これも一つのTVP 27

Slide 28

Slide 28 text

【事例2】テスト環境構築の自動化 28

Slide 29

Slide 29 text

【事例のサマリ】テスト環境構築の自動化効果 ● 結合試験環境の構築工数の低減（8時間/月 → 5分/月） ● リリースまでのリードタイム短縮（2週間 → 2日） ● リグレッションテストなども実施しやすく変更を気軽に試せるようになる ※今後開発量が増えていくほどに効果が高まっていくどんな仕組みを提供したか（予定） ● 本番データを利用した新しいdbtモデルのテストの環境構築を自動化 29

Slide 30

Slide 30 text

現状の開発プロセスのペイン困りごと解決方法【準備】データの準備が手動でとにかく時間がかかる（マスキングなしのデータの準備がさらに手間がかかる）開発環境（アカウント） Staging環境（アカウント）本番環境（アカウント） ※セキュリティのリスク低減のためにSnowﬂakeのアカウント単位で環境分かれています（＋環境破壊事故が起こらないように） dbtモデル開発のフロー SQLロジックのテスト（テストデータは手動投入）（コンパイルされたコードを本番環境で投げてのテスト）ココもペイン本番想定データでの結合テスト（テストデータは本番環境からコピー ※通常マスキング有）本番データでの受け入れテスト【準備】本番アカウントでゼロコピークローン機能を活用して回避ここがペイン 30

Slide 31

Slide 31 text

本番アカウント本番データを利用したテスト環境構築を自動化（構想中）本番DB テスト環境DB 1) dbt cloneコマンドで必要なモデルのみクローン（※Version 1.6にて導入された機能） 2) dbt buildコマンドで対象のモデルのみビルドリグレッションテストも自動化できそうな datafold (data-diﬀ) を組み込みたい https://www.datafold.com/data-diﬀ Before After 本番アカウント Stagingアカウント本番DB 本番DBのシェアテスト環境DB 1) シェアの設定で見れるように設定する 2) 対象のデータをINSERT 3) dbt buildコマンドで対象モデルをビルド 31

Slide 32

Slide 32 text

自動化による効果（試算）現状（小さめのリリース1回）自動化開発時にコンパイルしたコードを修正して本番でテスト incrementalモデルなどはdbtのdata testまで手が回らない 15〜30分 0分結合試験でコピーが必要なテーブルの情報を整理 ※マスキングの影響などの調査も含めて 60〜120分 0分結合試験でコピーの手順を準備 30〜60分 0分結合試験環境にデータをコピーしてくるオペレーション 15〜30分 5分 ● “モデルの複雑度” × “モデルの数” で増えていく → 並列開発体制で開発量が増え、今後右肩上がりで増えていく状態 ● リリースまでのリードタイムを劇的に短縮できるメリットも大きい → 現状環境の準備の大変さからある程度まとめて結合試験を実施 ● リグレッションテストまで自動化できるとリファクタリングなども積極的にチャレンジできる心理的ハードルを下げることができる 95% 削減 32

Slide 33

Slide 33 text

よく発生するオペレーションを効率化するこれも一つのTVP 33

Slide 34

Slide 34 text

事例から見る共通点 34

Slide 35

Slide 35 text

本質はいつもシンプル今回取り上げた事例に共通しているポイントは以下の3つ ● 利用者の声を拾う ○ 効果が高いものはユーザが一番知っている（自分もユーザの一人） ● ペインが継続していくものを対象にする ○ 繰り返し使えるものでないと投資対効果が出ない ● 最初から頑張り過ぎない ○ これが一番大事（TVPという考え方が一歩踏みだす勇気をくれる） Thinnest Viable Platform で一歩先のデータ基盤へ進化させています！（今回取り上げられなかった他にもやりたいことが山積みです） 35 頑張ろうという気持ちは大事頑張り過ぎないバランスも大事

Slide 36

Slide 36 text

働くをもっと楽しく、創造的に

Slide 37

Slide 37 text

Slide 38

Slide 38 text

「利用部門」のアナリストから見た、データ基盤開発のリアルをお話します 38 データエンジニアデータアナリスト（私）

Slide 39

Slide 39 text

発表者：小林 39 ○業務経験マーケティングリサーチャーとしてキャリアをスタート。顧客企業向けに、アンケートやインタビュー調査、ビジネスデータの分析などを実施してきた。事業会社でデータ活用まで携わりたいと思い、 23年9月にデータアナリストとしてChatworkに入社。主に、ビジネス部門向けのデータ分析・活用、 Lookerを使ったダッシュボード開発、dbtのモデル開発を担当。リサーチャー　→　データアナリスト

Slide 40

Slide 40 text

データ基盤開発デビューまでの道 40 SECTION TITLE １

Slide 41

Slide 41 text

ふだんの分析で、つらみに遭遇 41 Looker側でrawに近いデータから集計した結果・・・ ● Lookerのダッシュボードが重い。 ● LookerとDWHにロジックが散在。 ● 毎回クエリ発行する形になり、コスト増の原因に。膨大なイベントログを集計した結果・・・ ● 一回の集計に時間がかかる。 ● 定期運用すると、コストも無視できない。遭遇したつらみ日々のアナリスト業務 Lookerで、新規登録数をモニタリングするダッシュボードをつくるぞ！プロダクトのイベントログから、利用状況の総合スコアをつくるぞ！

Slide 42

Slide 42 text

「小林さん、dbtでモデル開発してみませんか？」 42 データエンジニアに相談したら、逆に開発に誘われる当時の心境↓ ● いやいや、無茶振りじゃないですか？ ● データエンジニアの仕事では？（リソースが足りないと見た　　） ● でも、先にdbt開発に参加していたチームメンバーは楽しそう「まあ、いい機会だし、できる範囲でやるか」くらいの気持ちで参加

Slide 43

Slide 43 text

あれよあれよと巻き込まれる気が変わらぬうちに、データエンジニアから、事前のセットアップ＆ハンズオンの案内

Slide 44

Slide 44 text

手厚いハンズオン 44 手順化＆ドキュメント化されているので、後からゆっくり確認できて安心 & つまずいた部分もフォローアップ ↓ハンズオン(1h)の内容 ↓フォローアップこばやしじまさんコンテナつくるところでエラー出ちゃいます。。ショートmtgで一緒に確認しましょう！

Slide 45

Slide 45 text

気づいたら、開発スタート 45 初回のモデルの全体設計は、開発経験者が実施（ここは、内容次第で設定） → まずは、開発スタート（手を動かしながら理解） ←全体設計初回設計は経験者側で作成。モデルの分け方、種類あたりで迷わず、初回開発でも不安なく手が動かせる。（結果、設計への理解も進む）

Slide 46

Slide 46 text

ポイント①：自分で試行錯誤できる環境 46 dev/staging/prod 構成開発フローが整っている＝安心して試行錯誤できることを、開発参加者が理解できることが大事過去のクエリ、PR、ドキュメントで、見ながら自分で理解できるようになっている開発環境で試行錯誤しながら、自分のペースで理解して進められる

Slide 47

Slide 47 text

ポイント②：「便利で楽しい」を実感する開発体験 47 実際に触ってみることで、dbtの良さも実感できる ↓アナリスト視点で、感動した点 ● dbt build一発で、モデル&テストがぶわーっとできる ● 今まで手動でやっていたテストが自動で走る ● マクロを使って、クエリがスッキリ書ける ↓思わず感動を報告する私

Slide 48

Slide 48 text

ポイント③：ポジティブなフィードバック 48 ↓レビューだけでなく、ポジティブなフィードバック ↓ピアボーナスポジティブなフィードバックをもらえて、うれしい（データエンジニア的には「ふつう」のことでも、あっているか実感なく不安。フィードバックしてもらうことで、「これでOKなんだ、次からもやってみよう」となる。）

Slide 49

Slide 49 text

めでたく、モデル開発デビュー 49 LookML側でrawに近いデータから集計した結果・・・ ● Lookerのダッシュボードが重い。 ● LookerとDWHにロジックが散在。 ● 毎回クエリ発行する形になり、コスト増の原因に。膨大なイベントログを集計した結果・・・ ● 一回の集計に時間がかかる。 ● 定期運用するとなると、コストも無視できない。遭遇したつらみ（再掲）ダッシュボードの表示速度が大幅改善ロジックがdbtに一元化処理時間が大幅短縮（10分近い処理が数秒に）分析業務のつらみも解消できて、Win-Win！

Slide 50

Slide 50 text

データ基盤開発にデータ基盤「利用部門」を巻き込むには 50 SECTION TITLE ２

Slide 51

Slide 51 text

データ基盤「利用部門」がジョインするために、ポイントだった点 51 ● やっている人が楽しそう & ポジティブなフィードバック ○ 「dbt開発楽しいですよ」 ○ 「ここの実装いいですね！こうすればもっとよくなりますよ！」 ● 開発環境の構築がラク＆手厚いサポート ○ dbt + コンテナベースの開発環境 ○ データエンジニアがハンズオン形式でサポート ● 自分で試行錯誤できる環境 ○ 一定開発が進んでおり、過去のクエリやPR、ドキュメントを見れば、なんとなくわかる ○ dev/stag/prod構成の開発フローが理解でき、dev環境で安心して試行錯誤できる ● 「便利で楽しい」を実感する開発体験 ○ dbt buildでモデルがぶわーっとできる ○ 今まで手動でやっていたテストが自動で走る ○ マクロ機能で、クエリがスッキリ書ける

Slide 52

Slide 52 text

利用部門が参加する／巻き込むメリット 52 【利用部門側のメリット】 ● データ基盤に、ビジネス部門のニーズを直接・素早く反映できる ● 工程を理解することで、自分が使うデータへの信頼感が高まる【利用部門を巻き込むメリット】 ● 開発リソースが増える（利用拡大に応じて開発リソースもスケールする） ● データ基盤のファンが増える（浸透に協力してくれる人が増える） ● 利用部門が、dbtモデル化できないか？と考えるようになる -> レビューされたロジックがdbtに一元化されるので、データカオス化しづらい ● 利用部門目線でデータに疑問があった際に、自分である程度調査できる -> ドメイン知識観点でのデータ品質の向上につながる

Slide 53

Slide 53 text

これからのチャレンジ 53 ● ユースケースに応じた、dbtモデル & BI層の開発・浸透（dbt + Looker、Exploratory、Streamlit、・・・） ● ビジネス部門用ツールとのパイプライン構築（↔Salesforce、スプレッドシート、・・・） ● ビジネス部門と協働で、データ品質を向上する取り組み（広告用マスタの整備・運用、Salesforceデータの最適化、・・・）一緒に作ってくださる方を絶賛募集中です！まだまだやりたいことはたくさん・・・

Slide 54

Slide 54 text

働くをもっと楽しく、創造的に

Slide 55

Slide 55 text

Slide 56

Slide 56 text

自己紹介 56 ● 田中賢太（たなかけんた） ● @tadaken3(タダケン) ● Chatwork ← LINE ← 任天堂 ● データアナリスト ● データをいい感じに集計・分析して、プロダクトの成長に繋げる ● 嫁と子供（３歳👦）と3人ぐらし ● 趣味：レトロゲーム集め https://chado.chatwork.com/entry/2024/03/12/100000 インタビュー

Slide 57

Slide 57 text

前回のハイライト

Slide 58

Slide 58 text

前回の「我が社が考える最強のデータ基盤'24最新版」 58

Slide 59

Slide 59 text

成果が出たこと、アナリスト自ら新機能を実現 59 ● アナリスト自ら、reverseETL(hightouch)を使ってエンジニアリソースを使わずに新機能を実現できた ○ 開発工数が確保できなく長く保留になっていた機能だった... ○ 自らdbtでデータモデルを開発＆検証を経て本番デプロイを実現した前回資料

Slide 60

Slide 60 text

成果が出たこと、アナリスト自ら大幅なコスト削減を実現 60 ● アナリスト自ら利用実態に即して、分析モデルを効率化するように。 ○ BIの応答速度が上がり、業務効率が上がった ○ クエリ効率がよくなって、コストが下がった前回資料

Slide 61

Slide 61 text

● 利用部門が自分たちで開発するとか、アナリストの人が開発なしで新機能実現とかすごい。いい話すぎる ● アナリストだけでリバースETL構築。素晴らしい ● 「アナリストが自ら分析機能を実現した」のは大きいな、データ民主化はもはや当たり前で「データ分析」の民主化が必要 ● データの利用者たちが横串でデータを利用できるようになることって素敵。DataOpsだなあ「我が社が考える最強のデータ基盤'24最新版」の反響 61 実際のX（旧Twitter）のコメントはこちら https://twitter.com/hashtag/ChatworkTechTalk?src=hashtag_click&f=live

Slide 62

Slide 62 text

それ、ワタシです 62

Slide 63

Slide 63 text

今日話すこと 63 データアナリストからみた並列開発体制のオモテガワとウラガワ

Slide 64

Slide 64 text

並列開発体制のオモテガワ

Slide 65

Slide 65 text

並列型の開発体制 65 データエンジニア ● 利活用現場で開発を進められる共通プラットフォームを整備していく ● データエンジニアがボトルネックにならない共通プラットフォームは、横串の機能を提供してデータ基盤開発をスケールさせる機能を持つ。直列型並列型

Slide 66

Slide 66 text

開発の役割分担 66

Slide 67

Slide 67 text

開発の役割分担 67 データエンジニアのプラットフォーム力アナリストのドメイン知識

Slide 68

Slide 68 text

68 もうちょっと詳しく開発体制の分担 1.設計 2.実装 3.単体テスト 4.結合テスト 5.リリースエンジニアアナリストエンジニアエンジニアアナリストアナリスト

Slide 69

Slide 69 text

並列開発体制のハジマリ (オモテガワ)

Slide 70

Slide 70 text

70 並列開発体制のハジマリタダケン目線 dbtの開発に入りたい場合、以下のドキュメントを参考に、開発コンテナをbuildするって感じでいですよね？（すみません。ドキュメント見つけたので、勝手に）この辺りもご確認いただけるといいかなと思います。操作がよくわからないとかあればMeetとかで画面共有しながらフォローとかもできますので、相談ください〜基本的にはそうなります。ただ、キャプチャのgitブランチ切ってないのでbuildは失敗します。ブランチとタスクを紐づけるためにこちらから〜検証みたいなタスク切った上でそれに紐づくブランチを作成して、 buildいただけると通るかと(新Dev環境整備中なので、できたら環境が切り替わる感じにはなりますがじまさんみっつさんタダケン

Slide 71

Slide 71 text

全てはここから始まった（アナリストとしてdbt開発の第一号として飛び込む）

Slide 72

Slide 72 text

72 最初は既存モデルの修正から手をつけて、、、やったこと 1. 既存のmodelの修正(まずはdbtになれる） 2. 既存のincremental modelの修正(差分更新の場合のお作法を学ぶ） 3. seedの開発（CSVデータなどの取り込み） 4. 新規のmodelの開発

Slide 73

Slide 73 text

73 ほぼ単独で設計から実装まで！組織単位でのプロダクト活用度ですが、こんな感じで行こうかなと。

Slide 74

Slide 74 text

74 datainfraのリポジトリではAdditionalで２番目に

Slide 75

Slide 75 text

並列開発体制でのReverse ETL (オモテガワ)

Slide 76

Slide 76 text

76 ある日のカスタマーマーケティングとの会話もっとプロダクト内のデータを使ってユーザーコミュケーションができるといいんだけどでも、エンジニアはほかにやることでいっぱいですよどこもエンジニア不足ですよね、、、カスタマーマーケティング

Slide 77

Slide 77 text

77 Reverse ETLのハジマリタダケン目線事業側で、デジタルマーケティングツールに、snowﬂakeのデータ連携したいのですが、なんかいい方法ないです？モダンデータスタックのジャンル的には、Reverse ETLというところですね。いくつかのReverse ETLを検証したWikiがあるので共有しますねみっつさんタダケンサポートしますのでわからないところはお気軽に〜じまさん

Slide 78

Slide 78 text

78 並列型の開発体制：Reverse ETLの実装やったこと 1. 要求・要件整理 2. 検証（要件を満たせるか） 3. 負荷試験 4. データ連携用dbt modelの開発 5. Reverse ETLの実装

Slide 79

Slide 79 text

Reverse ETL 「hightouch」 79 データソースと連携先を選んで、データ連携が簡単に！企業秘密

Slide 80

Slide 80 text

80 負荷テストもsnowﬂakeなら容易に 1000万レコードのダミーデータも10分で生成負荷テストは数年先も見越して、 1000万レコードでやりなさい技術基盤戦略室室長春日さん

Slide 81

Slide 81 text

データの移送速度もすごいhightouch 81 1000万レコードの２テーブルを並列でデータ移送して約2時間で完了。*実際は差分更新すごいな！hightouch 技術基盤戦略室室長春日さん

Slide 82

Slide 82 text

82 Reverse ETLを実装したおかげでカスタマーマーケティングアナリスト（タダケン）データに基づいて、ユーザーコミュニケーションできるぞー分析から施策へのデータ活用まで一気通貫してできるぞー

Slide 83

Slide 83 text

83 Reverse ETLを実装したおかげで Reverse ETLを実装したおかげで Reverse ETLを実装したおかげで Reverse ETLを実装したおかげで（２回目）エンジニアリソースを使わずに機能追加できてみんなHappy

Slide 84

Slide 84 text

並列開発体制のウラガワ

Slide 85

Slide 85 text

85 dbtの開発に入りたい場合、以下のドキュメントを参考に、開発コンテナをbuildするって感じでいですよね？（すみません。ドキュメント見つけたので、勝手に）この辺りもご確認いただけるといいかなと思います。（別のドキュメントのURL）操作がよくわからないとかあればMeetとかで画面共有しながらフォローとかもできますので、相談ください〜基本的にはそうなります。ただ、キャプチャのgitブランチ切ってないのでbuildは失敗します。ブランチとタスクを紐づけるためにこちらから検証みたいなタスク切った上でそれに紐づくブランチを作成して、buildいただけると通るかと新Dev環境整備中なので、できたら環境が切り替わる感じにはなりますがじまさんみっつさんタダケン並列開発体制の本当のハジマリ

Slide 86

Slide 86 text

86 dbtの開発にスッと入れた理由 ● 部署を超えた協力関係 ● ドキュメントがあったから飛び込めた

Slide 87

Slide 87 text

87 Reverse ETLの本当のハジマリ事業側で、デジタルマーケティングツールに、snowﬂakeのデータ連携したいのですが、なんかいい方法ないです？モダンデータスタックのジャンル的には、Reverse ETLというところですね。いくつかのReverse ETLを検証したWikiがあるので共有しますねみっつさんタダケンサポートしますのでわからないところはお気軽に〜じまさん

Slide 88

Slide 88 text

Reverse ETL 「hightouch」をスッと実装できた理由は？ 88 ● 部署を超えた協力関係 ● データエンジニアの方で、Reverese ETLの検証をしていたから ● しかも、実装が容易なモダンデータスタックで

Slide 89

Slide 89 text

● セルフサービスと自動化を通じて、開発業務の生産性を向上させること ● アナリストチーム（not エンジニア）が開発に参加でき、より迅速に価値を提供できる ● エンジニアは、プラットフォームをより拡充させる業務に取り組むことが可能 ● 将来的には、生成AIを活用し、オペレーションチームやビジネスチームも開発に参加できるかもプラットフォームエンジニアリングとは？ 89 ＊ガードナーが2022に提唱した概念 cf. https://www.gartner.co.jp/ja/articles/what-is-platform-engineering

Slide 90

Slide 90 text

90 ひとりでも多くの人が並列で開発できるようにアナリストだってドキュメント整備に協力これがChatworkのカルチャーや技術基盤戦略室室長春日さん

Slide 91

Slide 91 text

まとめ

Slide 92

Slide 92 text

まとめ 92 ● 我が社が考える最強の開発体制は「並列開発体制」 ○ データエンジニアとアナリストのバディ≒協業 ● プラットフォームエンジニアリング ○ ドキュメントの拡充 ○ マネージドされたサービスの利用（モダンデータスタック）エンジニアアナリストえらい人

Slide 93

Slide 93 text

働くをもっと楽しく、創造的に