「データアーキテクト（データ整備人）を”前向きに”考える会」に参加しました
はじめに
11/27に開催された「データアーキテクト（データ整備人）を”前向きに”考える会」にブログ枠として参加させて頂いたのでイベントの様子をレポートとして書きます。
analytics-and-intelligence.connpass.com
会場: 株式会社オプト
私の現在
ブログで報告するほどのことではなかったのですが、9月に大学院を卒業して10月からとある人材系企業でデータ分析組織の立ち上げに関わっています。
データ分析基盤の構築（データレイク、データウェアハウス）、からデータ分析、データサイエンスの啓蒙活動、（ゆくゆくは事業提案も？）など広く関わっています。 そんなこんなで情報収集も兼ねて今回の勉強会に参加しました。
以下は各発表のサマリーになります。
勉強会趣旨
- データエンジニアとアナリストの間には色々仕事があるが評価されないことが多く、つらみが溜まっている
- つらみの共有ではなく前向きに考えたい
発表ごとの要約
データアーキテクト（データ整備人）の概観とこれからの展望と課題 by しんゆう
- 免責事項
- データアーキテクトの仕事をやってる人の資料
- どこかにバイアスが残ってポジショントークになっているところがあるかもしれないのでご了承ください
- 前置き
- データ抽出やデータ整理の役割がある
- 誰かがやらなきゃいけないが誰がやるのかが微妙のまま
- 役割を整理したい
- データレイクの前と、データマートの跡を考える必要がある
- データレイクにデータを入れる作業が必要
- データマートのあとは集計→マーケターなど
- 分析結果は「「インテリジェンス」のことで、意思決定のために分析・洞察された情報・データ」
- 職種
- データエンジニア→データレイクにいれる
- データアナリスト→集計後の分析
- データウェアハウス、データマート、集計のところに役割の名前がない
- 「中間」の役割
- 抽出
- ダッシュボード作成を含む
- 整理
- DWHの設計、作成、イレギュラーデータへの対応
- 管理
- 仕様変更への対応、データの監視、正確性の確保
- 抽出
- 誰がやるのがいいのか
- よくあるケース1. データエンジニアが（他にいないから）やる→アナリストと仲が悪くなる
- よくあるケース2. データアナリストが（やらないと仕事にならないので）やる→つらみが貯まる
- たまにあるケース3. マーケター→いろいろ無理（専門から遠すぎてめちゃくちゃになるケース）
- 「別の役割として認識すべき」
- エンジニアは「作る側」。データフローの「中間」は組み合わせる作業
- 片手間でできることでもない
- 呼び方はとりあず「データアーキテクト（データ整備人）」あとは世の中の成り行きで。
- 必要なこと
- 「次にデータを使う人が使いやすい状況を作る」
- 将来に向けて
- 現場だけでなく味覚やマネージャと協力すべき
- もしかしたら本当に雑用かもしれない
- まとめ
- 名前や守備範囲は変わるかもしれないが、役割はなくならないので、備えよう
3社の事例から学ぶ！現場で使われるダッシュボードの作り方 by ゆずたそ
- 前置き(という名の要約)
- Case1 BtoB SaaS企業
- 5W1Hの例
- Who: 経営陣が
- When 週イチで
- Where: 会議室で
- Why: サービスの利用状況を知るために
- What: 主要導線UU率の推移
- How: 議事録テンプレのURL経由で
- Case2: BtoBtoC メディア広告企業
- PDCAの例
- よくあるレポート以外に、「曜日×時間帯ごとのPV」「エリアごとのPV」を追加
- Case3
- 実現のノウハウ
- 伝えたいこと
- 分析者だけでなく、現場の一人ひとりがデータに向き合うこと。
データ整備業でぶつかった5つの課題・データ整備人に求められる3つのスキル by shintaro iwai
- よくある依頼の内容
- 意思決定の材料
- 広告の分析
- CRMの自由分析
- 求められていること
- 意思決定への示唆
- 求められていないこと
- 意思決定
- 統計的な助言
- 5つの課題、というよりも分析者あるある
- 3つのスキル
- 課題抽出力
- 雑な依頼から課題を考え、聞き出す能力
- 高いSQL力
- データ理解力
- 扱うデータに責任を持つこと
- 課題抽出力
サイエンス視点からのデータアーキテクト by 堀野将晴
- データ整備人に求められるもの
- コミュニケーション←いろいろな人と関わるので
- ビジネス価値を考える力
- データエンジニアスキル
- ぶつかった困難
- ログ管理の難しさ
- ログを設計する人は実際にデータを使わない
- 整備人と開発のすり合わせが必要
- ダッシュボードが使われない
- データを見る習慣がない
- →思い切って潰した
- →数値を見る文化を作った
- 意図通りに使われないデータ
- Join不要のデータを作ったのに元データと再joinしたり
- アフターフォロー（改善を回す仕組みづくりは大事）
- データ抽出
- 分析という名のデータ抽出
- BIで簡単に見られうようにするべき
- サービス側でもデータ抽出できるようにすべき
- →Hiveの集計塾→課題を持ってきてもらって、一緒にやる
- データ整備だけでなく利用促進も考える
- データ整備にんだからできること
- みんなが積極的にやりたがらない
- データに困ったら必ず存在される存在に
- データ整備で価値を出すには
- とにかくいろんな部署と関わって、仕事を能動的に探しに行く
- 改善まで面倒を見る
- 整備したデータを用いて意思決定や改善につながるをゴールにする
- ログ管理の難しさ
まとめと感想
データ分析に関わり、しかも本テーマのタイトルでもあるデータアーキテクトの役割を担っている方々は、似たようなことを考えてるんだなあというのが話を聞きながら思った正直な感想です。
ただ、ゴールの設定として「意思決定の示唆を出すのか」と「そのさ先のPDCAサイクル（やデータを用いた事業まで）」面倒を見るのかで意見が分かれているなというのは書く発表を聞きながら感じました。このあたりは個々人の経験談によるところなのかもしれません。ちなみに私は事業会社のデータ分析者という立ち位置で、「意思決定に示唆を出すだけではだめ」（詳しくは紙面の都合で省略）と教わっていますし、それに納得して仕事をしています。
ちょっと不満だった点としては、発表者のみなさん喋りたいこと盛りだくさんでだいぶ時間オーバーしてたのと、「前向きに」と言いつつも結局つらみの共有になってた感が否めなかったことです。
全体的には楽しい勉強会でした。発表者の皆様、運営に関わった方々にお礼申し上げます。ありがとうございました。
