【輪読会】実践的データ基盤への処方箋 / 20220120

2022/1/20に輪読会で発表した実践的データ基盤への処方箋の1-9から１-12の内容です

Transcript

1. 実践的データ基盤への処方箋 〜ビジネス価値創出のためのデータ・システム・ヒトのノウハウ〜 第1章 データ活用のためのデータ整備 1-9 ~ 1-12 Momota Sasaki( @momota10s )　
2. 自己紹介 • Software Engineer at DeNA ◦ 今の専門領域はデータエンジニアリング • @momota10s でたまにインターネットにいます • 今まで取り扱った業界のデータ ◦ 決済(QR)、小売(POS)、医療
3. 目次 1-9 ユースケースを優先的に検討しツールの整備を逆算する 1-10 データの調査コストを減らすためにメタデータを活用する 1-11 サービスレベルを設定・計測して改善サイクルにつなげる 1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける
4. 目次 1-9 ユースケースを優先的に検討しツールの整備を逆算する 1-10 データの調査コストを減らすためにメタデータを活用する 1-11 サービスレベルを設定・計測して改善サイクルにつなげる 1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける
5. ユースケースとは何か？ ユースケースとはデータ基盤の用途のこと。 ユースケースは多岐にわたる • 顧客数、売上高、在庫、販売数、仕入数、仕入原価、広告コストのモ ニタリング • EC サイト閲覧から購入完了までの利用ファネルの可視化 • 法人販売チームごとの商談開始から契約完了までの営業ファネルの可視化 • etc 本のページ p42
6. なぜユースケースに注目すべきか データ基盤を作るのがユースケースを実現するためだから データの流れはレイク -> ウェアハウス -> マート -> ユースケース(BI etc)だが、実務で は最初にユースケースから検討するのが望ましい。 技術的難易度の高い仕組みをつくってもユースケースが伴われないと活用されなかっ たり、そもそも要件的に必要なかったりとビジネス価値の無いものに。 • 例: リアルタイムデータ転送システム 本のページ p43
7. どのようにユースケースを定めるか 「中期事業計画等の目標」を達成するための施策から定める 施策の解像度の高さ(詳細な業務設計)が良質なアウトプットへの道標。 ユースケースの解像度を上げるための5H1Wの考え方 • Who(誰が) • When(いつ) • Where(どこで) • Why(なぜ、なんのために) • What(何を) • How(どうするのか) 本のページ p43
8. どのようにユースケースを定めるか 5H1Wの例：売上ダッシュボードのユースケースについて。 • ◯◯部長が(誰が) • 水曜日の朝10時に(いつ) • 役員ミーティングで(どこで) • 進捗確認のために(何のために) • 週次の売上推移を(何を) • 報告する(どうするのか) 本のページ p45
9. どのようにユースケースを定めるか 業務設計が詳細にできた後にシステムの設計、実装、テ スト、リリース、導入、運用へ とフェーズを進めていく。 運用時は以下のモニタリングも必要。想定と違う場合はヒアリングして軌道修正して定着さ せていく。 • 導入したツールが活用されているか • 期待する効果が得られているか • 想定外のトラブルや労力が発生していないか 本のページ p45
10. どのようにユースケースを定めるか アンチパターン • 事業目標にそぐわない課題を解く • 優先順位が低い施策を進める • データ利用の 5W1H を想定せずに現場に押し付ける • 一度のリリースに全力をかける ビジネスとデータをつなげることを常に意識するのが大事 本のページ p46
11. 現場で生じるユースケースの課題 開発者目線だけで設計、実装しても使われないという課題が往々にしてある • 自分にとって良いと思うツールが、他の役割の人にとってベストな訳では無い • 利用者の目線に立って考える（人の気持ちを考える）事も大事 本のページ p47
12. 目次 1-9 ユースケースを優先的に検討しツールの整備を逆算する 1-10 データの調査コストを減らすためにメタデータを活用する 1-11 サービスレベルを設定・計測して改善サイクルにつなげる 1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける
13. メタデータとはなにか 「このデータはどのようなデータなのか」を知るために付与される情報 • データの作成者 • データの作成日時 • データに個人情報が含まれているか • データが文字列なのか数値なのか • その数値の単位はcmなのか日本円なのか • データが誰にどのくらい参照されているのか • データを保管する義務のある期間 • etc 本のページ p48
14. メタデータとはなにか BigQueryでの例
15. なぜメタデータを管理すべきか データの調査コストを削減するため ECサイトの注文レコードでfield: payment_typeに1,2,3のいずれかの整数があったとす る。以下の情報がソースコードを調べるor知ってる人に尋ねないと分からない場合、調 査コストが発生する • payment_type=1 -> クレジットカード • payment_type=2 -> 銀行口座 • payment_type=3 -> 後払い 本のページ p50
16. なぜメタデータを管理すべきか メタデータは、データ活用の場面だけではなくデータパイプラインの作成課程でも大いに役 立つ • データを収集するときに、テーブル名やカラム名などのテーブル情報 をもとにして、データソースにアクセ スする • データウェアハウス層をつくるときに、データレイク層のデータを把 握したうえで集計ロジックをつくる • データマート層をつくるときに、データレイク層やデータウェアハウ ス層のデータを把握したうえで集計ロ ジックをつくる • データ基盤のトラブル発生時に、誰にどのデータがどのくらい参照されているのかを調べて、対象者にア ナウンスする 本のページ p50
17. どのようにメタデータを管理するか 本のページ p51 分析用DBやメタデータ管理ツールを利用する GCPでいうとBigQueryやData Catalog など 以下個人の経験 • 実際の現場ではスプレッドシートや Excelで管理されている状態は往々にしてある。 • まだ管理されているだけマシでソースコード見てね、とか〇〇さんに聞いてみて、というのも あったり。
18. 現場で生じるメタデータの課題と対処法 本のページ p51 メタデータのための専門部隊は多くの場合機能しない。 • データの仕様に一番詳しいのはデータを生成する人（主に開発者） • 一方システムの規模が大きくなると生成、変更が盛んになり上記の専門部隊による 追従が難しくなる。（結果使われないメタデータツールとなる） • 対処としては、データを生成する人を巻き込んでメタデータの追従をしていく必要があ る。
19. 目次 1-9 ユースケースを優先的に検討しツールの整備を逆算する 1-10 データの調査コストを減らすためにメタデータを活用する 1-11 サービスレベルを設定・計測して改善サイクルにつなげる 1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける
20. サービスレベルとはなにか 本のページ p53 サービスの品質水準を表現したもの 品質は大まかに分けると「便利」「安心」の 2種類 簡単にアクセスできる便利さと整備済みのデータを使える安心感という暗黙的な期待があ る。以下のサイクルで品質の向上と担保に寄与していくのが望ましい。 • 目標設定 • 関係者との合意 • 現状の計測 • 課題の特定 • 必要な施策の実施 • 結果の振り返り
21. なぜサービスレベルを計測するか 本のページ p54 計測によって課題がより明確になり、改善施策に繋がっていくから サービスレベルの改善には以下の二つの要素がある • システムではなくサービスに注目すること • 計測すること
22. なぜサービスレベルを計測するか 本のページ p54 システムではなくサービスに注目すること • サービスは、システムに通じて得た 体験も含めた包括的な概念 • この体験が悪いと、いくらシステムが良くても利用されなくなる ◦ 案内やサポート体制が不十分、等
23. なぜサービスレベルを計測するか 本のページ p54 計測すること • 計測なしには何をどれぐらい改善すればいいのか判断が出来ない • 同時に、達成したい目標の合意も大事 「1 日の売上データの集計は翌朝 7 時に完了していること」というサービ スレベルを設定したのであれば、「売上データの作成日時」 (メタデータ) を もとに「7 時までに集計完了しているか」を計測します。 30 日間のうち、集計遅延が 1日だけ(達成率97%)なのか、集計遅延が 12日(達成率 60%)なのかで、次にとるべき施策は変わります。 また、目標が無いと 6時には集計終わってる状態なのに 5時を目指そう とROIの低い施策に走ったり、等
24. どのようにサービスレベルを設定・計測するか 本のページ p55 • まずサービスレベルの可視化を行い、利用者や要件を要望してきた人へのヒアリン グを通じて目標を設定する • ユースケース毎に期待されるサービスレベルも異なる ◦ 経理向け集計データは1円のズレもNG、分析向けデータは±5%までなら誤差を 許容、など • 図のように書き出して言語化すると目標の合意形成が出来る
25. 現場で生じるサービスレベルの課題と対処法 本のページ p57 • 目標設定とその合意が明確でない故にサービスレベルに過剰な品質目標を科してし まう事がよくあるので注意する ◦ その仕事はビジネス価値に直結するのか？ ◦ 全てのデータを完璧に整備するのが目標ではなく、事業用途で使用するデータに関して 完璧に整備されているのが目標 • 個人情報データはガバナンスと利便性のトレードオフに直面しやすい。関係者とよく 議論してCIAを念頭にデータガバナンスを設計するとよい (意訳) ◦ 機密性(confidentiality) ◦ 完全性(integrity) ◦ 可用性(availability)
26. 目次 1-9 ユースケースを優先的に検討しツールの整備を逆算する 1-10 データの調査コストを減らすためにメタデータを活用する 1-11 サービスレベルを設定・計測して改善サイクルにつなげる 1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける
27. データスチュワードとはなにか 本のページ p58 データ整備の推進者であり、データ活用者にとっての相談窓口 会社によっては「データマネージャ」と呼ばれる場合もある。 データについて最も相談を受けている人がいれば、事実上のデータスチュワードである。 専用の役職もあれば、データエンジニアやデータアナリストが事実上兼務していることもあ る（後者の方が大半の印象）
28. データスチュワードとはなにか 本のページ p58 https://linecorp.com/ja/career/position/2142 job description(LINE)
29. データスチュワードとはなにか https://www.indeed.com/jobs?q=Data+Steward&vjk=1ea13b41a110ea55 job description(Marriott International, Inc) Experience(by DeepL翻訳) • SQL Server、DB2、Oracle、Informix、Teradata、Netezzaの少なくとも1つで高度なSQLクエリスキルがあること。 • SSMSを含むSQL Serverに関する確かな知識。 • Microsoft Excelおよびその他の Microsoftスイート製品の高度な知識。 • データベース管理 、リレーショナルデータベース、 NoSQLの構造および調査方法の経験。 • ETL開発ツールの経験（ SQL Server Integration Services、Informaticaなど）。 • BIプラットフォーム （MicroStrategy、Tableau、Alteryx、Power BI）の使用経験 • ビジネスニーズに応じて適切な分析アプローチを見極める能力。
30. データスチュワードとはなにか https://uk.indeed.com/Data-Steward-jobs?vjk=9133ea0d203e8d39 job description(Boston Consulting Group) EXPERIENCE & QUALIFICATIONS(by DeepL翻訳)から抜粋 • 10年以上のデータ管理業務 （データマネジメント／ CDOオフィスまたはBI／アナリティクスチーム）での勤務経験、マスター データ管理およびデータガバナンスツールの使用実務経験 • データ品質に対する情熱と関心 があり、問題解決において正確さと細部へのこだわりを実証していること • データ管理の概念および関連するビジネスプロセスやツール（特にデータモデリング、データウェアハウス、データ品質）を 理解すること。 • 顧客とビジネスを重視し、効果的な仕事上の関係を形成 し、対立を解決する能力を有すること。 • 顧客や製品データ領域にフォーカスしたデータスチュワードは、マーケティングや製品開発プロセスやコンセプトを理解し、 マーケティングデータを扱った経験 が必要です。MS Dynamics、Salesforce、SAP（またはその他の ERPシステム）などのアプ リケーションを使用した経験をお持ちの方が最適です。
31. データスチュワードとはなにか 個人の所感 • 「データスチュワード」というロール自体はまだあまりなさそう ◦ データアナリストに内包されているのが多そう ◦ 実際データに詳しくなるのはデータアナリストな訳で • データスチュワードがキャリアの最初というよりは、 data analytics や data engineeringがデータの利活用を推進していく上で、事業の数や規模が増えてスチュ ワードの業務が片腕じゃ収まらなくなったら専任で必要になりそう ◦ data management office的な部署が出来るのがそのタイミングかも ◦ 1事業の会社では専門の役職はやりすぎだし手が余ると思われ
32. なぜデータスチュワードが必要か 本のページ p59 安心感や利便性といった サービス品質を担保して利用者の利益に直結することが重要だ から • データスチュワードはそのサービス品質を担保するための役割 • 相談窓口なので利用者の疑問点、データの不備やエンハンス等の話がやってくる • 「データを収集する役割」や「データを活用する役割」ではなく「その間をつなぐ役割」 として、サービスレベルを定義、計測、改善し、サポー ト提供や利用促進を行う
33. データスチュワードはどう振る舞うか 本のページ p60 以下の2つの役割を果たすように振る舞う • 問い合わせの対応(受動的) • データ整備の推進(能動的)
34. データスチュワードはどう振る舞うか 本のページ p60 問い合わせの対応 • データ抽出や集計依頼の対応 • 場合によっては別チームに転送
35. データスチュワードはどう振る舞うか 本のページ p60 データ整備の推進 • 問い合わせ対応によって、データ活用者の要望やユースケースを把握 する • そのユースケースを実現できるだけの品質をサービスレベルとして定義する • その品質水準や利用状況をメタデータで計測する (メタデータがなければ整備する) • 目標と現状の差分から課題を検知し、解決策を検討する • データソースに課題があればデータ生成者と協力してデータソースを整える • データ基盤に課題があればデータレイク、データウェアハウス、データマートを整備す る
36. 現場で生じるデータスチュワードの課題と対処法 本のページ p61 受動的な活動に時間を割かれがち • バックログで可視化し、問い合わせ対応を 0.5FTE以下に抑えるなど定量的に管理す る • 依頼者が自らの力で解決出来るように研修していく ◦ SQL研修とか データスチュワード自身も業務を計測して課題の特定から改善までやっていくことが大事
37. End Of File 本のページ p61