データ分析基盤の要件分析の話（202201_JEDAI）

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 Copyright © GeoLogic, Inc. All Rights Reserved. Copyright © GeoLogic, Inc. All Rights Reserved. 藪本晃輔 , Kosuke Yabumoto, @yabooun – 2009年3月　豊田工業高等専門学校卒業 – 同3月　京セラコミュニケーションシステム株式会社へ新卒入社  DSP（広告配信プラットフォーム）等の新規事業開発に従事 – 2014年4月　株式会社CyberZへ入社  広告計測ツールF.O.Xをはじめ、DMPやMarketing Automation、媒体収益化等、インターネット広告関連の開発に従事  – 2017年10月　株式会社ジオロジックに入社  位置情報広告の開発に従事  – 2019年8月　同社CTOに就任  藪本晃輔 Kosuke Yabumoto 略歴 Self Introduction  Tech 株式会社ジオロジック CTO  Hobby 登山  ピアノ  日本酒  家庭菜園  Position Data Engineering  Backend (Scala, Java)  Infrastructure (AWS)  Books サークル：エンジニア登山部 

Slide 3

Slide 3 text

3 Copyright © GeoLogic, Inc. All Rights Reserved. 低コスト、かつかんたん・シンプルな設定で、店舗周辺に「今いる人」「住んでいる人」「過去に訪問した人」のスマートフォンへ、チラシ配りの感覚で広告配信ができるサービスです。 GeoLogic Adとは？広告広告広告広告広告広告広告広告 STEP１ STEP２ STEP３商圏・ターゲットを設定広告を配信クリックして御社サイトへここで課金 Your Shop 過去に訪問した人にも近くに住んでいる人にも今、近くにいる人にも ● サービスイメージ ● かんたん・シンプルな３ステップ GeoLogic Ad 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 Copyright © GeoLogic, Inc. All Rights Reserved. - とりあえずデータがあるけど、どう使ったらよいかわからない - データカタログが整備できていない - データストラテジスト/エバンジェリストがいない - データを扱うシステムの目的が不明瞭 - 必要なデータにアクセスができない / 見えちゃいけなそうなデータが見えてしまう - データガバナンスが効いていない - データを扱うシステムの目的が不明瞭 - データはあるけど品質が悪くて使えない - ゴミデータが多い - 頻度が不適切 - データへの期待値が高すぎた - データの扱い方が想定できていない - データを扱うシステムの目的が不明瞭データがちゃんと使えない理由 

Slide 6

Slide 6 text

6 Copyright © GeoLogic, Inc. All Rights Reserved. - とりあえずデータがあるけど、どう使ったらよいかわからない - データカタログが整備できていない　→ Unity Catalog - データストラテジスト/エバンジェリストがいない - データを扱うシステムの目的が不明瞭 - 必要なデータにアクセスができない / 見えちゃいけなそうなデータが見えてしまう - データガバナンスが効いていない　→ Unity Catalog / Data Lineage / Masking - データを扱うシステムの目的が不明瞭 - データはあるけど品質が悪くて使えない - ゴミデータが多い　→ Unity Catalog / Data Cleansing - 頻度が不適切　→ Delta Live Table - データへの期待値が高すぎた - データの扱い方が想定できていない - データを扱うシステムの目的が不明瞭ある程度はテクノロジーで解決可能 

Slide 7

Slide 7 text

7 Copyright © GeoLogic, Inc. All Rights Reserved. - とりあえずデータがあるけど、どう使ったらよいかわからない - データカタログが整備できていない - データストラテジスト/エバンジェリストがいない - データを扱うシステムの目的が不明瞭 - 必要なデータにアクセスができない / 見えちゃいけなそうなデータが見えてしまう - データガバナンスが効いていない - データを扱うシステムの目的が不明瞭 - データはあるけど品質が悪くて使えない - ゴミデータが多い - 頻度が不適切 - データへの期待値が高すぎた - データの扱い方が想定できていない - データを扱うシステムの目的が不明瞭しかし目的が不足すると全てが壊れる 

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 Copyright © GeoLogic, Inc. All Rights Reserved. - 可視化方法、運用方法まである程度のイメージがある - 分析できそうなデータはあるが、まだ分析方法、運用方法が定まっていない - やりたいことは決まっているが、まだデータが揃っていない - データを上手く使って経営/営業/・・を改善したい - データビジネスをうまくやって儲けたい現実見込期待データへの期待値 

Slide 10

Slide 10 text

10 Copyright © GeoLogic, Inc. All Rights Reserved. - 可視化方法、運用方法まである程度のイメージがある - データとユースケースが定義できる - 分析できそうなデータはあるが、まだ分析方法、運用方法が定まっていない - データのみ定義できる - データを上手く使って経営/営業/・・を改善したい - データビジネスをうまくやって儲けたい - データもユースケースも定義できない現実見込期待データへの期待と現実 

Slide 11

Slide 11 text

11 Copyright © GeoLogic, Inc. All Rights Reserved. - 可視化方法、運用方法まである程度のイメージがある - データとユースケースが定義できる - 分析できそうなデータはあるが、まだ分析方法、運用方法が定まっていない - データのみ定義できる - データを上手く使って経営/営業/・・を改善したい - データビジネスをうまくやって儲けたい - データもユースケースも定義できない現実見込期待データ分析基盤の要件分析一般的な要件分析データへの期待と現実 

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 Copyright © GeoLogic, Inc. All Rights Reserved. - 誰が（ロール/アクター） - どんなデータに - どのようにアクセスできるか目的 - データ分析基盤そのものを表す - 新しいデータ種別を扱う際に更新する - ビジネスコンテキスト図と比べて更新頻度は低くなるはず - ロールという概念を早期に、明確に定義しておくことで権限設定の指針となる - 見てはいけないデータへのアクセスが発生する時に分離 - クライアントが、自分の広告配信結果はみたいが、全ての広告配信結果を見てはいけない - ロールとデータの間にツールが存在する - データソースとデータの間にデータパイプラインが必要になるデータコンテキスト/ガバナンス図 

Slide 16

Slide 16 text

16 Copyright © GeoLogic, Inc. All Rights Reserved. コンテキストモデルデータガバナンス図ビジネスコンテキスト図ユースケースデータ ● ３つの図は接続可能であり、相互にチェック可能 ● データガバナンス図、ビジネスコンテキスト図に、システムコンテキスト図にあるアクター /システム/データが全て登場しているか ● ビジネスコンテキスト図での使われ方は、システムコンテキスト図の目的に合致しているか ● データガバナンス図は、ビジネスコンテキスト図のユースケースを網羅できるか ● ビジネスコンテキスト図でのユースケースは、データガバナンス図に照らし合わせると実現可能かこういったことをシステマチックにチェックしながら要件分析の精度を上げていく３つの図を重ねてチェックする  目的

Slide 17

Slide 17 text

17 Copyright © GeoLogic, Inc. All Rights Reserved. ● まず、システムコンテキスト図に登場する人たちとしっかり認識を合わせる ○ これが期待値コントロールになる ● これらの図は非常に抽象度が高いので、順番に具体化し、開発を進めていく ○ 具体的なユースケース ■ 売上ダッシュボード→アタックリスト管理/受注ステータスリスト管理 /・・・ ○ 具体的なデータ ■ 広告配信結果→配信ログ/クリックログ/集計済みレポート/・・・３つの図ができた後 

Slide 18

Slide 18 text

18 Copyright © GeoLogic, Inc. All Rights Reserved. ● 営業/運用メンバー含め、Redashの活用がかなり進んだ ● 要件の認識合わせをしたことで、無茶な質問が減った ○ 営業現場や運用現場で、できることができないことがある程度推測できるようになった ○ エンジニアまで到達するときは、現実的な要求や質問が来るようになった ● データチームが健全に仕事できる弊社における要件分析の効果 

Slide 19

Slide 19 text

19 Copyright © GeoLogic, Inc. All Rights Reserved. ● 既存のシステムから、これらの図をリバース作成 ○ そして関係者と認識合わせ ○ 矛盾が出てくることが結構ある ● 矛盾 ○ ガバナンスが十分に考慮されていない ○ 目的に合致しない使い方がされている ○ 関係者の期待値とあっていない ○ などなど... ● これらに一つ一つ取り組んでいくことで、データの活用が進み始める ○ 関係者との認識合わせ ○ データ分析基盤の改修既にシステムが出来上がっている場合はどうするか 

Slide 20

Slide 20 text

20 Copyright © GeoLogic, Inc. All Rights Reserved. ● 見込みまでを対象に要件分析する ● データとユースケース、それぞれを軸に要件分析をすすめるとよさそう ● システムコンテキスト図、ビジネスコンテキスト図、データコンテキスト /ガバナンス図を作り、照らし合わせることによって、矛盾なく要件を分析できる ● 非エンジニアでも十分に理解できる形で、関係者と認識を合わせる ● その結果、データ利活用が促進されるデータ分析基盤も要件分析が必要 

Slide 21

Slide 21 text

Slide 22

Slide 22 text

22 Copyright © GeoLogic, Inc. All Rights Reserved. APPENDIX: RDRA  https://qiita.com/tatane616/items/f7f4e5ad818fe8b125d6 今回の要件分析手法は RDRA（Relationship Driven Requirement Analysis）に強く影響を受けています。 - システムがもたらす価値からユースケースを経てシステム内部に向けて要件分析を進めていく - 複数のモデルを使い、モデル動詞の関連性を保ちながら要件分析を進めていく - 現在はRDRA 2.0 GeoLogicでも、最初は管理画面プロジェクト（通常のWebアプリケーション）から導入。その後データ分析基盤の構築にも流用した。もちろん、今回の説明も RDRAに準拠しているわけではなく、もっと有効なモデルや考え方が詰まっているので、ぜひ参考にしてみてください。 RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法