「失敗しない データ分析・AIのビジネス導入」はいいぞ

統計学・機械学習の本はそれなりに読みましたが、分析プロジェクトについて書かれた本は読んだことがなかったので仕事の参考にしたいと思い読んでみました！

失敗しない データ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで

まずブレインパッドさんのノウハウを本を通して公開しているのがすごいですし、売上だけを求めるのではなくデータ分析で社会を良くしたいという思いが伝わってくるのが素敵ですよね。

本エントリーでは、

• 本書を読んだ所感
• 自分の仕事との関連
• 自分が分析していく際に忘れちゃいけないこと

を織り交ぜてまとめておきたいと思います！

目次

想定している読者

本書によると下記に該当する方々が対象だそうです。

1. 全社的にデータ活用を推進する立場にある方
2. 社内のデータ分析・AI専門部署の立ち上げに参画する、リーダーレベルの方
3. 現場でデータ分析・AI導入プロジェクトを率いるプロジェクトマネージャー、参加するプロジェクトメンバー

私は3に該当するのですが、本書はぜひ1, 2の方々に読んで欲しい1冊です。

というのも、データ分析のプロジェクトはスタート時が一番大事だと思っていて、

• そもそもデータ分析をする必要があるのか
• どんなデータをどうやって集めていくか
• どのような状態になればプロジェクトが成功したと言えるか

など後戻りするのに時間がかかってしまうことに関しては、最初に関係者間で適切に決めておくべきだと思います。後になって言ったことをひっくり返してくるお客さんもいるので、身を護るためにもちゃんと形として合意をとりながら進めることは大事ですよね。

データ分析界隈でよく用いられる言葉に

Garbage in, garbage out*1

という言葉がありますが、仕事をしているとまさにその通りだなと感じるシーンが多いです。自分は別に本書に携わっているわけでも、著者に知り合いがいるわけでもないですが、1, 2の意思決定権のある方が本書を読み、3のメンバーが幸せに仕事できる環境が1つでも増えればいいなと思っています。

データ分析の心得

データ分析は、目的ではなくあくまでも手段である。

これは本書でも似たようなことが書かれてましたが、分析が好きすぎるあまりついつい自己目的化してしまって分析することが目的になってしまうことが最初のうちはありますよね。

分析コンサルにおけるデータ分析とは、ビジネスにおける意思決定を助ける1つの強力な"手段"であることを忘れないようにしなければなりません。

クライアントと話していると「仮説とかないけど、データがたくさんあるから分析してみたい（意訳）」といったことを言われることがありますが、何回も言うようにデータ分析は"手段"なので、まずは「現状を定量的に理解すること」や「何を明らかにしたいのかを社内で話し合ってもらうこと」を勧めるべきだと思います。

逆に「解決したいことはたくさんあるけど、(他社と比較する)データがない」というクライアントには、私のいる会社でアンケートデータを取ったり、購買データを使ったりして分析し、課題を解決していくケースも多いです。この手のクライアントは分析に対するリテラシーやその業界の知識が豊富なケースが多く、難しい要求が多いですが、その分楽しくもあります。

クライアントがデータを適切に見られるようリテラシーを高めていくことも仕事の一つであり、分析屋の市場を拡大する一助になると私は信じています。

ちなみに私は「分析とは何か？」と聞かれたら、野球の松坂大輔選手の言葉*2を引用して

自信を確信に変えてくれるもの

と答えます。（結構気に入ってる）（でも、聞かれたことない）

つまり、分析は今までKKD(勘、経験、度胸)で行ってきたものを統計的な裏付けを持って意思決定できるよう手助けをしてくれるものであると考えています。

分析プロジェクトの流れ

本書によるとデータ分析の仕事は

1. データ分析プロジェクトの立ち上げ
2. PoC(Proof-of-Concept)*3
3. ビジネス適用（システムとしてデプロイ）

の順番に進めるとあります。

実際、本もこの流れに沿って、詳細に説明してくれています。

これを私の普段の仕事にざっくり当てはめるとこんな感じになります。

※担当しているところが青背景

先ほどの1〜3が上図の担当箇所それぞれに対応しています。

本書を読みながら思ったのですが、データサイエンティスト協会が提唱しているデータサイエンティストの3つのスキルセットもそれぞれに対応している気がします。

1. データ分析プロジェクトの立ち上げ　→　ビジネス力
2. PoC(Proof-of-Concept)　→　データサイエンス力
3. ビジネス適用 　→　データエンジニアリング力

これ全てを高いレベルで出来る人はTwitterにはたくさんいますが、自分の周りにはそうそういないですよね。 

3つのうちどれかに強みがある人が複数人集まって、相互に補完しあって仕事しているところがほとんどだと思いますし、それでいいと思います。

分析プロジェクトにおける役割分担

1. プロジェクトオーナー：責任者
2. プロジェクトマネージャー：分析の方向性・進捗管理担当
3. ビジネスサイド担当者：ドメイン知識保有者
4. 分析官(データサイエンティスト)：統計や機械学習に詳しい人
5. 機械学習エンジニア：機械学習のシステムを実装できる人
6. データエンジニア ：分析基盤担当

1プロジェクトに対し、このうちの数名で構成されることが多いそうです。

本書ではいくつかの失敗事例や関係者とコミュニケーションをとる際の注意事項なども載っていて、「わかるわ〜〜〜〜」って思いながら読んでました。関係者間の情報共有がきちんと出来ると実は省ける前処理があったり、特徴選択の参考になる情報を素早く手に入れたり出来るんだろうな…。

私は新卒4年目(分析は3年目)ですが、上記2, 4の役割を担当することが多いです。3についてはいろんな業界にクライアントがいるので、社内でこのポジションを設けるというよりはみんなで常に勉強していくスタイルです。

自分は野球(スポーツ)とか映画鑑賞とか比較的趣味が多い方なので、仕事で知識がどんどん増えていくことは単純におもしろいです。テレビCMの見方とかスーパーの陳列とか生活してて気づく目線が変わりますし。職業病と言えばそこまでですがw

使ってもらえるシステムをつくる

「意思決定」という言葉が本書の軸になっていますが、クライアントの目的を果たすアウトプットを提供するとなると使ってもらえるシステムをつくることが必要不可欠ですよね。これは最終成果物がシステムではなく、レポートだろうと回帰モデル自体だろうと成り立つと思います。

例えば、分析に対するリテラシーが低いユーザー*4の場合、こちらが「平均値だけ提示するとミスリードになる可能性があるので箱ひげ図を載せました」と言っても「箱ひげ図の見方がわかりません」と言われ、使われなくなるのがオチですし、クライアントとユーザーが違う場合は特に注意した方がいいと思います。

ユーザーの学習コストに見合うだけの価値があるか、そしてその価値をユーザーにどう伝えるのかを考えるのはとても重要なプロセスだと思います。

難しいことを噛み砕いてわかりやすく伝えるのってホント難しいです…。

最後に

自分の分析プロジェクト経験の棚卸しも兼ねて、「失敗しない データ分析・AIのビジネス導入」を読んで感じたことを私の立場からまとめてみました。

Twitterでもこの本に対するポジティブな意見をよく目にしますが、本当に良書だと思います。久しぶりに数式の出てこない本をマンガ以外で読みました笑。

さっそく自分の上司にも薦めてみたいと思います。

*1:無意味なデータを入力しても無意味な結果しか得られないこと

*2:知らない方は「自信が確信に変わりました」でググってみてください

*3:概念実証。本書では分析設計→実施評価のプロセスを指しています

*4:納品したシステムを実際に使う人を指してます