自己紹介
ゆずたそ氏（以下、ゆずたそ）：では、発表を始めたいと思います。「データマネジメントなきMLは、破綻する。〜こんなデータじゃ機械学習できねぇよ問題の処方箋〜」という話をしたいと思います。
はじめに、まず自己紹介です。「yuzutas0」というアカウントをやっています。機械学習の専門家ではないのですが、機械学習を使った施策に関わることや、機械学習で使うデータの整備を担当することも多いので、そういった立場から話をします。
自費出版も含めて本を何冊か出しているので、今日はその宣伝に来ましたという感じです。
本日の話、想定する聞き手は機械学習のソフトウェアエンジニアを想定しています。私たちが抱える課題、「データが使い物にならない」という課題に共感してくれる方に向けての発表にしたいなと思っています。
本日お伝えする内容は、「データが使い物にならない」「じゃあどうする？」というところを伝えられればいいかなと思っています。
この発表の聞き方なんですが、ご自身の担当現場を思い浮かべながら「確かにあのデータは使えないよな」「じゃあどうしようか？」という解決プランを考えながら聞いてもらえればなと思っています。
アジェンダ
本日のアジェンダです。大きく分けて3つ。「データが使い物にならないよ」というものの「それって具体的にどういうこと？」というのをまず説明します。次に「じゃあなんでそんな使い物にならないデータがあるのか？」「その問題がなんで生じているんだっけ？」という話をします。最後に「じゃあどうしましょうか？」という話をしたいと思っています。
データが使えない理由
まず1個目です。「データが使えないとは何ぞや？」と。
本日のテーマ、データマネジメントというテーマなんですが、データマネジメントではデータの品質というものを定義しています。
例えばこの上から2つ目。「完全性」というのは「欠損のないデータか」。「この時間のログが取れていませんでした」となったら、機械学習への適用時にその欠損データを使うことはできません。取れてないデータを使うことはできませんよね。そういった感じで品質にはいくつか項目があります。
ほかにあるのは、この真ん中の整合性ですね。データ間の関係に矛盾がないか。いわゆる不整合データと言って、1回しか初回登録できないはずなのに、なぜか同じユーザーで登録のログが2つある。そういったデータが混じることって、現実のデータだと残念ながらあると思っています。品質をちゃんと定義していきましょう、というのが本日の話です。
データ品質がよくない、つまり、機械学習で期待するデータ品質が満たされていないと、それは使い物にならないデータになっていきます。
とくに、機械学習で顕在化しがちだと感じている品質課題があります。真ん中の例を見てほしいのですが、取引先のテーブルに、レコードが2つあるよと。片方はこの「合同会社風音屋」という会社で、2レコード目は「Kazaneya LLC」って書いてあります。これって同じ会社、同じ取引先のはずなのに、担当者のオペレーションミスでデータが混ざっちゃっている。
しかもよく見ると、「退会済み」とか「重複のため無効」とか、メモ書きがてらNameカラムが汚染されてしまっています。そうすると、「結局どの顧客が退会済みなのかがわからないよ」「どれが重複データなのかわからないよ」といったところで、データを渡された機械学習の担当者は正規表現でうまく前処理しなければいけません。
それでがんばれるなら、まだいいんです……まだいい？ よくない。よくないんですけど、さらにこのUpdatedAtというカラムをよく見ると怪しくて、「退会済み」と書いてあってUpdatedAtだからといって、それが退会日付とは限らない。
もっと前に退会していて、そのあと別のなんらかの処理でアップデートされていて、その日付がUpdatedAtとして残っているかもしれない。そうなると、いつ退会したかわからないので、このデータをどうやって使うかが非常に難しい。こういった問題があるのかなと認識しています。
ほしいのはmachine-readableなデータ
これって何かというと、要はhuman-readable。人間にとって、見たらなんとなくわかる。だけど、machine-readableではないと。機械学習でいざ使おうとしたときに、そのままで読み込ませられないデータかなと思っています。
本来ほしいのはこのmachine-readableなデータですよね。取引先というのが認知できて、かつこの退会の処理も履歴データとして残っていてほしい。
退会済みの状態もちゃんとコード値として管理されていて、マスターテーブルで正確に管理されている。「退会済み」とか「閉鎖済み」とか「この顧客はNGです」とか、わけがわからない書き方ではなくて、ちゃんと1つに寄せられているデータ。こういった適切な形式であれば、最低限の前処理で済むようになりますよと。かつ正確なデータが入りますよと。こういった品質がほしいなと。
データマネジメントにあるべき姿
機械学習の担当者にとって理想的であるのは、この流れです。アプリケーションや運用がしっかりしていて、それ故にちゃんと管理されたデータというのがあって、そのデータを使って機械学習の施策を行なう。結果的にビジネス価値が提供される。この流れが本来あるべきかなと思っています。
が、往々にしてあるのがこれです。データが使い物にならない。結果的に、機械学習の担当者、がんばれるところはがんばるものの、できることが限られてくる。ビジネス価値までたどり着かないシーンもあるかと思います。「データマネジメントを伴わない機械学習の施策は破綻しちゃいますよ」という話になります。
問題が発生している理由
では、そういった問題がなぜ生じているのかという話に進めていきたいと思います。
これ答えはシンプルで、データを作っているところのアプリケーション、システムだとかオペレーション、運用が安定してない。そこに問題があるので結果的に使いにくいデータが生成されてしまうと認識しています。
例えば営業活動。営業のデータを活用する状況ですね。これは実際に、とある企業で自分が担当した事例を紹介すると、営業のデータが管理できていませんでした。
理想としては、取引先候補があって、問い合わせが来てリードが取れて、商談して、契約をして、サービスを納品していくといった流れを、機械学習で活用できる形式でデータ管理していきたいんですけれども。
実際に何が起きていたかというと、こんな感じで。営業担当がいて、そのあと取引先の審査があって、問い合わせを担当するカスタマーサポートがいる。といったときに、それぞれの担当者が手元のエクセルシートで顧客リストを作って管理しちゃっていました。スタッフが50人いて1人あたり30個のシートを作ったら、1,500の無秩序なデータが生まれることになります。
また、各自の手元のシートで管理しているということは、異動や退職に伴ってデータがなくなってしまう。やりとりもメールや口頭での問い合わせだったりとかスプレッドシートの受け渡しなので、途中でどんどんデータが変な整形をされて作業ミスや認識齟齬が多発しちゃうと。
私が担当した現場だとSalesforceというツールを使っていました。これは営業が入力するツールですね。
採用したものの、なかなか高機能ゆえ使いにくく、現場向けにアレンジされたマニュアルを整備できていなかった。高機能すぎて、ITに疎い方はなかなか使えない。といったところで、結局あまり使えなくて手元でシートを作ってしまうようになってしまいました。
そうなると分析者はどうするかというと、データがないのでシートをかき集めてなんとかマスターになるデータを復元しようとがんばるわけです。とはいえ、そういった状況なので100パーセントの再現はできない。
また、そもそもそういった状態でマニュアルが機能していないので、オペレーションが不透明だと。「このデータの意味って何だろう？」となり各担当者にヒアリングしていかなきゃわからない。
なおかつ、問題なのが、各自でリストを管理しているということは、取引先の情報のセキュリティですね、扱い方にも当然担当者ごとにばらつきがあるよと。
Salesforceをがんばって入力していても担当者ごとに入力方法にばらつきがある。例えば取引先。toBのビジネスだったら、「飲食・宿泊」という業種の書き方もあれば、「飲食店」とか「飲食業」とか「レストラン」とか、担当者ごとに入力にばらつきがある。入力されているならまだいいんですけれど、各自が勝手に運用しているシートだとその項目がなかったりもする。
そんな状態なので、誤入力・未入力だらけのデータをがんばってかき集めても、不完全なデータにしかならないので、正直、データウェアハウスにいくらデータを突っ込んでも、使い物になりません。
こういった独自シートの目的とか作成手順は誰も残していません。マニュアルがあるわけでもないので、作った本人でさえ、半年もしちゃうと「これ何だったっけ？」ってなっちゃう。目の前の業務に専念するうちに忘れていってしまう。作った本人が一緒なのに、複数のシートで一貫性が欠けていることも多々あります。
こういった感じで、営業担当は、手元の顧客リストを運用し続けるしかありませんよね。誰かが音頭を取って整理しようとしても、経営者からすると「いや、営業はどんどん数字を上げてくれ。とにかく受注してくれ」と。
……まあ、そうですよね、「営業の人に高い金を払ってるからには、営業の仕事は受注して売上を取ることだ」というなかで、データを整理するきっかけもない。
分析を担当する人は、手元のシートでひとまず自分用にデータをかき集めて、なんとか担当案件を進める。進めるはいいものの、それはスナップショットのデータで低品質だと認識しているので、今後使うデータのマスターにはできない。
なので、結局データが管理されていないということが起きる。だけど、一方で「分析したい」とか「データを使いたい」「データを使って業務を改善したい」といった現場の要求はある。結果、暫定対応が繰り返されていき、管理されていないデータが増えていく。こういったことが往々にして起きています。
システムや運用が安定していないと、データを管理できない。故に機械学習で使うときにもろくなデータが残ってなかったりする。
今は営業の例を出しましたけど、いわゆるWebサービス開発でも、似たようなことってあると思うんです。
技術的負債という言葉をよく聞くように、「キャンペーン施策を打つから、こういった機能を追加しなきゃいけない。このログがまだ出てないけど、いったんログを出力するための開発は後回しにしておいてね」といった会話ってけっこうあると思うんですよ。そうすると、なかなか機械学習までたどり着かないというのがよくある話かなと思っています。（後半に続く）
