機械学習できるデータを用意せよ　MLで重要なデータマネジメントの11領域

データマネジメントの11領域

ゆずたそ氏（以下、ゆずたそ）：そういったつらい状況の中で、解決のために何ができるかという話をしていきたいと思います。ちょうど今折返しぐらいの時間なので、後半、この話をやっていきます。

今回テーマにもあるように、データマネジメントという概念・手法が鍵になるかなと自分は考えています。

じゃあ「データマネジメントって何だよ？」というと、簡単に言うと、データを資産と捉えて、ほかの資産、例えば預金とか不動産の管理と同じようにデータをちゃんと管理していこうという取り組みのことです。

具体的には、この11個の領域が、代表的なフレームワークで定義されています。今日はこの11領域をご紹介します。

ぜひ自分自身の担当している現場で「あのデータ使いにくいな」「このデータぜんぜんダメだな」と思っているデータについて、今から紹介するこの11領域のうち「どこができていて、どこができていないか？」「そういった課題を解決するために何ができるか？」を考えながら聞いてほしいなと思っています。

先ほども申し上げましたが、機械学習の担当者1人だけで進められるような話ではなくて、データを作る人たちと連携しながら進める話だと思っています。「誰に相談したらこの話は進むかな？」って考えながらぜひ聞いていただけたらと思います。

データアーキテクチャ

1個目が「データアーキテクチャ」という領域です。何を言ってるかというと……実例を見るのがわかりやすいかな。データの流れを書き出したものです。

細かく説明しませんけど、社内にあるいろんなデータ、使っているデータの流れをちゃんと全部書き出しましょう。意外と「このデータどこから来てるんだっけ？」「どの部署が作ってるデータだ？」「どのアプリケーションから出てるんだっけ？」ってすらすらと言えることってあんまりないと思っているので、まずそこをしっかりと書き出していきましょうという領域です。

データストレージとオペレーション

2つ目の領域が「データストレージとオペレーション」で、要するにデータベースのシステムの運用をちゃんとやっていきましょうという話です。

例えば、先ほどの登壇でAWSの話がありましたけど、S3でログのファイルを管理しているんだったら、「アクセス権限ってどんなふうに扱っているんだっけ？」とか「このS3を使いたいときに誰に相談すればいいんだっけ？」とか「そのバケットやファイルの命名規則どうするんだっけ？」とか、いろいろな利用のマニュアルとかポリシーをちゃんとやりましょうという話です。

そういうのが放置されていると、結局「このログファイルどこにあるんだっけ？」というのがわからなかったり、トラブルや障害が起きたときに誰も責任を持ってなかったということが起きえます。

データの統合と相互運用性

3つ目が「データ統合と相互運用性」というテーマで、簡単に言うとETLと呼ばれるものです。

データをつないでいって、最終的にはデータウェアハウスに入れて、それを機械学習で使いたいといったときに、「じゃあデータウェアハウスにどうやってデータを集めるんですか？」というこのデータの流れです。とくに別のデータベースからデータウェアハウスにデータをつなぐところの、そのデータをつなぐ部分のシステムの話になります。

いろいろツールがあるので、ちゃんと使っていきましょうという話にもなります。

データモデリングとデザイン

4つ目が「データモデリングとデザイン」。これは簡単に言うと、データ同士の関係性。

わかりやすく言うとER図です。機械学習の施策を新しくやるときにデータの仕様をキャッチアップする。データの中身を見ると思うんですけど、ER図があるとちゃんと管理できてるねっていう、そういう話です。

マスターデータ管理

5つ目が「マスターデータ管理」というテーマです。これはよくあるマスターデータという言葉ですね。

何を言ってるかというと、例えば都道府県コード、そういったコード値の話です。都道府県コードとか、あとはわかりやすいのが、さっき例に挙げた業種。飲食店は10番で、宿泊業は20番。そういった「どの数字が何を表しているんだっけ？」というのがデータごとに違う値だと使うほうも大変だよねといった話になります。

データごとに「飲食店」「レストラン」とバラバラで管理していると分析しにくいですよねと。ちゃんと管理しましょうというテーマです。

ドキュメントとコンテンツ管理

「ドキュメントとコンテンツ管理」というテーマ。これは「データベースで管理できないような情報をいかに管理するか？」というテーマになります。

例えば、開発プロジェクトで使うドキュメント。データベースのデータを機械学習エンジニアが見たときに「なんでこんなデータを突っ込んでいるんだっけ？」という意図を知りたくなったときに、ちゃんと仕様ドキュメントが揃っているかどうかでその後の調査のしやすさも変わってくるよねと。

そういった意味では、データに紐づく情報ってことで、ちゃんとそういった情報も管理しましょうというテーマになります。

データセキュリティ

7つ目が「セキュリティ」ですね。これは一般的なシステムのセキュリティ、ITのセキュリティと同じ話だと思ってもらえればけっこうです。

とくにデータ分析者や機械学習を使う人からすると、個人情報ですね。迂闊に触りたくないじゃないですか。手元の端末に機密データが残ったら仕事を進めにくいでしょうし。そういった意味で「個人情報・PIIなどのデータをどうやって管理するんだっけ？」というのが決まっていたほうがやりやすいよねという話になります。

データ品質

8つ目が「データ品質」で、これは最初に説明したのと同じです。いくつか品質要件があるんですけど、例えば1個はこれ。サービスレベル。ツールによってはデータの反映完了に数日掛かるようなことも、とくに外部ツールだとあると思います。

そうなってくると、翌日にデータが使えるという前提でレコメンドのシステムを作っちゃうとトラブルの元になりうる。データ反映に数日かかるんだったら数日かかることを踏まえた上で使いましょう。そういった品質レベルを定義しましょうという話になります。

DWHとBI

9つ目が「データウェアハウスとビジネスインテリジェンス」という言葉で、これは機械学習というよりはいわゆるBI、アナリストの分析者側のトピックです。集計やレポーティングをどうやってやるんですかというテーマです。

機械学習エンジニアに関していうならば、分析用途・アナリスト向けのテーブルをいくら整備しても、機械学習に適さないことってあると思うんですよ。なので機械学習に特化したデータの管理方法もあれば、BIすなわち分析用途のデータもあれば、横断で使えるデータもあれば、そもそも余計な集計をせずに元のデータのコピーを残しておいてデータ探索ができるようにしましょうとか、そういったのも含めたデータウェアハウスのデータの持ち方が必要になってくるかなとも思います。

データ管理

10番目が「メタデータ管理」で、データを説明するデータです。例えばこのデータベースのカラムの説明で、一言コメントがあるだけでも調査する側がすごく楽ですよね。「このデータってどういう意味なんだっけ？」とか「どういう仕様なんだっけ？」というのを把握しやすくしようというのがメタデータ管理というテーマです。

データガバナンス

11番目が「データガバナンス」というテーマです。「データに関するいろんな取り組みを組織としてどうやってやってるんだっけ？」というのを管理するテーマになります。

機械学習担当者の視点から言うと、ステークホルダーを洗い出してちゃんと把握できていればいいかなと思っています。

最初にも申し上げましたが、こういったいろんな活動を進めていこうとすると、たぶん機械学習エンジニアが自分でやるってそんなイメージつきにくいと思うんですよ。なので、じゃあ誰に相談するんだっけというのが重要な視点かなと思っています。

いろんなステークホルダーがいるなかで、この「キーパーソンに相談する」というのがまずファーストステップかなと。

何でかというと、これです。相談なしに進むことは困難で、課題を検知する……右側の緑ですね、機械学習エンジニアが課題を検知しても、それを解消できるのってデータを作っている大本の人たちなので、どうしても複数人での仕事になっていくかなと思っています。

そういったときに「どうやって相談したらいいんだっけ？」というと、「相手に何をしてほしいのか？」と「なぜそれが必要なのか？」を相談していく必要があるよねと。

データマネジメントをはじめよう

具体的に「じゃあどうしてしてほしいのか」を会話していくためには……11領域がヒントになるかなと思うので、この11領域のうちどれができてないかというのを自分なりに考えておくと、それを足掛けにして相談しやすいかなと思います。

この11領域を取っ掛かりにして、自分自身が担当されている現場の具体的な課題を説明したり「こういうふうにやったらいいのかな」ということを相談するきっかけにしてもらえたらなと思います。

データマネジメントを始めようということで、一番オススメになる書籍がこれです。これね、1万円以上するし600ページ以上するし、とてつもなく大変な本なので、私がそれをわかりやすくした本を500円で売っていますので、しかも30分で読める本なので、ぜひこちらをお買い求めください。Amazonで「データマネジメント」で検索すると一番上に出てくるので、こいつを買ってくださいね。

ということで、以上です。ご清聴ありがとうございました。

【質疑応答1】11領域のうち、何から手をつけるべきか

上田隼也氏（以下、上田）：ありがとうございました。感動しました、僕。わかりみしかないですね。

ゆずたそ：ありがとうございます。

上田：では質問のほうに移っていきます。1つ目が「データマネジメントの11領域で、優先度付けをどうすればいいですか？」。「どれもこれもできない場合だと、どこから手をつけていくべきなのでしょうか？」という質問が来ています。

ゆずたそ：なるほど。いい質問ですね。まず教科書的な回答をするならば、よく言われているのが、1番目の「データアーキテクチャ」と11番目の「データガバナンス」。この2つは押さえておけと言われています。

なぜかというと、1つ目は「データアーキテクチャ」、これ全体像ですね。全体像がわかればそれを基に会話をしていけるでしょうという意味で、優先順位が高いよと。

そして11番目の「データガバナンス」は「誰がどうやって担当するんだっけ？」という役割分担の話なので、これが決まると責任者が決まるから話が進められるよと。

といったことで、一般的にはこの1番と11番。データアーキテクチャとデータガバナンスというテーマがかなり優先度高いと言われています。これは教科書的な回答ですね。

ただ、MLエンジニアの立場からすると、見えにくいところもあるかと思うんですよ。とくにデータを作る側の話とかって、自分たちはMLの施策を進めたいだけなのに、アナリストとかほかのマーケティング担当とかのデータの活用方法についてまで全部整理するって、ちょっとそれは違うんじゃないかと思ったりもすると思うんですね。

なので、MLエンジニアがやるんだったら8番の「データ品質管理」ですかね。「自分たちが実際何に困っているのか？　それはなぜ困っているのか？」ということを言語化するところから始めるのがいいかもしれませんね。

本当はリアルタイムでデータが欲しい。広告のデータを配信していて、ある程度リアルタイム性が欲しいと。なぜなら、その1パーセントのCTR（クリックスルーレート）の改善で巨額のインパクトがあるよと。だから、なるべくリアルタイム性が欲しい。だけど、1週間に1回しかバッチでデータが更新されないといったら、それはできれば相談したいじゃないですか。

そういった意味で、自分たちが求めるデータの品質と今提供されている品質とのギャップを言語化するところから始めると、自分たちで解決するにせよ、上司に相談するにせよ、ほかの人に相談するにせよ、進めやすいかなとは思います。そういった意味で品質管理から始められるのはマシンラーニングエンジニアにとってはよいかなと思います。以上です。

【質疑応答2】業務整理からビジネス価値につながる進め方

上田：ありがとうございます。では、次の質問です。「現場で『業務整理からデータ整理、そして機械学習、最後にビジネス価値』という優先順位について、こういう順で大事ですよという共通認識を得るために、どのような伝え方とか、どうやって進めていけばいいでしょうか？」という質問です。

ゆずたそ：なるほど。はい。この順番ですね。相手との関係性、相手の理解度にもよると思うんですけど、人によってはこの図を説明するだけでわかっちゃう人もいます。いろいろやってみて失敗した人とかは、経験的にわかっていらっしゃる。

一方であんまピンと来ていない方もいらっしゃったりするので、そういった方の場合は、説明の仕方もありますが、その人が何をしたいのかも含めて相談することが多いです。

例えば、データを整理するって大事ではあるものの、「じゃあそれで売上いくら上がるんだっけ？」とかって、P/Lで考えていらっしゃる方からすると、どうしてもデータを整備してから売上が上がるまで距離が遠いので、わかりにくいっちゃわかりにくいと。そういった方と組むときに、自分は業務の改善という文脈で入っちゃったりもします。

例えばさっきの営業の話でいうと、営業はデータ管理できていませんと。だから、例えば月末に精算するとき……成果を踏まえてボーナスを各営業スタッフに渡すときに、計算ミスが多いとかトラブルが多発してましたといった課題が潜在化しているので、現場課題の事例を聞きながら、そこの改善から入ります。完全に業務コンサル的な動き方ですね。自分はそういうふうにやっています。

とはいえMLエンジニアがやるのであれば、やっぱり素直に自分がこれらに困っていると話したほうが、中途半端に会話するよりも話は早いかなという気もします。

入口がダメだったら出口もダメになるよというのは図を見ればわかると思うので、それを基にまずは相談し始めるのがいいんじゃないかなと、個人的には思います。

すみません、これはあんまりスマートな回答にはなってないかもしれませんが、一応これが自分なりの見解です。

上田：そうですね。まぁ与太話だけど、僕もけっこう業務を進めてみて思っているのは、再現性を得たい場合はちゃんとデータに投資していかないと、評価も観測もなにもできないですよね、って話かなと思いましたね。

プロジェクトが成功していて、「別に再現しなくてもいいから、このまま突っ走りたい」寄りの、「別にデータなんかどうでもいいよ」みたいな人もいるかもしれないですけど、「この施策を再現性のあるかたちで成功させたいから、メトリクスを取って評価したいよね」ってなったほうが、みんなうれしいですよね。何がトリガーだったのかがわかって、再発明ができるとうれしい。というのを伝えると、データの有用性がわかってもらえるかなと思いました。

【質疑応答3】履歴を残すべきか

上田：これはざっくりまとめると、マスターテーブルとトランザクションテーブルについてです。トランザクションテーブルを作って履歴を残していないけれども、それでも作るべきか否かという質問ですね。

ゆずたそ：ありがとうございます。履歴保存について、しかるべきステークホルダーに打診してみていいと思います。なぜかというと、機械学習のためもそうなんですけど、合わせて、履歴がないと事業運営のトラブルになったりとか、法令違反をしているケースが意外とあるんですよ。

例えばECサイト。ECサイトって値段とか説明文とかって商品につけるじゃないですか。あの履歴を取っていないと、ユーザーが購入する直前にたまたま値上げしちゃったとか、データの反映のタイミングが違っていて、購入後に説明文が書き換えられていたってことが起きうるんですね。

でも、お金を払ってるユーザーからすると、自分が買ったときの情報と、今のサイトに表示されている情報が違った上にお金を払えと言われたら、それは筋が通っていないじゃないですか。消費者トラブルになりかねないので、そういった事態を防ぐために、消費者保護の観点でいろんな法令が整備されていたりします。

あと、カスタマーサポートの視点で問い合わせを受けたときに、過去のデータが残っていないと問い合わせ対応ができなかったりします。プロダクト開発の観点だと、履歴データを取ってないことによるトラブルって頻繁に起こりうる。機械学習の観点ではもちろんそうですし、そもそも「それ大丈夫なんだっけ？」ということも含めて、1回打診してみるのはありだなと思っています。

なぜこれを言ってるかというと、過去にそういうことが多くあったからですね。「えいや！」で作ったサービスがよくよく見ると非常にグレーな状態だったということは、わりと、とくにログ周りでありがちなので、一度確認しておいたほうがいいと思います。

そういうことを繰り返していくと履歴データをなるべく残しておこうというふうに話が進みやすくなっていきますね。結果的に機械学習にとっても使いやすいデータが残っていくのかなと思っています。

上田：ガバナンス的にもやっぱり必要という話ですね。

ゆずたそ：そうですね。

【質疑応答4】成功したMLプロジェクトは11領域を、どの程度実現できているのか

上田：次です。「経験的な話で大丈夫なのですが、成功したMLプロジェクトは、11領域はどの程度実現できているものなんでしょうか？」という質問ですね。

ゆずたそ：成功の定義にもよるのですが、たいして整備していなくても、プロジェクトを進めたらコンバージョンレートが上がっちゃいました、っていうのはけっこうあるかなと思っています。とくに広告だとかレコメンドだとか、1パーセントの改善で数字が出やすい案件は、勢いでやっちゃっても金額だけで言うなら成功しちゃいます。

ですが、そういったものを、例えば担当者が変わるとか、特定の画面だけじゃなくていろんな画面で使えるようにしようとかって、いざスケールしようとした瞬間に課題が噴出することが多いんじゃないのかなと思っています。

なので、短期的には、データマネジメントを意識しなくても成功するパターンは存在すると思っています。ですが成功し続ける、再現性のあるかたちでスケールさせようとすると、この11領域のできていない部分からボトルネックになっていくかなという認識です。

上田：なるほど。では、今回は質疑応答はここまでといたします。

ゆずたそ：最後に宣伝させてください。『データマネジメントが30分でわかる本』の紙媒体はAmazonで、電子版もKindleで購入できます。ぜひご覧くださいませ。よろしくお願いします。

上田：ありがとうございました。