この記事はfreeeデータに関わる人たち Advent Calendar 2019の13日目のエントリーです。

こんにちは、freee株式会社のAIラボで機械学習を使ったサービスの開発とかしていますKenji Usuiです。今回は「データに関わる人たち」ということで機械学習ではなくデータ分析、特に可視化に関してデータサイエンティストである自分がよく使っているグラフを紹介します。

なんで使っているグラフを紹介するのか？

データを分析する際に可視化は極めて重要なプロセスです。テーブルデータの状態では人間は直感的に状態を理解することが困難であるからです。データをグラフに起こすことは適当にやって良いことではなく、グラフやデータの特性、求めることに応じて適切なグラフを用いる必要があります。
しかし、可視化の手法は数えきれないくらいたくさんあります。とはいえ、実際に現場で使うグラフはほんの一部です。そのほんの一部を紹介するとともに使うべきケースや頭に入れておくべきことを解説します。
データ分析をやり始めた人が可視化に困らないようなちょっとしたTIPSになれば幸いです。

よく使うグラフ

（以下画像をGoogleのヘルプから引用させていただきました）

棒グラフ

超定番ですね。とりあえずこれ使っておけば困りません。特にカテゴリごとの値を表示するときは棒グラフを使います。
棒グラフを使うときは横軸と縦軸の交点は 0 である必要があります。原点を 0 以外にすると実際よりも大きな変化があるように見えてしまうためです。これを怠るとグラフ警察に捕まるのでご注意を。

折れ線グラフ

連続した変化を示したいときに使うグラフです。特に時系列データを扱うときによく使いますね。
折れ線の線は点と点の補完を意味しています。つまり点と点が連続である必要があります。なので横軸がカテゴリ変数のような場合は折れ線グラフを使ってはいけません。
点と点を曲線で補完する曲線グラフというものもあるのですが描かれた曲線の根拠が不明瞭なので個人的には非推奨です。

ヒストグラム

出現頻度を調べるために使います。
ヒストグラムはビンの大きさによって印象が大きく変わることがあるので何パターンか作ってみて見比べたほうがよいです。例えば、ビンが大きいと全体の傾向が見やすいですが細かい変化を見逃しやすいです。
ヒストグラムは件数が少ないとグラフの形が変になりやすいのでサンプルがある程度あるときに使いたいですね。

100%積み上げ棒・折れ線グラフ

割合を示すときに使うグラフです。カテゴリのときは棒グラフ、時系列では折れ線グラフを使います。
詳しくは後述しますが、割合を示すときに円グラフは使うべきではないので100%積み上げグラフを使っています。こっちのほうが見やすいよね。

たまに使うグラフ

ボックスプロット（ヴァイオリンプロット）

複数の断面で分布を比較したいときに使うことが多いです。ヒストグラムだと並べづらいのでボックスプロットやヴァイオリンプロットを使います。ボックスプロットは分布の代表的な値が明記されるため比較がしやすく、ヴァイオリンプロットはヒストグラムとほぼ同様なので情報の欠落がなく精緻に分析するときに便利です。

散布図

データ点のばらつきを見るために使います。データ分析するときはカウントや割合などが多く2軸で扱うデータがあんまりないので出現頻度は低めです。あと、私が扱うデータは量が多いので散布図で表記しきれないこともありあんまり使わないです。

コホート

グラフというか分析方法でしょうか。時系列変化を追跡するときによく使う鉄板の可視化方法ですね。
「ユーザーが課金した時期によるChurn Rateの変化」みたいなものを追いかけたいときはたくさんあるはずなので、そういうときはコホート見るとかなり強力です。
強力なんですが案外コホートを作る機会ってそんなになかったりします。とはいえ作れないと困るのでどこかで一回くらい経験しておくと良いやつですね。

使ってはいけないグラフ

3Dグラフ

三次元空間を示すなど一部の例外を除いて3Dグラフ、特に3D円グラフを使ってはいけません。絶対にダメです。
3Dグラフは遠近法により手前の系列が大きく見えるため実際の値と見た目から感じる印象が乖離してしまい相手に誤認させる可能性が高い可視化手法です。見た目の派手さから使用する人が多くいますが正しいデータを伝えるという目的から外れるため非推奨です。というか、誤認させる目的で3Dグラフを使う人が多いため非常に印象が悪いです。そのため3Dグラフを使うと “そういう人” だと誤認されて信用を無くす可能性もあります。

3Dグラフ乱用 ダメ。ゼッタイ。

画像引用: https://www.cresco.co.jp/blog/entry/950/

円グラフ

3D円グラフに続き、普通の円グラフも非推奨です。
これは人間は円グラフから割合を読み取ることが苦手だからです。そのため、割合を示すときは基本的に棒グラフなど他のグラフを用いて可視化するほうが良いです。円グラフは並べて比較することも難しいので、その観点からも使うべきではないでしょう。詳しくは下記URLが実例がありとてもわかりやすいので是非ご参照ください。

https://jikitourai.net/dont-use-piechart

可視化に用いるグラフについて利用するケースやメリット・デメリットを踏まえて紹介させていただきました。
人間の頭は数値から判断することが苦手な一方で視覚から騙されやすいので可視化する際はそのことに注意しながら間違った理解・判断をしないように行うことが重要です。3Dグラフや円グラフのその最たる例といえるでしょう。もちろんそれ以外のグラフでもデータのタイプや可視化して見せたいものによって適切なグラフを用いた可視化はとても重要です。

グラフの選び方で意思決定の精度も変わってきます。本記事がグラフに対する理解の助けになれば幸いです。

機械学習のプロダクトマネジメント

機械学習は今最も注目されている技術の一つだろう。プロダクトに関わる様々な人間が機械学習をプロダクトに組み込んで革新的なことができないか考えていることは間違いない。

しかし、一方で機械学習を有効に利用できているケースはあまりにも少なく感じる。機械学習の活用できるケースは世間が考えているよりも少ないことは広く指摘されていることだ。また、データが整っていないため機械学習の学習が困難なケースも散見される。

このように技術的な観点から見た機械学習導入が上手く行かないケースは機械学習エンジニアの中では議論が進んでおり非機械学習エンジニアにも浸透しつつある。しかしプロダクトマネジメントの観点から述べられたケースは少ない。

これは私がプロダクトに機械学習を使うアイディアを取捨選択する際に気がついた共通点をまとめたものである。これからプロダクト開発に機械学習を使おうと考えている人がいたら是非一読していただきたい。

機械学習を “いつ” “どこ” に使うべきか

どの機能をどのくらい重視するか優先度をつけることはプロダクトマネジメントの重要な工程の一つである。リソースは常に限られている。パズルを組み立てるように、効率よく重要なものから開発していかなければならない。そのとき機械学習という歪なピースはどのように当てはめれば良いだろうか？

その指針として機械学習をプロダクトへ使うときのタイミングと機能の位置が非常に重要であることを述べたい。プロダクト開発のどのフェーズから機械学習を使い始めるべきなのか。プロダクトのどの機能に機械学習を使うべきなのか。

今、目の前に機械学習を使おうとしている課題を次のどれに当てはまるか分析してみて欲しい。

• プロダクトは新規 or 既存
• 機能はメイン or サブ

この2通り vs 2通りより得られる4つのパターンについて、それぞれ機械学習の導入を検討すべきか述べる。

新規プロダクトかつサブ機能

はっきり言おう、このケースでは機械学習を採用するべきではない。プロダクトのコアバリューに労力をつぎ込むべきである。サブの機能に機械学習を使い始めたが最後、多くのリソースは機械学習をなだめすかすことに費やされる。

一般のプロダクト開発においてもサブ機能のイテレーションは後回しにされるものであるが、何故か機械学習を使う場合に限っては「機械学習を使いたい」という気持ちが先行するケースを散見する。

サブ機能であればルールベースや古典的なアルゴリズムでそれらを代替することを検討しよう。構造化された数値データであれば基本的な統計量を用いることで明瞭な設計に成るし、文字列なら類似度はレーベンシュタイン距離で測ることができる。これらのアイディアを飛ばして機械学習を使う必要はないだろう。少なくとも機械学習を使う場合でもこれらのケースはベンチマークとして一度計算する必要がある。

既存プロダクトかつメイン機能

この場合は機械学習の利用を検討するべきだろう。新規プロダクトとしてルールベースや古典的なアルゴリズムでリリースした後のイテレーションなどである。是非とも機械学習でプロダクトの価値が上昇するのか検討するべきだ。例えばAmazonがレコメンドエンジンを強化するようなものであり、ここの強化は大きな価値を生み出すだろう。

ただし、機械学習を使った機能のイテレーションが難しいことは頭に入れておくべき重要な事項である。今まで出来ていたことが突然できなくなるケースはありえる。例えば数値上は全体精度が向上していても今まで正しく推測出来ていたものが誤って推測されるようになった場合はユーザーから見たらデグレードだ。どのような価値基準の元にイテレーションしていくのか予め議論すべきであろう。

既存プロダクトかつサブ機能

このケースも機械学習を検討しても良いだろう。例えばコアバリューへの投資が落ち着き周辺の性能の低さがネックになりつつあるケースは機械学習をプロダクトに使うのにちょうど良い場面である。

ただし、機械学習をむやみに用いることは厳禁である。機械学習の開発には特殊な人材が未だ必要であるし、保守・運用は他のプロダクトとは異なってくる。常に精度に目を配る必要も出てくる。

目の前の課題がを要件定義やUIの問題として解決できないか検討すべきだ。機械学習は使わないで済むならそれに越したことはない。

新規プロダクトかつメイン機能

このケースでの機械学習の利用は十分に検討すべきだ。というのも機械学習が無くともルールベースでプロダクトとして成り立つケースが多々ある。新規プロダクトは早くリリースすることが非常に重要なので、プロダクトとして最低限のUXを確保できるならば機械学習は後のイテレーションで導入することを検討しよう。

また機械学習を使う場合でも「精度にこだわり過ぎない」ように注意する必要がある。機械学習エンジニアとして高い精度を出したい気持ちは痛いほど理解できるが、プロダクトとして最低限の精度がでるならばリリースを優先しよう。

以上4パターンに分けて機械学習の利用の是非を述べた。もちろん実際の現場では複雑に要因が絡むので単純に考えることは難しい。しかし、何事も検討するにはスタート地点が必要である。非機械学習エンジニアや非エンジニアに限らずプロダクトへ機械学習の使用を検討する際のフレームワークとなれば幸いである。