本日開催された「第2回 データアーキテクト（データ整備人）を”前向きに”考える会」に参加しました。
勉強会メモ 第2回 データアーキテクト（データ整備人）を”前向きに”考える会 本日開催された「第2回 データアーキテクト（データ整備人）を”前向きに”考える会」に参加しました。
analytics-and-intelligence.connpass.com
- 全体を通した所感
- t-kurimuraさん：「EurekaのDataPlatform開発状況と"再現性"の実現」
- しんゆうさん：「抽出や集計の依頼を受ける時に気を付けていること」
- midaさん：「データエンジニアとデータアナリストを兼任して良かったこと」
- sotaronさん：「データの価値を失わないための Data Reliability Engineeringについて」
- ぶんけいさん：「意思決定に繋がる Intelligence とは」
全体を通した所感
- 「データエンジニアとデータアナリストを兼任して良かったこと」を聴講して、データ整備や抽出はストレスフルな職務ではある。しかし、データの信頼性がなくなれば、ディレクターとプロダクトエンジニアは厳密にデータ分析を行わずとも職務の遂行はできるので、データ系の仕事の価値は減る。そのため、データの信頼性を担保することは重要。（辛みはあるけども。）
- 「意思決定に繋がる Intelligence とは」を聴講して、マーケティング系指標のレポートを色々作っていたため、自分はデータアナリストと思っていた。ただ、Insight & Intuitionを出す観点で考えると、自分はデータアナリストの領域まで到達していなく、データの調理上手な人に過ぎないなと感じた。
t-kurimuraさん：「EurekaのDataPlatform開発状況と"再現性"の実現」
内容
- DataPlatform基盤
- BigQuery, Composer(Airflow)
- Datalake, DWH, Datamart
- DataPlatfrom公式化
- DataPlatfromに乗せるために満たすべき基準
- 再現性
- 体制
- プロジェクト毎にデータ分析担当が付いている。
- CloudComposerの基盤管理はSREとして別の担当が担う。
- 30分の定例で、DataPlatformの知見をメンバーと共有する。
- 業務フロー
- 一度簡易的な試しのDataMartを作成し、可視化する。
- その後、FBをもらいながら要件を確定して、DWH, Datamartに落とし込む。
- 監査ログから共通化できそうなクエリを共通かする。（例：JOINが良く使われているテーブル同士など）
- Tips
- 永続UDFの活用（Temporary UDFが各SQLに散らばるのを防止）
所感
- 試しのDatamartを作るという位の心持ちの方が、作り直しから発生するストレスがなさそうで良さそう。
しんゆうさん：「抽出や集計の依頼を受ける時に気を付けていること」
内容
- 基本戦術
- 依頼はきちんと聞く
- 邪険にしない。
- 納期をとにかく確認する
- ”なるはや。”のような曖昧な表現は、基本的にいつまでに？を明らかにする。
- あればうれしいがいつでも良い。基本放置しつつ、集計依頼された側から確認を定期的にすると良い。
- 依頼もデータも鵜呑みにしない
- 依頼者のやりたいことを実現することが真の目的。
- 目的を明らかにする。（データが欲しいのか？、分析して欲しいのか？、施策などの提案して欲しいのか？）
- 依頼はきちんと聞く
所感
- 依頼の内容は基本参考程度にして、背景・目的を明らかにして真の依頼に答えるという戦術が、基本的に大事。
midaさん：「データエンジニアとデータアナリストを兼任して良かったこと」
www.slideshare.net
内容
- JapanTaxiに関して
- ログとしては、アプリ利用だけでなく、配車情報、決済情報、位置情報がある。
- BIチームは、データアナリスト３名、データエンジニア１名である。
- 兼任してよかったこと
- データソース・DataLake・DWH・データマートはデータエンジニア。データマート・集計分析・意思決定はデータアナリストという分業
- データエンジニアがビジネスに対して理解が浅いと発生するケースを回避できる
- 理解が浅い場合、データアナリストからの分析要求に対して最適なデータ利用の提案ができない。要求の背景ある課題に対して他に使えそうなデータソースを紹介できない（データアナリストの分析が良くなるチャンスを喪失）。
- PDCAにおけるデータ分析でのメリット
- 分析基盤のエンドポイントとしてデータに関するなんでも相談先として頼られる
- データの存在有無、データの意味や分析のための特徴量として有用性など、必要なときに必要な情報を提供できる存在。
- 兼任のデメリット
- 組織規模が大きくなるほど、仕事量的に兼任が難しくなる。
- 通常の組織では、データエンジニア、データアーキテクト、データアナリストで職種が分かれていくと思われる。
所感
- データドリブンでない施策を行ってしまう理由の一つとして、データ分析の工数がない、データ分析者に依頼すると時間がかかるなどの理由で施策実行までが遅れるから、データ分析を待たずして施策を実行してしまう流れができてしまうという状況が発生する。という問題にとても納得した。そのために、いかに工数を抑えるか？を考えることは大事。
sotaronさん：「データの価値を失わないための Data Reliability Engineeringについて」
内容
Data Reliability Engineerは何か？
- どこかの有名な組織が決めた職種ではない。（ただ、様々な会社で発生する仕事ではある。）
- まだまだ定義が決まっていないが、必要な仕事。
よくないケースの発生を防ぐためにData Reliability Engineerが必要
- A/Bテストのログ欠損により、結果が信頼できず意思決定できない。
- バッチの遅延による最新のデータではなく、間違った判断を生む。
- データの価値、信頼を失わないこと
- データへの信頼が失われると、PMがデータ分析に基づく施策のプロセスがなくなる可能性が起こりうる。
Data Reliability Engineerの始め方
所感
- この方の信頼できるデータ整備へのこだわりを感じた。
- 一つ前の発表と同じく、データが信頼されなくなれば、それが当たり前と受け入れられて、データが軽視された判断が下されてしまう。という常にある危機は意識しないといけない。
- データ基盤における、サービスレベルというものをどのように定量化するか？については、今回の資料を参考にしつつ、さらに各々が模索していく段階だなと感じた。
ぶんけいさん：「意思決定に繋がる Intelligence とは」
内容
- システムを知らなくてもデータが欲しいのは、意思決定したいから。
- 課題が振られてなんか可視化して欲しい。と言われたときに、Intelligenceとは？
- Intelligeneとは？
- 意思決定につながらないと無価値
- Intelligence + Insight & Intuition（直感）
- 読み手に半強制的な行動を伴うもの。
所感
- データ分析とは？のフィクションながらケース問題が面白かった。データをデータとして集計してみるだけでなく、現実に即した形で配置したり可視化しないと、問題の本質を見逃す良いケースだった。
