datatech-jp Casual Talks #4 レポート
datatech-jp Casual Talks #4 レポート
恒例のdatatech-jpのLTシリーズです。
今回もレポート書きます。
データマネジメント セミナーレポート
過去のレポートはコチラからどうぞ
その他データマネジメント関連のセミナーに興味ある人はこちらから。
データリネージの組織導入事例と今後の戦略
発表者
tosh2230（GMOペパボ）
発表資料
＜後であれば更新する＞
概要
データリネージをはじめた背景
データリネージとはデータの系譜を明らかにすること。データの可観測性の向上が目的。
Bigfootと名付けられたデータ基盤を運用している。
データ駆動のためのエコシステムの提供
サービスの動的な改善と意思決定の自動化をサポート
GMOペパボはいろんな運営サービスがあります。複数サービスを活用していることによる困りごとが２点あります。
データ障害の原因や影響範囲を把握しにくい
業務データの活用状況を把握しにくい
業務データ全体に対するデータリネージがしたい。
データリネージ具体的な手段
OSSでStairlightというものを開発しました。
特徴
SQLからデータのつながりを見つける
コードベースにあるSQLを探す。
独立性が高い
詳しくはこちらへ
GMOペパボでのデータリネージ導入事例
まずはcloud composerのリネージ情報を収集。
SELECT文の数は約220。
リネージによって起きたこと
情報伝達の質と展開速度の向上
俯瞰的な視点
今後の戦略と課題
次はView層のデータリネージを対象にする予定。
データが期待した状態であるか、ヘルスチェックを開示する。
遅延通知を自動で行う。
質疑
（吉田さん）
データ基盤を管理している人以外でもニーズがありそう、使えそうなので良さそう。
テーブルだけじゃなくて、カラムの依存関係がわかるとよいがカバーされる？
できればやりたいと思っていて、今はそんな機能はないが、是非やっていきたい。
（Kiriharaさん）
SQLのパースには何を使っていますか？Bigqueryの独自の構文があるので、大変だと思いますが。
今は正規表現でやっています。うまくいかないところを見つけてはStairlightに反映するという事をやっている。
感想
データリネージは利用者も管理者もニーズがあり、調査するとなると大変なので可視化されると具体的な工数削減や、ビジネスへの活用ができると思う。
おそらくやっていると思われるが、効果を基にデータリネージを可視化する領域を決めていくのが良さそうだと思った。
データ基盤側
手を入れるときに影響範囲の調査したい
データ基盤の運用を楽にしたい
データ利用者側
この数値の出どころはどこのシステムか知りたい
数値の集計ロジックが知りたい
データ現新比較テストを用いた Lift & Shift のすゝめ
発表者
a1008u（株式会社インタースペース）
発表資料
＜後であれば更新する＞
概要
発表の背景
データ基盤の移行に関する事例は少なく手探りだった。
データ基盤の移行について、何かお伝えできればという事が背景。
システム移行って大変ですよね？
今回のテーマは自作のBIからTableauの移行について。
TreasureData → Bigquery
自作BI → Tableau
移行の話
出力データは基本一致させることが移行における要件
自作BIツールはロジックの全てがAPI側にあった。
データ整備も必要ではないかという事になり、dbtを導入することも対象にした。
データ整備の方針
Lake - API - Front
Lake - DWH - BI
API部分のテストはデータエンジニア側が、フロント部分はビジネス側が担当する事になった。
API側の処理については、DatadogからSQLを取得した。
結果、移行はうまくいきました。
本日のポイント
現新比較テストをレイヤごとにやるので、どの部分が間違っているのか切り分けられてよかった。
マシンパワー大切
Data Modelling and Transformation
Lift＆Shiftはテスト設計を最初に決めておくことが重要
Lift＆Shiftは細かく分けて
整合性が取れているレイヤーを明確にする
質疑
（吉田さん）
全部移行しようと思うと大変だと思うけど、対象を絞ることはやった？
結果、全てやることになったが、絞り込むアプローチはとった。
感想
ビジネス側の要件である、「出力データは基本一致させること」というのは、言うが安しに対応できると思われがちなのだけど、実はかなり難易度が高い。
今回話をされた「数値がずれる問題」は、こういったように一つ一つのレイヤーで担保していかないと難しいと思う。
自分も今テストをやっているが、取り込み時間だったり、取り込み時のロジックであったり、ずれる要因はあるのでやり方として参考にしたい。
SHOWROOMの分析〜目的を意識した伝え方・コミュニケーションの工夫〜
発表者
はたの（SHOWROOM株式会社）
発表資料
＜後であれば更新する＞
概要
サービス、組織の紹介
SHOWROOM、ライブ配信サービス９周年を迎えた。
ライバーとコミュニケーションを取って視聴者も参加することができる、というのが特徴
データアナリスト、データエンジニア、AIエンジニアが存在する。
SHOWROOMのみんながデータを使って仕事できるようにすることを目標としており、Slackのチャンネルでいつでもアナリスト宛にコミュニケーションが取れるようになっており、ここの効率化が本日の話。
データ基盤の話
SHOWROOMはサービスからのデータが１日に一回程度GCS→digdag→BigQueryにて送られるようになっている。
BigQueryにあるものを、BIで使っている。
依頼主は「〇〇が欲しい」という依頼を送られるが、データリテラシーは様々なので、ほんとに欲しいのは何なのかということを、きちんと目的をヒアリングして
JIRAのテンプレに以下をして、必須で書いてもらう。
依頼内容（背景、条件、期間などを詳しく）
用途
いつ使うの？
目的によってアウトプットを以下の４つにする。
Redashクエリ
CSVや数値の共有
Redashのダッシュボード
自動更新のスプレッドシート
Redash整理については以下のnoteを参照ください
質疑
（ゆずたそさん）
「数字が◯◯だったらアクションはどう変わりますか？」みたいなシミュレーションするのもオススメです。
アクションが変わらないなら見る必要ないですし、もっと良い指標が見つかるかもなので。
営業のためであればそもそも先方に絶対渡さないといけない数字なので出す前提、企画であればそういうコミュニケーションもあります。
ただ、作ったほうが早いと思ってしまって渡すケースもあります。
（toyamaさん）
gcs から bigquery へは digdag を使用しているとのことでしたが、digdag で data transfer service を使用しているのでしょうか？
digdagでBQロードを読んで、GCSからBQへ転送しています。
（ゆずたそさん）
アウトプット＞アウトカムを重視する感じですかね
評価基準とか気になっちゃうところです。依頼に沢山対応すれば評価される感じなんでしょうか。
評価基準とか気になっちゃうところです。依頼に沢山対応すれば評価される感じなんでしょうか。依頼によって評価されるというより、全社的な貢献をするかという観点。結構依頼主との信頼関係もありますが、やる必要が無いと言って終わることも多々あります。
感想
依頼をフォーマット化して内容に沿ってアウトプットを標準化するというのは、依頼者もアナリストもわかりやすくて良さそう。
依頼側はビジネス目標もあり、データについてはあまりリソースを割きたくないという意図もあるので、どうしても依頼は省力化されてしまう。
そういう状況なので、依頼側にもちゃんとやれとデータ側から言い返すようなことをやらないと、認識が相違しちゃってニーズが無いものを作っちゃうというのはありそう。
BigQueryにおけるポリシータグを用いた秘密情報管理とデータ連携
発表者
keisuke taniguchi（ZOZO）
発表資料
概要
データ基盤の紹介
ZOZOのデータ基盤は
秘密情報管理で抱えていた課題
秘密情報はマスクしてBigQueryへ連携
セキュリティ面での課題
ポリシータグの選定理由
ポリシータグとはカラム単位でアクセス制御が可能なもの。
承認済みビュー
機密性の高さ
匿名化による機密性の高さが魅力。
利便性
承認済みビューはプレビューでデータを確認できないのが不便。
ポリシータグは利用者が使いやすい。
保守運用
秘密情報がなかったテーブルに秘密情報が追加されたときに追加しやすい。
運用方法
秘密情報の分類マスタを作成。
SQL ServerからBigQueryの非公開環境にデータを連携する。
BigQueryの非公開環境からBigQueryの公開環境に連携するときに、ポリシータグを追加する。
ポリシータグ運用時に考慮する事
ポリシータグを付与したテーブルは「ALTER TABLE」が使えない。
テーブルにマスクカラムが必要
ジョブに失敗した際ポリシータグが外れないように注意
詳しくはQiitaの記事にて
秘密情報分類マスタの整備
質疑
（吉田さん）
BigQueryだとストラクトのカラムがあって、そこはどういう風にしている？
都道府県は見せたいが、アパート名は見せたくないとか。
そういう事例はないためないが、ストラクトで管理しない、連携時にカラムを分けて管理するとかがよさそうだと思っている。
（吉田さん）
ポリシータグを使うとアクセス制御できるが、叩ける人がなにかやらかしてしまうとかあるのでしょうか？
書き込みやめてくださいと運用している、実際追えているかというと追えていない。
感想
吉田さんの２つ目の質問が自分も気になった点で、秘密情報をどのくらい秘密として扱うのかという会社の規定が重要なのではと思った。
セキュリティ要件は事業によって結構違うので、やる場合はセキュリティチームと密に連携して行う必要があると思う。
タイミーのデータ基盤チームにおけるユーザストーリー導入（仮）
発表者
Masahiro Ishii（Timee）
概要
＜後であれば更新する＞
概要
サービスの紹介
Timeeは隙間バイトのサービス。
働きたい時間、条件を見て働くことができる。
そのサービスのデータ基盤をどのような体制で作っていくのか。
開発体制の話
スクラムでやっている。スクラムを選定する理由はあるが。
Timeeのデータ基盤チームはは「ユーザーに使われるものを作りたいから」スクラムで開発している。
開発機能を作るときに、ユーザーにとって何を届けるのかユーザーストーリーとして言語化していっている。
ユーザーストーリーとはユーザーの価値にフォーカスして、検証したい要求事項を整理したもの。
Who,What,Whyをベースに整理する。
ユーザーストーリーを書くだけだと起こる問題で、メンバーによって違う解釈をしてしまうことが起こる。プロセスを徹底することで、イメージを一致させることを頑張った。
責任者と開発者でがっつり議論して、書かれたユーザーストーリーこまかい違和感を一つ一つ認識合わせをしていった。
ユーザーストーリーを入れると、開発者としてよかったこと。
開発者の目線が統一され開発フェーズでの議論がしやすくなった
事前に開発者と責任者の目線が統一されて、開発フェーズでの議論がしやすくなった
プロダクト責任者との役割分担が進んだ
ユーザーストーリーを導入することで自己組織化された組織に一歩近づけたと思う。
質疑
（吉田さん）
データ基盤開発の場合、スクラムの経験がない人がいると思いますが、どのくらいスムーズにスクラムを導入できましたか？
結構チーム内勉強会が盛んで、スクラムの知識を得ている人がいる。
（tosh2230さん）
ユーザーストーリーをしっかりまとめるタイミングは、スプリントプランニングのときでしょうか？
コンテキストをしっかり揃えるとなると、どうしてもスプリントプランニングにかける時間が長くなりがちという悩みがあるのですが、運営上の工夫はありますか？
ユーザーストーリーを話すのはリファインメントという別のイベントを作っています。
プランニングについては、開発者だけで閉じていて、関係者を絞ってやれているので、影響を小さくしている。
感想
開発チームがビジネス側に寄り添っていくケースと、開発チームは技術の専門家集団であり、ビジネス側とは別であるケースの２つがあるかなと思うのですが、データ基盤はビジネス側に寄り添っていくケースなのかもしれない。
データ関係は話者によって特に用語の認識が統一されていない分野なのかなと思っているので、今のようなデータが分野として立ち上がってきたタイミングではしっかりがっちり議論したほうがいいのかなと思った。
おわりに
自分の知識をまとめるためと今後誰かがデータマネジメントをやってみたいと思った時のきっかけとなるためにnoteを書くことにしました。
モチベーションのために役にたったという人はぜひ、フォロー＆スキをお願いします。
ツイッター（@yoshimura_datam）でもデータマネジメントに係る情報をつぶやいてますので、よろしくお願いします。
データマネジメントを学ぶ人が抑えておきたい本
今すぐわかるデータマネジメントの進め方
著者のDMBOKを用いてCDO室を立ち上げデータマネジメントを推進した経験を基にデータマネジメントの進め方をまとめたkindle本を執筆しました。
データ組織立ち上げ編 ＡＩ事務員宮西さん
著者のデータ組織の立ち上げ経験をマンガ＋コメントでまとめてみました。立ち上げ編は組織を立ち上げてやることが決まるまでのストーリーです。
無料公開のため0円となります。
データ組織の立ち上げに関係する方は是非読んでみてください。
DXを成功に導くデータマネジメント
DXを成し遂げるために必要なデータをどうマネジメントしていけばよいかが書かれている。
データ環境より、セキュリティの観点であったり、プライバシーの観点であったりといった非技術者向けの内容が多く書かれている。
データマネージメントに興味を持った人はまずは読んでみるとデータマネジメントでなすべき概要が理解できる。
実践的データ基盤への処方箋
データ利活用を行うために必要なデータ基盤の考え方と、利活用するためにはデータをどのようにマネジメントしていけば良いかを具体的な例を用いて説明されている。
技術が中心になるので現在データ技術に係る人がデータマネージメントに興味を持った時には、まず手に取ることをおすすめする。
個人データ戦略活用 ステップでわかる改正個人情報保護法実務ガイドブック
個人情報保護法を順守するための基本的な考え方が実務ベースで書かれている。2022年4月に施工される改正個人情報保護法で新たに追加される概念も同様に記載されている。
政府の出しているガイドラインよりも俯瞰的に読めるためデータプライバシーにかかわる人、データを使ったビジネスを推進する人は読んでおくとスムーズに業務が進められる。
データマネジメント知識体系ガイド（DMBOK）
自分も要約・解説記事を書いているDMBOK。データマネジメントに興味を持った人がまず手に取ると挫折することは間違いないほどのボリュームがある。
読めば読むほど味が出てくるので、データマネジメントを進めようとしている人は各家庭に1冊は是非買っておきたい。
データマネジメントが30分でわかる本
著者もDMBOKを読むためには非常にボリュームが多く読み解くには苦労するので、かみ砕いた解説書をまとめたと書いてある通り、DMBOKを独自解釈してわかりやすく書かれている。
DMBOKを技術者目線で読み解いた内容になっているので、実践的データ基盤への処方箋と同様データ技術に係る人におすすめする。
この記事が気に入ったらサポートをしてみませんか？