解きたい問題に対して分析アプローチを考える場面というのは、データサイエンティストやアナリストの腕の見せ所です。
例えば、人事データからハイパフォーマーの行動特性を探るタスクでは、パフォーマンスや行動特性の計量方法から、それらの関係性を推測するモデリング手法、評価観点などの分析アプローチを考えることなります。これは問題設定とも呼ばれ、業務課題を技術課題に落とし込む重要なフェーズで、データサイエンティストやアナリストの応用力が問われます。
問題設定が完了すればあとはデータを使って分析していくことなります。そして、分析を依頼された人やチームへのレポーティングを行えば分析プロジェクトは完了となるわけですが、このときに次のような会話になったことはないでしょうか？
- 分析結果を報告したら「わかっている話しかないね。もっと何かないの？」といわれてしまった。
- 分析結果をめぐってクライアントチームのメンバーが対立し始めてしまった。
- PoC結果を報告したが「システムはできていないの？ 早くAIを導入して楽にしてよ」と指摘されてしまった。
- 「大変参考になりました」とのコメントがあったが、質問やコメントもなく、その後業務に活用されなかった。
- 「分析結果が想定と違うので、効果が出るまで工夫して頑張ってほしい」といわれて、作業の延長を求められた。
このような会話が発生する場合、データ分析プロジェクトとして価値を出せているとはいえません。結果的に業務に活かされないデータ分析を行ってしまったことになります。その原因は様々ですが、多くの場合、解くべき問題を間違えた、もしくはステークホルダーのコンセンサスを得られていなかったことに起因します。
このような経験がない方は、データドリブン経営が業務にしっかりと組み込まれている素晴らしい組織で仕事をされているのでしょう。一方、昔のプロジェクトがフラッシュバックした方もいらっしゃるかもしれません。
それでは、業務に活かすデータ分析プロジェクトにするためにはどうすればよいでしょうか？
データ分析の目的を引き出す
データ分析プロジェクトを業務に役立てるためには、第一にその目的をはっきりさせることが大切です。これは当たり前の話に聞こえるかもしれませんが、突き詰められていない場合が多々あります。
ビジネスでデータ分析を行う場合、究極的にはビジネスの利益につながることでなければ価値を出しているとはいえません。例えば、マーケティングでは売上につながること、生産では原価改善につながることが求められます。
データ分析一発で売上や原価に直接影響を与えることは少ないかもしれませんが、データ分析で取り組んでいることが売上や原価につながる施策に組み込まれていることが重要です。組織や製品のKGIを起点として、ブレイクダウンされたKPIに対する分析テーマとなっていることが理想です。もしくは、既存のサプライチェーンに対する課題を発見するようなプロジェクトも有益でしょう。
一方、ピープルアナリティクスのようなコストセンターに対するプロジェクトの場合、売上や原価といったわかりやすいKGIがないため、テーマを決めるときに丁寧な議論が必要になることが多いです。人事戦略や施策と接続はどうか、人的資本経営のKPIとの関連はあるか、または具体的な業務課題は何かというような切り口で、データ分析の目的を引き出す必要があります。
分析を始める前に、分析後のことを具体化してみる
データ分析の目的を考えるとき「データ分析の目的は何ですか？」という問いを投げかけるだけでは、なかなかよい議論ができないということもあるでしょう。特に、冒頭にあげたような会話に陥ってしまうようなデータ分析プロジェクトでは、このような直接的な会話をしても、表面的な議論に終わってしまう可能性があります。もしクライアントサイドで十分な吟味がされているのであれば、そもそも目的を外したプロジェクトにならないはずだからです。
一方、データサイエンティストやアナリストは何らかの依頼を受けてデータ分析を始めるわけですから、言葉からそれが解くべき問題か見極めることが難しいのが正直なところです。
そこで、一つの工夫として、クライアントに対してデータ分析の結果が得られた後のアクションを聞いてみるという方法があります。例えば、次のようなことを尋ねます。
- 回帰によって目的変数と関連する説明変数を探索するようなタスクでは、関連する変数が見つかったらその情報をもとにどのような施策を打つのか尋ねてみる。
- AIによる予測モデルの検証を行うプロジェクトなら、そのモデルをどのような場面で使うのか聞いてみる。もしくは、予測モデルがない状態で今業務をどのように回しているか尋ね、現行業務の課題ヒアリングに移っていく。
- ある施策に対して効果を検証するプロジェクトでは、期待効果があったときにどのようなアクションをとるか尋ねる。それと同時に、期待効果が得られなかった場合の対策も必ず聞く。
データ分析を始める前にデータ分析後のことを尋ねることで、目的を具体化することができます。すぐに答えがでなくとも、より本質的な議論になっていく印象があります。
もしこれらの質問に対して、
「それは今は考えなくてよい」
「データ分析の結果を見て考えます」
「期待効果が得られなかった場合は考えていない」
などの話になったときは十分に注意すべきです。クライアントとデータ分析チームの関係性が十分にできていないことも想定されるため、現行業務の状況を丁寧にヒアリングすることに時間をかけるべきでしょう。
データ分析デザインフレームワークTIHAM
以上の議論を踏まえ、データ分析のテーマを検討するときの重要な観点をフレームワークとしてまとめました。
データ分析のテーマを考えるとき、目的、課題、仮説、アプローチ、施策を具体化しておくとで業務に活かすプロジェクトにすることができます。クニラボではこれら5観点の英単語を使ってTIHAMと呼んでいます。
- 目的 Target
ビジネスで達成すべきことや取り組みの狙い整理する。 - 課題またはアイデア Issue/Idea
目的達成のための課題またはアイデアを具体化する。 - 仮説 Hypothesis
分析調査型：想定される問題、取り組みの期待効果。
課題解決型：課題解決のための仮説的ソリューション。 - アプローチ Approach
仮説を検証するため、どのようなデータと分析方法を利用し、どう評価するかを検討する。 - 施策 Measures
仮説が検証された後、とるべきビジネス上のアクションを言語化する。
データ分析を始める時点でこれら5点が言語化されていれば、分析の目的を外すリスクを減らすことができます。
上でご説明した「分析後のことを具体化する」という工夫は、5点目の「施策」に対応しています。データ分析を始める前にあえて分析後のことをイメージすることで、それが1点目の「目的」につながるアクションなのかチェックすることができるようになっています。
残りの項目についてざっと解説します。
2点目の「課題」は、ビジネスの目的を達成するために実施すべき打ち手ということになります。ここでは、ビジネスのあるべき姿(To Be)と現状(As Is)のギャップを問題と捉え、その問題を解決するための方策を課題と定義しています。ここで、議論をやわらかくするために「課題」に加えて「アイデア」という言葉を意図的に入れています。
職場や業務領域にもよりますが、To Be-As Isの議論から始めて課題を具体化していくと、「ゆるぎない打ち手」というイメージを持ってしまうことがあります。そうなると、不確実性を意識しない非データタスクでとらえてしまい、検討が進まないこともあります。こうした問題を回避するため、あえて「アイデア」という言葉もいれました。
3点目の「仮説」は、プロジェクトのタイプとフェーズによって変わってきます。問題発見や施策の効果検証を行う場合は分析調査課型と捉えて仮説を洗い出します。一方、AI導入のPoCのようなソリューション検討では課題解決型と捉えて、ソリューションを試す際の仮説を洗い出します。仮説というと前者のイメージが強いかもしれませんが、アジャイルに何かを試す場面も増えており、後者のデータ活用タスクも存在します。
4点目の「アプローチ」は、仮説を検証するための手段そのものになります。データサイエンティストやアナリストの専門性が発揮される個所です。しかし、もし対峙している課題の解決にデータ分析は適当でないということが分かった場合には、無理にデータ分析の世界で語る必要はありません。
分析調査型のプロジェクトでインタビューが適当な場面もありますし、課題解決型のプロジェクトでガチっとした業務システムを導入する方がよいということもありえます。むしろ、データサイエンティストは目の前に提示された問題に対し、「データを使わず目の前の問題は解けるだろうか？」と一度考えてみることをおすすめします。
TIHAMの使いどころ
さて、データ分析デザインフレームワークTIHAMはいつ、どのように活用すればよいのでしょうか。第一には、データ分析プロジェクトを始める前に、以下のようなワークシートを使って、分析デザインを行ってみるとよいでしょう。
このとき、プロジェクトメンバーで議論をしながら埋めていく方法もありますが、クライアントとデータアナリストの関係性が十分にできていない場合、直接議論するとあまりうまくいきません。その昔、データ分析を始めたばかりのクライアントに対して、このようなワークシートを埋めていただくようお願いしたことがあったのですが、イメージがわかないといわれてしまったことがあります。また、埋めていただいたとしても、クライアントの本音につながらないこともあります。
したがって、このシートはまず聞き手（データアナリストやビジネスアナリスト）の頭の中に描いておき、様々な角度で質問を投げかけていくのがよいでしょう。そして、議論が十分に尽くされたころに議論をシートに整理して共有し、会話を深めていきます。そうすることにより、少しずつではありますが、クライアントの本音に到達することができます。
こうした会話を重ねてプロジェクトの方向性が決まったら、プロジェクトのキックオフ資料の1枚目にこのシートの内容をサマリとして付けます。そうすることで、関係者のベクトルを合わせることができます。
もし、キックオフ会議で内容に疑義がでてきたらどうしたらよいでしょうか？
それは有益なことだととらえて、軌道修正をしていきましょう。出鼻をくじかれて焦るかもしれませんが、少なくとも最終レポーティングの場で混乱するよりかは建設的です。
議論を深めるポイントは「問い」
この記事ではデータを業務に活かすための分析デザインについて考えてきました。今回ご紹介したデータ分析デザインフレームワークTIHAMを使うことで、業務に接続したデータ分析プロジェクトを立ち上げることができます。
一方、TIHAMを使って議論を深めるには丁寧な会話を積み上げる必要があります。時間をかけて会話することにより、クライアントも気づいていない課題にたどり着いた経験を何度もしています。このとき、議論を深めるために重要なのが「問い」です。問いかけによってプロジェクトメンバーの議論を掘り下げることができます。
データサイエンティストやアナリストにとって、問いをうまく活用してクライアントや自分自身からヒントを引き出すスキルは重要です。これについては、別の記事で改めてご紹介させていただきます。
