株式会社Crosstab 代表取締役 漆畑 充

何かが足りないレポート…

データ解析のプロジェクト(仮説検証、予測モデル構築など)でクライアントや上司にレポートを提出した時に、苦虫を噛み潰したように「まあ、うーん悪くは無いんだけど…」という反応をされた経験はありますでしょうか?またはその反対に、部下や分析会社から出てきたレポートに対して同じような反応をした経験はありますでしょうか?

一般的な統計数理及び機械学習の作法としては間違ったことはしていないようです。では何故このようなことが起こるのでしょうか。

このような場合、受け手(クライアントや上司)はレポート全体に「雑さ」を感じていることが多いです。受け手はその事業のプロですので彼らが何故そう感じるのかを考えることはより良い分析のヒントになるはずです。なお受け手自身の分析リテラシーが高い場合はこの「雑さ」を言語化することができるのですが、実際はそのような例はあまりありません。

原因

体系的に議論するよりは、筆者の経験からこのような印象を与えてしまう理由をいくつかあげてみます。

① 基礎集計表が無いため全体や小計の数値が不明

 →受け手は事業のプロです。そのため精緻に事業の数値を把握しています。そのためグラフに違和感を感じた場合、元の数値を見せてくれと言われることも多いです。その場合Appendixでも良いので基礎集計を用意しておかないと「気が利かない」と思われます。

② 何故か前回報告の時と値が変わっている

 →再現性の問題です。これもよく見かけるのですが、乱数を固定していないまたは処理を前回から変更した場合に発生します。乱数は固定する、処理の変更は補足として記載するなどが必要です。優秀なビジネスマンほど良く数値を見ており、社内報告でも同じ数値で報告します。そのため毎回値が変わるようでは困るのです。(特に金融のお客様は1桁目までしっかり確認する習慣があります)

③ 明らかに異常な数値が出ている

 →間違っていてもエラーメッセージの出力がない作業で、不具合が起きていることが多いです。例えば、良くあるのは巨大なcsvをexcelで読み、保存してしまい行数制限によりある行以降が消えてしまっている。(excelは1,048,576 が行の最大数ですのでpythonで読み込んだ後に行数を確認しましょう)またこれもcsvを開いて閉じたりした場合大きな数値の下何桁かが0になってしまっているなどです。これは基礎集計を注意深く行えば回避できることが多いです。そのため①の基礎集計がないというのが間接的にこちらに響いています。

 →その他にもカテゴリ変数のコードが間違っている。例えばお客様システム上で性別という項目は1=男性、2=女性と定義されているとのことでしたが実際はその逆になっていたようです。実際にあった話です。集計した段階で本来女性が多いサービスなのにそうなっていないため、問い合わせたところで発覚しました。

 上記2つの例では分析者側に直接の落ち度がないとも言えます。特に前者の例ではお客様がシステムからファイルを抽出する場合に破損していたりすることも多いです。一方で分析依頼側である受け手はそうは見ません。プロとして受領データを注意深く観察しなかったことに「雑さ」を感じるのです。

④ 目的変数や説明変数の設定不備

 →例えばサブスクリプションの解約に至る要因を分析するということを考えます。目的変数を「解約フラグ」とし、説明変数を解約ユーザの特徴とします。特徴の一つとして解約予兆行動が考えられますが、解約ユーザは解約方法を探すためサービスサイトにアクセスするので直近のPVが増えます。従って解約直前の行動を説明変数として採用してしまうと、「直近サービスサイトのPVが多いユーザが解約しやすい」という誤った結論を導いてしまいます。

 →またECサイトなどのようにユーザが明確に「解約」の意思を示さない離脱分析の例では、離脱の定義を分析側で設定しないといけません。年に一度しか購買しないような商材に対して「離脱=3ヵ月購買なし」とするのは不適切です。

どうするか

このようなことが起こる主な原因は「データに対する理解不足」と「業務に対する理解不足」からです。

データに対する理解不足を解消するには、分析作業の初期に基礎集計などのデータを理解するためにまとまった時間をとることです。ある程度やっていると必ずデータに対しての疑問がいくつか出てくるはずです。それらをリストにして関係者へのヒアリングを行いましょう。ステークホルダの中には「早く分析に入れ」とせかしてくるタイプもいますが、十分な時間をとりましょう。できればデータ精査の結果を彼らを交えてレビューしたいところです。

後者に関しては業務知識を身に着けるというのが月並みな意見ですが、一朝一夕にはできないと思います。従ってお客様や担当者にとにかくわからないことを聞くということが重要です。ただし少し調べればわかるようなことを聞くのではなく、調べた上で自分はこう考えた、というような仮説を提示するようにしましょう。重要なのはお客様やステークホルダーのビジネスを理解したいという態度です。

また普段からビジネスの教養として、業界本やお客様の業界紙や専門雑誌などを読む、中小企業診断士試験の勉強をするなどがあります。

なぜこのようなことを書いたか

実のところデータ解析のプロジェクトにおいて数理統計の知識の有無やプログラミングの巧拙でトラブルになることはあまりないのです。一方でデータに対しての理解や業務知識の有無は成果物のクオリティに大きな影響を与えます。しかしデータ解析一般論においてこの点は軽視されていると感じています。当然といえば当然ですが、数理統計や機械学習が好きでこの仕事をしている人ほどその傾向があります。優秀なスキルセットがありながらソフトスキルの欠如によりその評価を落とすのはもったいないです。そのために参考になればと思い書きました。

またデータ解析の成果物に失望してしまうステークホルダーを減らしたいという意向もあります。はじめて取り組んだ成果物が、本稿で書いた「雑な」ものであった場合データ解析に対する期待値は地に落ちてしまいます。これは解析者、ステークホルダー双方にとってデメリットです。

コンビニのおにぎりの見た目から試食を拒否したシェフが話題になりました。コンビニはおにぎりを沢山の人に入手しやすい価格で提供するのが使命ですので、見た目がどうのというのは見当違いです。データ分析でも大衆向けの廉価分析であるならばここまで気にすることはないと思います。しかし高付加価値のコンサルティング業務として行う場合料理でいうところの見た目というのも重要になります。一度「雑さ」みたいなものを感じさせてしまうと、モデルの精度や技術に関する中身まで評価してもらえなくなるのです。

モデル精度もさることながら、「精度の高い分析」が重要というお話でした。