データ分析のプロセス

とあるIT企業でアナリストをやっていて、最近ちょっとだけいい感じで分析作業が出来るようになってきたのでそのノウハウを共有したいと思います。ただコンサルの方は入社直後に学んでいそうな内容なので二番煎じかもしれません

ステップ1 : ヒアリング

ポイント
- まずは依頼主の課題を言語化する。依頼主は自分の課題を言語化できているわけではない
- 課題を把握する為だけのmeetingを実施する
- 課題はgoogle docsなどで簡潔に言語化しておく

　我々アナリストは他部署の社員から依頼を受けて動きます。彼らは自分の担当業務を遂行する上で何らかの課題を抱えていますが自身の課題を明確に言語化・構造化出来ていない状態で依頼を出すことが多いです。そして彼らの第一声は大抵の場合課題の解決手段で、解決したい課題それ自体ではないことがほとんどです

「XXX(KPI)を計算してください！」

　彼らの第一声を鵜呑みにして行動を起こすとどうなるか？そこそこの確率で業務の手戻りが発生します。その計算タスクが依頼主の課題を解決するための適切な手段になっていないからです

なのでまずは解決策について論じる前に依頼主の課題を言語化し理解を深めることが必要です。その為だけのmeetingを実施すべきでしょう。slack※でチャットしたり、別目的のmeetingの最後に「5分だけ時間ください！」とお願いしてヒアリングしてもそこそこ慣れてないと認識齟齬が発生したり課題に対する理解が不十分なまま分析作業が始まります(そして手戻りが発生します)。meetingを実施してまずは依頼主の課題を言語化・構造化することを心がけましょう。依頼内容はDocsなどに簡潔にまとめておくと備忘録になり、分析チームのメンバーに共有するとき楽です

※ 余談になりますがテキストチャットを過信するのは止めましょう。テキストチャットは認識齟齬が生まれやすくこれを回避するためのコストがかかります。依頼主と分析者が言語化能力に優れているならば大丈夫でしょうがそうでないなら出来るだけmeetingを設定しましょう

ステップ2 : 分析方針の言語化

ポイント
- ユーザー仮説、計算すべき指標とその粒度などを言語化する
- 所属している分析チームのマネージャーやメンバーにレビューしてもらい分析の方向性が妥当であるか確認する

　ステップ1を実行に移したあなたは依頼者の解決したい課題についての理解がある程度進んでいる状態です。次のステップはどういう分析をやれば良いのかその方針を言語化することです。SQLやpython、Rがある程度書けるならコーディングをしながら試行錯誤を繰り返して分析しようと思っているのではないでしょうか。コードを書きたいという気持ちがあるのはわかりますがまずはユーザー仮説は何か、どんな指標をどんな粒度で計算すれば良いのか、どんなグラフがあれば依頼主は納得してくれるのかをGoogle Docsなどにまとめる作業をしましょう。そしてそれを書いたらあなたが所属してる分析チームのマネージャーやメンバーにレビューしてもらいましょう。この時点で依頼主に共有してフィードバックをお願いするのも手です。この分析方針で納得できそうか、依頼主だからこそ気が付く新たらしい視点がないかなどコメントをもらいましょう。
　何故こんなことをするのか？時間をかけて分析を進めても、もしかしたら全く見当違いの方向性かもしれませんし、もっと良い分析があるかもしれません。なのでまずはどんな方針で分析するのかを言語化しておき社内有識者からフィードバックをもらい分析方針を改善しましょう

ステップ3 : 分析と結果のまとめ

　分析の方針が固まったらいよいよ分析作業の開始です。このnoteではこの工程について詳細に述べませんがSQL、python、Rなど適切な分析環境を選んで分析を実行してください。そして分析が終わったらGoogle Docsなどにその結果をまとめましょう。まとめる時は次の点に注意すると良いでしょう

• ユーザー仮説、分析の結論を最初に書く。読み手は忙しい場合が殆どです。依頼主が知りたいことを真っ先に書きましょう

• 依頼内容のサマリーも追記しておきましょう。この部分が無いと数ヶ月も経過すると自分でさえどんな依頼内容なのか完全に忘れます

• クエリやコード、最終集計にスプレッドシートを使った場合はそれらへのリンクも載せておきましょう。あとで自分が振り返る時楽になります

ステップ4 : 分析結果の共有とフィードバック

ポイント
- 依頼主に分析結果を共有してフィードバックをもらう
- 時間をかけて確度の高くするのではなく、イテレーションを多く回して確度を高めていく。アジャイルに分析を進める
- 依頼主が納得する解決策が見つかるまでイテレーションを回す

結果をまとめ終わったら依頼主にみてもらいフィードバックをもらいましょう。分析結果を見ることで依頼主は新たなユーザー仮説を思いつくかもしれません。この結果共有のプロセスを出来るだけ多くこなすのがポイントです。時間をかけて確度の高い分析をやるのではなく、確度は低いけれど短い時間で結果を共有しフィードバックをもらうことが大事です。時間かけて分析やっても実は方向性間違っていましたなんて事になりかねません。なので最初に立てた仮説をある程度検証できたらその時点でdocsにまとめて依頼主からフィードバックをもらいましょう

最後に

　「いま自分がやっている業務の目的 is 何？」という視点はとても重要です。ビジネス分析の目的は課題解決なので今現在やっている集計や分析が課題解決の手段にならないといけません。そして最適な解決手段かどうかは作業着手直後は依頼主もアナリストもわかっていません。依頼内容によっては最適解が即見つかる、自明である場合もありますがそうでないことも多いです
　なので[ステップ1] 依頼主の課題を言語化、構造化して理解を深めることに努めましょう[ステップ2] 課題解決のための分析方針を言語化してレビューしてもらいましょう[ステップ3,4]分析結果を簡潔にまとめ依頼主やチームメンバーからフィードバックをもらいましょう。そして時間をかけて確度の高い結果を出すのでは無く作業=>レビュー=>改善のサイクルを素早く回すことが重要です

参考図書

• 思考・論理・分析―「正しく考え、正しく分かること」の理論と実践 波頭 亮(amazon)

• 入門 考える技術・書く技術 山﨑 康司(amazon)