レポート

データエンジニア大集合!「実践的データ基盤への処方箋」輪読会レポート 〜データ整備編〜

この記事を読むのに必要な時間:およそ 6 分

データエンジニアリング,データ活用の知見の共有を目的としたコミュニティdatatech-jpおよび株式会社風音屋の協力のもと実践的データ基盤への処方箋の輪読会がオンライン形式で開催されました。輪読会は3回に分けて開催され,発表者だけでなく執筆者も参加し,書籍では扱えなかった内容についても議論が交わされました。本稿では輪読会の様子をダイジェストで紹介します。

データ基盤に応用されるソフトウェア開発のノウハウ

第1回の輪読会では,第1章の読み合わせを行いました。datatech-jpの管理人山田雄氏が進行を担当し,最初に執筆者のゆずたそ氏から,ディスカッションの場として楽しんでもらえると嬉しいとの挨拶がありました。

株式会社ナウキャストの隅田 敦氏が1人目の発表者を務めました。隅田氏が担当したのは,第1章のデータ整備についてです。

隅田敦
隅田敦@yummydum

自己紹介: 東京大学経済学部経済学科にて計量経済学を専攻。経済現象の理解のためには高品質高頻度のデータが必要との想いから2018年よりナウキャストにてインターンを始める。2019年より東京大学大学院情報理工学系研究科コンピュータサイエンス専攻に進学し,計算言語学/自然言語処理の研究を行う。2021年4月にナウキャスト入社。

現在は,データエンジニアリングやデータサイエンス,データまわりのこと全般を担当していると自己紹介したうえで発表に入りました。

第1章 データ活用のためのデータ整備
1-1 データの一連の流れを把握し,入口から出口までを書き出す
1-2 データの品質は生成元のデータソースで担保する
1-3 データが生じる現場を把握して業務改善につなげる
1-4 データソースの整備ではマスタ・共通ID・履歴の3つを担保する

発表スライド

1章の内容については,データソースからユースケースまでの流れを概観したあと,データ活用にはCRUD表を用いて入口と出口を押さえる必要がある,ということが書かれていると説明しました。

隅田
「著者のゆずたそ氏は,CRUD表(データのC:Create,R:Read,U:Update,D:Deleteをまとめた表)を作成して,データを洗い出すことを提唱しています。例えば,販売促進部が雨天限定でメルマガ(クーポン)を発行したいというユースケースがあったときに,どういうデータが必要になるかを考えます。雨が降っているか否かをデータから判断する必要があるため,気象庁のデータが必要と判断したとします。この場合,天候というデータに対して気象庁が行うCRUDはCreateとUpdateで,メルマガシステム開発部のメルマガの部署がそれをReadします。」

図1 CRUD表の例(P.7より)

図1

隅田氏は社内でもCRUD表を使ってみたいと話します。続いて,データ品質が悪ければデータ基盤側でカバーすることは難しいこと,ユースケースの目的を満たすにはデータの生成過程を理解する必要があることなどを説明したうえで,データソースを理解するために用いる「業務レイヤ」の説明に入ります。

隅田
「業務レイヤという考えが提唱されています。業務レイヤをもとにデータを整理すると,データマネジメントにおける課題の原因や改善案が考えやすくなります。」

図2 業務レイヤの例(P.17)

図2
隅田
「ある作業を,ロールとオペレーションとアプリケーションとストレージという観点で整理します。ロールは作業を行う人,あるいは自動化されている場合はシステムです。オペレーションは,作業を完了するためのアクションです。アプリケーションは,そのアクションに用いる道具です。ストレージが,データ保存する物理的な場所です。
例えば,営業活動を毎日モニタリングしたいとします。営業活動の中で, 営業スタッフが商談のメモを紙媒体に入力するという状況があったとします。アプリケーションの観点から見ると,紙媒体へのメモではなく,入力システムを導入したらどうかという改善案が考えられます。この場合,紙で書くよりも手間がかかるので商談時間が減るとか,システムを導入すると利用料がかかるという欠点も考慮する必要があります。
次にロールに注目して,営業アシスタントに入力してもらうという施策も考えられます。 この場合,業務も安定するし商談時間も減らないというメリットがある一方で,人件費やアシスタントの教育にコストがかかるというデメリットもあります。あるいは,オペレーションに注目して,OCRで紙のメモを自動でデータ化するという方向性も考えられます。この場合, 紙というアプリケーションは変えなくていいので楽ですが,OCRの品質が問題になります。」

業務レイヤごとにPros/Consを出せば改善案を整理できること,データ生成の現場にはデータ入力を改善できるポイントがあると書かれていると説明します。続いて,データ整備で問題になりやすいデータについて書かれていると話します。

隅田
「全社的にデータ活用したいとなったときに,よく問題になる3つのデータということで,マスタ,共通ID,履歴が挙げられています。」

図3 マスタ・共通ID・履歴

図3

システムや部署によって,これらの違いがあとあと問題になりやすいと説明したうえで,特にマスタと共通IDは,部署横断で仕様をそろえる必要があり,難しい作業だと話します。最後に次のような感想で発表をまとめました。

図4 担当章の感想

図4
隅田
「本書は,ソフトウェア開発において重要なノウハウが,データ基盤の分脈に応用されています。ユースケースやユーザーストーリーを明確にすることはデータ基盤に限らず重要で,データ基盤の三層構造も責務が明確なサブシステムで分割しようという,一般的なソフトウェア開発の原則にのっとっています。
また,ドメインを深く理解することが重要というのは,例えば売上という概念をとっても,経理部門から見たときの売上とECサイト側から見たときの売上はまったく定義が違うので,データ分析以外の観点でも問題になりそうです。ドメインごとに用語の定義をして,関係者の理解をそろえることはデータ分析に限らず重要です。」

発表後には,datatech-jpのSlackに書き込まれた参加者からのコメントが読み上げられました。

山田
「部署ごとに報告する売上が違って社長がブチ切れた(笑⁠⁠。私が過去に見た例では,ROIを取り合うこともありましたね。」

発表者の隅田氏が著者のゆずたそ氏に質問を投げかけました。

隅田
「業務レイヤという考えに至った経緯は何でしょうか?」
ゆず
「エンタープライズアーキテクチャ(EA)という,日々の仕事をどうやって改善していくのかを整理するような知識体系があります。DMBOKの中でも紹介されています。EAでは,さまざまな仕事をレイヤに分けて整理します。EAを参考にしつつ,データを扱う場合の重要な点をふまえて整理し直したのが業務レイヤという考え方です。」

参加者からの「部署横断で取り組むのは実際には難しい気がするがどうか」という質問に対し,進行の山田氏がコメントをしました。

山田
「トップダウンで決めるのが良いですね。ボトムアップでやろうとすると,ガバナンスが効かず,本人に任せるような状態になってしまいます。」

これに加えてCDOなど設置する企業は見本のようなもので実際にはIT部門に丸投げになってしまう現状があるなどのコメントも寄せられました。

山田
山田雄@nii_yan
SIer にて組込系の開発に従事したのち,フリーランスとして独立。フリーランスの間にシミュレーションシステムの開発や,大手ECサイトのメールマーケティング用分析基盤の構築を経験。ユーザ企業に転職してからはグループ会社共通分析基盤構築をする傍ら,chatbot の開発やメールマーケティングにも関わる。

著者プロフィール

高屋卓也(たかやたくや)

編集者。2002年技術評論社に入社。販売促進部にて書店/取次などの担当を経て編集部に異動。主な担当書籍に『効果検証入門』(2020),『Kaggleで勝つデータ分析の技術』(2019),『前処理大全』(2018),『データサイエンティスト養成読本』などがある。

Twitter:@tkaytkuy

バックナンバー

2022年

バックナンバー一覧