アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド - FL #81 に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第81回目では『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』を取り上げます。

データ基盤やデータエンジニアリングにかかわるすべての人必携の一冊である本書。

邦訳書を出版するにあたって、12件の国内事例も特別掲載されている本書のポイントを、訳者である 打出 紘基 氏, 佐々木 江亜 氏, 土川 稔生 氏, ゆずたそ 氏にお話していただきます。

会の様子

基調講演

書籍の概観を30分で紹介するというセッションでした。

最初に、書籍の主題として、最初にすべてを設計してデータウェアハウスを作るのではなくステークホルダーとコラボレーションしながらデータ要件をヒアリングして段階的に改善していくという話が書かれているということです。

書籍を読むときは、初心者の人は日本語オリジナルで記載されている事例紹介をまず読んでみるという話と、Howに関しては原著が2011年ということもあってちょっと古いという話がありました。

発表では一定テーマを絞るということで、まずディメンショナルモデリングの解説がありました。ディメンショナルモデリングはファクト×ディメンションで分析するもので、データ分析の要求に応える手法だということでした。

BEAM*は、本書独自で定義されている手法であり、Business Event, Analysis, Modeling、スタースキーマの頭文字を取ったものだということでした。
要件収集とモデリングを組み合わせることでモデルストーミング*1を行うことができ、これによってステークホルダーと共にデータモデリングができるということでした。

パネルディスカッション

基調講演の後は視聴者からの質問に答えるパネルディスカッションがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

社内のチームで読むときのおすすめの読み方は？

読書会を進めながら実務の進行をふりかえり、ディメンションモデリングをしてみる

各データに関して事前にテーブルまで作るメリットがあるのか？という葛藤にどう立ち向かうか？

葛藤があるならまだ作らないといいとは思う。実際にテーブル整理してみて、意外とやるメリットがあるかも？と思うことはある。

データアナリストがやるアジャイルデータモデリングの一歩は？

書籍の事例集を見てほしい。あとはビジネスメンバーと会話するというところからやってみるなど。

技術面以外ではアジャイルデータモデリングの組織に広めていく際にぶち当たりそうな壁やその乗り越え方は？

• 身も蓋もない話をすると、アジャイルデータモデリングを行うための工数を確保すること。そのために、ディメンショナルモデリングをしてどれくらいの人が必要か？を説明するなどが対策になる。
• 知識不足を補うために、フォーマットを作ったり本書の読書会をやったりするとかはある

BEAMテーブルや階層図、エンタープライズ・バスマトリックスなどはデータカタログツール等に保存されているのか？

今時点では保存できるほどでもないので、社内Wikiとかも使うようにしている。

データモデリングのプロジェクトマネジメントに関するTipsは？

データモデリングに特有ななにかはない気がする。大まかなテーマを決めてから細かいところをアラインしていくとか。

ディメンショナルモデリングをやるための知識を身につけてもらうためにおすすめの方法は？

ワイドテーブルを作るとかは事例集にあるのでそこを読んでもらうといいかもしれない。

アジャイルであることの意味があまりわからなかったのだがモデリングにおいて何が違うのか？

一般的なアジャイル開発をデータ基盤に適用するとどうなるか？という話になる。一般的なアジャイル開発についてはあまり詳しくないので踏み込まないが、細かくデリバリーすることがデータ基盤でもできるよということが書籍では書かれている。

レイク層、DWH層、マート層でディメンショナルモデリングを適用するのはどの層か？

DWH層で一旦適用するというとかがトレンドに近いと思う。

データマート作成に関して、社内開発向けのルールを定めているものや設計時のアイデアを知りたい

命名規則的なところなどをまとめている。詳細は風音屋標準と呼ばれるのがあるのだが今は非公開なので、いつかそういうナレッジもオープンにできるようにしたいと思っている。管理者を明確にするとかは気をつけている。

アドホックな分析をする際に今は生データを一からSQLで都度整形しているが、クエリ保存していてもまた別の分析が始まったときは使えず、1からSQLを書いている。この分析工数を改善する基盤構築はあるか？

まさに書籍を読んでほしいとは思う。SQLのレイヤリングをわけて処理を分割しておくとかは良いと思う。
分析工数を改善するのが基盤構築のメリットだと思うので、まさにやってみると良いと思う。

過去で一番苦労したことは？

• スタースキーマって半直感的なので、分割できちゃうから分割してしまい、第三正規系でもないしスタースキーマでもないというのが出てしまう
• レイヤリングの話がずっと繰り返されてしまうなど、Howに寄った議論だけが進んでしまう
• ダッシュボードを作り込みすぎて誰も使っていない(顧客の声を聞かずにどんどん使い込んでしまう)

会全体を通した感想

翻訳のみならず現代版に即した話をするための事例集をつけるだったりといった工夫をして、書籍を読んだ後になかなか現場への適応が難しいという問題に対処されているのはすごく良いなと思いました。

自分の職業的に、アジャイル開発への誤解がだいぶされていたところはひやひやしたのですが、一次情報にあたったうえで使われるデータ基盤を作ろうというコンセプトには共感しました。

*1:ビジネスイベントのモデリング→ディメンションのモデリング→イベントマトリックスに追加→バックログに追加の手順で進める