Tweet
Tweet

Slide 1

Slide 1 text

Google Cloud で学ぶデータエンジニアリング入門 2025年版（スライド公開用） 2025-08-05 Google Cloud Next Tokyo ‘25 株式会社風音屋 Google Developer Experts @yuzutas0

Slide 2

Slide 2 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 2

Slide 3

Slide 3 text

1. はじめに

Slide 4

Slide 4 text

本日の内容 初学者向けにデータエンジニアリング＆データアナリティクスの全体像を解説します。 ● Cloud Storage、BigQuery、Dataform、Looker Studioによるデータの収集・連携・監視・加工・ 可視化の流れを紹介します。 ● また、Dataplex Universal Catalog によるメタデータの管理・活用や、BigQuery Canvasによる データフローの設計・実装・動作確認にも言及します。 ビジネスユーザーでも直感的に利用できること、Geminiによるさらなる補助が期待できることから、 改めてこのタイミングで全体像を抑えておきましょう。 4

Slide 5

Slide 5 text

想定する対象 ● データ基盤の構築に関心がある人。 ○ 「風音屋にデータ基盤構築の発注を検討しているIT部門長やマーケティング部門長」、 「風音屋に入社したデータエンジニア」といった方々に配るつもりで資料を作っています。 ● [必須] ITパスポート相当の知識がある人。 ○ Python、RDBMS、SQL、CSV、WebAPI等の初歩的な説明ができる水準を想定します。 ○ それ未満だと、IT関連の仕事を担当したり、発注管理するのはちょっと難しいかもしれません󰢛 ■ 最初は少し大変ですけど、ぜひ学習を頑張りましょう💪 ● [推奨] Google Cloudや各サービスの基礎知識がある人。 ○ 文量の都合上、個々のサービス説明は淡泊になるため、別教材で補強いただくと助かります。 ○ Google Cloudの担当営業に60分のデモをお願いするだけでも十分理解は深まると思います。 ○ Google Cloudのハンズオンチュートリアル経験者や、認定資格の保有者だとBetterです。 ● 職種は特に限定なし。ITエンジニア以外でも歓迎です。 ○ データ基盤という題材の特性上、どうしてもITエンジニア向けになっている箇所があります。 ○ Google系ツールという題材の特性上、Webマーケティング系の用語を扱う箇所があります。 ○ 細かいところは飛ばしながら読んで、雰囲気だけでも掴んでいただければと！ 5

Slide 6

Slide 6 text

注意事項 1. 本資料は許諾した範囲内でのみご利用ください。無断転載ならびに複写を禁じます。 2. 本資料に記載されている会社名・製品名などは、一般に各社の登録商標または商標、商品名です。資 料内では ©, ®, ™ マーク等は省略させていただいております。 3. 本資料は特定企業の情報公開や称賛・批判を意図するものではありません。社名が提示されていない ケーススタディやシステム構成は、原則的に複数企業の事例を踏まえたダミー情報となります。 4. 説明を簡略化するために、用語やツールの紹介は厳密な定義に則っていない場合があります。ご自身 や所属チームでの理解・解釈が紹介内容と異なる場合は、適宜読み替えていただけると幸いです。 5. 本資料はGoogle Cloudならびにその関連企業の見解を代表するものではありません。風音屋は Google Cloudの認定パートナー企業であり、発表者はGoogle Developer Expertsに所属しています が、あくまで独立した立場にもとづいて情報発信を行っています。 6

Slide 7

Slide 7 text

登壇者（カジュアル版） ゆずたそ（@yuzutas0） リクルートやメルカリでデータ活用を推進後、AWSを経て、風音屋（かざねや）を創業。 データ基盤やダッシュボードの構築について積極的に情報発信しており、主な著書・訳書に『実践的データ 基盤への処方箋』『データマネジメントが30分でわかる本』『アジャイルデータモデリング』がある。 1,800人が参加するSlackコミュニティ datatech-jp、延べ参加者15,640人の勉強会 Data Engineering Study の立ち上げに関わるなど、日本のデータエンジニアリング業界の発展をリードしてきた。 7 Now Writing…

Slide 8

Slide 8 text

登壇者（エンタープライズ版） 横山 翔（@yuzutas0） 株式会社風音屋 代表取締役。Conservation International、リクルート、メルカリ、AWSを経て、風音屋（かざねや）を創業。 広告配信の最適化、店舗営業のインセンティブ改善など、データ分析によって数億円規模のインパクトを創出。 データ基盤やダッシュボードの構築について積極的に情報を発信。 主な登壇・発表 ● Pythonのカンファレンス「PyCon JP 2017」にてベストトークアワード優秀賞 ● 翔泳社主催「Developers Summit 2018 Summer」にてベストスピーカー賞 ● Google主催「Google Cloud Day」（‘21, ‘23）,「Google Cloud Next Tokyo」（‘23） ● 日本統計学会 第16回春季集会 主な執筆・翻訳 ● 講談社サイエンティフィク『アジャイルデータモデリング』 ● 技術評論社『実践的データ基盤への処方箋』 ● 技術評論社『Software Design』（’20年7月号 - ログ分析特集、’25年7月号 - SQL特集） ● 風音屋『データマネジメントが30分でわかる本』 ● 内閣府「経済分析 第208号 - 景気動向分析の新たな潮流」 主なコミュニティ活動 ● 1,800人以上のデータ人材が参加するSlackコミュニティ「datatech-jp」の立ち上げ・運営 ● 延べ参加者15,640人以上の勉強会「Data Engineering Study」の立ち上げ・モデレーター（2020〜2025） ● 国内最大規模の技術カンファレンス「Developers Summit」コンテンツ委員会（2022〜2025） ● 東京大学 経済学研究科 金融教育研究センター 特任研究員（2023〜2025） ● Googleが認定する技術エキスパート「Google Cloud Champion Innovator / Google Developer Experts」に選出（2023〜） 8

Slide 9

Slide 9 text

大手からスタートアップまで幅広いクライアント企業のデータ活用を支援するITコンサルティング企業。 100社のデータ経営を実現し、諸産業の活性化に貢献することをミッションとして掲げています。 データエンジニアたちが技術相談やノウハウ共有しあう副業ギルドとして始まり、 日本全国から多数のご相談・ご要望を受けて法人化。 ステークホルダーの皆様にご協力いただきながら、会社組織としてアジャイルに成長してきました。 スタートアップCEOからの推薦コメント 風音屋（かざねや） 9 ご支援先（一部抜粋）　　　　 ● ランサーズ株式会社 ● エイベックス株式会社 ● 株式会社クラシコム ● 株式会社商船三井 ● 株式会社ビズリーチ ● NE株式会社 ● 株式会社リクルート ● 福岡地所株式会社 ● 住友化学株式会社

Slide 10

Slide 10 text

風音屋が提供するサービス 10 データ基盤構築 データ分析

Slide 11

Slide 11 text

データエンジニアリングの書籍が読み放題です！ 風音屋オフィス（Library） 11

Slide 12

Slide 12 text

話題の新刊を次々とご恵贈いただいております！Google Cloudの書籍もご恵贈いただきました！ 風音屋オフィス（Library） 12

Slide 13

Slide 13 text

採用活動の文脈でMENTA講座を提供 13

Slide 14

Slide 14 text

MENTA講座では「Google Cloudによるデータ基盤構築」のハンズオンを行います！ Google Cloudによるデータ基盤構築 14

Slide 15

Slide 15 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 15

Slide 16

Slide 16 text

2. データ活用の事例

Slide 17

Slide 17 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 17 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 18

Slide 18 text

組織経営のためのデータ分析 ● 営利企業の経営会議で「利益 = 売上 - 費用」の予算・実績を確認し、差があれば深堀りを行う。 ● 非営利団体（例：学校）の活動状況を可視化し、運営方針のブラッシュアップを行う。 株式会社風音屋（監訳）『アジャイルデータモデリング』より「株式会社クラシコム」「学校法人 北陸大学」の事例 18

Slide 19

Slide 19 text

指標モニタリング 販売数、登録数、コンテンツ閲覧数、広告費、商談数、問い合わせ数、問い合わせ対応時間など。 毎朝の売上データ通知 予算管理シート グラフ・ダッシュボード 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 19

Slide 20

Slide 20 text

顧客セグメント、商品セグメントなど。 ①全体の数値→②切り口によるドリルダウン→③N1（具体的な1人）と深堀り、課題を特定する。 セグメント分析 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 全体 > セグメント別 セグメント > n1 ■A1層(ロイヤル顧客) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 要 因 ロイヤル増加 ロイヤル離脱 既知 パターン ・xxxだった ・xxxだった ・xxxだった ・xxxだった 新規 パターン ・おそらく xxx・お そらく xxx ・おそらく xxx・お そらく xxx 20

Slide 21

Slide 21 text

傾向分析 例：問い合わせ内容の偏り。売れ行きの良いジャンルと悪いジャンルの確認。 問い合わせの詳細 問い合わせの傾向 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 21

Slide 22

Slide 22 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 22 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 23

Slide 23 text

ユーザーの利用状況 主要導線における遷移、離脱を計測して、改善インパクトの大きい箇所を特定する。 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 行動ファネル(遷移率) ジャーニーマップ+各遷移の遷移率 23

Slide 24

Slide 24 text

顧客データベース整備による部署連携（後工程への引き継ぎ） ● セールス部門のツールと、カスタマーサポート部門のツールで見える情報に差があると お客様とのコミュニケーションに齟齬が生じたり、データの受け渡し作業が何度も発生する。 ● 各自で使いやすいツールを使いつつ、顧客データを統合・参照することで、サービス向上を実現。 「スピード」と「品質」のスイッチング ～事業成長を支える生存戦略～　https://speakerdeck.com/yuzutas0/20210218c1 例：Salesforce BigQuery セールス サポート オペレーション 例：Kintone 例：Zendesk 加盟店契約 審査・キット配送 問い合わせ対応 24

Slide 25

Slide 25 text

人材データベース整備による履歴管理（将来への引き継ぎ） 人材斡旋事業の履歴チェック自動化 ● 過去のコミュニケーションを確認することで、候補者打診前にアンマッチを防ぐ ● 社内に散在している人材データを統合し、ボタン1つで人検索できるようにシステム化 ● 担当者の自助努力に依存していた→システム化によって安定品質を実現可能にする Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 25

Slide 26

Slide 26 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 26 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 27

Slide 27 text

工場における製造プロセス改善や故障検知 ● MI（マテリアルズ・インフォマティクス）によって新しい材料の開発・探索を効率化。 ● PI（プロセス・インフォマティクス）によって材料を量産できるように製造プロセスを最適化。 ○ 例：粉体製品の製造プロセスについて分析を行って、収率低下原因を解明し、改善を実現。 ● プラント（大型工場）の操業ダッシュボードによるタイムリーな操業判断。 ○ 例：ポリマー製品の押出機の不調を早期発見し、設備トラブルを未然に防止。 株式会社風音屋（監訳）『アジャイルデータモデリング』より「住友化学株式会社」の事例 27

Slide 28

Slide 28 text

エンタテイメント領域におけるコンテンツ制作の促進 ● ラジオ局の番組をポッドキャストに配信 ● インターネットを通して世界中へと対象リスナーを拡大 + 音声広告による収益化 ● 地域別/時間帯別の再生状況をモニタリングし、データ駆動の番組企画を実現 https://pitpa.jp/studio Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 28

Slide 29

Slide 29 text

レコメンド、マッチング 類似商品の推薦、プッシュ通知やメールでのコンテンツ案内、CTRを最大化する検索結果の表示順、 マッチングの期待値が高い人材やお相手の紹介など。 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 29

Slide 30

Slide 30 text

施策によって主要指標が変動し、期待するビジネス効果を得られたかを確認する。 施策の効果測定 ABテスト結果 新機能の利用率 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops https://speakerdeck.com/yuzutas0/20211210 株式会社風音屋（監訳）『アジャイルデータモデリング』より 「ランサーズ株式会社」の事例 30

Slide 31

Slide 31 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 31 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 32

Slide 32 text

あああ セールススタッフが使う顧客管理ツール （プロダクトの前の世界を扱うデータ） 従量課金による粗利益の最大化 　　ソフトウェアエンジニアが見るデータベース （プロダクトの中の世界を扱うデータ） データを 横断活用 ● 従量課金やレベニューシェア、ダイナミックプライシングによる、粗利益・ARPPUの最大化。 ● 契約件数ではなく利用状況に応じて営業代理店にインセンティブを付与することで、 利用に繋がらない契約を無理に取るのではなく、アフターサポートまで見据えた商談を促す。 メルカリ社が運用する trocco & BigQuery のデータ分析基盤と経済性 #GoogleCloudDay https://speakerdeck.com/yuzutas0/20210526 32

Slide 33

Slide 33 text

相場が不透明な商品のプライシング（値付け）支援 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 ● クラシックカーの購入希望者に過去取引データを提示。動産（アート）や不動産（物件）など、 個人間の交渉で価格が決まる「1点モノ」は相場感が見えると意思決定の後押しになりうる。 ● フリーランス依頼時に発注価格が低すぎないかをAIがチェック。取引プラットフォームにおける トラブル防止や健全性担保に寄与する。 33

Slide 34

Slide 34 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 34 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 35

Slide 35 text

モビリティや物流、宇宙領域における交通ルートや移動スピードの最適化 ● 月面探査機における「資源ポイント」へのルート最適化。 ● 配車手配サービスにおける「送り迎え地点」へのルート最適化。 ● 走行スピードや路面画像から「事故が起きやすい地点」を特定し、ドライバーに減速を促す。 「宇宙を人類の生活圏にする」民間発の月面探査チーム・HAKUTOが描く、近未来のビジョン　https://logmi.jp/brandtopics/194965 月面探査プロジェクトの最終ゴールとは？ HAKUTOとリクルートテクノロジーズの挑戦　https://logmi.jp/brandtopics/195185 35

Slide 36

Slide 36 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 36 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 37

Slide 37 text

デジタル広告配信の業務効率化 ● ROAS（売上÷費用）を最大化できるように、 「配信媒体」「クリエイティブ」「予算配分」を調整。 ● 広告効果の集計作業を自動化して、効率的にレポート。 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 37

Slide 38

Slide 38 text

広報コンテンツ化による市場メッセージ ● IRで利用状況を開示したり、プレスリリースやインフォグラフィックで市場にメッセージ。 ● 時節に適したデータ開示を行うことでメディアが取り上げやすくなる。 ● ファクトブック作成のデータ抽出を仕組み化すると、即座にアップデートできるようになる。 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 38

Slide 39

Slide 39 text

ユーザーの熱狂や ”バズり” の検知 (1) SNSやYouTubeで話題になり始めているコンテンツ（楽曲）を自動検知 (2) それらの楽曲を含むプレイリストを即日公開 (3) 音楽ストリーミングサービスのプレイリストランキングにランクイン 株式会社風音屋（監訳）『アジャイルデータモデリング』より「エイベックス株式会社」の事例 39

Slide 40

Slide 40 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 40 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 41

Slide 41 text

対象者リスト抽出の効率化 クーポン配布の対象顧客、障害発生時の影響調査など。わざわざ本番インフラ環境にアクセスしたり、 CSVダウンロードプログラムを作らなくても、BigQueryのWEBコンソール画面でデータを確認できる。 データベース サーバログ アクセス解析ツール BigQuery SQLを書く データを見る 実行する 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 対象抽出の ロジック検討 イメージ 41

Slide 42

Slide 42 text

迷惑行為やスパム行為の異常検知 (1) 過剰アクセスや迷惑投稿を各フェーズで検知 (2) 違反候補者のリストを作成 (3) オペレーターが目視チェック 登録情報 サイト回遊 （商品検索） 投稿内容 （口コミ） リクエスト （日時や頻度） アクション （ブクマ） ルールベース or 機械学習 検知：早い 精度：低い チェック データ データ チェック データ チェック チェック チェック データ データ 検知：遅い 精度：高い 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 42

Slide 43

Slide 43 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 43 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 44

Slide 44 text

資産ポートフォリオの最適化 物件や船舶などの資産（アセット）をベースとしたビジネスの場合、 「購入・開発などのアセットを増やす活動」「売却・廃棄などのアセットを減らす活動」を行い、 アセットごとの収益率や変動（ボラティリティ）をモニタリングしながら、バランスシートを拡大する。 株式会社風音屋（監訳）『アジャイルデータモデリング』より「株式会社商船三井」の事例 44

Slide 45

Slide 45 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 45 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 46

Slide 46 text

M&Aのシナジー効果や事業間ポートフォリオの計測 株式会社風音屋（監訳）『アジャイルデータモデリング』より「ランサーズ株式会社」の事例 46 ● 既存事業とM&A（予定の）事業とで、利用ユーザーの重なりや送客効果を推定・測定する。 ● 事業A（エントリー向け）から事業B（ベテラン向け）へのユーザー移動を正確に把握することで、 事業Aのユーザー離脱が「自社ポートフォリオ内の移動」か「対処すべき離脱」なのかを特定する。

Slide 47

Slide 47 text

新規事業のモックアップ加速 ランサーズのデータ活用を手伝っている話 - 下町柚子黄昏記　https://yuzutas0.hatenablog.com/entry/2020/12/24/153000 47 オープンデータや社内データをモックアップに当てはめることで、開発工程の一部を省略し、短期間での コンセプト検証を可能とする。

Slide 48

Slide 48 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 48 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 49

Slide 49 text

ビジョン達成状況の可視化 株式会社風音屋（監訳）『アジャイルデータモデリング』より「ランサーズ株式会社」の事例 49 ● 売上や顧客数だけではなく「こうなってほしい」というビジョンの達成状況を計測する。 ● 例：「自分たちのプラットフォームが◯人の生活を支えている」を社長室のモニターに投影。

Slide 50

Slide 50 text

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたる データ活用によって恩恵を得られる領域 50 組織経営 B/S P/L 3C 4P 製品 価格 流通 集客 顧客 事業投資 社会貢献 ビジョン 政策・学術 アセット管理 リスト抽出 結果指標 活動領域 オペレーション テーマ

Slide 51

Slide 51 text

データに基づく政策立案や社会活動 ● EBPM：エビデンス・ベースト・ポリシー・メイキング＝証拠に基づく政策立案。 ● 生物や森林などの環境資源を計測し、データにもとづいて政策提言や環境保護活動を行う。 ● 例：ジンベイザメに識別タグを付けて、リアルタイムで追跡。 Whale Shark Tracker - Conservation International　https://www.conservation.org/projects/whale-shark-tracker 51

Slide 52

Slide 52 text

研究論文・学術調査 ● 民間企業のリアルなデータを用いて、社会課題に関する学術調査を行い、研究論文として発表。 ● 例：クレジットカードの決済データから、COVID-19による飲食店への購買行動の変化を調査し、 「どのような属性の消費者」「どのような属性の店舗」の組み合わせで「自粛効果」が生じたのか （あるいは生じなかったのか）を特定する。 52 https://kazaneya.com/news | https://note.com/kazaneya

Slide 53

Slide 53 text

教育・授業 ● 民間企業のリアルなデータを用いて、学生向けにデータ分析の授業を実施。 ● データ分析の結果をレポートにまとめて、企業の執行役員にプレゼンテーションを行い、 マーケティング活動を推進する立場から実践的なフィードバックを受け取り、学びを深める。 ● データリテラシーを身につけ、社会に出てからリーダーシップを発揮するための土壌を養う。 53 株式会社風音屋（監訳）『アジャイルデータモデリング』より「国立大学法人 東京大学」の事例

Slide 54

Slide 54 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 54

Slide 55

Slide 55 text

3. データエンジニアリングの位置付け

Slide 56

Slide 56 text

データ活用の流れ（カフェのビジネス） ◯◯さん カフェラテを注文 (消費) リラックス (効用) 統合 注文履歴 会員登録 データ基盤 ・購買データ ・顧客データ 生成 新商品の開発 リピーター割引券 活用 価値 ☕ 56 サービス提供に伴い、データが生成される。 そのデータを統合し、活用することで、さらなるサービス提供を実現できるようになる。 データにまつわる（青い背景の）箇所がデータエンジニアリングの対象領域。

Slide 57

Slide 57 text

データ活用の流れ（一般化） 製品・商品 プロダクト 顧客・消費者 ユーザー 統合 業務データ、行動ログ データ基盤 生成 開発、施策、業務 活用 価値 57 サービス提供に伴い、データが生成される。 そのデータを統合し、活用することで、さらなるサービス提供を実現できるようになる。 データにまつわる（青い背景の）箇所がデータエンジニアリングの対象領域。

Slide 58

Slide 58 text

構造化データ ● 行（横）と列（縦）のテーブル（表）で表現できるデータ。 ● 従来のデータベースが前提としている形式であり、最も安定してデータを管理・利用できる。 非構造化データ ● 表形式で表せないデータ。画像、動画、音声、PDFなど。 ● AI技術の発展に伴い、非構造化データを扱うツールが急進化しているが、どれもまだ発展途上。 ● プログラムでのテキスト処理が簡単なJSONやXMLを「半構造化データ」と区別することもある。 構造化データと非構造化データ 58 id 決済日付 決済利用者 加盟店 金額 100 2022-03-01 Aさん いろは商店 900円 101 2022-03-02 Bさん いろは商店 700円 102 2022-03-03 Cさん にほへ屋 1,100円 103 2022-03-04 Dさん にほへ屋 800円 レコード (行) カラム (列)

Slide 59

Slide 59 text

複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋ぐ装置。 データ基盤とは何か（概要） 59 データ活用基盤

Slide 60

Slide 60 text

複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋ぐ装置。 データ基盤とは何か（詳細） 60

Slide 61

Slide 61 text

なぜデータ基盤が必要か（BI） 人間の意思決定を加速し、PDCAサイクルを回すため。 61 顧客価値 担当業務（オペレーション）の目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：販売目標を達成できているか？ 採用目標を達成できているか？ クレーム件数は減らせているか？ 業務横断（オペレーション）での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：キャンペーンや商談は継続利用に繋がっているか？ 押し売りで後工程のトラブルを招いていないか？ 事業（ビジネス）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：会員や商材のストックは増えているか？ 顧客ニーズのトレンドは変わっていないか？ 資源（リソース）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：対象領域の（予算｜人員）を（増や｜減ら）して（組織変更｜新規事業化｜買収｜売却｜撤退）するか？ ソフトウェア 開発 デザイン 販促 マーケ カスタマー サポート 法務 経理・財務 広報 セールス 在庫管理 配送 店舗接客 セキュリティ 人事・労務 製造管理 事業開発 IR 商談 販売促進 受注・契約 初回利用 継続利用

Slide 62

Slide 62 text

なぜデータ基盤が必要か（AI） 機械の自動判断を加速し、業務の効率化および顧客体験の変革を進めるため。 62 Before After 注文書作成 オペレーション ビジネス 在庫発注 タスク 店頭スタッフ販売 Geminiが自動作成 Agentspaceで 自動発注 無人店舗 （AIスタッフ販売） 人間の 脳内 社内外の データ

Slide 63

Slide 63 text

どういった手順で作るか ● 「データソース」と「ユースケース」の絵を描き、両者を繋げるための流れを描く。 ● Return（どのような恩恵を得られるか）とInvestment（どのような開発を行うか）を明確にして ステークホルダーに提示し、ROIの高い順番でシステム開発やダッシュボード構築を進める。 ● キーワードや製品ありきで「XXXを導入しましょう！」から始めるのはアンチパターン。 63 例：ヘラルボニーにおけるデータ基盤の初期構築。設計・実装は風音屋が担当。

Slide 64

Slide 64 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 64

Slide 65

Slide 65 text

4. データテクノロジー（主な技術要素）

Slide 66

Slide 66 text

● データ基盤を支える代表的なテクノロジーと構成例は以下のようになる。 ● Google Cloudでデータ基盤を構築する場合は、主にBigQuery（＝DWH：データウェアハウス）が 中心的な役割を果たすことになる。 主な技術要素（概要版） 66 元データA 元データB DWH 蓄積・集計 BI 分析・可視化 ワークフローエンジン 処理の流れを管理 ETL 収集・連携 データカタログ 仕様の入力・検索

Slide 67

Slide 67 text

主な技術要素（詳細版） 67 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 68

Slide 68 text

主な技術要素（詳細版） 68 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 69

Slide 69 text

BI（Business Intelligence）ツール ● グラフ可視化やダッシュボード構築に特化したツール。「分析ツール」として分かりやすい。 ● Googleアカウントがあれば Looker Studio をWEBブラウザで利用できる。基本料金は無料。 ● 日本で有名な利用事例としては、クリスプ・サラダワークスさんがLooker StudioでKPIを全公開。 ● https://lookerstudio.google.com/gallery ● https://metrics.crisp.co.jp/ 69

Slide 70

Slide 70 text

主な技術要素（詳細版） 70 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 71

Slide 71 text

DWH（データウェアハウス）製品 ● 大規模データの保存や集計に適したデータベース。データエンジニアリングの中核となる存在。 ● Googleアカウントがあれば、BigQueryがWEBブラウザで利用できる。月1TBまでの集計が無料。 ● SQLと呼ばれるデータベース言語を使ってデータの抽出・集計を行う。 ○ 例えば「SELECT name FROM customers WHERE prefecture = “東京都”」だと 「氏名を取得せよ」「顧客テーブルから」「東京都で絞り込んで」という指示になる。 71 SQLを書く データを見る 実行する

Slide 72

Slide 72 text

主な技術要素（詳細版） 72 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 73

Slide 73 text

クラウドストレージ ● 安全・安価なファイルの置き場。 ● Google Cloudを使う場合は、GCS（Google Cloud Storage）が該当する。 ○ Googleドライブが人間用のファイル置き場なら、GCSはシステム処理用のファイル置き場。 ● データエンジニアリングの分野だと以下の用途で使われることが多い。 ○ ①バックアップの置き場。DWHの更新ミスがあったときに備えて、ストレージにバックアッ プを保存し、データを復旧できるようにしておくことが望ましい。 ○ ②データの中継地点。DWHは事前に定義した仕様（列名や型）と異なるデータを追加すると エラーになる。ストレージにデータがあれば、外部システムからデータを再連携せずに済む。 73 風音屋のMENTA講座の資料より

Slide 74

Slide 74 text

主な技術要素（詳細版） 74 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 75

Slide 75 text

プログラム実行環境 ● Pythonなどのプログラムで「外部からのデータ取得」や「外部へのデータ連携」を実現するには、 プログラムを実行するためのインフラ環境（＝サーバ）が必要になる。 ○ 個人がPC端末（＝ローカルサーバ）でGoogle Chrome（＝プログラム）を起動したり、 スマートフォン（＝ローカルサーバ）でYouTubeアプリ（＝プログラム）を動かすのと同じ。 ● Google Cloudを使う場合、Cloud Run functionsというソリューションが、特に軽量かつ安価で、 使い勝手が良いのでオススメ。 ○ PythonのソースコードをGCSに置き、Cloud Schedulerで定期スケジュールを設定すると、 Cloud Run functionsで処理を実行できる。 風音屋のMENTA講座の資料より 75

Slide 76

Slide 76 text

補足：ETL（Extract / Transform / Load）ツール データの抽出・変換・格納を行うツール ● 例：設定ファイルとプラグインで様々なデータベース間のデータ転送を実現できるEmbulk ● 転送元（Source）から転送先（Target）へのマッピングを定義してフォーマットの差異を吸収する in: type: mysql host: HOST_NAME user: USER_NAME password: PASSWORD database: DATABASE_NAME table: purchase select: id, user_id, title, contents, created_at, updated_at out: type: bigquery auth_method: json_key json_keyfile: *****.json path_prefix: /tmp file_ext: .csv.gz source_format: CSV project: BQ_PROJECT dataset: postapp__datalake__mysql auto_create_table: true schema_file: article.json formatter: {type: csv, charset: UTF-8, delimiter: ',', header_line: false} Out (target) In (source) 76

Slide 77

Slide 77 text

用語解説：ETL、ELT、ReverseETL ①狭義のETL（処理／ツール）：外部からDWH製品へデータを連携・統合。 　外部からデータをE（抽出）→DWH製品が読み取れる形式にT（変換）→DWH製品にL（格納）する。 ②ELT（処理／ツール）：DWH製品の中でデータを加工。 　DWHにL（格納）されたデータをT（変換）するので①のE→T→Lと対比する意図でE→L→Tと呼ぶ。 ③ReverseETL（処理／ツール）：DWH製品から他システムへデータを連携・転送。 　他システムからデータを取り込む①の逆（Reverse）なのでReverseETLと呼ぶ。 ④広義のETL（処理／ツール）：上記3つを含んだ一般的なデータの加工・転送の総称。 　元は④想定で数々のETLツールが誕生したが、多くのPJで①に関心が偏り、①の機能強化が優先された。 　その後、②や③のニーズが顕在化したことで、専用ツールが登場し、①に対して②③を名乗る。 データソース DWH製品 社内システムや 外部ツール 元データのコピー 加工済みデータ Reverse ETL処理 Reverse ETLツール ELT処理 ELTツール 広義のETL処理 広義のETLツール 狭義のETL処理 狭義のETLツール ① ② ③ ④ 77

Slide 78

Slide 78 text

主な技術要素（詳細版） 78 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 79

Slide 79 text

SQL管理ワークフロー / ELTツール ● SQLでのデータ変換・集計処理について、依存関係をパイプライン管理するツール。 ● BigQueryを使う場合は、付随機能として Dataform というツールを無料で使うことができる。 ● 以下のような複数のSQLを段階的に実行できる。 1. POSレジのデータと通販DBのデータを統合する 2. 顧客一覧を作成する 3. 顧客ごとの年間売上を集計する 4. 年間売上を元に顧客ランクを付与する 5. メルマガ配信リストを作成する。 79 風音屋のMENTA講座の資料より

Slide 80

Slide 80 text

ワークフローエンジン ● 一連の処理の流れを管理するツール。 ● Google Cloudを使う場合は、Cloud Workflowsというソリューションが汎用的で使いやすい。 ● 複数のシステムを横断して、以下のような一連の処理を管理・実行できる。 1. Cloud Run functionsでPythonプログラムを実行してデータをBigQueryに反映する。 2. DataformでBigQueryのデータを加工・集計し、メルマガ配信リストを作成する。 3. Cloud Run functionsでPythonプログラムを実行してメルマガ配信ツールにリストを送る。 風音屋のMENTA講座の資料より 80

Slide 81

Slide 81 text

主な技術要素（詳細版） 81 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 82

Slide 82 text

データカタログ ● 社内データを検索したり、データの特徴や注意点を調べることができるツール。 ○ 例えば、「user」で検索するとユーザーに関連する社内データを見つけられる。 ○ データの最終更新日や他にどのような項目が含まれているかといった情報も確認できる。 ● Google Cloudを使う場合は、Dataplex Universal Catalog というソリューションが該当する。 ● 「個人情報を含む」といったタグ付け（PIIタギング）を行い、特定の部署以外がアクセスすると、 該当データの中身をマスキングするといった設定も可能（現時点では旧Catalogのみ対応）。 82 風音屋のMENTA講座の資料より

Slide 83

Slide 83 text

主な技術要素（詳細版） 83 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 84

Slide 84 text

● 「誰が」「どのデータに」（どのシステムに）アクセスできるのか、を管理するための機能。 ● Google Cloudだと、Cloud IAM（Identity and Access Management）が該当する。 ● Google Driveのフォルダ権限管理と同じで、Google Groups（メーリングリスト機能）のグループに 対して、データ参照の権限を付与することができる。 ○ 入退社や部署異動の手続きでGoogle Groupsを使っている場合は、同じ要領で管理できる。 IAM（アクセス管理） 84 Aさん@kazaneya.com Bさん@kazaneya.com Cさん@kazaneya.com D部署@kazaneya.com E案件@kazaneya.com F職種@kazaneya.com E案件の受領データ D部署が管理するデータ 研修用のデータ データ利用者 Google Groups BigQueryのデータ IAM 編集権限 閲覧権限 編集権限

Slide 85

Slide 85 text

監査ログ ● データへのアクセス記録を残し、後から監査を行うことができるログ。 ● Google Cloudだと、主に Cloud Logging というログ出力ソリューションを用いる。 ○ クラウドサービスの標準機能であり、利用者が他の候補を検討するといった類のものではない。 ● あらゆるログが出力されるので、調査のノイズを減らしたり、保存コストを節約するために、 「特定データへのアクセス」といった条件で絞り込んで、保存ストレージを指定することもできる。 85

Slide 86

Slide 86 text

主な技術要素（詳細版） 86 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 87

Slide 87 text

なぜ他のツールではなく、ストレージやデータウェアハウスを中心にするのか 「個別ツールのコンソール画面やCSVダウンロード」だとダメ？ ● 複数ツールを横断してデータを利用する場合は、どこかしら別の管理場所が必要になる。 ● ツールごとにCSVダウンロードして、Excelでデータを統合＆集計することになる。 ○ 人材不足の時代に、労力を投下して単純作業を繰り返すことは好ましくない。 ○ 作業ミスが混入すると、集計した値が誤ってしまうといった品質面の課題が生じる。 ○ 担当者のローカルPC端末でデータを処理する場合、セキュリティやガバナンス観点でリスク。 ● メルマガ配信リストを手動作成してMAツールに手動アップロードするような場合、上記の一連の デメリットが重なり、メールの誤配信といった顧客トラブルにも繋がる。 「Excel / Google Sheets」だとダメ？ ● 扱えるレコード件数に上限がある。 ● 操作内容やデータ形式によっては、システムによる自動化と相性が悪い。 「MAツール / CRMツール」だとダメ？ ● 顧客単価を上げるために「機能豊富で高価」路線の製品が多く、用途によってはToo Muchとなる。 ● 離脱防止のためにバックアップやエクスポートの制限が多く、ロックインのリスクが高い。 87

Slide 88

Slide 88 text

データ基盤にGoogle Cloudを使う理由（1/3） - 少額で始められる サーバの運用保守が不要なシステム構成 ● 例：BigQuery（蓄積）+ Dataform（集計）＋ Looker Studio か Google Sheets（可視化） ● スタートアップや初期構築フェーズならデータ基盤はこれだけで十分。 ● コストや人員を抑えることができる。毎月のインフラ費用が数百円で済むケースもある。 スモールデータだと破壊的な安さ ● BigQueryは毎月1TBまで無料。Dataform、LookerStudioは無料。 ○ LookerStudioの有料機能（Pro）は代表者1名ｘ1,000円/月だけで恩恵を受けられる。 ● 類似のクラウドサービスを契約すると最低でも数万円/月は必要になる。 ● 類似のOSSをサーバで管理すると、メンテナンス対象が増えて人員が必要になる。 88

Slide 89

Slide 89 text

データ基盤にGoogle Cloudを使う理由（2/3） - 連携先が多い Googleのマーケティング製品とのデータ連携 ● 広告媒体（Google広告）、動画サイト（YouTube）、Androidアプリのストア（Google Play） 、 WEBサイト運営（Google Analytics 4）、モバイルアプリ運営（Firebase）、SEO（Googleサーチ コンソール）、検索ボリューム（Googleトレンド）等のデータに対応。 ● これらのデータをエクスポートする先は原則的にBigQueryのみ。他のデータウェアハウスを使うと BigQueryとの二重管理になってしまう。 Googleの業務支援製品とのデータ連携 ● Google Sheets（Googleスプレッドシート）で管理しているリストをBigQueryに取り込んだり、 Google Sheets で BigQueryのデータを抽出・集計・可視化できる。 ● GeminiチャットやNotebookLMによる分析レポートの生成、Agentspaceによる業務自動化など、 今後のAI系サービスへの連携強化も期待できる。 ○ Google社はAIサービス提供の土台が充実している。開発者・研究者（世界のトップ人材）、 計算資源（世界中にGoogle Cloudのデータセンター）、社外データ（Google検索に世界中の WEBコンテンツ、YouTubeに世界中の動画、Google Photoに世界中の画像、Google Mapに 世界中の地図）、社内データ（Google Cloudに基幹データ、GA4やFirebaseにWEBデータ、 Google Workspaceに文書データ）など。「とりあえずGoogleで良いか」に説得力がある。 89

Slide 90

Slide 90 text

データ基盤にGoogle Cloudを使う理由（3/3） - ビジネスユーザーが使いやすい ビジネスユーザーが手軽に試せる ● 無料Gmailのユーザーを含めて、Googleアカウントさえあれば、数クリックで利用開始できる。 ● 他のクラウドサービスでデータ基盤を作ろうとすると、早くても1-2週間（普通は1ヶ月以上）、 安くても数万円/月は必要になってしまう。どうしても「会社が本格導入するもの」になってしまう。 ビジネスユーザー向けの学習教材が豊富である ● 例1：中小企業の経営者がLooker Studioを使うための書籍 　⇒『データを使って利益を最大化する 超効率経営』 ● 例2：WebマーケターがBigQueryを使うための書籍 　⇒『BigQueryではじめるSQLデータ分析 GA4 & Search Console & Googleフォーム対応』 データ専門職以外にも普及している ● 特にBigQueryやLookerStudioは「よくわからないけど◯◯さんの真似をして使っている」状態。 ● 例：WEBサイト運営者（Google Analytics 4）、動画配信者（YouTube）、SEOライター（Google サーチコンソール）、個人アプリ開発者（Firebase）、WEBマーケター（Google Ads） ● 「会社による契約やシステム導入」が必要な類似サービスとは利用者数の桁が違う。当社調べ。 ● エコシステムを含めて「よくわからないけど使える」「初心者に選ばれる」土台が整っている。 90

Slide 91

Slide 91 text

本資料における設計ポリシー ● 個人がカジュアルに試せる規模のスモールスタートに対応できる内容とする。 数万円〜/月のコストがかかる Cloud DataflowやCloud Composer、 数十万円〜/月のコストがかかるLookerには言及しない。 ● Snowflakeやdbt Cloudなどの他クラウドサービスを追加契約するとリードタイムがかかる上、 ガバナンス対応が複雑化するため、なるべくGoogle Cloudで完結することを想定する。 ○ データ収集用のETL SaaSについても、従来は自前でメンテナンスするよりもROIが高かったが、 この1年でAIエージェントやAIコーディングに任せられるようになったので対象外とする。 ● dbt Core / dbt FusionやLightdashなどのOSSをGCEやCloud Runで動かすと、 メンテナンス対象が増えるため、なるべくマネージドサービスを使うことを想定する。 91

Slide 92

Slide 92 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 92

Slide 93

Slide 93 text

5. データ収集

Slide 94

Slide 94 text

主な技術要素（詳細版） 94 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 95

Slide 95 text

データ収集のざっくり実装方針 1. BigQueryに直接保存できるデータはなるべくその通りにする。*1 2. そうでないデータはGCSを経由して保存する。 3. Pythonのプログラムを書かないといけないときは、Cloud Run functionsでPythonを動かす。 95 *1：一部例外あり。後述。

Slide 96

Slide 96 text

社内管理シートからのデータ取得 ● 担当者がGoogle Sheetsを直接編集するか、またはGoogleDriveにExcelファイルをアップロード。 ● BigQueryの外部テーブル機能でそれらのファイルを読み込むことで、データを取得する。 96 インターネット ユーザー Google Workspace Google Sheets データ基盤システム （Google Cloud） BigQuery 外部 テーブル HTTPリクエスト シートに入力 ユーザー HTTPリクエスト ファイルをアップロード Excelファイル Google Drive ファイルサーバや ストレージ等 Excelファイル 取得 外部 テーブル

Slide 97

Slide 97 text

Python等のプログラムを実行して、SaaS（例：Kintone、Shopify、Moneyforward、Salesforce）、 広告媒体（例：Meta広告）、メールやLINEの配信ツール（例：Klaviyo、CRM Plus on LINE）、 アプリデータ（例：Apple Store）、自社Webサービス等が提供するWeb APIからデータを取得する。 データ基盤システム（Google Cloud） コンソール利用時 Web API によるデータ取得 97 SaaS等のWebシステム データベース Web画面 （ユーザー用） Web API （システム連携用） 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS BigQuery Webブラウザ インターネット 人間 HTTP リクエスト 外部 テーブル 保存 HTTP リクエスト PC端末 表示 提供 アクセス 💡SalesforceやServiceNowなど、一部のSaaSは BigQuery Data Transfer Serviceのプレビュー版が 登場したので、ゆくゆくは置き換えられるかも？

Slide 98

Slide 98 text

Web APIをユーザーに対して提供していないSaaS等のWebサービスからデータを取得する場合、 ● コンソール画面からダウンロードしたCSVファイルをGoogleDrive経由でBigQueryに連携する。 ● またはPython等のプログラムを実行してスクレイピングを行う。 データ基盤システム（Google Cloud） コンソール画面からのデータ取得 98 インターネット Google Workspace BigQuery ユーザー HTTP リクエスト ファイルを アップロード CSVファイル Google Drive 外部 テーブル SaaS等のWebサービス コンソール画面 HTTPリクエスト ファイルをダウンロード 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS 保存 スクレイピング SaaS等の Webサービス コンソール画面 外部 テーブル HTTPリクエスト 💡Webサービスの画面レイアウト変更時は、 エラーログとHTML文字列をもとに GitHub Issueを自動起票してコーディングAIに パース処理を修正してもらおう！

Slide 99

Slide 99 text

BigQueryのfederated queryで定期的にDBからデータを取得するか、 またはDatastreamでDBの更新ログを取得してGCS経由でBigQueryに連携する。 データ基盤システム（Google Cloud） 業務DBからのデータ取得（Google Cloud内のDB） 99 Datastream ファイル GCS BigQuery Webシステム（Google Cloud） データベース 例：Cloud SQL 更新ログ WEBアプリ ケーション ユーザー データ 更新 保存 外部 テーブル フェデレーションクエリ （その時点の最新データを取得） 取得 💡ユーザー影響を防ぐために DBのレプリカ（コピー）を 経由することもあるよ！ Cloud Run等 インターネットや VPN等 HTTP リクエスト

Slide 100

Slide 100 text

クラウドサービス（例：AWS）のエクスポート機能でストレージ（例：S3）を経由してデータを渡すか、 またはDatastreamでDBの更新ログを取得してGCS経由でBigQueryに連携する。 なお、DatastreamからBigQueryに直接出力すると履歴が消えるので、強いリアルタイム要望がなければ （＝10分間隔のマイクロバッチで要件を満たせるなら）GCSを経由することが望ましい。 データ基盤システム（Google Cloud） 業務DBからのデータ取得（Google Cloud以外のDB） 100 Data stream ファイル GCS BigQuery Webシステム（例：AWS） データベース 例：Amazon RDS 更新ログ WEBアプリ ケーション データ 更新 保存 外部 テーブル 取得 ⚠セキュリティ要件によっては アクセスNGの場合もあるよ！ 💡差分エクスポートなどで ファイルの数や容量を減らそう！ ストレージ 例：Amazon S3 エクスポート Storage Transfer Service 取得 ファイル GCS 外部 テーブル 保存 AWS Fargate等 ユーザー インターネットや VPN等 HTTP リクエスト プライベート接続、 VPCピアリング、VPN等 💡MySQLやPostgreSQL、Oracle等、 一部のRDBMSは、BigQuery Data Transfer Serviceのプレビュー版が 登場したので、N/Wアクセスが 許可されるのであれば、 ゆくゆくは置き換えられるかも？

Slide 101

Slide 101 text

アクセスログやアプリケーションログと呼ばれるWebシステムのログは、 ● Google Cloud内ならCloud LoggingからGCS経由でBigQueryに連携する。 ● Google Cloud外（例：AWS）ならエクスポート機能でストレージ（例：S3）を経由して受け渡す。 データ基盤システム（Google Cloud） サーバログからのデータ取得 101 ファイル GCS BigQuery Webシステム（Google Cloud） Cloud Logging WEBアプリ ケーション ユーザー HTTP リクエスト ログ 出力 保存 外部 テーブル ファイル GCS Webシステム（例：AWS） ログサービス 例：Cloud Watch Logs WEBアプリ ケーション ユーザー HTTP リクエスト ログ 出力 ファイル GCS エクスポート Cloud Run等 AWS Fargate等 💡ECS + Fargateの構成なら FireLens→S3に直接連携も！ 💡ファイルの数や容量が多い場合は Lambda等で事前に加工・削減！ Storage Transfer Service 取得 外部 テーブル エクスポート インターネットや VPN等 プライベート接続、 VPCピアリング、VPN等

Slide 102

Slide 102 text

Google Analytics 4（FirebaseやGoogle Tag Managerを含む）は、標準機能でBigQueryに連携が可能。 ● データが1日100万件以上だと、有償プランに切り替えるか、一部項目の取得を妥協する必要がある。 ● コンソールの集計方法は非公開であり、データ反映ラグやバグ混入もあるため、BigQueryの集計とは 数値が一致しないケースがある。 データ基盤システム （Google Cloud） アクセス解析ツールからのデータ取得 102 BigQuery Webシステム WEBアプリ ケーション Cloud Run等 インターネット HTTP リクエスト ユーザー WEB画面 PCやスマホ ログ出力 Google Analytics 4 GA4内の データベース コンソール 画面 表示 エクスポート コンソール利用時 人間 WEBブラウザで HTTPリクエスト インターネット

Slide 103

Slide 103 text

Google検索サービスからのデータ取得 103 ● Googleサーチコンソール（自社サイトの検索パフォーマンス）はエクスポート機能で連携。 ● Googleトレンド（キーワードの検索ボリューム）はBigQuery Sharing機能でデータを取得。 Google検索 クローラー 検索 ログ データ ベース インデックスを 保存 検索機能 検索 ユーザー HTTP リクエスト インターネット Googleサーチコンソール Googleトレンド Googleサーチ コンソールの データベース Google トレンドの データベース WEB画面 WEB画面 コンソール利用時 人間 WEBブラウザで HTTPリクエスト インターネット コンソール利用時 人間 WEBブラウザで HTTPリクエスト インターネット データ基盤システム （Google Cloud） BigQuery 表示 表示 エクスポート エクスポート ログ出力

Slide 104

Slide 104 text

Google運営サービス（検索以外）からのデータ取得 104 広告媒体（Google広告）、動画サイト（Youtube）、Androidアプリのストア（Google Play） など、 Googleが運営する各プラットフォームのデータは、BigQuery Data Transfer Serviceで取得が可能。 Google広告 Google広告の データベース WEB画面 コンソール利用時 人間 WEBブラウザで HTTPリクエスト 表示 Youtube Youtubeの データベース WEB画面 表示 コンソール利用時 人間 Google Play Google Playの データベース WEB画面 表示 コンソール利用時 人間 インターネット WEBブラウザで HTTPリクエスト インターネット WEBブラウザで HTTPリクエスト インターネット データ基盤システム （Google Cloud） Data Transfer Service 取得 Data Transfer Service Data Transfer Service BigQuery 取得 取得 保存 保存 保存

Slide 105

Slide 105 text

● 政府統計や各社オープンデータはBigQuery Sharing機能で提供事業者からデータ取得が可能。 ● WEBコンテンツは、Python等のプログラム + Geminiでスクレイピングを行い、BigQueryに連携。 データ基盤システム （Google Cloud） 各提供者 各省庁等 オープンデータによるデータ取得 105 WEB公開 コンテンツ 提供事業者A 政府統計 収集・加工 システム BigQuery 提供事業者B 各社 データベース BigQuery BigQuery BigQuery Sharing BigQuery Sharing インターネット 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS 保存 外部 テーブル HTTPリクエスト スクレイピング （Google検索） Gemini 取得 更新 更新 連携 HTTPリクエスト スクレイピング （ページ指定） 💡Webサービスの画面レイアウト変更時は、 エラーログとHTML文字列をもとに GitHub Issueを自動起票してコーディングAIに パース処理を修正してもらおう！

Slide 106

Slide 106 text

● 各ツールから文章、画像、動画、PDFファイルなどの非構造化データを集約する。 ● システムが管理する場合はGCSに置き、必要に応じてBigQueryにデータをロードする。 ● 人間が管理する場合はGoogle Driveに置き、必要に応じてGCSを経由してBigQueryにロードする。 ● BigQueryのObject Table機能でGCSの非構造化データを参照し、バイナリ形式で機械学習に利用。 データ基盤システム（Google Cloud） 社内フォルダ等のデータ取得（ストレージに集約する場合） 106 インターネット Google Workspace BigQuery ユーザー HTTP リクエスト ファイルを アップロード 各ファイル Google Drive 取得プログラム 例：Python Cloud Run functions 各ファイル GCS 保存 WebAPIコールやスクレイピング 各ツール 外部 テーブル HTTPリクエスト Web API コール HTTP リクエスト

Slide 107

Slide 107 text

● 各ツールから文章、画像、動画、PDFファイルなどの非構造化データを連携する。 ● Agentspaceに直接データを連携し、BigQueryに集約した構造化データと組み合わせる。 ● データ分析のレポートやSQLを自動生成したり、カレンダーやメールの作成が可能。 ● 例：キャンペーン企画や契約書を連携 ⇒ 売上の変動要因を解釈 ⇒ 重点顧客にアポ依頼のメール。 社内フォルダ等のデータ取得（Agentspaceで直接利用する場合） 107 Microsoft Teams Microsoft Outlook Microsoft OneDrive SharePoint Slack Box Gmail Google Drive Confluence JIRA GitHub Salesforce Google Group Google Calendar 文章 | 画像 | 動画 | PDF 非構造化データ HubSpot Zendesk Service Now Workday etc… Trello BigQuery 構造化 データ データ基盤システム （Google Cloud） Agentspace Vertex AI Agent Engine Python + ADK Assistants Gemini Google Workspace Google Calendar Gmail 人間 連携 連携 利用 利用 スケジュール設定や メールの送信 分析レポートや SQLの作成 Web画面で チャット指示 ⚠Agentspace等のAI Agent系サービスは Early AccessやPreview段階のものが多い。 機能強化は今後に期待。 ⚠Claude Desktop等を使い、 各サービスをMCP経由で参照して 分析レポートを作る方法もあり。

Slide 108

Slide 108 text

データの仮想化について ● データ本体を持たずに「外部テーブル」や「federated query」で別のシステムにアクセスしつつ、 利用者にはデータがそこにあるかのように振る舞うことを「データの仮想化」と呼ぶ。 ● データの仮想化ありきで整えたシステム構成を「レイクハウスアーキテクチャ」と呼ぶ。 ネイティブテーブルへの変換 ● 上記機能だと、接続設定が容易な一方で、データアクセスの挙動が安定しないことがある。 ○ 例：Google Sheetsへのアクセスがエラーになる。再実行すると問題なくデータを取得できる。 ● 頻繁に参照されるデータは、BigQueryに実体をコピーする（ネイティブテーブルを作る）ことで、 エラーに煩わされずに済む。 ● Dataformで “SELECT * FROM 仮想化テーブル WHERE 対象日” を実行し、別テーブルに保存する。 他システム データ基盤システム （Google Cloud） BigQuery 補足：仮想化テーブルの一部はネイティブテーブルへと変換 108 仮想化テーブル ネイティブテーブル Dataform 取得 保存 元データ本体 都度参照 取得経路と解釈 rawデータと解釈

Slide 109

Slide 109 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 109

Slide 110

Slide 110 text

6. データ加工

Slide 111

Slide 111 text

主な技術要素（詳細版） 111 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 112

Slide 112 text

データ加工の概要 Excelシートで経理データを集計・活用するときには、以下のような工夫を行う。 ● データが更新されて、シートが上書きされてしまわないように、履歴（スナップショット）を残す ● Excel関数で処理できるようにフォーマットを調整（前処理）する ● 1つのセルに含まれるExcel関数が膨大・複雑になったら、途中集計のセルを分ける ● 汎用的な会員リストを作ってから、複数のシートでそのリストを参照し、フィルタリングを行う このような「データの加工」の流れを設計して、SQLで実現していく。 112

Slide 113

Slide 113 text

風音屋式の簡易DFD（データフロー図）でデータ加工処理を設計する 113 最終的な活用イメージ（モックアップ）と テーブルが紐づくところまで確認する 加工前のデータが 出口まで繋がることを確認する 結合条件や加工結果を明記する →1つ1つがSQLのCTEやDataformのファイルになる 最終形となるテーブルの具体例を書き、 ステークホルダーと擦り合わせる 参考：BEAM✲テーブル テスト観点を明記する → Dataformのテストコードに反映する 1.『Software Design 2025年7月号』 特集「データ分析のためのSQL講座」 2. データ分析で用いるSQLクエリの設計方法 - 風音屋TechBlog 　 https://techblog.kazaneya.com/20241208-design-of-analytical-sql-queries/ インプット アウトプット プロセス（途中処理）

Slide 114

Slide 114 text

BigQuery CanvasでSQLを書き、簡易DFDを再現する クエリの実行結果をプレビュー表示して、その結果に対して次のクエリを実行することが可能。 簡易DFDの設計をベースにしてSQLを実装＆テストしていく。 114 風音屋のMENTA講座の資料より

Slide 115

Slide 115 text

作成したSQLをDataformに移植する Dataformのデータ集計機能 ● 集計処理の定期実行、エラー時のリトライ ● バリデーション（NotNullやUnique）や自動テスト ● データの依存関係の管理 115 Git/GitHubでのコード管理 ● Gitでのバージョン管理 ● GitHubでのCI管理（Linterなど） ● AIエージェントによる開発の半自動化 風音屋のMENTA講座の資料より

Slide 116

Slide 116 text

データの取得（左）から活用（右）に向かって層（レイヤー）ごとに役割＆名前を分ける。 ● 元データのコピー（ローデータ）を格納する「raw__xxx」テーブル ● 顧客属性や商品カテゴリといった分析の切り口は「dim__xxx」テーブル ● 商品購入の金額・数量といった集計対象は「fact__xxx」テーブル ● dimとfactを結合して、簡単にデータを使えるようにした「wide_xxx」テーブル 責務に応じてレイヤーを分け、命名規則で管理する 116 株式会社風音屋（監訳）『アジャイルデータモデリング』より

Slide 117

Slide 117 text

構造化データにおけるレイヤリングの過去議論 117 “ゆずたそ”の3層構造（概要） Bill Inmon “CIF” 画像は『データマネジメント知識体系ガイド』より Kimball “DW Chess Pieces” 画像は『データマネジメント知識体系ガイド』より 青木峰郎 “SQL中心アーキテクチャ” 画像は『10年戦えるデータ分析システム』より Databricks “Medallion Architecture” https://www.databricks.com/jp/glossary/medallion-architecture dbt labs “dbt best practice” https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview

Slide 118

Slide 118 text

風音屋のデータモデリング標準 / “ゆずたそ”の3層構造（詳細） データの「入口」「中間」「出口」で、重視すべきステークホルダーや担うべき役割が異なるという思想。 世に出ている様々なテーブル設計のテクニックを、それぞれに適した箇所で使うように位置付けている。 118 raw 元データの コピー データ ソース ユース ケース 前処理 提供形式調整 用途別I/F ディメンショナルモデル 主にデータ保有者が データ品質を担保する （データレイク層） 主にデータ利用者が データ品質を担保する （データマート層） 主にデータ整備者が データ品質を担保する （データウェアハウス層） snapshot 変更履歴の 保持 adapter 標準化や クレンジング hub 名寄せ・統合 bridge fact/dimの 生成ロジック dim 分析の切り口 （5W1H） fact 集計対象 出来事＞指標 dim 分析の切り口 （5W1H） dim 分析の切り口 （5W1H） dim 分析の切り口 （5W1H） wide factとdimの 組み合わせ summary 粒度を集約 metric 主要・共通の 指標を管理 bi BIツールに データ提供 team 各チームに データ提供 sys 各システムに データ提供 z 各ユーザーに データ提供 raw 元データの コピー データ ソース raw 元データの コピー データ ソース raw 元データの コピー データ ソース ユース ケース ユース ケース ユース ケース

Slide 119

Slide 119 text

● データの分析や活用に特化したテーブル設計手法。 ● Fact（ファクト：集計対象）とDimension（ディメンション：分析軸）でテーブルを管理する。 ● データを整備すると、売上高◯◯円という事実（Fact）を3つの次元（Dimension）で分解できる。 補足：ディメンショナルモデリング 119 fact_order id user_id item_id item_count amount 1 100 10 1 300 2 101 20 3 2400 3 102 500 15 15000 dim_user id name age 101 ◯◯ 18 102 △△ 22 103 □□ 25 dim_item id name category 10 トマト 野菜 11 ナス 野菜 12 じゃがいも 野菜 株式会社風音屋（監訳）『アジャイルデータモデリング』より （網掛けは本資料での追記） この期間での売上 2億円 この製品での売上 5,000万円 この店舗での売上 800万円 売上累計 30億円

Slide 120

Slide 120 text

補足：イベントマトリクス ファクトとディメンションの組み合わせを表形式（イベントマトリクス）として書き出す。 データチームの定例ミーティングで表を更新したり、データ整備やデータ分析のTODOリストに反映する。 ● 縦軸：ファクトとなる「出来事」（ビジネスイベント） ● 横軸：ディメンションとなる「切り口」（5W1H） 120 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用

Slide 121

Slide 121 text

非構造化データ ⇔ 構造化データ の変換 生成AIによる「非構造化データ」から「構造化データ」への変換（以下は例） ● 商品名のテキスト → 商品カテゴリーの分類 → カテゴリー別の売上集計が可能になる ● 自動車が撮影した路面写真 → リスク要因のラベリング → 走行データと合わせて事故予測の精度向上 ● 代理店との会議メモやメール → キャンペーンの情報を抽出 → MMMに組み込んで広告効果推定の改善 生成AIによる「構造化データ」から「非構造化データ」への変換（以下は例） ● 法人顧客の行動データ → 営業担当向けに追加提案メールのドラフトを生成 ● 商品の在庫や注文のデータ → 今日推すべき商品で「こんな人が買ってます」訴求文面を生成 ● 企業の募集要項と求職者の履歴書 → 条件ミスマッチを緩和するための修正提案メッセージを作成 121 風音屋TechTalk #4 発表資料より

Slide 122

Slide 122 text

非構造化データ in データパイプライン パイプラインに組み込むかどうかで2つのアプローチが考えられる。 1. データパイプラインに組み込む場合。BigQuery ML GeminiでSQLからGeminiを実行する。 2. 従来のデータパイプラインには組み込まず、Agentspaceで各データを集約してAI側で完結させる。 122 非構造化データ データパイプライン 構造化データ 非構造化データ ①生成AIで前処理 ②生成AIで出力作成

Slide 123

Slide 123 text

非構造化データの3層構造 Garbage In, Garbage Out（ゴミを入れたらゴミが出てくる） ● 社内文書や動画ファイルはボリュームが多い割に、品質が低かったり、ノイズ情報も混ざる。 ● 生成AIが一度に記録・利用できるデータ量には上限がある。 ● ルンバ（お掃除ロボット）を動かすために、床の物を片付けるのと同じ。事前に整える。 構造化データと同じようにデータの整理が必要 ● 元のファイル（入口）→整理した情報（中間）→用途に必要な情報（出口）を整備する。 ● “ゆずたそ”の3層構造の「データレイク層」「データウェアハウス層」「データマート層」に該当。 この領域は生成AIの台頭に伴って急進化が始まったフェーズ ● 現時点でこれぞというリファレンスアーキテクチャが定まっていない。 ● データの持ち方も定まっていない。テキストを書き直したもの、文書ベクトル、グラフ構造 etc…？ ● 対応するソリューションも違う。BigQuery、Vertex AI Feature Store、Spanner Graph etc…？ ○ グラフDBの構築はToo MuchなのでGIS機能と似た位置付けのBigQuery Graphが欲しい。 123 ソース 水源 レイク 湖 = 蓄積する ウェアハウス 倉庫 = 管理する マート 市場 = 売る ユーザー 利用者

Slide 124

Slide 124 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 124

Slide 125

Slide 125 text

7. データ提供

Slide 126

Slide 126 text

主な技術要素（詳細版） 126 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 127

Slide 127 text

Google Sheets（Googleスプレッドシート）でのデータ抽出・集計 シートでの柔軟なデータ分析 ● N1分析：BigQueryからデータを抽出して、顧客や商品、取引など1件1件のデータを確認する。 ○ Connected Sheet機能でBigQueryのWideテーブルやSummaryテーブルに接続する。 ● ピボット集計：カテゴリ別ｘ月次の注文総額といった簡易的な集計ならピボットシートで完結。 ● アドホック分析：顧客や商品のセグメント分類、ファネルｘコホートで離脱ポイント特定など。 ● モニタリング：主要指標を計測シートにまとめて、日次＜週次＜月次で計測できるようにする。 ○ 取締役会や投資家向けGoogle Slidesにシートを貼り付けて1クリックでデータを更新。 利用者本人がシートを編集する世界観（セルフサーブ型） ● 素早く、柔軟に、欲しいデータが手に入る。 ○ 10分で30点のアウトプット。これで十分なケースも。 ○ 試行錯誤を通して「筋の良い計測」に辿り着く。 ● データ分析職に依頼するストレスから解放される。 ○ 「要件を決めてください」ばっか言ってくるし。プロの提案が欲しいのに。 ○ なんか期待したのと違うものができるし。ビジネス理解が浅すぎない？ ○ ぶっちゃけ依頼者が自分でやったほうが早いし。ダラダラやるの勘弁して。 127 https://cloud.google.com/bigquery/docs/connected-sheets

Slide 128

Slide 128 text

Looker Studio（旧Googleデータポータル、Google Data Studio）でのモニタリング ダッシュボードを直感的に作成 ● Google Sheetsの集計から「ダッシュボードで定点観測すべき指標」を特定し、反映する。 ● BigQueryのBI連携テーブルに接続して、LookerStudioでグラフごとにフィルタリングを行う。 ● ソースコード管理はできず、開発AIエージェントとの相性は悪いので注意。 128 https://codelabs.developers.google.com/codelabs/community-connectors#0 https://cloud.google.com/billing/docs/how-to/visualize-data

Slide 129

Slide 129 text

生成AIによるアドホック分析 ジュニア分析者より正確で、シニア分析者より早い＆安いアウトプット ● GeminiチャットやNotebookLMによるデータ分析レポートの作成。 ● Claude Desktop等のサードパーティツールからBigQueryを参照する事例も散見される。 MCP経由で加工済みテーブルにアクセス ● 本資料作成時点で主流なのはBigQueryのMCPを経由してデータを参照する方法。 ● 将来的にはGeminiやNotebookLM、Looker Studio Pro（対話エージェント機能）を社内提供する アプローチがGoogle Cloudユーザーの主流になりうる。まだ高水準とは言えないが今後に期待。 ● BigQueryでFact＆Dimension（またはそれらを結合したWide or Summary）テーブルに接続する。 129

Slide 130

Slide 130 text

チャットツールへの自動配信 毎朝の始業時間に、前日の経営状況をSlackで通知 ● 実現方法としては以下いずれかが簡単。 ○ Cloud Run functionsでPythonスクリプトを実行する。 ○ Google App Script（GAS）でGoogle Sheetsの内容を送信する。GASのソースコードは、 clasp / GitHubでソースコードを管理するとメンテナンスや挙動が安定する。 ● BigQuery側で計測対象となるデータを整備する。 ○ BigQuery側でビジネス指標を固定する（日次で締める）ためのmetricテーブルを用意する。 ○ BigQuery ML による異常検知（Anomaly Detection）にて、急激な数値の変動があれば、 レポート対象として含めるように設定する。 130 https://speakerdeck.com/yuzutas0/20211210?slide=27 https://cloud.google.com/blog/products/data-analytics/bigquery-ml-unsupervised-anomaly-detection

Slide 131

Slide 131 text

CRMツールや広告媒体などの外部連携 各ツールの機能を120%活かし、一度は夢見た「データ活用構想」を実現 ● SalesforceやKintoneへのデータ入力。営業やCS向けに法人情報や利用状況を受け渡す。 ● メルマガやLINE、プッシュ通知など、顧客へのパーソナライズ or セグメンテーション配信。 ● Google広告やInstagram広告などのリターゲティング配信。 外部システムへの連携処理をステップバイステップで構築 ● まずはExcelでのリスト作成を自動化。担当者がBigQueryコンソール画面からリストをCSV形式で ダウンロードした後、対象システムのコンソール画面に手動アップロード。 ● その後に連携作業を自動化。Cloud Run functionsでPythonスクリプトを実行し、対象システムの WebAPIへと受け渡す。Reverse ETLと呼ばれる仕組み。 連携先システムのアップロード項目に合わせたデータで作成 ● 各チームがBigQueryのteamテーブル（ビュー）でSQLを書いて試行錯誤。 ● 要件が固まったらsysテーブルに移管し、品質チェックの対象とする。 131 https://www.salesforce.com/jp/campaign/lightning/

Slide 132

Slide 132 text

Agentspace等のAIエージェントによる業務効率化・自動化 業務フローを整理して、作業・判断を「システムで完結する」「AIが担う」ように置き換えていく ● AIエージェントの設計プロセスについては後述。 ● システム構成はAgentspaceのデータ連携スライドを参照。他システムでも似た構成となる。 ● 本資料作成時だとAgentspace（7月31日に一般公開）はまだ理想とギャップがある。 ○ Google Workspaceとネイティブ連携できる強みから、将来的な進化に期待したい。 ○ 直近はDifyやn8nのほうが期待像に近い。あの方向性に進化してほしい。コード管理もほしい。 例：法人顧客の離反検知とフォローアップの（半）自動化 1. BigQueryで法人顧客の利用状況を収集 2. 日次集計で離反の可能性を検知（＝事前定義したセグメントに分類） 3. Googleカレンダーで営業担当者の空き日程を確認 4. Gメールで対象顧客に打ち合わせのアポイントメントを送信 5. Google Slidesで提案スライドの草案を作成 6. Google Docsで打ち合わせ台本の叩き台を生成 7. Salesforceにフォローアップ状況を入力・更新 132 https://cloud.google.com/blog/products/ai-machine-learning/bringing-ai-agents-to-enterprises-with-google-agentspace

Slide 133

Slide 133 text

NotebookやFeature Storeによるデータサイエンス BigQuery Notebook（Jupyter Notebook / Google Colab Enterprise相当）での統計解析 ● 四則演算ベースの集計はSQLで済ませ、ノートブックでは定量的な予測や解釈を行う。 ● 例：値上げの影響、購買促進のハブとなるコンテンツの特定、自然成長や季節変動や景気連動や需要 の先食いを除去したマーケティングキャンペーン効果の推定。 BigQuery内のデータで機械学習を行い、Vertex AI Feature Store 経由でプロダクトに組み込み ● プロダクト内における商品、コンテンツ、物件、人材のレコメンド機能など。 ● Notebookでアドホック分析した後、機械学習のモデルやパイプラインに組み込む。 ※必要に応じてBigQueryの（加工前）rawテーブルや（前処理済み）adapterテーブルを参照する。 133

Slide 134

Slide 134 text

BigQuery Sharingによるデータの外部提供 統計データを法人顧客、取引先、研究機関に提供 ● BtoBサービスのオプション商品として組み込むケースも散見される。 ● データ提供用の加工テーブルを用意し、BigQuery Sharing（旧：Analytics Hub）で受け渡す。 ● 例：@yuzutas0が東京大学で実施した授業。Pythonの使い方を学んだ後、NE株式会社が保有する 年1兆円以上の取引データ（日本のEC市場の1割弱に相当、統計加工済み）を用いて、マーケティング 課題の発見・解決提案をレポートにまとめ、授業最終日には執行役員に対して成果発表を行った。 134 株式会社風音屋（監訳）『アジャイルデータモデリング』より「国立大学法人 東京大学」の事例

Slide 135

Slide 135 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 135

Slide 136

Slide 136 text

8. メタデータ管理

Slide 137

Slide 137 text

主な技術要素（詳細版） 137 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 138

Slide 138 text

メタデータ ● データを説明するデータのことをメタデータと呼ぶ。 ● 図書館に対する図書目録のように、利用者が様々な着眼点からデータを見つけられるようにする。 ○ 例：「価格」（price）データの「100」が「100円」なのか「100ドル」なのか分からない。 ● 様々な分類がある。 ○ 「データソースに紐づく情報」「データ加工に紐づく情報」「データ利用に紐づく情報」など。 ○ 「システムが自動で付与する情報」「人間が工数を費やして付与する情報」など。 138 『実践的データ基盤への処方箋』より

Slide 139

Slide 139 text

データ活用で必要になるメタデータ（1/4） ● テーブルの用途や作成経緯。 ● カラム名、型、制約（ユニーク、NotNull）、値の範囲などのスキーマ情報。 ● 問い合わせ先。 ● 類似データとの使い分け。 ● 一緒に使うことが多いテーブル。 139

Slide 140

Slide 140 text

● よくある質問と回答例（FAQ）。 ● 既知のエラーケース。 ○ 例：◯◯日〜◯◯日はシステムトラブルでデータが0件になっている。 ● 機密情報に該当するか。 ● データの更新頻度やタイミング。 ● データの依存関係。 データ活用で必要になるメタデータ（2/4） 140

Slide 141

Slide 141 text

● 代表的なクエリ例。 ● 複雑なデータ仕様、状態遷移、ドメイン用語の解説。 データ活用で必要になるメタデータ（3/4） 141

Slide 142

Slide 142 text

データ活用で必要になるメタデータ（4/4） ● データ利用状況 ○ 誰が、いつ、どこで、どのデータを参照・利用するのか。 ○ 後述する監査ログを用いる。 ● データ生成過程（DGP：Data Generation Process） ○ データが生成されるときの業務フロー。 ○ 誰が、いつ、どこで、どのデータを記入・更新するのか。 ○ GoogleDriveや社内Wikiにあるマニュアルを転用する。 142

Slide 143

Slide 143 text

Google Cloudにおけるデータカタログ機能 ● Google Cloudのコンソール画面からデータカタログ機能を利用できる。 ○ Data Catalog → Dataplex Universal Catalog とリブランディング。 ● Googleアカウントでログインして、データを探したり、メタデータを入力できる。 ○ データセット（スキーマ）、テーブル、カラムそれぞれに説明文を記載できる。 ○ 個人情報などのタグをつけることもできる。 ● BigQueryの利用補助AIはデータカタログの情報を主に参照するため、充実させておくと良い。 ● 集計ロジックの図解やデータ横断のルールなどは扱えないため、社内Wikiの整備が別で必要となる。 143

Slide 144

Slide 144 text

「データの説明文」には「横断のルール」と「個別の説明」がある 144 ＜例＞ 横断のルール 固別の説明 データセット （スキーマ） productA_xxxは製品Aの teamB_xxxはチームBのデータを扱う 同じGA4のエクスポートデータでも、 ◯◯はサイトA、△△はサイトBを扱う テーブル raw_xxx、dim_xxx、fact_xxx、 wide_xxxの使い分け paymentsテーブルは◯◯で、 salesテーブルは△△を扱う カラム dwh_xxxはDWH側で加工したデータ、 _maskedはマスキング済みのデータ customer_name_maskedカラムは 顧客名（マスキング済み）を扱い、 退会した後はNullで上書きされる 横断ルールの 設定ファイル 個別説明の 設定ファイル 両者を統合した データ説明文 データカタログの 説明欄 統合 統合 反映 ● データセット、テーブル、カラムそれぞれに「横断のルール」と「個別の説明」がある。 ● この両方が揃って初めてデータ利用者やAIはデータを正確に使えるようになる。 ● データカタログでは「横断のルール」を分けて管理できないため、全てのデータの説明文の中に、 同じ「横断のルール」を書いておかなければならない。 ● 「横断のルール」と「個別の説明」は別の設定ファイルで管理しておき、メタデータ統合システムで 両者を統合してからデータカタログに連携する。

Slide 145

Slide 145 text

非構造化 データ 構造化 データ メタデータ管理の3層構造（1/2） メタデータも、収集（入口）→統合（中間）→提供（出口）の3層構造でパイプライン化される。 145 RDBMSのスキーマ情報 ＠DDL SFDCで入力する データ項目 ＠管理シート Dataformが加工する BigQueryテーブル仕様 ＠設定ファイル BigQuery コンソール画面の クエリ作成補助AI （Gemini） 各AIチャットへの データ分析依頼や 問い合わせ データ利用ガイド 社内ポータル Dataplex Universal Catalog 一連のデータ仕様と クエリ生成のコツを 組み込んだ 社内MCPサーバ 一連のデータ仕様を SphinxやJekyllなどの サイトジェネレーターに 反映 基幹システム 顧客管理システム （CRM） BigQuery 加工テーブル BigQuery 利用記録 Cloud Loggingが 出力する監査ログ ＠監査ログ 顧客対応システム Zendeskの入力手順 社内マニュアル ＠GoogleDocs 取得元 メタデータの入口 メタデータの出口 利用先 メタデータの中間 GitHubの 専用リポジトリ メタデータ管理プログラム

Slide 146

Slide 146 text

メタデータ管理の3層構造（2/2） 前提：システムで自動化できるものは自動化し、人間は人間にしか扱えない情報に専念する。 ● システムで自動生成されたメタデータはそうと分かるように自動生成のラベルをつける。 ● 人間がチェックしたら認証済みのラベルを、管理部門が承認したら「公式」ラベルをつける。 入口：データを生成する人が、データを生成する箇所で、メタデータを管理する。 ● 例：SFDCの設定は管理者がシートで管理。RDBMSのスキーマはSREチームがDDLで管理。 ● 理由1：データ基盤以外の通常業務でも使うため。何らかの形でメタデータは必要。 ● 理由2：データ利用者が事後調査すると1日かかる。担当者本人が事前記入すると10分で済む。 中間：それぞれのメタデータを集約管理する。 ● 現状、ここを満たせるツールが世にないため、各社がGitHub管理の仕組みを作っている。 出口：メタデータの利用箇所に合わせた場所・形式でメタデータを連携する。 ● 例：GeminiでBigQueryを使う場合はDataplex Universal Caralogにメタデータが必要。 146

Slide 147

Slide 147 text

Google Cloudにおけるメタデータ管理の補助機能 ● グロッサリー（辞書）：「売上」等のキーワードを設定し、関連データを紐づける。 ● データプロファイリング：nullの割合、一意となる値の割合、平均、標準偏差、最大、最小、四分位数 といった統計情報を確認する。 ● データリネージ（依存関係）：どのテーブルがどのテーブルから作成されているか、を管理する。 147 https://cloud.google.com/data-catalog/docs/concepts/about-data-lineage https://cloud.google.com/blog/products/data-analytics/dataplex-business-glossary-now-ga

Slide 148

Slide 148 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 148

Slide 149

Slide 149 text

9. データ品質

Slide 150

Slide 150 text

主な技術要素（詳細版） 150 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 151

Slide 151 text

風音屋が定義するデータ品質の5分類 数十種類の「データ品質」を大まかにまとめると以下の5種類になる。①〜⑤の順に依存関係がある。 例：①が不十分だと②〜⑤を正確に計測できない。②が不十分だと③で見るべきデータが存在しない。 151 ②データが適切な場所に置かれている （可用性・即時性・最新性・回復性・移植性） ③データの中身が現実を正確に表現している （正確性⊇完全性、一意性、一貫性、有効性、精度） ④適切な人が適切なデータにアクセスできる （アクセシビリティ・機密性） ⑤データが使いやすい状態になっている （ユーザビリティ⊇理解性、効率性、標準適合性） ①活動を追跡できる（追跡可能性・信憑性）

Slide 152

Slide 152 text

SLO（サービスレベル目標）をステークホルダーと合意する ● 誰も望んでいないのに過剰な目標を追ってしまうと、徒労で終わる。 ● 部署や用途ごとに暗黙的に期待されている品質目標を洗い出し、明文化して、関係者と合意する。 152 例 用途 約束相手 連絡先 利用データ 期待品質 未達時の影響範囲 1 日次 レポート マーケター Slack #daily_kpi BigQueryの 売上テーブル 毎営業日の8時までに 欠損なく前日売上が レポートされること （即時性） 売上状況に応じた 施策が打てなくなる （機会損失） 2 … … … … … … 3 … … … … … … … … … … … … …

Slide 153

Slide 153 text

テスト・監視 Dataformによる定期データ集計時に、チェックを行う。 ● Dataformの集計処理の成否。 ● 各テーブルの更新日時、レコード件数、nullや空白の有無、値の範囲など。 ● 処理エラーとなる場合はシステム管理者に通知を送る。 153 https://cloud.google.com/dataform/docs/assertions

Slide 154

Slide 154 text

データ利用者への案内 ● ダッシュボードのトップ画面に「🚨現在判明している問題🚨」欄を設けて、検知可能にする。 ● システム管理者への通知とは別に、データ利用者にチャットBotで速報を送る。 154

Slide 155

Slide 155 text

システムチューニング ● 品質の目標と現状のギャップが大きい箇所（ボトルネック）を特定し、原因を特定する。 ● 例えば、「朝8時までに売上集計を終わらせる」（即時性）が担保されていない場合、集計処理のうち どの部分に時間がかかっているのかを確認する。 ● その上で、以下のようなチューニング施策を実施する。 ○ 「全件更新」から「差分更新」に切り替える。前日分だけを集計する。 ○ 「クラスタリング」や「パーティション」でデータの参照範囲を区切る。 ○ 処理Aの後に処理Bを行う「直列実行」から、A・Bを同時に行う「並列実行」に切り替える。 155 処理時間が最も長い箇所（＝ボトルネック）をチューニングする

Slide 156

Slide 156 text

週次ミーティングで改善サイクルを回す ● 毎週の振り返りミーティングで現状（AsIs）と期待（ToBe）を比べる。 ● その週のインシデント（トラブル）一覧を読み返す。 ● サービスレベル目標（SLO）を満たせていなければ、改善アクションのためのTODOを起票する。 ○ 例：新規データ連携を後回しにしてパフォーマンスチューニングを優先する。 ● サービスレベル目標（SLO）自体を見直す。 ○ 過大目標であれば下方修正（e.g. 未使用ダッシュボードはメンテナンスせずに除却する） ○ 過小目標であれば上方修正（e.g. データ更新頻度を毎週から毎日に変更する） 156 What 何をするか スプリント レビュー どうやってするか How スプリント プランニング レトロ スペクティブ デイリー スクラム

Slide 157

Slide 157 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 157

Slide 158

Slide 158 text

10. データセキュリティ・権限管理

Slide 159

Slide 159 text

主な技術要素（詳細版） 159 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 160

Slide 160 text

データセキュリティで実現したいこと 160 よくある相談例 BigQueryで個人情報を扱うのは、カスタマーサポート（CS）部門の「問い合わせ対応」業務のみとしたい 要件（Requirements）を言語化すると？ ①ルール違反をしたくない。 ● 個人情報保護法に準拠したい。 ● カスタマーに提示している利用規約やプライバシーポリシーに準拠したい。 ● 個人情報取扱に関する社内規程に準拠したい。 ②「顧客ID」は使いたい。 ● 厳密な「個人情報」の定義だと「顧客ID」も含まれてしまうが……。 ○ 規約や用途によっては顧客IDの利用もNGになることがあるので注意！ ● 顧客IDなどの仮名加工情報（それ単体では個人を特定できない情報）はOKとしたい。 ● 氏名やメールアドレスなど、特定個人を直接的に表す情報のみNGとしたい。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc…

Slide 161

Slide 161 text

データセキュリティの設定（全体像） 161 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 与件となるルール・規程（文書で管理） 例 位置付け 項目 法令 個人情報保護法 顧客合意 利用規約・プラポリ or 契約書 社内ルール 個人情報取扱に関する社内規程 取り扱うデータの種別（シートで管理） 例 対象データ 種別 氏名 特定個人を 直接的に表す情報 メールアドレス 顧客ID 仮名加工情報 メールアドレスのハッシュ値 機密性レベル（シートで管理） 例 レベル データ種別 提供範囲 2 特定個人を 直接的に表す情報 特定部署のみ 1 仮名加工情報 社内限 アクセス制御（Terraformで管理） 例 PJ レベル 通信要件 認証・認可 gcp-pii-pj 2 CS部門用の VDI経由のみ CS部門社員に 閲覧権限を付与 gcp-bi-pj 1 社内VPNで アクセス可能 複数部門社員に 閲覧権限を付与 監視・監査（GCS等で管理） 例 データ混入や権限付与ミス、 意図しないデータアクセスなどの ガイドライン違反を自動検知＆都度チェック データセキュリティを担保するにあたって 「規程」と「データ種別」から「機密性レベル」を定め、 通信要件（N/W）と認証・認可（IAM）を設定する。 また、要件に沿って運用していることを監視・監査する。

Slide 162

Slide 162 text

データセキュリティの設定（1/3） 与件となるルール・規程（文書で管理） ● 法令：個人情報保護法、金融商品取引法（インサイダー規制）、電気通信事業法（通信の秘密） ● 認証基準：PCI DSS、Pマーク ● 契約事項：利用規約、各取引先との契約書 ● 社内規則：情報管理規定、セキュリティ細則 取り扱うデータの種別（シートで管理） ● PII（個人識別情報） ● PHI（個人健康情報） ● インサイダー情報（財務データなど） ● 契約上の制限に抵触する情報 ● 競争上の優位性に関わる情報 ● 企業秘密に関わる情報 ● 公開している情報 162 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 与件となるルール・規程（文書で管理） 例 位置付け 項目 法令 個人情報保護法 顧客合意 利用規約 or 契約書 社内ルール 個人情報取扱に関する社内規程 取り扱うデータの種別（シートで管理） 例 対象データ 種別 氏名 特定個人を 直接的に表す情報 メールアドレス 顧客ID 仮名加工情報 メールアドレスのハッシュ値

Slide 163

Slide 163 text

データセキュリティの設定（2/3） 機密性レベル（シートで管理） ● 社外公開 ● NDAの範囲内で共有 ● 社外秘 ● 限定共有：特定の役職、部署、プロジェクトメンバー アクセス制御（Terraformで管理） ● 通信要件 ○ システム構成図から通信経路を網羅する ○ アクセス元ｘアクセス先Bｘ権限（許可｜禁止） ○ VPC Service Controls ● 認証・認可 ○ シートからデータ操作の組み合わせを網羅する ○ 対象者グループｘ対象データｘCRUD権限 ○ Cloud IAM 163 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 機密性レベル（シートで管理） 例 レベル データ種別 提供範囲 2 特定個人を 直接的に表す情報 特定部署のみ 1 仮名加工情報 社内限 アクセス制御（Terraformで管理） 例 PJ レベル 通信要件 認証・認可 gcp-pii-pj 2 CS部門用の VDI経由のみ CS部門社員に 閲覧権限を付与 gcp-bi-pj 1 社内VPNで アクセス可能 複数部門社員に 閲覧権限を付与

Slide 164

Slide 164 text

データセキュリティの設定（3/3） 監査・監視（GCS等で管理） ● 監査ログの取得・保存 ○ 各サービスごとに取得可能なログが異なるため、仕様詳細を確認・調査する ■ 例：本資料作成時点でBigQueryの「Save results」の監査ログは誤検知しうる ○ Cloud LoggingやGoogle Workspace管理機能で監査ログを取得する ○ 他環境から独立した監査用Google CloudプロジェクトのGCSに保存する ● 監査ログの参照 ○ アラート条件で不審な変更・作業を早期検知 ○ トラブル発生後に事後調査 ○ 定期・不定期の監査でログを確認 ● Google Cloudの自動チェックサービスで補完 ○ Security Command CenterでCISベンチマークによる自動チェック ○ Cloud DLPによる機密情報の混入チェック 164 BigQueryのセキュリティ対策手順 - 風音屋TechBlog https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ BigQuery の「Save results」をモニタリングするための現実的なアプローチ - 風音屋TechBlog　 https://techblog.kazaneya.com/20250714-bigquery-save-results-audit-log/ 監視・監査（GCS等で管理） 例 データ混入や権限付与ミス、 意図しないデータアクセスなどの ガイドライン違反を自動検知＆都度チェック

Slide 165

Slide 165 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 165

Slide 166

Slide 166 text

11. コスト管理

Slide 167

Slide 167 text

主な技術要素（詳細版） 167 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 168

Slide 168 text

Cloud Billingによるコストモニタリング ● 毎月のコストや内訳は Cloud Billing のコンソールで確認可能。 ● 個人やスタートアップが無料サービスを中心に活用すれば、コストが問題になることは少ない。 ○ 嘉悦大学では月2万円でデータ基盤を運営。書籍『アジャイルデータモデリング』事例集より。 ○ 数百円/月で業務利用しているケースもある。 168 https://cloud.google.com/billing/docs/how-to/cost-breakdown https://cloud.google.com/billing/docs/reports

Slide 169

Slide 169 text

監査ログによるBigQuery利用金額のモニタリング ● Cloud Logging→GCS→BigQuery→LookerStudioに連携して、BigQueryの利用金額を可視化する。 ○ 利用金額が高い or 増えている「チーム > ユーザー」x「テーブル」 チェックする。 ● Cloud Logging→Cloud Monitoringでアラート設定を行って、高額クエリ検知時にSlack送信する。 ● パフォーマンス・チューニングと同様に、余分なスキャンや集計処理を削っていく。 ○ システムが毎日データを集計しているのにユーザーが使っていない場合はクリーニングする。 169 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27

Slide 170

Slide 170 text

Cloud Run functionsの料金（東京リージョンの場合） 簡易的なデータ収集だけならばそこまで大きな金額にはならない。毎日数万人のアクセスが来るような 本格的なWebサービスを構築する場合にコストかかる。どうしても節約したいなら、オフィスや自宅で Mac Miniを常時起動してスクリプトを定期実行する手もあるが、端末代と電気代とエラー対応で多分赤字。 ● リクエスト ○ 料金：$0.40/100万リクエスト ○ 月額の無料枠：200万リクエスト ○ シミュレーション：1日10万リクエストの場合、$0.40 = 60円 ● コンピューティング（CPU） ○ 料金：$0.000024/vCPU秒 ○ 月額の無料枠：180,000 vCPU秒 ○ シミュレーション：1日10万リクエスト * 1秒の場合、282万vCPU秒 → $67.7 = 10,155円 ● コンピューティング（メモリ） ○ 料金：$0.0000025/GB秒 ○ 月額の無料枠：360,000 GB秒 ○ シミュレーション：1日10万リクエスト * 1秒 かつ メモリ512 MiBの場合、114万GiB秒 → $2.85 = 428円 170 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記 しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Slide 171

Slide 171 text

Google Cloud Storageの料金（東京リージョンの場合） 簡易的なデータ蓄積だけならばそこまで大きな金額にはならない。数千万人が毎日開くアプリだとさすがに それなりの金額になるが、デフォルト設定が最安値と言って良いので、あまりチューニング余地もない。 どうしても節約したいならGoogle DriveやBOXなどの導入済みクラウドストレージに置く手もあるが、 ストレージ単位あたりの効率だけだとGCSのほうが安いはず。 ● ストレージ（Standard storage） ○ 料金：$0.023/GB/月 ○ シミュレーション：1日10GBのデータを保存 * 30日 * $0.023/GB = $6.9 = 1,035円 ● オペレーション（Class A：書き込み） ○ 料金：$0.005/1,000オペレーション ● オペレーション（Class B：読み取り） ○ 料金：$0.0004/1,000オペレーション 171 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記 しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Slide 172

Slide 172 text

BigQueryの料金（東京リージョンの場合） 簡易的なデータ分析だけならばそこまで大きな金額にはならない。 「毎月1TBまで無料のデータウェアハウス」は業界としても価格破壊の水準で、代替サービスも限られる。 ● ストレージ ○ 料金：$0.023/GB/月 ■ 90日以上未変更のデータは半額になる ○ 月額の無料枠：10GB ○ シミュレーション：毎月100GBのデータを保管すると90GB * $0.023/GB = $1.98 = 310円 ● クエリ処理 ○ 料金：$7.5/TB ○ 月額の無料枠：1TB/月 ○ シミュレーション：毎月30TBのクエリを実行すると29TB * $7.5/TB = $145 = 32,625円 ● ストリーミング処理 ○ 料金：$0.03/GB ○ 備考：GA4からのデータ連携など一部が該当 172 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記 しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Slide 173

Slide 173 text

Cloud Loggingの料金（東京リージョンの場合） 主に監査ログなどでの利用を想定。簡易的なデータ利用だけならばそこまで大きな金額にはならない。 基本的にはGCSにバックアップを取って、余計なコストも発生させないようにする。 さすがにデータを扱うのに「監査ログを取らない」はよろしくないので、必要経費と割り切るのが吉。 ● ログ取り込み ○ 料金：$0.50/GB ○ 月額の無料枠：50GB ○ シミュレーション：毎日10GBのログを収集すると、250 GB * $0.50/GB = $125 = 18,750円 ● 長期保持（30日以降） ○ 料金：$0.01/GB/月 ○ 備考：GCSに退避すれば削除可能 173 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記 しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Slide 174

Slide 174 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 174

Slide 175

Slide 175 text

12. 継続的開発を支える技術

Slide 176

Slide 176 text

主な技術要素（詳細版） 176 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 177

Slide 177 text

開発標準・開発環境（1/2） 177 ■ リポジトリ：コードの置き場。 ● Git：コードの差分や履歴を管理するツール。AIエージェントがミスをしても復旧できる。 ● GitHub：Git管理のコードをチームで共有し、開発を進めていくためのツール。 ● GitHub Actions：GitHubの機能。Linterや自動テスト、Terraform等の処理を実行できる。 ■ CI（継続的インテグレーション）：継続的にコードを開発し、安全かつ効率的に統合する。 ● Linter：コードが社内ルールに沿った書き方になっていることを自動チェックする仕組み。 ○ 例：PythonならRuff、SQLならSQLFluff、TerraformならTFLint、。 ● 自動テスト：コードが期待通りに挙動することを自動でチェックするための仕組み。 ● Code Rabbit：GitHubで人間の代わりにコードレビューしてくれるAI。 ○ 「シニアデータエンジニアとして振る舞って」「若手に助言するようにレビューして」 「若手の反論が甘かったら徹底的にツッコミして」と設定すると、丁寧に教えてくれる。 ■ CD（継続的デリバリー）：継続的にコードを本番環境へとリリースする活動。 ● Terraform：クラウドインフラをコードで管理して、自動構築するためのツール。 ○ IaC（Infrastructure as Code）なる概念。画面操作と異なり、作業ミス防止や横展開が容易。 ○ 例：BigQueryの設定をコードで管理して、GitHubでレビューが通ったら自動反映。

Slide 178

Slide 178 text

開発標準・開発環境（2/2） 178 ■ 開発標準：自社のルールを決めたり、仕組みを自動化することで開発効率を上げる。 ● テンプレート：要件定義フォーマット、セキュリティ設計シート、コスト計測シート etc…。 ● 規約／ガイドライン：Pythonコーディング規約、SQL規約、データモデリング標準 etc…。 ■ 開発AIエージェント：Terraformを含めて一連のプログラムを自動実装するツール。 ● Cursor：ローカル環境のIDEでユーザーに編集提案してくれる。 ● Claude Code：ローカル環境のターミナルで自律開発してくれる。Gemini CLIもこの立ち位置（？） ● Claude Code Actions：GitHubでのユーザーコメントをもとに自律開発してくれる。 ● Devin：Slackでのユーザーコメントをもとに自律開発してくれる。 ○ データ分析者がGemini支援の元でSQLを作り、SlackでDevin君にパイプライン追加を依頼。 ⇒風音屋では一連のデータ基盤システムを クライアントが最短工数で利用開始できる仕組みを構築中。 本資料のように「データ基盤の構築や運用」といった業務を 1つ1つ言語化し、手順化し、システムに反映することで 徐々に「AI Ready」な開発環境へ進化していく（はず）！

Slide 179

Slide 179 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 179

Slide 180

Slide 180 text

13. データ利活用の促進

Slide 181

Slide 181 text

主な技術要素（詳細版） 181 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 182

Slide 182 text

データ利用促進＝社内マーケティング ● 毎月のデータ利用の人数（MAU）が増えているか、安定しているか、をモニタリングする。 ● どのチームで、どの水準までデータを利用できているか、をモニタリングする。 ● 次の注力支援先を決めて、ニーズを調査し、仕組みを整え、社内営業とサポートを行い、伴走する。 182 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用 チームA チームB チームC チームD チームE チームF 生ログ 独自利用 データT支援 業務依頼 データT支援 データ出力 自主的 データ出力 担当者 依存 自主的 データ生成 他チーム 依頼 基盤貢献！ 担当者 依存 担当者 依存 局所化 自走 改善 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops https://speakerdeck.com/yuzutas0/20211210

Slide 183

Slide 183 text

監査ログによるBigQuery利用状況のモニタリング ● Cloud Logging→GCS→BigQuery→LookerStudioに連携して、BigQueryの利用状況を可視化する。 ● クエリ実行数が多い or 増えている「チーム > ユーザー」x「テーブル」 チェックする。 ● 「既に活用しているチーム」「まだ活用していないチーム」を把握し、社内営業やサポートを行う。 ● 「活用ニーズがあるデータ」を優先して充実させたり、メンテナンスしたり、社内に宣伝する。 183 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27

Slide 184

Slide 184 text

データ利用ガイドを社内提供 ● 「ここで全体像が分かる」という社内Wikiを整備する。 ● ダッシュボードのトップに、利用案内のURLを掲載する。 184

Slide 185

Slide 185 text

社内勉強会やハンズオン ● データ利用の流れを解説したり、実際に体験してもらう場を設ける。 ● 毎月の「相談会」で伴走しながら分析レポートを作り、そのまま上司や経営陣、投資家に報告する 流れになるとスムーズ。上司から「A案件はデータ相談会に持ちこもう」と声が掛かるようになる。 185

Slide 186

Slide 186 text

● チャットツールで相談場所を設ける。 ○ データチームで運用当番を設けてユーザーサポートに当たる。 ● よくある問い合わせ（FAQ）はWikiやデータカタログツールに反映する。 ○ 次からはURLの案内だけで済むようにする。 ○ ナレッジを充実させることでAIの回答精度を高める。 ● 自動対応するチャットBotを構築する。 ○ Slackを窓口にするならGoogle CloudのConversational Analytics APIを用いて実装する。 ○ 今後はAgentspace + GeminiやLooker (Studio Pro) のConversational Analyticsに期待。 ○ データ項目追加や権限付与依頼はGitHub管理とし、Devin等の開発AIエージェントに任せる。 問い合わせ対応や作業依頼 186 分析相談 レビュー依頼 FAQ 充実化 再利用

Slide 187

Slide 187 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 187

Slide 188

Slide 188 text

14. DXからAIエージェントへの変遷、データエンジニアリングの未来

Slide 189

Slide 189 text

主な技術要素（詳細版） 189 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト

Slide 190

Slide 190 text

DXの進め方①：現状のリソースの流れを書き出す 「アナログ志向の業務」は「ヒト・モノ」（リソース）の流れに依存している。 190 自社法務 郵便局員 相手法務 契約書を印刷 署名・押印 受付 配達 受付 配達 受け取り 受け取り 署名・押印 ヒト ヒト ヒト モノ モノ

Slide 191

Slide 191 text

DXの進め方②：理想のデータの流れを書き出す 「デジタル志向の業務」は「情報」（データ）の流れを最適化する。データ基盤の本来のコンセプト。 191 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録

Slide 192

Slide 192 text

DXの進め方③：システムで自動化できる箇所を特定する ツール導入やシステム化によって「人間」の作業を減らし、ムダ・ムラ・ムリを解消する。 192 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録 ■ヒトがやるべきこと （入力と確認） ■DXで実現できること （加工と出力）

Slide 193

Slide 193 text

DXの進め方④：システムで置き換えた後のリソースの流れを書き出す 「デジタル志向の業務」になった後のフローを書き出し、業務マニュアル作成やスタッフ研修を行う。 システム構築やツール導入で終わりではなく、現場業務の落とし込みとカルチャー装着まで「変革」する。 193 自社法務 GMOサイン 相手法務 PDFアップロード 入力・送信 受け取り 入力・送信 ヒト ヒト 情報 受け取り 転送 転送 DX

Slide 194

Slide 194 text

Beforeから「増やすべきもの」を追加し、「減らすべきもの」を取り除く。 そのための予算確保、体制整備、社内営業＆サポートの徹底、ロードマップ策定・推進を行う。 DXの進め方⑤：BeforeとAfterの差分を埋めるのがDXプロジェクト 194 After Before 減らすもの 増やすもの 契約書PDF、電子契約ツール、 PDFアップロード、電子署名 紙の契約書(原本) 署名、捺印、郵送依頼、 郵便局員、配達、受け取り

Slide 195

Slide 195 text

AIエージェント導入の勘所①：AIで半自動化できる箇所を特定する AI導入によって「人間」の作業＆判断をさらに減らし、ムダ・ムラ・ムリを解消する。 195 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録 ■ヒトがやるべきこと （入力と確認） ■DXで実現できること （加工と出力） ■AIが一部担えること （草案作成＆懸念指摘） NEW!

Slide 196

Slide 196 text

AIエージェント導入の勘所②：AI導入後のリソースの流れを書き出す 業務手順の中にAIエージェントを組み込む。あるいはAIエージェントの中に人間の介在箇所を組み込む。 業務マニュアル作成やスタッフ研修を行い、現場業務の落とし込みとカルチャー装着まで「変革」する。 196 自社法務担当 GMOサイン 相手法務担当 PDFアップロード 承認・送信 受け取り 入力・送信 ヒト ヒト 受け取り 転送 転送 法務’sサポートAI　　. （ワトソン君） 契約書の作成 自社記入欄の入力 情報 DX AI

Slide 197

Slide 197 text

AIネイティブな時代の「ビジネス」や「オペレーション」の行き着く先 あらゆる事業（ビジネス）や業務（オペレーション）は以下の一連の活動と言える。 ● 何らかのリソースを投入（Input）して ● 何らかの価値を付加（Processing）して ● 何らかの財・サービスを提供（Output）する AIエージェントによって「情報」（データ）の担う部分が拡大する。 結果、あらゆるビジネスやオペレーションが「データエンジニアリング」化する。 ● 「情報」（データ）の流れを制御する中核システムが「データ基盤」 ● 「情報」（データ）の流れを制御する活動が「データエンジニアリング」 ⇒Development（仕組みの構築） 　「データエンジニアリング」と「AIエージェント導入」と「業務定義」と「経営」とが一体化する。 ⇒Operations（仕組みの運営） 　「データ基盤」と「AIエージェント」と「業務フロー」と「事業運営」とが一体化する。 197

Slide 198

Slide 198 text

ITエンジニアやWEBマーケターだけではなく、人事や経理などのバックオフィス職（事務職）にも 「AIエージェント」や「データエンジニアリング」の考え方が必要になる バックオフィス職にもAI＆データが必須の時代 198

Slide 199

Slide 199 text

アジェンダ アジェンダ アジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩ データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、 データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 199

Slide 200

Slide 200 text

15. おわりに

Slide 201

Slide 201 text

データエンジニアリングを楽しもう！ 201 データエンジニアリングは、いわば総合格闘技です。 データの重要性が日々増していく時代、世界中で誰もが困っている課題に立ち向かっていく仕事です。 データ活用やビジネス理解の面白さ（そして難しさ）が詰まった、やりがいのある分野です。 Google Cloudは、データエンジニアリングの最前線を開拓し、同時に、専門家以外にも裾野を広げる 魅力的なソリューションだと思っています。ぜひフル活用していきましょう。 この発表が皆様の業務に少しでもお役に立てたら嬉しく思います。

Slide 202

Slide 202 text

ご清聴ありがとうございました 202 改善サイクルを回し、今日よりも良い明日を。 https://kazaneya.com/contact