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

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

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

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

隅田敦（@yummydum）

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

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

第1章 データ活用のためのデータ整備

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

1-2 データの品質は生成元のデータソースで担保する

1-3 データが生じる現場を把握して業務改善につなげる

1-4 データソースの整備ではマスタ・共通ID・履歴の３つを担保する

発表スライド

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

隅田

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

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

隅田

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

隅田

「ある作業を、ロールとオペレーションとアプリケーションとストレージという観点で整理します。ロールは作業を行う人、あるいは自動化されている場合はシステムです。オペレーションは、作業を完了するためのアクションです。アプリケーションは、そのアクションに用いる道具です。ストレージが、データ保存する物理的な場所です。

例えば、営業活動を毎日モニタリングしたいとします。営業活動の中で、 営業スタッフが商談のメモを紙媒体に入力するという状況があったとします。アプリケーションの観点から見ると、紙媒体へのメモではなく、入力システムを導入したらどうかという改善案が考えられます。この場合、紙で書くよりも手間がかかるので商談時間が減るとか、システムを導入すると利用料がかかるという欠点も考慮する必要があります。

次にロールに注目して、営業アシスタントに入力してもらうという施策も考えられます。 この場合、業務も安定するし商談時間も減らないというメリットがある一方で、人件費やアシスタントの教育にコストがかかるというデメリットもあります。あるいは、オペレーションに注目して、OCRで紙のメモを自動でデータ化するという方向性も考えられます。この場合, 紙というアプリケーションは変えなくていいので楽ですが、OCRの品質が問題になります。」

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

隅田

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

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

隅田

「本書は、ソフトウェア開発において重要なノウハウが、データ基盤の分脈に応用されています。ユースケースやユーザーストーリーを明確にすることはデータ基盤に限らず重要で、データ基盤の三層構造も責務が明確なサブシステムで分割しようという、一般的なソフトウェア開発の原則にのっとっています。

また、ドメインを深く理解することが重要というのは、例えば売上という概念をとっても、経理部門から見たときの売上とECサイト側から見たときの売上はまったく定義が違うので、データ分析以外の観点でも問題になりそうです。ドメインごとに用語の定義をして、関係者の理解をそろえることはデータ分析に限らず重要です。」

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

山田

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

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

隅田

「業務レイヤという考えに至った経緯は何でしょうか？」

ゆず

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

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

山田

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

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

山田雄（@nii_yan）

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

データ整備の課題はテクノロジーだけで解決できるのか？

2人目の発表者のしんゆう氏は「⁠『⁠データ分析とインテリジェンス』というブログを執筆しており、データアーキテクトまたはデータ整備人と名乗ることもある」と自己紹介したうえで発表をはじめました。担当したのは、第1章のデータレイク、データウェアハウス、データマートの作成方法について書かれている箇所です。

しんゆう（@data_analyst_）

知ることに強い興味があり、うまくやるのが多分得意。フリーランスで活動する「データを使いやすくする人」たまに「データを分析してインテリジェンスを提供する人⁠」⁠。その実態は謎のデータ分析業界ウォッチャー。最近のテーマは「もっとうまくやる」こと。ブログ「データ分析とインテリジェンス」

第1章 データ活用のためのデータ整備

1-5 データレイク層の一箇所にデータのソースのコピーを集約する

1-6 データウェアハウス層では分析用DBを使って共通指標を管理する

1-7 共通指標は本当に必要とされるものを用意する

1-8 特定用途に利用するデータマートはユースケースを想定してつくる

発表スライド

データレイク層とはデータを集約したもので、何も加工していない、ただのコピーであることが重要だと書かれていることを説明しました。なぜ一箇所に集めるべきかについては、集約による部門横断によるデータ活用と、分散されて置かれることの手間が減るということを説明し、データレイクの課題について紹介します。

しんゆう

「データレイクがデータレイクになっていないという問題が挙げられています。分析用に集計してから連携してしまう。複数の箇所にデータレイクをつくってしまうなどです。ほかにも、データレイクが存在してもそこにアクセスする権限がないことや、データレイクにデータがあるのかどうかわからないなどの課題があると思います。」

データレイクを1箇所にデータを集める理由として、部門横断のデータ活用が容易になること、データが分散していると発生する作業がなくなることなどを説明しました。次に、本書では共通指標となるデータ、ならびにそのデータの置場のことを「データウェアハウス層」とみなしていると説明し、その共通指標については次のように書かれていると話します。

しんゆう

「部署ごとに独自の集計をしてしまうと、部署横断のデータ活用が進みません。SSOT（Single Source of Trust：信頼できる唯一の情報源）として、一箇所で定めておくことが必要です。少なくとも同じデータを使っていれば、売上を集計するときに定義がぶれなくなります。

部署が違えばルールも変わるので、売上が違うという話になれば、間違い探しが発生してしまいます。共通指標は集計があった方が良いこと、これはガバナンスにも関係すると言っています。」

共通指標は複数のデータを統合・整理したデータで、分析用DBで集計・管理することが望ましいと説明し、データウェアハウス層に格納する共通指標をつくるには、データをクレンジングして、スタースキーマを作って、共通指標の集計を取るという流れを紹介しました。また、初期段階でデータウェアハウス層を作ってしまうと、実態にそぐわない共通データができあがって、現場で使われないことがあると説明し、最初はデータマートからデータレイク層を直接参照する方法を紹介します。実態にそぐわないデータができあがってしまう原因は、エンジニアが利用者の話を聞かずに、技術的にできるかどうかで判断してしまうことがあるとご自身のエピソードにもふれました。

次に、データマート層の説明に移ります。データマートは、特定の利用者、特定の用途向けに加工・整理したデータ、ならびにそのデータの置き場です。データマート層はユースケースと1対1となり、あるデータについてデータウェアハウス層に置くべきか、データマート層に置くべきかを判断できないときは、時期尚早なのでデータマートに置くことが書かれていると紹介しました。ユースケースごとに管理するメリットについても紹介します。

しんゆう

「1つは影響範囲を制限できること、もう一つは集計ロジックを再利用できることです。データ利用の視点に立つと、試行錯誤が容易になること、過去のロジックを再利用できること、システムの応答時間が速くなることがメリットだと言っています。」

さらにしんゆう氏はデータマートについての自論を展開します。

しんゆう

「大きなテーブルにクエリを投げても、システムの応答時間が気にならない程度にツールが発展すれば、ユースケースごとにクエリを持つだけで、データマートという入れ物はなくなるのかもしれないと思います。」

続いて、現場で生じるデータマート層の課題とその解決法について紹介しました。データマートのメンテナンスは難しく、ガバナンスが効きにくいので、利用が減ったデータを検知して、不要になったデータマートを削除することが書かれていると説明しました。

しんゆう氏はデータマート層の課題とその解決法について、自身のノウハウも紹介します。

しんゆう

「本書では、ツールが利用者との間で分断されるのを避けるには、最初の試行錯誤はBIや表計算ソフトで行って、利用方法が固まってきたらSQLに書き直すことを推奨しています。データマート自体が増えすぎる問題は確かにありますが、定期的に見続ける予定がなければ、アドホックなクエリだけを残しておく方法もあります。また、データマートやクエリを作っても、ある期間を設定して消えるようにしておく方法もあります。」

最後に以下のように発表をまとめました。

しんゆう

「主にテクノロジーで解決するための方法が書かれている印象を受けました。データ整備は対人スキルが必要になるケースが少なからずあって、そこを埋めてくれるコンテンツに需要がありそうだと思います。」

しんゆう氏は、発表内で本書で示されているデータの三層構造について疑問を投げかけていました。それに対し著者のゆずたそ氏から次のような回答がありました。

ゆずたそ

「たとえば、ある会社では四層で作っているという話を聞きました。非構造データをテーブル形式に整えるとか、列名をわかりやすく変換するとか、元のデータのセマンティクスを変えない範囲内での変換を行っているようです。

本書の流れでは、ユースケースとデータソースという文脈があるので、そこに注目してください。ユースケースに紐づく層とデータソースに紐づく層、そしてその間を横断する層があります。この二層目は、粒度によって複数の層があり得ると思います。例えば、ソースコードを書くときに、エンジニアがクラスとパッケージとコンテキストをどう区別するかのような話と同じです。コンテキストという粒度なら三層かもしれないし、クラスまで分けるならもっと増えるかもしれません。そこは設計次第だと思います。

重要なのは最初のコンテキストの切り方は、データソースとユースケース、データの入口と出口に注目しましょう。それ以外にもう1つ必要になるはずというのがこの三つの分け方です。」

データスチュワードは存在するか？

最後の発表者はmomota氏（@momota10s）が務めました。専門領域はデータエンジニアリングで、決済や小売、医療系のデータを扱った経験があるとお話したうえで発表をはじめました。ユースケースのあり方、メタデータ、サービスレベル、データスチュワードといった箇所を担当しました。

momota（@momota10s）

大学を卒業後、ソフトウェアエンジニアとして様々な実務を経て現在はデータエンジアリングを主軸に仕事をしている。事業課題から逆算してデータの入口から出口までを一気通貫で構築する事を得意とする。
LinkedIn: https://www.linkedin.com/in/momotasasaki/

第1章 データ活用のためのデータ整備

1-9 ユースケースを優先的に検討しツールの整備を逆算する

1-10 データの調査コストを減らすためにメタデータを活用する

1-11 サービスレベルを設定・計測して改善サイクルにつなげる

1-12 データ基盤の品質を支えるデータスチュワードの役割を設ける

そもそもデータ基盤を作るのは、そのユースケースを実現するためであって、技術的に難易度の高いデータ基盤を作ったところで、ビジネス価値がなければ使われないと述べ、どのようにユースケースを決めるかについて説明しました。

momota

「事業計画の目標を達成するために、施策から逆算してユースケースを定める。施策の解像度の高さが良質なアウトプットへの道しるべだと書いてあります。5W1H（画像は5H1W）の例では、誰が、いつ、どこで、なんのために、何を、どうするのか、まで解像度を高く設定してあげることで、実際にユースケースを満たすためのデータ基盤、またその先のBIツールなど、確度高く仕事が進められると書いていて、その通りだなと思います。」

事業目標にそぐわない課題、そもそも課題が間違っている、優先順位が低いなどのユースケースのアンチパターンにもふれます。作ったけれども使われないという課題に対しては、そもそも自分にとってよいと思うツールが他の役割の人にとってベストなのか、利用者の気持ちに立って考えるってところが重要であることを紹介しました。次にメタデータの説明に移ります。

momota

「どのようなデータなのかを知るために付与される情報です。写真データで言うと、いつ撮影されて、拡張子、撮影場所といった付随する情報などをメタデータと言います。データ基盤におけるメタデータは、データの作成者、作成日時、カラムに個人情報が含まれているか、単位、参照数など、たくさんあります。私自身、BigQueryをよく使うので、パブリックデータの例をお見せします。」

momota

「フィールド名に対して説明をつけたらそれがメタデータになりますし、そもそもテーブルのIDやサイズなどの情報もメタデータです。」

なぜメタデータを管理すべきなのかについては、データの調査のコストを削減するためと延べ、Momota氏ご自身の経験を紹介しました。

momota

「とあるECサイトの注文のレコードに、「⁠payment_type1、2、3」という整数があって、「⁠1、2、3」が何なのか、ソースコードを調べるか、知ってる人に尋ねないとわからないことがありました。メタデータが整備されてないと、調査コストがかかるのはその通りです。メタデータはデータ活用の画面だけではなくて、データパイプラインの作成過程でも役に立つと書いてあります。」

続けてmomota氏がどのようにメタデータを管理しているかにふれます。

momota

「⁠（⁠メタデータの管理は）BigQueryやData Catalogで行います。分析用のデータベースやメタデータ管理ツールですね。他のクラウドサービスであっても、自社サービスであっても、作成者自身が書きます。とはいえ、スプレッドシートやExcelで管理されていることも往々にしてありますし、BigQueryにメタデータ拡充したから見てね、と言っても誰も見ないこともありえます。ここでも、ユースケースをよく考えることは重要だと思います。」

このように話したあと、メタデータ作成の専門部隊の多くは機能しないことが書かれていると説明しました。次にサービスレベルについて次のように解説します。

momota

「サービスレベルとはサービスの品質水準を表現したもので、データ基盤には簡単にアクセスできる便利さと整備済みデータを使える安心感という暗黙的な期待があります。サービスレベルは、目標設定から関係者との合意、計測、特定、施策の実施、振り返りといったサイクルで品質の向上を継続します。なぜサービスレベルを計測するかですが、計測によって課題が明確になって改善策につながるからです。」

このように解説し、サービスレベルを改善するポイントとして「システムではなくサービスに注目することと、計測すること」の2つの要素があると紹介し、どのようにサービスレベルを設定・計測するかを説明しました。

momota

「可視化が第一です。そのうえで、ビジネス要件や、要望がある人へのヒアリングを通して目標設定をしていきます。ここで、ユースケースごとに期待されるサービスレベルが異なるというのはミソだと思います。経理向けの集計データと分析向けデータは、求めるデータの品質が全然違います。」

最後にデータスチュワードについての説明に入ります。データスチュワードはデータ整備の推進者であり、データ活用者にとっての相談窓口であると説明します。データについて最も相談を受けている人がいれば、それが事実上のデータスチュワードであるとの記述を紹介しました。

momota

「専門の役職もあれば、データエンジニアやデータアナリストが事実上兼務していることもありますが、今までの経験上では後者の方が事実上兼務していることがほとんどかなと思います。」

このようにコメントしたうえで、データスチュワードの求人のジョブディスクリプションについて調査し、その一部を紹介しました。

momota

「LINEは、ビジネス周りのノウハウ、あとはコミュニケーション能力、分析の能力など、割と幅広く求められているように見えます。マリオットインターナショナルというホテル会社では、データエンジニアリングよりのスキル、経験を求めているように見えます。最後にボストンコンサルティンググループは、コンサルティングのノウハウ、顧客との折衝動力、マーケティング能力といったことを求められているように見えます。」

そのうえで、そもそもデータスチュワードという役割に就いている人をLinkedInで調べてみたが多くはなかったことを紹介し、データスチュワードのキャリアについてご自身の考えをお話します。

momota

「データアナリストに内包されている会社が多いと現時点では思っています。データスチュワードが最初のキャリアというより、データアナリクスやデータエンジニアリングなどのキャリアを積んで、書籍では「事実上は兼任」と書かれていましたが、事業の数や規模が増えて、相談窓口としての業務が兼任では収まらなくなったタイミングで、専任となるのかなと考えました。」

続いて、データスチュワードの振る舞いについて、受動的な対応と能動的な対応の二つがあることが書かれていると話しました。

momota

「⁠（⁠受動的な）データ抽出や集計などの問い合わせについては、場合によって別チームに転送します。一方、能動的なデータ整備の推進について、問い合わせによって何が課題なのかを知るために、ユースケースを把握しにいって、そのユースケースを実現するための品質を定義して、品質水準や利用状況をメタデータで計測することもあります。必要であればデータソースを整えることも必要です。なので、完全に2つの対応が分断しているというよりは、データを作りにいくところに関わることもあり得るし、活用する方に関わることもあり得ます。主軸としてはマネジメントなのかなというふうに思っています。」

最後に現場で生じる課題と対処法について紹介しました。

momota

「受動的な活動で時間を割かれることはよくある話です。セールスや事業開発側から、こんなデータが欲しい、あんなデータが欲しいという要望に対応していたら1日が終わってる人を見たことがあります。

自分の活動、自分の時間が何に使われているのかを定量的に管理することや、データ分析一つとっても依頼者が自らの力で解決できるように研修していくことが重要と書かれています。と言っても、SQLの研修は本当に大変なので、場合によってはSQLを使えなくてもデータの抽出や集計ができるBIツールの導入もソリューションとして考えられるかもしれません。

事業開発もセールスもみんなSQLを扱えるスタートアップ企業に所属していたこともあります。みんながデータについて知っているから、ドキュメントを拡充するよりも早く分析をして、試作の結果を見たいという感じでした。事業規模やそこにいる人の能力などによって変わると思います。」

以上で発表は終わりましたが、momota氏はこれまでのエピソードについてもいくつかお話されました。

momota氏

「データスチュワードの役割としてSQLの研修が挙げられていましたが、SQLを教えようとしても挫折する方が多いので、最終的にはTableauを導入するという話になったこともあります。結局、SQLの基本的な構文を覚えても、データモデルを理解していないとまったく立ちゆかないと思います。それを他の職能の人に期待するのは負担が大きいです。組織規模が大きくなって分業化が進むと、データ基盤を作る人が専任になって、他は見るだけの人のように分かれるんだろうなと思います。」

最後に著者のゆずたそ氏から、第1回輪読会は閉会しました。

ゆずたそ

「正解を勉強するために本を読むわけではないと思っています。みなさん自身がよりよい活躍をして、より世の中を良くしていく仕事をしてるんだと思うんですけど、本書がそういった仕事を後押しできればと思っています。そういう読み方をしてもらえるとすごくいいかなと思っています。」

ゆずたそ（@yuzutas0）

本名：横山翔。令和元年創業・東京下町のITコンサルティング会社「風音屋」代表。日本におけるDataOpsの第一人者。慶應義塾大学経済学部にて計量経済学を専攻。リクルートやメルカリ、ランサーズでデータ活用を推進。広告配信最適化や営業インセンティブ設計など、データを駆使した業務改善を得意とする。コミュニティ活動では、DevelopersSummitのコンテンツ委員やDataEngineeringStudyのモデレーターを担当し、データ基盤やダッシュボードの構築について積極的に情報発信している。当面の目標は100社のデータ活用を支援して各産業の活性化に貢献すること。著書に『個人開発をはじめよう！』『⁠⁠データマネジメントが30分でわかる本』がある（プロフィールは本書出版当時のもの⁠）⁠。