あなたは正しく理解できていますか?データ解析を行う手順3/3

参考資料:
データ解析の実務プロセス入門

著者:あんちべ

出版社: 森北出版

前回の記事でデータ解析フローの2つ目、分析計画について紹介しました。

この記事では、残りの各プロセスとその流れを学び、実践データ解析をするためにとるべき行動を見ていきましょう。

3.データ設計

家がレンガでできているとはいってもレンガの集積を家とは言わないし、単なる情報の集積をデータとは言わない
―ポアンカレ

目の前にあるデータが単なるゴミの山ならそこから宝物は出てきません。
単にデータを大量に集め、その中に宝物が含まれていますようにと祈るのではなく、データの山の中に宝物が含まれているように意識して設計するする必要があります。
寿司屋に行った時「寿司はネタが7割、職人3割だよ」と職人から教えていただきました。これは寿司はネタが価値の大半の要素を占めるという意味ですが、では職人の技は大した貢献をしてないということでしょうか。そうではありません。
そもそもの仕入先をどこにするか、その仕入先から実際に何を選ぶか、仕入れたネタをどう保存するかということにこそ職人の腕の見せ所があり。職人の力量は寿司を物理的に握ることだけに発揮されるのではありません。
データ解析も全く同じで、データを分析ツールにかけるところではなく、どのようなデータをどう設計し、収集し、保存するかが成果を大きく左右します。
また、分析手法とデータは密接に結びつくものです。
各分析手法はデータの性質や形式によって利用可能のものが異なります。
そのため、データ設計を考える際、同時に分析手法についても決めてしまえば良いと思うかもしれません。しかし、何らかの事情で手法を制限されているのでもない限り、 実際の分析では色々な手法を適用することになるため、分析手法に特化したデータを設計するのは得策ではありません。

4.データ収集・保存

Web からデータを収集するには

  1. データを配布しているサイトから取得する
  2. 提供されているデータ出力機能(API)を 利用する
  3. Web サイトから収集(クローリング)してくる
  4. 自前のサービスやウェブサイトにログ(行動・履歴のデータ) を出力する仕組みを設ける

という方式があります。
各方式とも、データ設計に合わせてデータ収集ツールを利用(1の場合は手動で行うこともあります)し、取得したデータをデータ解析用のデータベースに格納するのが一般的です。
あるいは、自ら運営している自社サービスなどの場合は、ユーザーのログを取得できる仕組みを設けることも考えられます。
データを収集するにあたり、単に公開されているファイルをダウンロードするだけなら簡単ですが、大抵の場合は何らかのプログラムを利用する必要があり、自作せざるを得ないことも多々あります。
それでも一度きりのデータ収集であれば大した問題でありませんが、常時データを収集し続けるとなると大きな困難が立ちはだかります。
特にTwitterやFacebookなどの SNS はリアルタイムでデータを出力しているため、解析条件によってはリアルタイム収集の仕組みを作る必要もあります。
また、システム稼働させ続けることもにも労力を割く必要があります。

データ収集時の泥臭い戦い

データ収集では「何らかのトラブルでデータを取得できない」、「データの仕様が変わってしまう」、「データ格納スペースの容量が足りなくなってしまう」、「分析の要件が増えたり変更されたりで格納するデータが変更される」などの混乱との泥臭い戦いがつきものです。
決して一度ツールの設定をすればあとは自動で毎日動くことが保証されるものではありません。
これはエンジニアリングが大きな比重を占める部分であり、残念ながら専門外の人間が一朝一夕で身に付けられるスキルではありません。

5.データの前処理

収集したデータをそのまま分析に利用できるとは限りません。
多くの場合、何らかの処理を施す必要があります。
収集したデータを分析しやすいよう前もって加工しておく処理のことを前処理と言います。

前処理の具体的な中身は

  • 分析ツールに沿った形式への変換
  • データに抜け漏れや異常が発生していないかの確認
  • 分析用のサーバやフォルダにデータを移す
  • 適切なファイル名が変数名をつけてデータを管理する

など多岐にわたります。
要件に合わせて様々の前処理が必要になります。

6.分析手法選択と適用

データを分析ツールにかけて何らかの実力を得るステップです。
このプロセスで最も重要なことは、ここに時間をかけすぎないことです。
このプロセスに熱中しても、設定された目的に対し劇的な改善につながることは稀だからです。
分析ツールや手法について、 多少パラメータをいじって精度を調整したり分析ツール上で試行錯誤したりすることもうあるでしょう。
ただし、そう長い時間をかけるべきではありません。
精度が想定を大幅に下回っているとか意味不明な分析結果しか出ない時に、分析ツールをいじくり回しても成果に結びつくことは本当に少ないのです。
その状況に陥った時は、これ以前のプロセスに誤りがないかを振り返ってみましょう。

とはいえ、データ分析ツール放り込んで試行錯誤するのはデータ解析の華の部分であり、パラメーターや手法を変えたりして少しずつ精度を上げていくのは職人気質の方にはとても面白いプロセスであることは認めざるを得ません。
私は時間をかけすぎないように30分だけ分析してその結果について検証し知見を記述するという手順を取るようにしています。
新たな知見がその30分で得られなくなったらそこで一旦分析ストップするという手順をこのプロセスに対して課しています。
もちろん、データサイズによっては分析ツールが結果を出力するまでに30分以上かかったり、分析ツールに不慣れな場合はひとつの分析手法を適用するだけでかなりの時間がかかってしまったりすることもあるため、必ず30分に作業止めるべきだというわけではありませんが、何らかの制限をかけて分析を続けるべきかどうかをあらかじめ決めておきましょう。

7.分析結果の解釈

データを分析ツールに放り込み様々な分析結果やグラフが表示されると、もうこれでデータ解析は終わったも同然だと思うかもしれません。しかし、 残念ながらそうではありません。
分析結果の生の数値やグラフそのものに宿る価値を乏しく、それらの分析結果をもとにドメイン知識からの検証、積み重ねた議論によって解釈されて初めて有益な知見が見いだせます。
あくまでも価値は解釈によって生み出されます。
プレゼン資料に出力結果をそのまま貼り付けるだけで終わるのはやめましょう。

一つの事実と複数の解釈

解釈の一つの事実から複数生まれることがあります。
あるコーヒーショップでコーヒーの価格を下げたら売り上げ伸びたとします。
この事実を踏まえて「価格を下げれば今まで価格を理由として購入しなかった層を顧客として取り込むことができる」 と価格引き下げを肯定的に解釈することも、「価格を下げたことによって今まで築いてきたブランド力が下がってしまい、短期的な売上向上と引き換えに将来時点で取り返しのつかない損失を生む」と否定的な解釈をすることも可能です。
どちらの解釈に基づいて判断すべきか(つまり値下げ戦略を継続すべきかどうか)はこれだけの情報では不明であり、さらにブランド認知などの別調査が必要です。
肝心なことは、前提や懸念点が複数あると、同じ事実から複数の解釈を導き出せるということです。
解釈は、データから 導かれた事実と前提や懸念点などの考慮材料とのセットで生み出す必要があります。

独りよがりな解釈を避けるために

分析結果を解釈する上での注意点として、どうしたの独りよがりになりがちなところです。
これはデータ解析の初心者でも熟練者でもその危険性は変わりません。
最も簡単な解決方法は他人にレビューしてもらうことです。
関係者を交え、複数人で解釈をする・解釈の妥当性を検討する場を設けましょう。
どうしても相談相手を確保できず自分一人でやらざるを得ない場合は、一旦日を空けてみましょう。
一度データ解析から離れ冷静になると、分析結果もその解釈のまた違って見えるようになります。

8.施策の提案

良いデータ解析をすることはあくまで手段であり、それ自体が目的ではありません。
本来の目的である売上貢献や利用者数増加、問題点の改善などを達成するには意思決定者にデータ解析の結果を理解してもらい、実践につなげなければなりません。
データ解析者が「意思決定者の頭が固くてせっかくの分析結果を理解してもらえなかった」、「解析自体は良かったが、現場のせいで実践に至らなかった」などと言い訳するのは最悪です。
問題があるならばデータ解析者が主体的に解決へと乗り出しましょう。
データ解析者はデータ解析のすべてに責任を持つべきです。
統計結果を理解させ、処方箋を出し、実施させるまでがデータ解析者の仕事です。

適切な提案のために

提案時は何が事実・仮説・解釈なのかを明確にしなければなりません。
これを混同して伝えると適切な意思決定ができません。
事実と解釈の部分を混同させてしまった提案を見ることはよくありますが、それは絶対に避けるべきです。
解釈や仮説は正誤・選択について議論が必要な未確定の部分であり、その議論の土台となる確定的な部分が事実です。
また、一つの分析結果でも解釈や提案の仕方は複数考えられます。
データや分析結果を前に議論が粉砕し、最終的に本来の目的や仮設から離れてしまうケースもよくあります。
目的と事実をベースに、解釈や提案についてよく吟味しましょう。
提案時に伝えるべき内容には以下のものがあります。

目的

最終的に達成すべきことです。
これを実現させるためにデータ解析を行います。

仮説

データ解析を進める際の出発点となる、その時点での現象の説明です。
「 Y という現象が発生している。これは X が原因ではないだろうか」というように論理を構築してきます。
仮説設定時点では仮説そのものの真偽を問う必要はなく、その後のデータ解析の段階で真偽を検討していくことになります。

事実

データが正しく収集されたという前提のもと、データから直ちに導けるものでかつ誰が見ても納得するものです。
これにあなたの予想や推測は一切交えてはなりません。

解釈

データ分析結果に対するあなたの考えです。
前提や考慮点によって複数出てくることがあります。
事実から誤りなく導かれているか検証が必要です。

予測

データで解析結果に基づいて未来の状態を推測することです。
これも前提や考慮点によって複数の予測が生じます。
複数の予測を生じるケースとしては、例えばある新商品の売上を予測する際、競合商品が出るシナリオと出ないシナリオで別々に売上予測値を出す場合などが考えられます。

提案

事実や解釈、予測をもとに実践すべき具体的な施策案です。
解釈から論理的に誤りなく結論が導かれているかチェックする必要があります。
複数の提案の中から重要視する側面ごとに最良の選択肢を提示することも、意思決定を行いやすくするためには重要です。

理論や数字だけで物事を理解するのは困難なことがあります。
必須ではありませんが、抽象度が高い話をする場合は出来る限り差し込んだ方が良いでしょう。
式を含む提案なら、具体的に値を当てはめたりしてみせるのも効果的です。

事実と解釈

特に混同してはならない事実と解釈の分別を中心に、気温とビールの売上を例で考えてみましょう。
ビールの売上と気温との関係について、10年分のデータを参照した結果、「気温が25℃の状態のビールの売り上げを1とすると、27℃では1.2倍、29℃では1.4倍になる」という関係だったとします。
これは事実です。
それに対し「暑ければ暑いほどビールが売れる」は解釈であり、「25℃を基準として気温2℃上がるごとに20%すつ売上が向上する」は予測です。
どちらも事実ではありません。
このデータは25℃から29℃までの気温の変化と売上の変化の関係を示してるだけであって、他の気温でも同じ関係を保つという根拠ではありません。
「暑ければ暑いほどビールが売れる」はまだ正しいような気もしますが、先ほどの予測から従う「8℃から10℃になったらビールの売り上げは20%上がる」は直感に反するのではないでしょう。
か。
ここで説明しているのは「先ほどの解釈や予測は誤りである」ということではありません。
データに含まれていない部分についてまでデータから得られた結果を適用するのは解釈や予測であって、 事実とは区別すべきだということです

「明日の予想気温は31℃であると気象庁が発表している」は一見予測のようですが、捉え方によって事実にも予測にもなります。
もし、あなたが気象庁で予想気温を算出する立場にあるならば、様々なデータから導かれる予想気温は予測です。
一方、あなたが気象庁の予想気温に参考にして何らかの経営戦略を立てるという立場であるならば、予想気温は事実です。
ただし、その場合には「明日の気温は31℃である」 ことではなく「気象庁が明日の予想気温は31℃であると表明していること」が事実となります。
このように、立場によって何が事実なのかは異なります。

「明日の予想気温は31℃なので、気温が上がれば上がるほどビールが売れるため、29℃の日よりも多めにビールを仕入れて売り切れによる商機損失を防ぐべきである具体的には25℃の日の60%増しの仕入れをすべきである」 、これは提案です。
この提案の懸念点として、本当に29°より気温が上がればビールが売れるのか、25℃を基準として2℃上がるごとに20%売上向上するという予測が正しいのかという疑問があります。
ただし、懸念点があるからその提案が間違っているというわけではありません。
不確定要素を含んだ話をする場合、100%確実な提案は不可能です。
事実とその解釈、解釈と提案の間に飛躍や誤りがないか、その提案が仮に失敗してしまった時の損失はどの程度なのかなどを天秤にかけて意思決定をします。
最終的に選択した提案を元に実施手順や実施責任・担当者を決定し、施策へと繋げます。

9. 実施と検証

ここまでで決定されたことを実施するステップです。
データ解析者は施策を滞りなく実施すること、実施後の効果検証を行いやすくするために実施計画と実際の実施状況に何らかのズレがないかや、想定外の外部要因が発生していないかなどを観測する必要があります。

ここで発生し得る最悪の事態は、提案した施策が実施されないことです。
施策を実施するには、 例えば Web サービス企業からの依頼であった場合、経営層、サービスのマネージャーなどの管理者層、現場のデザイナーなど関係者全体の協力を得なければならないことがほとんどです。
データ解析者が経営層、あるいは管理者層から依頼を受けて施策を提案し、その提案が有効であり実践すべきと認められたとしても、そこでデータ解析者の仕事は終わりではありません。
放っておいても依頼者が施策を実施してくれるということは、むしろまれだと言っても良いでしょう。
データ解析者は出来る限りにおいて、各関係者にアプローチをしましょう。

スケジュールの設定

権限的に可能であるならば、データ解析者が施策実施のスケジュール設定にも関わる方が良いでしょう。
施策実施について、「どうしたらよいですか」「いつまでに決めてもらえますか」と受け身でいると、施策実現が後回しにされてしまう可能性があります。
「この施策を実現するために何が必要で、誰が何を決めなくてはならないのか」、「いつまでに◯◯を決めますか、いつ頃実現できそうですか」 と確認しましょう。

関係者間の調整

データ解析には様々な立場の人が関わりますが、関係者ごとに役割やデータ解析によるメリット・デメリットが異なります。
提案施策の実施により、経営層には売上改善、管理者層にはサービス品質向上、デザイナーにはユーザーにより好まれるデザインの傾向が何かつかめるなど、各関係者にとってメリットがあることを認識していただければ一丸となって施策実施に取り組むことができます。
外部のコンサルタントや上からの一方的になお達しだけで施策実施がうまく成されると期待するのはやめましょう。
また、ときには各関係者の利害が一致しないこともあります。
その場合、 最終的には全社的なメリットがどの程度あるかを明確にして、それが各関係者が直接かぶるデメリットを上回ることを説明し、また、発生したデメリットを補償するような働きかけることが大切です。
全社的にはメリットがあるからといって、ある関係者一部門だけが割を食うような施策は内部から批判が生まれ、施策実施の大きな障壁となるからです。
これは、一見データ解析者の職務を超えた話のように聞こえるかもしれません。しかし、何度も説明するように、データ解析は何らかの価値につなげてこそ意味がある取り組みです。
施策実施が滞りなく進むよう、できる限り補助をしましょう。

10.反省、さらなる改善のために…

施策後に効果検証を怠ってはなりません。
ただし、効果検証は解析手法の適用以上の困難が待ってます。
ほとんどの場合、施策の成否に外部要因が深く入り込んできます。
そして外部要因をまったく予想外のところからやってくるケースもあります。
とあるソーシャルゲームの例ですが、全く新規利用登録キャンペーンや広告を打ったわけでもないのに新規利用者登録が跳ね上がり、要因を探っていたらたまたま著名な漫画家がそのソーシャルゲームを絶賛しているのを発見したことがあります。
巨大掲示板や SNS でそれが話題になって一気に知名度が上がっていたのです。
このような想定外の要因が発生するのが実データです。
実データを施策以外にも様々な要因によって変化を見せるため、その中から施策による変化を抽出して施策の成否を検証しなければなりません。
単純全体の売上が上がった下がっただけをもって、成否については結論を下さないように心掛けてください。

参考資料:
データ解析の実務プロセス入門

著者:あんちべ

出版社: 森北出版