今日は 「データアーキテクト（データ整備人）を”前向きに”考える会」に参加してきました。
analytics-and-intelligence.connpass.com
レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。
今日のテーマ
以下はイベント詳細より。
データを整備・抽出・加工したりダッシュボード作ったりとエンジニアとアナリストの間にある「誰かがやらないと別の誰かが困るのに、なぜか誰もやりたがらない役割」であるデータアーキテクト（データ整備人）のスキル・ノウハウ・キャリアなどについて、恨みつらみではなく”前向き”に考えようという会です。
参加者であるわたしの状態
ほぼはじめてデータ分析に関わる勉強会に参加しました。 カスタマーサクセス話題だと10のうち6とか7くらいについてはわかった状態で、残りの特有の話題について新しく知見を得る、という感じですが、データ分析まわりについては10のうち、1とか2とかの理解で、基本的な文脈についても憶測して補いつつ、新しい文脈についても知る、という感じで、なかなか難易度が高かった……
なので今回はレポートという感じではないかも...？ 念のため、これを読む方が、余計な情報に触れないように、わたしがどういう人で、どういう視点で聞いた話かを書いておきます。
- わたしはBtoBのSaaSプロダクトのカスタマーサクセス的立場（職種名はCRE
- カスタマーサクセス方面の関心でデータを触っている
- データ分析については初級本を1冊読んだ
- SQLの本、pandasの本を最近2,3冊必要に応じてペラペラ読んでみている
- もともとは、SQLは書いたことある。むかしOracleの資格とった。けど、業務で触ったことなかった
- 最近会社でデータ分析の勉強会なども開催されていていろんな話題に触れつつある
- チームメンバーと言葉を合わせたい、課題感を共有したい、自走できるレベルを上げたい、というようなモチベーションで参加
登壇者の方々は以下。みなさん資料がしっかりしていて、レポートを書かずとも、資料を見たらよい！という感じでした。すごい…
お話を聞くのに必死でほとんどメモれなかったので以下は資料リンク一式と本当にわたしが気になったぽちぽち書いたキーワートやぼやきだけです…基本的には資料読み込まれることがおすすめ。
本編
しんゆうさん データアーキテクト（データ整備人）の概観とこれからの展望と課題
- データエンジニアという職種で働いている人は少なくて、多くは何かのエンジニアが兼務している
- データを集めるところからデータを扱うところまでの間にある仕事＝データアーキテクト（データ整備人）
- データ整備人に向いている人
- エンジニアは何かを作る人、なので、エンジニアではないけど、エンジニアリングのスキルもゼロではないし
- 一方、分析の経験がないと利用者とのコミュニケーション、提案が難しくなる
- 企業がデータを扱い始めたのは2010年代ころ
非分析者・分析者という区分けはじめて聞ききました。 データ整備人は...スキルセットを定義するのが難しそう。 アプリケーションについてもまあまあ知っていて、ビジネスについてもまあまあ知っている必要もあるし、コミュニケーション能力が必要そう（わたしのことでは！？ あとは、無料で講演に来てくれるらしい。来て欲しい！！
ゆずたそさん 【永久保存版】3社の事例から学ぶ！現場で使われるダッシュボードの作り方
- コミュニケーション重要
- PDCAで何度か微調整を重ねて業務で使われるようにしている
- 5W1H（データを扱う人や目的）とPDCAが大事
- botつかって業務の中で自然と必ずPDCAに触れる機会をつくっている（天才では
- アジェンダにPDCAが回る項目を追加している
shinaro iwaiさん データ整備業でぶつかった5つの課題・データ整備人に求められる3つのスキル
- Google Colaboratory
- ipynb
- SQLを再利用可能な状態にしておく。パラメーター変えるだけでSQLわからなくても叩けるようにしておく
- こういう工夫で営業の人にやってもらえるようにする
CREATE TEMP FUNCTION使って冒頭に書いて修正箇所が見つけやすくする
- クエリレシピ をまとめている（私もまとめたい。今雑に書いているけどフォーマットつくろうかな
- データ整備は組織として専任がいるわけではない
- データを2つの形式にまとめられるのではという仮説を持っている
- 行動分析
- ユーザー分析
堀野将晴さん サイエンス視点からのデータアーキテクト
www.slideshare.net
- データ活用部門が3つ
- サービスサイド
- サイエンス
- データ活用推進する部隊
- サイエンスのためにデータを使う
- データ活用とサイエンスの違い
- コミュニケーションは重要
- HiveQL
すでにこの時点で知見で頭の中がいっぱいでメモも少なめですみません。また、あとでゆっくり復習しよう......
理解まとめと感想
理解まとめ
- データエンジニア、アナリティスト、サイエンティストが抱える狭間の課題がある
- それを解決する人に名前をつけるならデータアーキテクト（データ整備人）
- この課題を解決するための課題
- 誰かがやらないといけないけどやる人が決まってない、誰かがまとめてやっている
- エンジニアスキルもヒューマンスキルも必要な立派な仕事だけど評価する仕組みがない
- リソースが足りない......etc
- データが求められる場面
- サービスや業務のKPI
- プロダクトサイドの改善
- データに触る2つのやり方（わたしの理解
- データ活用ぽいところ
- 今までいろいろなところにころがっていてすぐに使えなかったデータを使えるようにして集計などを簡単にする
- データサイエンス
- サイエンスの力を借りて課題に対して新しい切り口を見出す（これはわたしはまだまだわからない
- データ活用ぽいところ
- 関連しがちな部署など
- 事業責任者や企画をしているひと
- プロダクトを改善したい人
- 広告収入をあげたい人
- 日々の自分の業務を改善したい人
- 本質的にはいろんな人がデータを見てそれぞれのKPIに沿って活用して課題解決できる
- ただ、KPIの建てつけによって必要なデータや形式は変わる
- だからデータ整備人は、いろいろなロールの人の意見を聞いて適切に深掘りしたり優先度づけしてデータを整備する必要がある（高スキル！！
- 大事なこととして言われてたこと改めてまとめ
文脈関係なく疑問におもったこと
- いろんな人からいろんな方面で課題が集まるというコメントが多かったけど、そもそもデータ分析にとってよい課題の立て方、よい問題文の書き方、課題の絞り方ってどうやってやるの
- データアナリティクスについてかじりたい場合は何からはじめたらいいの。今やってるpandas練習がそれか？
明日すぐやってみたいこと
- データ活用の 5W1H はすぐ考える！
- ゆずたそさんの資料見る。
レポートは以上です。 はあ〜〜まだまだレベルアップしないといけないことが山積みですね。
