「データアーキテクト（データ整備人）を”前向きに”考える会」参加レポート
ブログ枠はブログが書くまでが勉強会ということで書きました！
イベントページ
analytics-and-intelligence.connpass.com
「データアーキテクト（データ整備人）の概観とこれからの展望と課題」 しんゆう さん （フリーランス）
発表資料
概要
データエンジニアはデータを集めてデータレイクに入れる人。ログ、バッチ処理などをする
データエンジニアとアナリストの間にあるのは
データの抽出
- ダッシュボードなどでデータを可視化
データの整理。イレギュラーなデータへの対応や仕様変更への対応や監視や正確性の担保
抽出、集計、管理は雑用ではなく専門家として役割を確立させるべき -> しんゆうさんは「データ整備人」という風に名付けた
分析の経験がないと抽出の依頼に対して提案ができない
データ抽出はエンジニア領域に近い部分はあるものの、それが本業ではないので非エンジニアが対応すべき
「次にデータを使う人が速やかに業務に遂行できるようにデータを使いやすくする人」
感想
懇親会での話や発表を聞く限り、エンジニアやアナリストがデータ整備人を兼務していてデータ整備業は彼らの本分ではないのでモヤモヤしているという意見が多かったので、データ整備専門チームがある今の現場は恵まれていると思った
分析の経験が自分にはないので、適切な提案できるデータ整備人ではないのが痛いところ
「3社の事例から学ぶ！現場で使われるダッシュボードの作り方」 ゆずたそ さん
発表資料
概要
メルカリをサポートしている
メルカリはデータ整備人のポジションを最近作った
ダッシュボードは運用設計してちゃんと運用開始後にも見直すべし
5W1Hは焦点を小さく絞ろう。このくらい細かい粒度で↓
- Who - 経営陣(Aさん、Bさん、Cさん）
- When - 毎週水曜日の16時から
- Where - 会議室Aで
- Why - サービス利用状況を知るために
- What - 主導線UU率の推移を
- How - 議事録テンプレのURL経由で見る
社内でSlackをどのように扱っているかのダッシュボードの例ｰ>Slackbotでオペレータに月イチで知らせる。ちゃんと運用される仕組み作り。
「誰が」「いつ」「どこで」使うのか説明できるダッシュボードにしよう。誰かがいつか使ってくれるかもしれないのは結局使われない。
データを可視化するのはビジネスを助けるため
感想
- データの可視化によってビジネス側が問題の原因となりうる事象に気付き、ビジネスルールを改善するという事例があった。データの可視化によってビジネスが改善される良い事例だった。メディア広告の例↓
https://speakerdeck.com/yuzutas0/20191127?slide=32
5W1Hがとても細かくて驚いたけれども、そのくらい具体的で焦点が絞られていた方がちゃんと使われるかもしれない
データ整備の目的はデータが意思決定やビジネスの改善に貢献できるようにすること、というのが伝わる発表だった
「テータ整備業でぶつかった5つの課題_テータ整備人に求められる3つのスキル」 shinaro iwai さん（株式会社オプト）
発表資料
概要
データ整備業をしている
クライアントからの依頼、社内からの依頼から求められていること： 意思決定の示唆、意思決定するために必要なことのすり合わせ
雑なデータ取得依頼ｰ>なんのためにデータがほしいのかしつこく聞く
https://colab.research.google.com/notebooks/welcome.ipynb?hl=ja
ノウハウが共有されなくて辛い->GitHubにクエリTipsを保存
データ整備人に必要なスキル
感想
- Google Colaboratory使ってレビューしてみたい(されてみたい)
数値の正しさの感覚やデータ理解力が自分にはまだないので、もっとビジネスを知る必要があるのが自分の課題
何のためにデータを使いたいのかをビジネス側とすり合わせることは、余計なことをしたくない自分たちのためにも、効果的にビジネスの改善をしたいビジネス側の人たちにとっても大事なこと
「サイエンス視点からのデータアーキテクト」 堀野将晴 さん (ヤフー株式会社)
発表資料
www.slideshare.net
データサイエンスではモデリング・分析のための前処理・可視化
モデリングからサービス実装までが1チーム。
大きなデータなので前処理が必須だけれども時間もCPUも使って大変。共通データが必要
たくさんの部署と関わるのでコミュニケーション能力がとても大事
ドメイン知識も大事
データ開発運用をサービス側の開発に求めるのは失敗した。目標の違いやリソースが逼迫しているため。サイエンス側と協力して開発
ログ設計のルールは整備人と実装側の認識合わせが必要
意図通りに使われないテーブル。中間テーブル作ったら大元のテーブルとジョインされた・・・。ｰ> 使われ方はよく確認してから作ろう
データ整備人で価値を出すには能動的に動くことと開発運用まで携わること
感想
データサイエンスに使われるデータための開発とサービス開発は根本的な目的が違うので、サービス側に任せずデータサイエンス側と開発するというのが印象的だっ た。サービス側でも開発できると思っていたので・・・
データ整備は誰もやりたがらないからこそ能動的に動くと価値があるというのもキャリアを考える上で参考になった
全体的なまとめ
データ整備業は雑用に思われがちだけれども他の役割と片手間で専門的な知識が必要な大事な役割
データ整備人に必要なスキル
- 課題抽出力 - ビジネス上の課題を知ってビジネスの改善や意思決定に貢献できるようになろう
- コミュニケーション能力 - データ取得を依頼するいろんな部署の人や外部の人と関わるため
- ドメイン知識 - データがビジネスの改善や意思決定に使われるためにはそもそもビジネスを知っている必要がある
