Zenn
🦁

読み合せ会「実践的データ基盤への処方箋」第一回

2022/01/21に公開
実践的データ基盤への処方箋
tech

概要

データ整備人としても大いに活躍されているゆずたそさんの著書「実践的データ基盤への処方箋」を部内にて「読み合せ会」をしましたので、記録していきたいと思います。
https://gihyo.jp/book/2021/978-4-297-12445-8

なぜ「輪読会」ではなく「読合せ会」か

学生時代に論文などの輪読会もやっており、一人一章を担当しそれを発表する・・・という形式でもやったことはあったのですが、
この方式だと発表者以外はちゃんと読まないなぁ・・・・（自分、担当箇所以外は読む真剣さが違うなぁ・・・）と漠然と思っていました。

そこで、
みんなで一緒に「読み合せ」したあとに、気になった部分をそれぞれが発表する
という形式でやってみたところ

  • 読む人によって着眼点が違う
  • エンジニア視点での見え方や解説などが聞ける
  • ビジ側の人のマネージメントや対クライアント、対エンジニアでの気をつけるところなどが聞ける
  • 実は、感想を言い合っている議論が一番勉強になる

という利点がありました。

読み合せ会の方法

  • ZOOMなどのオンライン形式で開催
  • 1-1を読む
  • その章で気になったところをMiroなどでそれぞれメモしておく　（GoogleSpreadSheetを使うでも良いでしょう）
  • 読み終わったら終わりましたという
  • 皆が読み終わったら、読み終わった順に、簡単に（一人1,2分）発表する
  • 着眼点や大切だと思うことはかぶるので、あとの人は、それまでの人以外の意見などを言う
  • そのときに、それぞれで意見を言い合う
  • 1-2にうつって、繰り返し

読み合せ会

はじめに

「はじめに」では、各メンバーの考えをほぼそのまま記載します。

  • データ基盤構築の意義は、これまで担当者の勘と経験でやってきたものを客観的に判断できるものにする　→　ただ、勘と経験を全否定するわけではなく、むしろそれを補強するものとして使うのが大事と思う。こうしないと無駄な対立が起きてしまう・・・

  • 属人性を廃して、"正しい"意思決定をする　→　「正しい」が難しいよね・・・

  • PoCならDSやDAだけでいいけど、継続的にするにはデータ基盤構築必要！

  • *データ集めればなんとかなる！*→失敗例

  • データがあるからこれからなにかできない？　→　失敗例

  • Tableauなどではまず「質問から始める」ってのがあるが、それが重要

  • データ構築のセオリーができてきた（レイク層、データウェアハウス層、マート層など）

  • データエンジニア、データスチュワード（データ責任者、データ整備・活用をサポート）、組織長の３つの役割分担が理想

  • 真のデータ活用とは一時的ではなく継続的に企業を支えること　→　とても共感！

  • データ基盤は作れても、ビジネス価値は創出できない　→　これについては試行錯誤中

  • データ基盤の作り方は周知されているが、活用方法は認知されていないのではないか

  • データ基盤の道具としてどの道具を使うのが良いだろうか？選ぶ基準は？

  • 基盤を関係者全員が活用する状態が理想だが、なかなか難しい

  • ビジネス案件の変化が早いので、継続的なカイゼンが必要と感じる

  • データ基盤は誰がなんのために使うか？というゴールありきで作る

  • データ基盤の「利用」という観点から、基盤の管理・運用をするデータエンジニアとは別にデータスチュワードが橋渡しをする必要あり

  • KTさんがsnowflakeの動画でお話ししていた「データをインフラとして日々業務で使う」という内容。電気や水道のように、安全に使えるのが当然になるように

  • データ基盤を整える道具や知識は揃ってきたが利便性やビジネスインパクトを与えられるとは言えない状況

  • データ基盤の知識・技術だけでなく、現場のノウハウやドメイン知識を掛け合わせた構築が必要（継続的な活用なども）

  • データ活用とは一時的ではない、継続的なもの

  • データを活用することで属人性を排除できる →　正しい意思決定につながる

  • データの持ち方は確立されているが、データの活用のさせ方が認知されていない　→　BI等を作るにしても、目的をもっと明確にしないと

1-1 データの一連の流れを把握し、入口から出口までを書き出す

※出た意見をある程度まとめています

  • 入口と出口を書き出すとなんのデータが必要・足りないかが明確になる
  • データ領域の発展が日進月歩なので、用語が揺らいでいる　→　チーム内でもしっかり共通認識を作るの大事
  • データ基盤に関する用語は、一般的なものでも案件によって定義や認識が異なることがあるので内容が明白でも具体的に記載して整理することが重要(特にビジネスメンバーが絡む案件になるとより丁寧に行う必要がある業務だと思いました)
  • 分かりやすいこと（細かく分けること）とシンプルにする（単純にする）ことのバランスってどう考えたら良いか（本書では細かく区切るような文脈で書かれているが）
  • メタデータの定義がいまいち人によって違う気がして理解できてない（本質は何か）、正解がよくわからない
  • CRUD図は大切、ER図と合わせるとさらに効果的

データの品質は生成元のデータで担保する

※出た意見をある程度まとめています

  • どのデータを取得するべきか、検討段階で関係者全員で話せるといいかも？手戻りを未然に防ぐ
  • データソースの種類・品質は継続的に改善。データウエアハウス層などでは修正したりはしないようにする、大元で！
  • 業務レイヤーのところまで、データの人がやるべきことだろうか・・・と疑問に思った。PMやコンサル業務の領域かなという気もした（もちろん、データ関連の人も入るべきだろうが）
  • データ活用者 vs データ生成者　の対立は起きるよねー（実際起きてる、データほしい！　くれ！　→　めんどくさい、余計な仕事増やすな！　的な）
  • データソースは上流、下流でカバーするとより労力がかかる（クライアント（データ生成者）とのコミュニケーション大事、データ構築者の意見）　また、下流から上流へのフィードバックができるように仕組み化しておいたほうがいい
  • ユースケースとデータソースを踏まえて品質を担保するために、「高い品質」を定義するのが難しい

シリーズ

なぜ読み合せ会？という形式をとって開催しているか？も記載してます。

Discussion