データアーキテクト(データ整備人)の概観とこれからの展望と課題 / maemuki_data_seibinin01

29e4aa4e265e478995df09ca52d62103?s=47 ShinU
November 27, 2019

データアーキテクト(データ整備人)の概観とこれからの展望と課題 / maemuki_data_seibinin01

グループのメンバーになっていただくと新しいイベントが公開された際にご連絡が行きます(登録無料)
https://analytics-and-intelligence.connpass.com/

しんゆう@データ分析とインテリジェンス
ブログ :https://analytics-and-intelligence.net/
Twitter:https://twitter.com/data_analyst_

29e4aa4e265e478995df09ca52d62103?s=128

ShinU

November 27, 2019
Tweet

Transcript

  1. データアーキテクト(データ整備人)の概観 とこれからの展望と課題 しんゆう@データ分析とインテリジェンス 2019/11/27 データアーキテクト(データ整備人)を ”前向きに”考える会

  2. データアーキテクト(データ整備人)の概観 とこれからの展望と課題 しんゆう@データ分析とインテリジェンス 2019/11/27 データアーキテクト(データ整備人)を ”前向きに”考える会

  3. • 本日の資料は https://speakerdeck.com/shinu/maemuki-data-seibinin01 に公開済み。ブログ・Twitterからもリンクあり • 〇 SNSで話題にすること • × 写真撮影

    資料・SNS・写真撮影などについて
  4. • 本資料を読むにあたり特に注意してほしいこと • 本資料の作成者は、資料の中で提唱する「データアーキテ クト(データ整備人)」を業務で行ったり案件の提案に使 っており役割が認知され評価されることへの直接の利害関 係者である • 従って、中立性はできる限り保持するよう考察し、資料を 作成してはいるものの、どこかにバイアスが残っている

    (ポジショントークになっている)可能性は捨てきれない ことは留意すること 前置きのさらに前置き
  5. • エンジニアとアナリストの間には、データを抽出したりそ のためにデータを整理したりする仕事がある • この「誰かがやらないと他の誰かが困るのに誰もやりたが らない役割」については名前すらなく、何となく誰かがや っているが、それでは良くないと考えた • 今回はこの役割をまずはきちんと整理し、概要をまとめる ことを試みるのが中心

    • スキルとかノウハウとかキャリアとかまでは話す時間がな いので最後におまけとして追加しておく 前置き
  6. • データの流れと役割分担 • エンジニアとアナリストの間にある役割 • その役割は誰がやるのがいいのか? • 主張:別の役割として認識するべき • 役割の名称について

    • 一言で表現すると • もしデータアーキテクト(データ整備人)が完璧に機能したら • うまくミッションを遂行するために考えないといけないテーマ • 将来に向けて考えるべきこと • まとめ & 宣伝 & おまけ & 参考URL 目次
  7. 自己紹介

  8. • しんゆう( Twitter : @data_analyst_ ) • ブログ「データ分析とインテリジェンス」を書いてる人 https://analytics-and-intelligence.net/ •

    仕事でやりたいこと:意思決定のための情報分析をする人 • 仕事でやってること:データをうまく使えるようにする人 自己紹介
  9. データの流れと役割分担

  10. データレイク データウェアハウス データマート データはどこにある? • 企業によって違いは当然あるが、 概ねこの3つにまとめられる データの流れ データの流れと役割分担

  11. データレイク データウェアハウス データマート 集計 分析 データの流れ 前後の流れを考える • さらに前後を考えると、データ レイクまでの流れと、データマ

    ートから先への流れがある データの流れと役割分担
  12. データレイク データウェアハウス データマート 集計 分析 マーケターなど データの流れ 集計されてもまだデータ • 集計されたデータはマーケター

    などの非分析者に渡り、そこで 分析される データの流れと役割分担
  13. データレイク データウェアハウス データマート 集計 分析 意思決定者 マーケターなど データの流れ 分析結果の流れ 分析は意思決定者へ

    • 最後にデータは分析・洞察を経 て意思決定者に渡らないと意味 をなさない データの流れと役割分担
  14. データの流れと役割分担 • ちょっと補足 • 「分析結果」というのは「インテリジェンス」のこと。つ まり「意思決定のために分析・洞察された情報・データ」 • DWHやデータマートは存在しない場合もある • マーケターなど(コンサル・企画・営業とか)と意思決定

    者は同じであることもよくある
  15. データレイク データウェアハウス データマート データの流れと役割分担 集計 分析 意思決定者 マーケターなど 誰がどこを担っているのか •

    どういった職名の人がどのあた りを担当しているのかを見てみ る
  16. データレイク データウェアハウス データマート データの流れと役割分担 集計 分析 マーケターなど データエンジニア • 様々なデータを集めてデータレ

    イクに入れる人(あんまりいな いので別のエンジニアが兼任) • ログ、バッチ処理、ETL 意思決定者
  17. データレイク データウェアハウス データマート データの流れと役割分担 集計 分析 マーケターなど データアナリスト • データから次に何が起きるかを

    分析・予測しようとする人 • モデリング、洞察 意思決定者
  18. データレイク データウェアハウス データマート データの流れと役割分担 集計 分析 マーケターなど ???????? • エンジニアとアナリストの間に

    あるこのあたりの役割をしてい る人には名前が無い • そもそも何をしているのか? 意思決定者
  19. エンジニアとアナリストの間にある役割

  20. データレイク データウェアハウス データマート エンジニアとアナリストの間にある役割 集計 分析 マーケターなど どんな役割があるのか • エンジニアとアナリストの間

    にはどういった役割があるの かをまず考えてみる 意思決定者
  21. データレイク データウェアハウス データマート 集計 分析 マーケターなど 1.抽出 • 分析が主業務でない人達からの 依頼を受けてデータを抽出

    • アウトプットはExcel・CSV・ ダッシュボード(可視化) 意思決定者 1 エンジニアとアナリストの間にある役割
  22. データレイク データウェアハウス データマート 集計 分析 マーケターなど 2.整理 • 集められたデータはそのままだ とまず使えないので整理が必要

    • DWHやマートの設計や作成・ イレギュラーなデータへの対応 意思決定者 2 エンジニアとアナリストの間にある役割
  23. データレイク データウェアハウス データマート 集計 分析 マーケターなど 3.管理 • 仕様変更への対応、おかしなデ ータが無いかを監視、入ってき

    た場合へのリカバリー • 正確性の担保 意思決定者 3 エンジニアとアナリストの間にある役割
  24. その役割は誰がやるのがいいのか?

  25. データレイク データウェアハウス データマート その役割は誰がやるのがいいのか? 集計 分析 マーケターなど 現状はどうなっているのか • 現状このあたりの役割を誰が担

    っているのか様子を見てみると 意思決定者
  26. データレイク データウェアハウス データマート 集計 分析 マーケターなど よく見聞きするケース1 • データエンジニアが(他に誰も できないので)やっている

    • 特に抽出でコミュニケーション ギャップが発生 意思決定者 その役割は誰がやるのがいいのか?
  27. データレイク データウェアハウス データマート 集計 分析 マーケターなど 意思決定者 よく見聞きするケース2 • データアナリストが(やらない

    と仕事にならないので)やって いる • 分析できずに整理と抽出ばかり。 管理は手が付かない その役割は誰がやるのがいいのか?
  28. データレイク データウェアハウス データマート 集計 分析 意思決定者 マーケターなど よく見聞きするケース3 • エンジニアもアナリストもいな

    いので非分析者がやるしかない • 簡単なことでも無駄に時間を取 られたり、整備されていないと そもそもできない その役割は誰がやるのがいいのか?
  29. データレイク データウェアハウス データマート 集計 分析 意思決定者 マーケターなど ちょっとわかりづらい・・・? • これだけだと抽象的なので、料

    理に例えてみる その役割は誰がやるのがいいのか?
  30. 市場 倉庫 加工工場 小売業 レストラン 消費者 一般家庭 料理に例えてみるとこんな感じ • 野菜であれば加工工場を通さな

    いこともあるし、シェフが直接 市場に行くこともあるが概ねこ んな感じになりそう その役割は誰がやるのがいいのか?
  31. 市場 倉庫 加工工場 小売業 レストラン 消費者 一般家庭 データエンジニアがやるべき? • データエンジニアが加工までや

    るのは生産者としての農家や漁 師が加工して自分で売るみたい なもの その役割は誰がやるのがいいのか?
  32. 市場 倉庫 加工工場 小売業 レストラン 消費者 一般家庭 データアナリストがやるべき? • データアナリストが抽出したり

    整理したりするのはレストラン が他の店や消費者のための加工 工場を経営して料理人をそこで 使うようなこと その役割は誰がやるのがいいのか?
  33. 市場 倉庫 加工工場 小売業 レストラン 消費者 一般家庭 マーケターなどがやるべき? • マーケターなどが抽出しようと

    するのは自宅で使うために自分 で店を経営するようなものだし 整理は無理 その役割は誰がやるのがいいのか?
  34. データレイク データウェアハウス データマート 集計 分析 マーケターなど どれか1つを選べと言われても • やはりどれもあるべき姿として は違うような気がする

    意思決定者 その役割は誰がやるのがいいのか?
  35. 主張:別の役割として認識するべき

  36. • この役割はある程度の技術は必要だが何かを作るよりはう まく組み合わせて技術を使う側なのでエンジニアとは違う • 一方で分析の経験がないと利用者とのコミュニケーション、 特に提案することが難しくなるが、分析するわけではない • 営業と総務を兼任している人が自然な状態であるとはだれ も認識しないのと同じように、この役割を兼務しているの は不自然な状態なのではないか

    主張:別の役割として認識するべき
  37. • 被るところは多くあれど、エンジニアともアナリストとも スキルも違うし片手間で出来る分量ではないのでやはり別 の役割であると認識するべきでは • 当然企業の規模や状況によっては複数の役割を兼務するこ とは当然あるし、明確な線引きもできないがエンジニアや アナリストと一体化させるのも無理がある 主張:別の役割として認識するべき

  38. 役割の名称について

  39. • 「この役割」とかではどうにも説明しづらいので名前を付 けようと考えた • そこでとりあえず「データ整備人(仮)」としてブログに 記事を書いたところ、バズる • しかし整備だけでは済まないのとこれだと雑用っぽい気が して「データアーキテクト」を考えたがいまいち浸透して ない気がする&整備人の方がわかりやすい

    • アンケート取ってどちらがいいか聞いてみよう! 役割の名称について
  40. 役割の名称について

  41. • まさかの同率でさらに悩む • しょうがないので当面はデータアーキテクト(データ整備 人)と両方併記 • あとは成り行きに任せる 役割の名称について

  42. 一言で表現すると

  43. データレイク データウェアハウス データマート 一言で表現すると 集計 分析 意思決定者 マーケターなど もっとわかりやすい説明が欲しい •

    直接関わっていない人にも伝わ りやすいようにそれぞれの役割 をごく簡潔に表現してみる
  44. データレイク データウェアハウス データマート 集計 分析 マーケターなど データエンジニアとは • 「データを集める人」 意思決定者

    一言で表現すると
  45. データレイク データウェアハウス データマート 集計 分析 マーケターなど データアナリストとは • 「データを扱う人」と表現する ならば

    意思決定者 一言で表現すると
  46. データレイク データウェアハウス データマート 集計 分析 マーケターなど データアーキテクト(データ整備 人)とは • 「データを使いやすくする人」

    と言えるだろう 意思決定者 一言で表現すると
  47. もしデータアーキテクト(データ整備人)が 完璧に機能したら

  48. • ここまででデータアーキテクト(データ整備人)の役割に ついては一通り(具体性は欠きつつも)整理した • しかしこれだけでは単に区別をしただけであえて役割とし てわざわざ作るメリットがあるかは見えにくい • では、もしこの役割が存在して完璧に機能したらどうなる のだろうか? もしもこの役割が完璧に機能したら

  49. • あらゆる人が望んだデータを望む形で望んだ時に簡単に得 られるし、困った時にもすぐ相談することが出来る • データは常に最新かつ正確に整えられている • 欠損や重複などが起きたら即座に事象を捉えあるべき形に 修正される • 求人募集にはデータエンジニア・データアーキテクト(デ

    ータ整備人)・データアナリストがどれぐらいの割合で求 められるかが書かれて名前と実態の乖離が少なくなる もしもこの役割が完璧に機能したら
  50. うまくミッションを遂行するために 考えないといけないテーマ

  51. • つまり「データを使いやすくする人」である「データアー キテクト(データ整備人)」のミッションを定義するなら ば • 「次にデータを使う人が速やかに業務を遂行できるように 事前に対策を行うこと」ということになるだろう • ではミッションを遂行するためには何が必要か ミッションを遂行するために必要なこと

  52. • どのようなスキルセットがあるとうまくやれるか • 成功失敗のノウハウは何か • どのようなキャリアに繋がるのか • 上司や外部へのアピールをどうやればいいのか • 組織の中での立ち回り方

    • といったことを自分の経験や妄想でまとめてみた ミッションを遂行するために必要なこと
  53. • どのようなスキルセットがあるとうまくやれるか • 成功失敗のノウハウは何か • どのようなキャリアに繋がるのか • 上司や外部へのアピールをどうやればいいのか • 組織の中での立ち回り方

    • といったことを自分の経験や妄想でまとめてみたが、話す 時間がないので最後におまけとして追加しておく ミッションを遂行するために必要なこと
  54. 将来に向けて考えるべきこと

  55. • 概要や何をしているかは整理してみたが、では実際にこの 役割分担にどう取り掛かるか • 新人やオペレーターレベルに任せてもダメのは経験済み • データアナリストやデータエンジニアからシフトさせるの は本人が納得するか? • たまにいる偶然はまる人を期待するだけでは心もとない

    • 最初から前提にするのは現状ではキャリアが不透明で誰に とってもリスク要因 将来に向けて考えるべきこと
  56. • さしあたりはエンジニアとアナリストの間でできる人がい いように案分する形が増え続けるのだろう • しかし、企業がきちんと評価しないと押し付け合いになっ たり外部に丸投げするなどして今と変わらないままになる • 現場だけでなく経営者やマネージャーを交えてどうあるべ きかを考えていくことが必要 将来に向けて考えるべきこと

  57. • より根本的には、もしかしたら本当に雑用に過ぎないので 今でも役割そのものがいらないのかもしれない • 今は必要だったとしても今後民主化(というか自動化)が 進んで抽出や整備への負担が大きく減るなら別の役割の1 部分として吸収するほうがよいのかも • もし必要ないとなったらどうするかは常に考えておく •

    役割として認識することが自分への利益に繋がる人はバイ アスに気を付けよう(自戒) 将来に向けて考えるべきこと
  58. まとめ

  59. • エンジニアとアナリストの間にある「データアーキテクト (データ整備人)」についてどういった役割なのかをまと め、それは1つの役割として認識するべきだという主張を 行った • データの活用自体が広まったのはこの数年でありとにかく 「使う」ことから「よりうまく使う」ためにどうするかの 動きはこれからが本番 •

    名前も守備範囲も変わるかもしれないが、その仕事は消え ることは無いので準備しておこう まとめ
  60. 宣伝

  61. • データアーキテクト(データ整備人)について興味のある 企業での講演・意見交換会を開催します • 基本は講演(30分)+意見交換会 • 無料、地方対応可(交通費のみお願いします) • 高層階不可(ごめんなさい) •

    詳しいことはお問合せください こんな人や企業を募集中
  62. • データアーキテクト(データ整備人)について“前向きに” 考える会は今後も継続していきたい • こんな話がしたい、5分とかのLTならやってみたい人 • あんなテーマでやって欲しいというリクエスト • 場所貸すよ&スポンサーやるよという企業 •

    DMでもメールでもお気軽にご連絡ください こんな人や企業を募集中
  63. ご清聴ありがとうございました しんゆう@データ分析とインテリジェンス https://analytics-and-intelligence.net/ Twitter:@data_analyst_

  64. おまけ

  65. うまくミッションを遂行するために 考えないといけないテーマ

  66. • どのようなスキルセットがあるとうまくやれるか • 成功失敗のノウハウは何か • どのようなキャリアに繋がるのか • 上司や外部へのアピールをどうやればいいのか • 組織の中での立ち回り方

    • などいろいろ考えないといけないことはあるので自分の経 験&思いついたことを書けるだけ書いておく (言い訳)今回のテーマは概観なので、ここにはあまり時間がさけなかった分は今後のブログ記事とかでちゃんと書きます 考えないといけないテーマ
  67. どのようなスキルがあるとうまくやれるか

  68. • 技術はなんといってもSQL。ただしSQLそのものは難易度 はさほど高くなく、いかにうまく組み合わせるか • Excelも何かと必要。自社では使わなくても外部からのデー タは・・・ • 各社で使っているそれぞれの環境についての理解。基盤、 ETL、DWH、BIなど •

    その中でもやはり特に重要なのはデータそのもの。くせや 例外の把握 どのようなスキルがあるとうまくやれるか
  69. • 抽出は本当に社内外のあちこちの部署の様々レベルの人か ら多種多様な依頼があるのでそれをうまくさばけないとす ぐに仕事が滞る • 依頼通りにデータを返すだけなら難易度はかなり下がるの で、依頼を鵜呑みにせず整理してより良いアウトプットを 返す提案をできるかどうかが差別化の鍵 • 他にもコードをうまく書く、優先順位の調整、先回りして

    手戻りを減らすなど どのようなスキルがあるとうまくやれるか
  70. どのようなスキルがあるとうまくやれるか • 次に使う人のためなので当然次の人の業務が理解できない と良いアウトプットを作るのは難しい • 当人すら何をどうしたらいいのかわかっていないことも 多々あるので何を知りたいのか、何がしたいかを引き出す ためには依頼者以上に分析に知見があるとなお良い

  71. • 整理もこの後誰がどう使うかが想像できないと一見すると 整っているが実務に使えないということが起きる • システムエラー、新機能実装、新しいページ追加とデータ がおかしくなる要因は数多いため、エラーを早期に察知し て対応することが求められる • 一方ありとあらゆることに対応することもできないので、 どこをやらないかを考えることも重要

    • この時実際の利用者とはもちろん実現可能性をエンジニア にも説明や交渉が必要になる どのようなスキルがあるとうまくやれるか
  72. • 管理はさらに事前にエラーそのものを極力減らすために対 策を考える • データべースにあるデジタルデータだけではなくありとあ らゆる調査、論文、非デジタルなども全て「データ」であ り対象に含まれる(将来は) • 特に管理は権限が無いと厳しくなるので組織として守って もらう必要性の認識

    どのようなスキルがあるとうまくやれるか
  73. 成功失敗のノウハウは何か

  74. • SQLそのものではなくいかにうまく組み合わせて使うかが 求められる。SQLの入門書だけでは身につかないのでいろ いろなパターンの経験を積む • 例えば抽出の依頼も依頼内容をそのまま抽出だけでも仕事 にはなるだろうが、本当は何がやりたいのか聞聞き出して 適切なアウトプットを提案できるようになれる • 知識は深さよりも広さの方が多分有効

    成功失敗のノウハウは何か
  75. どのようなキャリアに繋がるのか

  76. • 役割そのものがまだあいまいとしているので長期的にはど うなるかは見通しがたっていない • データアーキテクト(データ整備人)の認識が無いのでデ ータエンジニアかデータアナリストなどとりあえずできる 人が間を埋めている状態であるが、それらのキャリアもま だ不透明 • データマネジメント、セキュリティ、法務といった分野と

    合わせて企業におけるデータを統括するポジションへのル ートはありえるかも どのようなキャリアに繋がるのか
  77. • 規模が大きい、サービスの種類がたくさんある企業であれ ば仕事はいくらでも発生する反面、そうでない企業ではや ることがすぐに頭打ちになる可能性もある • 抽出とデータアナリストやマーケターなど、整備や管理と データマネジメントの組み合わせは視野に入れておく • かなりポータブルな技能ではあるので、データ整備の専門 家としてのコンサルタント・実務家として動きやすいかも

    しれない どのようなキャリアに繋がるのか
  78. 上司や外部へのアピールをどうやればいいのか

  79. 上司や外部へのアピールをどうやればいいのか • 何をしている人かわからないから脱却するためにまずは言 語化して概要を説明する、が第一歩でそれはこの資料であ る程度できた? • と言いたいところだがまだ現場向けで外向けの説明には冗 長すぎるのでもっと簡潔にしないといけない • データに関わっている人が圧倒的に少ないので概要が伝わ

    らないとアピールも何もできない • 実務経験者から経営者やマネージャーになった人には伝わ りやすいと思うのでまずはそこから?
  80. 組織の中での立ち回り方

  81. • 最初は何でもやりますでいいかもしれない • ただし度が過ぎるとそれこそ雑用になる • 個人的関係で解決させるのではなく、組織としての取り決 めで誰がどこまでやるかを決めた方がいい • 特に管理は何の権限もないといくら仕組みを作っても各部 署各人が勝手に動くのを止められないので会社全体の問題

    として捉えてもらう必要がある(が、そのためのアピール はどうしたらいいのか?) 組織の中での立ち回り方
  82. 参考URL

  83. • 本資料の話の基になったブログの記事を紹介しておく。資 料に書いていない話などもあるので参考にどうぞ • 「データ整備人(仮)」という、「データベースからSQLを書いて抽出する」という仕事 についての考察というか「なにこれ?」という話 https://analytics-and-intelligence.net/archives/5826 • 続・「データ整備人(仮)」という「関わっている人が多くて、誰かがやらないといけな いということは共通認識だけれども名前すらない役割」に関する雑多な話

    https://analytics-and-intelligence.net/archives/5879 • エンジニアとアナリストの間で兵站を担う「データアーキテクト」は1つの役割として確 立しておいた方が良いと思うので整理してみた https://analytics-and-intelligence.net/archives/6009 参考URL