バイアスと戯れる

Rと言語処理と(Rによる言語処理100本ノック終了)

失われたtidyを求めて

はじめに

 この記事は「tidyポエム Advent Calendar 2017」の7日目の記事です(ほんとうにポエムです)。

adventar.org

 フランスの小説家マルセル・プルーストの『失われた時を求めて』で、主人公がマドレーヌを紅茶に浸したとき、その香りをきっかけに幼年期の記憶が鮮やかに蘇るという描写があり、これにちなんで特定の感覚からそれにまつわる過去の記憶や感情が呼び覚まされる心理現象を「プルースト効果」と呼ぶそうです。

 認知バイアスを引き起こしそうな心理現象のお話ではなく、tidyなデータについてが本題です。
 また、「データ分析が活かされる組織の5つの要素」のうち、「データ」の面に関する話でもあります(他の要素は下記で話したり書いたりしています)。

 自身が体感・見聞した中でこうした方が良いと考えて進めているやり方であり、よりいい方法があれば取り入れていきたいと思います。
 データの品質や管理、ガバナンスなどの話題もありますが、この記事のテーマはデータ整理(主に事業会社の分析者の立場からの内容)に関してです。

 参考資料として、下記の資料を読んでおきましょう。

整理されたデータの必要性

 データに一貫性があり、構造がわかりやすいデータで分析できると非常に効率がよく分析が捗ります。
 ログ取得と集計と可視化がひとつの大きなテーブルにまとめられ、用途によって同じカラムでも意味合いが異なるというテーブルしかない状況(加えてデバイスが異なると同じカラム名でも値が変わる)では、データの把握や値の確認に多大な時間と労力がかかり、精神がガリガリと削られていきます。仕様書ですか、見かけないですねぇ。

 tidyなデータ設計は分析を効率良く進める上で必要になるでしょう。
 しかし、往々にしてデータとは綺麗に整ったものばかりではありません。
 設計者がデータベースの知識がなかったり、自分で分析したことがなかったり、集計ツールに任せて実ログを日常的に見ていなかったりすると、おかしさに気づかないまま負債が溜め込まれていきます。
 すると「データならたくさんあるから分析できる」と経営層や部長陣に認識され、データ整備に投資がされない状況に陥り、ひょんなことで分析することになると負債のままで使わないといけなくなって疲弊していきます。
 このような使えないデータがたくさんある状況はない以上に厄介だったりします(分析に役に立たない大量データは負債データと呼びましょう。ゴミデータと称すると、未だに生み出し続けているチームに角が立ちます)。
 なお『ゴミデータに遭遇したら逃げろ』と、先日のJapanRにて経験者の方よりアドバイスがありましたが、事業会社で分析担当者が部署にひとりしかいない状況でのエンカウントは大魔王に対峙したときと近いでしょう。
 このような負債データでもなんとかして使えるような分析結果を出さないといけないことはままあります(もちろん、そもそも負債データを作り出さければこの上なく良いのですが、前述の通り、いくらでも生み出されてしまいます)。

 こういう状況で分析を効率良く進めるためにデータ整理を始める際は、必要なところだけ整理しましょう。
 すべてのデータをtidyに染める必要はありません。messyな負債データをtidy化するにはコストが大きいですし、行うにしても根元を絶つ方が賢明です。
 まずは自分が扱う範囲に限定して成果を出して、分析する上でないと進まないと交渉しましょう。

整理すべきデータ

 それではどういうデータをtidyにすればいいでしょうか。
 tidyにするデータを定義するにはデータを意味付けして分ける必要があります。
 ここでは「生データ、集計加工データ、分析データ、最適化データ」という利用フェーズに応じた4つに分けています。
 生データは分析環境に集められたままのデータです。
 集計加工データは、前処理が施されたり、データ量が大きすぎるものをある程度決まった軸で仮集計したりした、分析前段階のデータです。
 分析データは、文字通り分析結果になります。
 最適化データは、BIツールやAPIで利用するにはパフォーマンスが足らないを分析結果データをチューニングしたものです。

 余談ですが、データ分析を料理に喩えることがありますがデータ分析自体はそうでもデータ分析業務になるとレストラン運営に近くなるでしょうか。 機械学習エンジニアは食品工場運営かもしれませんね。
 その喩えで表現するなら、こんな感じでしょうか。
 収穫されたままの状態が「生データ」。大きな倉庫などに入っています。
 スーパーで売られている状態が「集計加工データ」。手にとって見やすい状態になっています。
 味はさておき食べられる状態が「分析データ」。味見もできる状態です。
 味を整えたり、盛り付けを綺麗にしたりした状態が「最適化データ」。売り物として提供する状態です。
 これらの処理が流れ作業で進んでいき、美味しくいただけるようになっていると分析が活用されています。

データ整理をはじめる

 データ分析者が主に関わるところは「集計加工データ」と「分析データ」です。(もちろん、仕入れから味付け・盛り付けまでも行う方もいます)
 生データは加工はせず、とにかく一箇所に自動的に集めることを目指します。材料がなければ始まりません(今回は触れません)。
 データをひとつの環境に集めることは分析者であれば必要性を感じるでしょう。ここで生データが腐っていたらどうしようもありません。逃げましょう。
 最適化データは分析結果のサービス利用やBIツールなどの可視化や絡むため、最終的な結果(お客さんの趣味・嗜好、ニーズ)をヒアリングして調整しておきましょう(こちらも今回は触れません)。
 ここがうまくいけば分析の品質は問われないケースが多いですが、将来的な不安を覚えますね(傷んだ食材を薬で滅菌し、味がなくなるくらい茹でても、調味料で濃く味付けして綺麗に盛り付けていれば満足してもらえる人も大勢いらっしゃいそうですね)。

 集計・加工データは大規模データ処理をこなせるエンジニア(データエンジニア)がいるならお任せしたいですが、必要になる「分析軸」まで鑑みるスキルを持つ方々はレアですので(いらっしゃる場合は、常に感謝を忘れないようにしましょう)、分析者が要求を伝えて同じような集計をしてもらうのが多くなります。
 ただし集計ばかりお願いすると対応してくださる方々のヘイト値が上がっていきますので、依頼する際にはご注意を。
 できるだけ自分でこなす、そもそも人がいないというときは、クラウド環境を活用して札束で殴りましょう。
 その際には分析に必要になる部分だけに限ってtidy化していきます。欲張って全部をやっても分析自体が進まないですし(評価者はデータを整理しても喜んではくれません)、せっかく整えたデータが不要になるケースもあります。
 売上に繋がるコンバージョンを最優先に、コストに繋がる広告(ただし、限りなくmessyなので開けない方がいい箱かもしれません)、ユーザー情報などは積極的にデータ整理していきましょう。

 分析データは分析者自身が主導して作っていきます。
 ここからはtidyverseの出番になり、今まで培ってきた分析スキルの見せ所でもあります。圧倒的な分析成果をあげましょう。

 ただし、「わーい、たのしー」と分析に集中するのもいいですが、分析の後のことも考えておきましょう。
 分析経験のみの方だとアドホックな作りになりがちになるので、設計をエンジニアの方に意見をもらったり、属人化を避けるためにワークフローエンジン(Azkaban, Airflow, Luigiなどなど。R言語で管理したいところですが、見た限りでは見当たりません)を導入していきましょう。
 周りにエンジニアがいなかったり、インフラにリソースを割けなくてもテーブル定義書やER図がデータフロー図を作ることを心がけてください。
 RにはDiagrammeRがありますので、こちらで作成してもいいですよ。
 これらは自分を助け、身を守ります(分析結果が運用される始めるときに調べ直してミスに気づいたり、納品後に必要なデータを削除してしまっていたり、データ更新前に更新後のデータが参照されていたり、想像するだけでもおそろしいことが不思議なことに分析現場では起こります)。
 また分析自体がうまくいかなくても、これらの蓄積は他でも分析を継続していく上で資産になりえます。
 自分の担当領域は分析だから分析しかしないと特化するのもいいですが、幅を広げていくと分析自体の幅も広がります。

おわりに

 こうして継続的にデータ整理を行いながら分析していくと、散らかっていたデータも徐々に整頓されていき、分析しやすいデータが揃ってきます。
 今までは時間がかかりすぎてできなかった分析も手早くこなせるようになっていき、あのときは逃げ出した魔王もいつか倒せることでしょう。
 ですが油断は禁物です。
 messyなデータはどこからともなく現れ、あれだけ丹精込めて作り上げたtidyなデータをまたたく間に蹂躙していきます。

 tidyがある限り、messyもまたあります。
 ふたたび何者かがmessyを生み出します。

 messyなデータとの闘争に終わりはありません。
 今日もまたどこかでtidyが失われました。

--- 

 続くかもしれないし、続かないかもしれない。