2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
ゆずたそ氏(以下、ゆずたそ):そういったつらい状況の中で、解決のために何ができるかという話をしていきたいと思います。ちょうど今折返しぐらいの時間なので、後半、この話をやっていきます。
今回テーマにもあるように、データマネジメントという概念・手法が鍵になるかなと自分は考えています。
じゃあ「データマネジメントって何だよ?」というと、簡単に言うと、データを資産と捉えて、ほかの資産、例えば預金とか不動産の管理と同じようにデータをちゃんと管理していこうという取り組みのことです。
具体的には、この11個の領域が、代表的なフレームワークで定義されています。今日はこの11領域をご紹介します。
ぜひ自分自身の担当している現場で「あのデータ使いにくいな」「このデータぜんぜんダメだな」と思っているデータについて、今から紹介するこの11領域のうち「どこができていて、どこができていないか?」「そういった課題を解決するために何ができるか?」を考えながら聞いてほしいなと思っています。
先ほども申し上げましたが、機械学習の担当者1人だけで進められるような話ではなくて、データを作る人たちと連携しながら進める話だと思っています。「誰に相談したらこの話は進むかな?」って考えながらぜひ聞いていただけたらと思います。
1個目が「データアーキテクチャ」という領域です。何を言ってるかというと……実例を見るのがわかりやすいかな。データの流れを書き出したものです。
細かく説明しませんけど、社内にあるいろんなデータ、使っているデータの流れをちゃんと全部書き出しましょう。意外と「このデータどこから来てるんだっけ?」「どの部署が作ってるデータだ?」「どのアプリケーションから出てるんだっけ?」ってすらすらと言えることってあんまりないと思っているので、まずそこをしっかりと書き出していきましょうという領域です。
2つ目の領域が「データストレージとオペレーション」で、要するにデータベースのシステムの運用をちゃんとやっていきましょうという話です。
例えば、先ほどの登壇でAWSの話がありましたけど、S3でログのファイルを管理しているんだったら、「アクセス権限ってどんなふうに扱っているんだっけ?」とか「このS3を使いたいときに誰に相談すればいいんだっけ?」とか「そのバケットやファイルの命名規則どうするんだっけ?」とか、いろいろな利用のマニュアルとかポリシーをちゃんとやりましょうという話です。
そういうのが放置されていると、結局「このログファイルどこにあるんだっけ?」というのがわからなかったり、トラブルや障害が起きたときに誰も責任を持ってなかったということが起きえます。
3つ目が「データ統合と相互運用性」というテーマで、簡単に言うとETLと呼ばれるものです。
データをつないでいって、最終的にはデータウェアハウスに入れて、それを機械学習で使いたいといったときに、「じゃあデータウェアハウスにどうやってデータを集めるんですか?」というこのデータの流れです。とくに別のデータベースからデータウェアハウスにデータをつなぐところの、そのデータをつなぐ部分のシステムの話になります。
いろいろツールがあるので、ちゃんと使っていきましょうという話にもなります。
4つ目が「データモデリングとデザイン」。これは簡単に言うと、データ同士の関係性。
わかりやすく言うとER図です。機械学習の施策を新しくやるときにデータの仕様をキャッチアップする。データの中身を見ると思うんですけど、ER図があるとちゃんと管理できてるねっていう、そういう話です。
5つ目が「マスターデータ管理」というテーマです。これはよくあるマスターデータという言葉ですね。
何を言ってるかというと、例えば都道府県コード、そういったコード値の話です。都道府県コードとか、あとはわかりやすいのが、さっき例に挙げた業種。飲食店は10番で、宿泊業は20番。そういった「どの数字が何を表しているんだっけ?」というのがデータごとに違う値だと使うほうも大変だよねといった話になります。
データごとに「飲食店」「レストラン」とバラバラで管理していると分析しにくいですよねと。ちゃんと管理しましょうというテーマです。
「ドキュメントとコンテンツ管理」というテーマ。これは「データベースで管理できないような情報をいかに管理するか?」というテーマになります。
例えば、開発プロジェクトで使うドキュメント。データベースのデータを機械学習エンジニアが見たときに「なんでこんなデータを突っ込んでいるんだっけ?」という意図を知りたくなったときに、ちゃんと仕様ドキュメントが揃っているかどうかでその後の調査のしやすさも変わってくるよねと。
そういった意味では、データに紐づく情報ってことで、ちゃんとそういった情報も管理しましょうというテーマになります。
7つ目が「セキュリティ」ですね。これは一般的なシステムのセキュリティ、ITのセキュリティと同じ話だと思ってもらえればけっこうです。
とくにデータ分析者や機械学習を使う人からすると、個人情報ですね。迂闊に触りたくないじゃないですか。手元の端末に機密データが残ったら仕事を進めにくいでしょうし。そういった意味で「個人情報・PIIなどのデータをどうやって管理するんだっけ?」というのが決まっていたほうがやりやすいよねという話になります。
8つ目が「データ品質」で、これは最初に説明したのと同じです。いくつか品質要件があるんですけど、例えば1個はこれ。サービスレベル。ツールによってはデータの反映完了に数日掛かるようなことも、とくに外部ツールだとあると思います。
そうなってくると、翌日にデータが使えるという前提でレコメンドのシステムを作っちゃうとトラブルの元になりうる。データ反映に数日かかるんだったら数日かかることを踏まえた上で使いましょう。そういった品質レベルを定義しましょうという話になります。
9つ目が「データウェアハウスとビジネスインテリジェンス」という言葉で、これは機械学習というよりはいわゆるBI、アナリストの分析者側のトピックです。集計やレポーティングをどうやってやるんですかというテーマです。
機械学習エンジニアに関していうならば、分析用途・アナリスト向けのテーブルをいくら整備しても、機械学習に適さないことってあると思うんですよ。なので機械学習に特化したデータの管理方法もあれば、BIすなわち分析用途のデータもあれば、横断で使えるデータもあれば、そもそも余計な集計をせずに元のデータのコピーを残しておいてデータ探索ができるようにしましょうとか、そういったのも含めたデータウェアハウスのデータの持ち方が必要になってくるかなとも思います。
10番目が「メタデータ管理」で、データを説明するデータです。例えばこのデータベースのカラムの説明で、一言コメントがあるだけでも調査する側がすごく楽ですよね。「このデータってどういう意味なんだっけ?」とか「どういう仕様なんだっけ?」というのを把握しやすくしようというのがメタデータ管理というテーマです。
11番目が「データガバナンス」というテーマです。「データに関するいろんな取り組みを組織としてどうやってやってるんだっけ?」というのを管理するテーマになります。
機械学習担当者の視点から言うと、ステークホルダーを洗い出してちゃんと把握できていればいいかなと思っています。
最初にも申し上げましたが、こういったいろんな活動を進めていこうとすると、たぶん機械学習エンジニアが自分でやるってそんなイメージつきにくいと思うんですよ。なので、じゃあ誰に相談するんだっけというのが重要な視点かなと思っています。
いろんなステークホルダーがいるなかで、この「キーパーソンに相談する」というのがまずファーストステップかなと。
何でかというと、これです。相談なしに進むことは困難で、課題を検知する……右側の緑ですね、機械学習エンジニアが課題を検知しても、それを解消できるのってデータを作っている大本の人たちなので、どうしても複数人での仕事になっていくかなと思っています。
そういったときに「どうやって相談したらいいんだっけ?」というと、「相手に何をしてほしいのか?」と「なぜそれが必要なのか?」を相談していく必要があるよねと。
具体的に「じゃあどうしてしてほしいのか」を会話していくためには……11領域がヒントになるかなと思うので、この11領域のうちどれができてないかというのを自分なりに考えておくと、それを足掛けにして相談しやすいかなと思います。
この11領域を取っ掛かりにして、自分自身が担当されている現場の具体的な課題を説明したり「こういうふうにやったらいいのかな」ということを相談するきっかけにしてもらえたらなと思います。
データマネジメントを始めようということで、一番オススメになる書籍がこれです。これね、1万円以上するし600ページ以上するし、とてつもなく大変な本なので、私がそれをわかりやすくした本を500円で売っていますので、しかも30分で読める本なので、ぜひこちらをお買い求めください。Amazonで「データマネジメント」で検索すると一番上に出てくるので、こいつを買ってくださいね。
ということで、以上です。ご清聴ありがとうございました。
上田隼也氏(以下、上田):ありがとうございました。感動しました、僕。わかりみしかないですね。
ゆずたそ:ありがとうございます。
上田:では質問のほうに移っていきます。1つ目が「データマネジメントの11領域で、優先度付けをどうすればいいですか?」。「どれもこれもできない場合だと、どこから手をつけていくべきなのでしょうか?」という質問が来ています。
ゆずたそ:なるほど。いい質問ですね。まず教科書的な回答をするならば、よく言われているのが、1番目の「データアーキテクチャ」と11番目の「データガバナンス」。この2つは押さえておけと言われています。
なぜかというと、1つ目は「データアーキテクチャ」、これ全体像ですね。全体像がわかればそれを基に会話をしていけるでしょうという意味で、優先順位が高いよと。
そして11番目の「データガバナンス」は「誰がどうやって担当するんだっけ?」という役割分担の話なので、これが決まると責任者が決まるから話が進められるよと。
といったことで、一般的にはこの1番と11番。データアーキテクチャとデータガバナンスというテーマがかなり優先度高いと言われています。これは教科書的な回答ですね。
ただ、MLエンジニアの立場からすると、見えにくいところもあるかと思うんですよ。とくにデータを作る側の話とかって、自分たちはMLの施策を進めたいだけなのに、アナリストとかほかのマーケティング担当とかのデータの活用方法についてまで全部整理するって、ちょっとそれは違うんじゃないかと思ったりもすると思うんですね。
なので、MLエンジニアがやるんだったら8番の「データ品質管理」ですかね。「自分たちが実際何に困っているのか? それはなぜ困っているのか?」ということを言語化するところから始めるのがいいかもしれませんね。
本当はリアルタイムでデータが欲しい。広告のデータを配信していて、ある程度リアルタイム性が欲しいと。なぜなら、その1パーセントのCTR(クリックスルーレート)の改善で巨額のインパクトがあるよと。だから、なるべくリアルタイム性が欲しい。だけど、1週間に1回しかバッチでデータが更新されないといったら、それはできれば相談したいじゃないですか。
そういった意味で、自分たちが求めるデータの品質と今提供されている品質とのギャップを言語化するところから始めると、自分たちで解決するにせよ、上司に相談するにせよ、ほかの人に相談するにせよ、進めやすいかなとは思います。そういった意味で品質管理から始められるのはマシンラーニングエンジニアにとってはよいかなと思います。以上です。
上田:ありがとうございます。では、次の質問です。「現場で『業務整理からデータ整理、そして機械学習、最後にビジネス価値』という優先順位について、こういう順で大事ですよという共通認識を得るために、どのような伝え方とか、どうやって進めていけばいいでしょうか?」という質問です。
ゆずたそ:なるほど。はい。この順番ですね。相手との関係性、相手の理解度にもよると思うんですけど、人によってはこの図を説明するだけでわかっちゃう人もいます。いろいろやってみて失敗した人とかは、経験的にわかっていらっしゃる。
一方であんまピンと来ていない方もいらっしゃったりするので、そういった方の場合は、説明の仕方もありますが、その人が何をしたいのかも含めて相談することが多いです。
例えば、データを整理するって大事ではあるものの、「じゃあそれで売上いくら上がるんだっけ?」とかって、P/Lで考えていらっしゃる方からすると、どうしてもデータを整備してから売上が上がるまで距離が遠いので、わかりにくいっちゃわかりにくいと。そういった方と組むときに、自分は業務の改善という文脈で入っちゃったりもします。
例えばさっきの営業の話でいうと、営業はデータ管理できていませんと。だから、例えば月末に精算するとき……成果を踏まえてボーナスを各営業スタッフに渡すときに、計算ミスが多いとかトラブルが多発してましたといった課題が潜在化しているので、現場課題の事例を聞きながら、そこの改善から入ります。完全に業務コンサル的な動き方ですね。自分はそういうふうにやっています。
とはいえMLエンジニアがやるのであれば、やっぱり素直に自分がこれらに困っていると話したほうが、中途半端に会話するよりも話は早いかなという気もします。
入口がダメだったら出口もダメになるよというのは図を見ればわかると思うので、それを基にまずは相談し始めるのがいいんじゃないかなと、個人的には思います。
すみません、これはあんまりスマートな回答にはなってないかもしれませんが、一応これが自分なりの見解です。
上田:そうですね。まぁ与太話だけど、僕もけっこう業務を進めてみて思っているのは、再現性を得たい場合はちゃんとデータに投資していかないと、評価も観測もなにもできないですよね、って話かなと思いましたね。
プロジェクトが成功していて、「別に再現しなくてもいいから、このまま突っ走りたい」寄りの、「別にデータなんかどうでもいいよ」みたいな人もいるかもしれないですけど、「この施策を再現性のあるかたちで成功させたいから、メトリクスを取って評価したいよね」ってなったほうが、みんなうれしいですよね。何がトリガーだったのかがわかって、再発明ができるとうれしい。というのを伝えると、データの有用性がわかってもらえるかなと思いました。
上田:これはざっくりまとめると、マスターテーブルとトランザクションテーブルについてです。トランザクションテーブルを作って履歴を残していないけれども、それでも作るべきか否かという質問ですね。
ゆずたそ:ありがとうございます。履歴保存について、しかるべきステークホルダーに打診してみていいと思います。なぜかというと、機械学習のためもそうなんですけど、合わせて、履歴がないと事業運営のトラブルになったりとか、法令違反をしているケースが意外とあるんですよ。
例えばECサイト。ECサイトって値段とか説明文とかって商品につけるじゃないですか。あの履歴を取っていないと、ユーザーが購入する直前にたまたま値上げしちゃったとか、データの反映のタイミングが違っていて、購入後に説明文が書き換えられていたってことが起きうるんですね。
でも、お金を払ってるユーザーからすると、自分が買ったときの情報と、今のサイトに表示されている情報が違った上にお金を払えと言われたら、それは筋が通っていないじゃないですか。消費者トラブルになりかねないので、そういった事態を防ぐために、消費者保護の観点でいろんな法令が整備されていたりします。
あと、カスタマーサポートの視点で問い合わせを受けたときに、過去のデータが残っていないと問い合わせ対応ができなかったりします。プロダクト開発の観点だと、履歴データを取ってないことによるトラブルって頻繁に起こりうる。機械学習の観点ではもちろんそうですし、そもそも「それ大丈夫なんだっけ?」ということも含めて、1回打診してみるのはありだなと思っています。
なぜこれを言ってるかというと、過去にそういうことが多くあったからですね。「えいや!」で作ったサービスがよくよく見ると非常にグレーな状態だったということは、わりと、とくにログ周りでありがちなので、一度確認しておいたほうがいいと思います。
そういうことを繰り返していくと履歴データをなるべく残しておこうというふうに話が進みやすくなっていきますね。結果的に機械学習にとっても使いやすいデータが残っていくのかなと思っています。
上田:ガバナンス的にもやっぱり必要という話ですね。
ゆずたそ:そうですね。
上田:次です。「経験的な話で大丈夫なのですが、成功したMLプロジェクトは、11領域はどの程度実現できているものなんでしょうか?」という質問ですね。
ゆずたそ:成功の定義にもよるのですが、たいして整備していなくても、プロジェクトを進めたらコンバージョンレートが上がっちゃいました、っていうのはけっこうあるかなと思っています。とくに広告だとかレコメンドだとか、1パーセントの改善で数字が出やすい案件は、勢いでやっちゃっても金額だけで言うなら成功しちゃいます。
ですが、そういったものを、例えば担当者が変わるとか、特定の画面だけじゃなくていろんな画面で使えるようにしようとかって、いざスケールしようとした瞬間に課題が噴出することが多いんじゃないのかなと思っています。
なので、短期的には、データマネジメントを意識しなくても成功するパターンは存在すると思っています。ですが成功し続ける、再現性のあるかたちでスケールさせようとすると、この11領域のできていない部分からボトルネックになっていくかなという認識です。
上田:なるほど。では、今回は質疑応答はここまでといたします。
ゆずたそ:最後に宣伝させてください。『データマネジメントが30分でわかる本』の紙媒体はAmazonで、電子版もKindleで購入できます。ぜひご覧くださいませ。よろしくお願いします。
上田:ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには