データアナリストの頭の中（問題設定のコツ）
データ分析の問題設定はとても楽しいもので、悩みながらもやりがいを持って取り組んできました。ビジネス課題を分析課題に落とし込み、分析アプローチを組み立てるスキルは、データアナリストやデータサイエンティストにとって重要でもあります。
その一方で、初学者の方から「どうやったら問題設定ができるようになるのですか？コツを教えてください」とたずねられることもあります。この問いにはいつも苦戦していたのですが、ここ数日頭をひねってみて少し見えてきたことがあります。
忘れないうちに残そうと思って、久々にデータ分析のnoteを書きました。
問題設定に必要な3観点
ビジネスシーンでデータ分析の問題設定を行うとき、ビジネス、データ、技術が交差するところを見つけることが大切だと教えられてきました。データがなければデータ分析はできませんし、データと技術だけでも業務に活かすことができません。
そのため、課題としてのビジネスを筆頭に、データと技術の接点を考える必要があります。図にすると以下のような三角形のような感じでしょうか。
このうち、ビジネスとデータの関係は意思決定の構造や業務プロセスによって対応付けられます。また、データと技術の関係はデータサイエンスの知識体系そのものといえます。もっとも難しいのがビジネスと技術のつながりを考えることで、データアナリストの腕の見せ所ともいえます。
データ分析を始めて間もないころは、ビジネス（実問題）と技術（数理）の対応を考えることに大変苦戦していました。いろいろなプロジェクトをこなしつつ、技術の勉強も粘り強くやっていたところ、いつの間にかできるようになっていたという感じです。
まさに暗黙知なので何とか言語化しようと自分の頭の中を観察してみたところ、「ビジネスと技術を抽象化して紐づけている」ということが分かりました。ここまでわかったところでnoteに投稿したのがちょうど4年前でした。
自分としてはこれで納得できたのですが、当時のチームメンバーに1on1で説明しても「抽象化・・・ですか」ということで、今一つ腑に落ちていない様子でした。それでも、技術書を片手にOJTで経験を重ねていくことで、多くのメンバーがこの壁を乗り越えることができました。
しかし、独立後に改めてクライアントから「どうやって分析方法を思いついているのですか？」とたずねられることが増えてきました。そこで、おずおずと「そうですね、ビジネスの課題を抽象化して技術とくっつける感じですかね…」とお答えしたのですが、ホワンとした雰囲気になってしまい、再び言語化にトライしてみました。
データアナリストの頭の中
まずは結論から。抽象化の過程を整理して図にしてみました。左から右にかけて抽象化が進んでいきます。上段がビジネス課題、下段が技術を示しています。
上段と下段で時間の流れは異なっている点に注意してください。上段はクライアントとのミーティングを通してリアルタイムに行われますが、下段は日ごろの勉強や過去のプロジェクトの蓄積によって徐々にできあがってきます。
それぞれの流れをもう少しひも解いてみましょう。
ビジネスの課題を抽象化する
まずはビジネスの課題を抽象化する過程を考えてみます。
多くの場合、ビジネスの課題は言葉として与えられますが、会話の初期段階ではふんわりしていることも多いものです。例えば、ピープルアナリティクスでは、以下のような言葉がでてくるかもしれません。
エンゲージメントを向上させたい。
ハイパフォーマーを育てたい。
従業員のキャリア自律を後押ししたい。
これとは逆にあまりにもピンポイントで、業務課題が見えない場合もあります。
採用区分によるエンゲージメントの差をみたい。
パフォーマンス評価のバイアスを調べたい。
社内ポストの募集に応募した従業員の特徴を知りたい。
どちらの場合もデータ分析で取り組むべきテーマの輪郭が見えにくい状況です。このような状態でミーティングで出た分析のアイデアに飛びついて分析しても、おそらくは上手くいきません。そのため、ビジネス課題の輪郭をくっきりさせることをまず行います。ここまではデータ分析に限らない話だと思います。
次に、ビジネスの課題が見えてきたら、それを分析の課題に落とし込んでいきます。取り組むべき課題の性質によって落とし込み方が変わりますが、例えば次のような切り口でおおよそのあたりを付けていきます。
今を知りたいのか(記述的)、予測したいのか(予測的)、変えたいのか(処方的)。
意思決定支援なのか、それともオペレーション効率化なのか。
探索的な分析なのか、それとも仮説に対する検証か。
こうした流れを経て課題が抽象化されていきます。もちろん、この段階でデータ分析や機械学習のタスクではないと判断することもあります。
分析技術を抽象化する
次に分析技術を抽象的に捉える流れについて解説します。ただ、我流であるため、人によって合う合わないがあると思いますし、もっと効率的なやり方があるよ、という方もいらっしゃるはずです。あくまで一例としてお考えくださいませ。
データ分析手法は山のようにありますが、基本的には数理的に考案された技術です。そのため、調べていくと数式やアルゴリズムにたどり着きます。
残念ながら、私は数式だけで使い方をイメージできるほど数学のセンスを持ち合わせていません。しかし、それでも数式が載っている専門書を調べることは多いです。なぜかというと、その分析手法の本質や制約条件がわかるからです。
統計モデルにしても、機械学習アルゴリズムにしても、何らかの仮定を置いて問題を解いています。「なんでも解けるよ！」という手法にはまだお目にかかったことがありません。かの統計学者のジョージ・ボックスは次の言葉を残しています。
すべてのモデルは間違っているが、中には役立つものもある
問題は手法（モデルやアルゴリズム）が持っている仮定を詳しく知りたいと思ったら、数式が載っているような本にあたるしかない、ということです。本来は原論文を読めばよいのでしょうけど、それは厳しいので定評のある参考書に頼っているというわけです。やや古くなっていますが、過去にお世話になった参考書についてnoteを書いたこともありました。
さて、こうした参考書と格闘しながら技術の使いどころを学んでいきます。具体的に気にしているのは以下の点です。
その手法はどのような問題を解けるのか。
どのような仕組みなのか。
使うときにどのような制約条件や前提条件があるのか。
インプットとアウトプットは何か。
類似手法との違いは。
私の場合、本を一回読んだだけでは実はよく理解できていません。「理解した！」と思うことがあったら、きっと表層的にとらえているか、ミスリードしているのだと思うようにしています。要は、何となくわかったきになっているわけですね。
この状態が改善されるのは、実際に使ってみたときです。何事もやってみなければ分からないものです。そして、やってみて「全然うまくいかんやん」とか「あれれ、どうやってこのデータに使うんやろ」と悩んで初めて身になります。逆に、理論を学ばずに実地だけでやり散らかした場合も上手くいきませんでした。
センスのある方は参考書を読んだだけでわかるのかもしれませんが、少なくとも私はこの過程を通らないと学びが深まりません。裏を返すと武器たるデータ分析手法をそろえるのに、とてつもない時間がかかるということになります。不器用なのです。
このような過程を経て徐々に武器がそろってきたところで、それらを類型化します。
例えば、線形回帰は目的変数と説明変数の線形の関係性を捉えるのだなとか、コサイン類似度は量的変数で構成されたベクトルの類似性を計量するのだなという形で言語化します。（頭の中にそのように詰め込まれているという意味です）
このレベルだとまだ類型化とはいえませんが、武器が増えてくると武器同士をカテゴライズしたり、関連づけたりできるようになってきます。そして、最後に経験と紐づけて整理しておくことで、先ほど整理したビジネス課題から抽出した技術課題と武器の紐づけができるようになる、というわけです。
まとめ
今回は問題設定に必要な観点を3つ取り上げ、ビジネスと技術を結びつけるプロセスを言語化してみました。個人的には暗黙知を抽出できたように感じてすっきりしましたが、まだまだ汎用性があるとはいえませんね。
これからも探求していきたいと思います。