プロジェクトの種類で変わる
データ分析の役割

　課題が明らかになると、すぐにでもデータ分析をやりたくなるが、その前に必ず「意思決定プロセスの設計」を行う。意思決定プロセスとは暗黙知の塊であるため、形式知であるデータ分析に当てはめようとしてもうまくいかない。そこで意思決定プロセスを形式知に変換するステップが必要になるのだ。

　そのコツが、意思決定プロセスを類型化してから、選択に至るまでの選択肢、選択基準、手掛かりを考えてみることだ。河本氏はデータ分析のプロジェクトは「A. 反復選択型」「B. 体制選択型」「C. 原因解明型」「D. 仮説試行型」「E. 計画策定型」「F. 経営判断型」の6つに分類できると指摘した。

　また、それぞれのタイプごとにデータ分析の役割も変わる。Aでは複数の選択肢を採用した場合の帰結の予測、Bでは合理的な選択を行うための判断材料の入手、Cでは因果関係の仮説発見と検証、Dは仮説の発見と検証、Eは最適な計画の発見といった具合だ。Fでできることは少ないが、少なくとも経営者の思考バイアスを排除することに役立つという。

画像を拡大
河本氏はデータ分析の役割について、意思決定の種類によって上記の6パターンに分類して説明した

「データ分析」のための準備が整うと、企業によっては外部のデータサイエンティストに分析を委託しようと考えるかもしれない。だが、河本氏は「できる限り、ビジネス担当者自身がデータ分析を行うべき」と主張する。その理由は大きく2つある。1つはプロジェクトでは出戻りが多々発生するため、もう1つはビジネス担当者とデータ分析の担当者との間に心理的な壁が存在するためだ。壁を壊すことに時間をかけるよりも、ビジネス担当者が自分の業務に壁を吸収させる方が、プロジェクトのリスクを下げることにつながる。

　もっと言えば、ビジネス担当者だけが頑張る必要はない。トップマネジメントやミドルマネジメントも努力するべきだ。プロジェクトを「課題の発見」「意思決定プロセスの設計」「データ分析」「現場への実装」の4段階で進めるとすると、特定の部門に閉じた業務改善であれば現場の担当者だけで4つを完結できる。だが、サプライチェーンの最適化のように、複数部門をまたがる「組織横断的な変革」の場合、「課題の発見」「意思決定プロセスの設計」は本来ミドルの仕事であるべきだ。さらに、売り切りからサブスクリプションにビジネスモデルを変えるような、会社としての命運を左右する意思決定を伴うプロジェクトは「課題の発見」はトップ、「意思決定プロセスの設計」はミドル、後の2つは現場という分担で臨むべきであろう。

　その意味で、これからのトップにはデータ分析のポテンシャルを理解し、全社員が目指すべき目標や行動指針を示す力を付けることが求められる。