デザイン思考によるデータ分析における問題、仮説の定義と合意プロセス

デジタルコンサルティング本部 アクセンチュア アプライド・インテリジェンス (AAI) シニア・マネジャーの青柳雅之と申します。私はAAIにおいてCloud Data & Analytics Capability Groupのリードをしており、AWSやAzure、GCPといった主要なパブリッククラウドを使用したアナリティクスに関わる業務を中心に担当しています。

データ分析のステークホルダーである、分析結果を活用する業務部門、データを保有する部門、データサイエンティスト、分析基盤を開発・保守するIT部門が、デザイン思考の手法を用いて「何をデータ分析の問題とすべきか」、「仮説は何か」、「分析に必要なデータは何か」を合意するプロセスについて紹介します。アクセンチュアには、「_FORM_」と呼ばれるイノベーション創出のためのフレームワークがあり、デザイン思考はそのうちの1つです。このデザイン思考の手法をデータ分析の問題、仮説の定義と合意プロセスに応用してみました。

データ分析のプロジェクトでは、業務部門が主導でプロジェクトを進めるケースが多いのですが、IT部門が主導し、業務部門をメンバーとして巻き込むこともあります。後者の場合、データ分析の問題、合意形成でうまくいかないケースもあるため、IT部門の観点で記載をします。

データ分析で解決する問題を特定、合意することの難しさ

データ分析では、「業務部門のニーズを取り込む」、「業務部門の業務を理解する」、「ビジネス部門と問題を合意する」が重要です。ここで起きうる問題は、IT部門やデータサイエンティスト主導で作業が進み、実際にデータ分析の仕組みを導入した後に、分析結果をもとに行った施策で効果が出ない、運用が定着しない、その結果、データ分析のROIが出ない、といったケースです。様々な要因が考えられますが、そこにはビジネス部門側の真のニーズ（インサイト）や情報を引き出せていない、何を分析するのかの合意が得られていないという事実が存在するのは確かでしょう。

IT部門には業務部門のインサイトを引き出すケイパビリティが必要

データ分析の目的は、業務部門の価値を向上させることが目的です。まずはIT部門が業務部門を理解するために、業務部門自らが把握していないインサイトの把握も含め、業務部門からの真の課題、アイデア、経験と言った大量のインプットを引き出すファシリテーションのケイパビリティが必要となります。

業務部門から大量のインプットを引き出す

どうすれば業務部門から多くのアイデアを引き出して、データ分析へのニーズを引き出す、つまり問題領域の特定をすることが出来るでしょうか。経験のある人ならば業務部門との対話を感覚的に行っても、十分なインサイトを引き出すことが出来るかもしれません。デザイン思考ではステークホルダーが集まりワークショップ形式で行いますが、定義されたプロセスとテンプレートにより、経験の浅いメンバーによるファシリテーションでも、決められた時間内で一定の成果を出すことができます。ただし、当然ながら経験のあるファシリテーターのほうが良い結果は得られるでしょう。

デザイン思考では解決策の絞り込みに至る過程で、アイデアを発散、収束するプロセスを繰り返し利用しますが、これをダブルダイヤモンドと呼びます。データ分析プロセスの中では、特にユーザーからのインプットが重要な「データ分析の設計」プロセスでデザイン思考が利用できるでしょう。

データ分析のプロセスとデザイン思考

以降は上図でオレンジ色のセルで示されているデザイン思考の手法について紹介したいと思います。

■ユーザーへの共感、課題の洗い出し （業務部門を理解する）

IT部門やデータサイエンティストが業務部門のビジネスを理解するには通常は長い時間がかかります。デザインシンキングではユーザーから大量のインプットを引き出すことで、この時間の短縮が期待できます。

●　とにかく参加者全員がアイデアを出す -

　　Rose（バラ=ポジティブ）, Thorn（トゲ=ネガティブ）, Bud（つぼみ＝機会）
この手法では、データ分析に関係するステークホルダーが一堂に会して、データ分析に対する思い、その組織が優れている点、課題感、やりたいこと、やればよかったことを各自が付箋に１つずつ書いて貼っていきます。従来のように、経験のあるメンバーが業務部門にヒアリングをする場合、ヒアリングを行うメンバーの人の意向が強く反映されてしまう可能性があります。Rose,Thorn,Budではこれを回避することができます。

Rose,Thorn,Budで集められた付箋

付箋の色と記入する事項

この作業のポイントは、個人ワークとグループワークに分かれていることです。個人ワークでアイデアを書き溜めてから、グループワークで全員が付箋を貼って内容を確認するため、全員のアイデアが可視化され、声の大きい人の意見だけが通ることはありません。これは参加者全員が必ずアイデアを出す強制的な仕組みです。

●　ユーザーの感情とイベントを紐づけ - 経験ダイアグラム

データ分析を業務として行っているメンバーの過去の経験（イベント）と感情の動きをダイアグラムに書きます。モチベーションの上がったイベント、下がったイベント、なぜそうなったのか、モチベーションが下がった状態から上がった状態に遷移する際に何が起こったのか、をレビューすることでデータ分析に対するPainや望むことのヒントを得ることができます。

経験ダイアグラム

●　ユーザーの業務の体験

IT部門やデータサイエンティストが、ユーザーの業務内容をインタビューでヒアリングしただけでは、実感がわきづらいです。そこで、実際の業務を行ってみるのです。データを活用する現場にIT部門やデータサイエンティストが入り、実感としてユーザーが持つ問題意識を理解します。データを活用する組織がどのような業務を行い、どのようなステークホルダーに報告をしているか。その一部を体験し、ユーザーの業務を理解します。また、この過程でユーザーとの関係が良好になれば今後の作業もしやすくなります。

ユーザー業務の体験

■課題の絞り込み

●　アイデアの分類と問題の抽出 - アフィニティクラスタリング

Rose,Thorn,Budで集められたアイデアを分類します。内容が近いものをグループ化します。これをアフィニティクラスタリングと言います。そして、各グループの特徴に対して、「～すべき」といった内容にまとめた文章を別の付箋に記述してグループ毎に貼っていきます。この分類の作業は参加者全員で行います。これにより、各アイデアとその分類が参加者全員で理解されます。これも合意形成プロセスの１つです。ピンク、青、緑が同じグループに入ってもかまいません。例えば、あるデータは不足しているが（青色）、存在すれば分析に利用出来てビジネス上有益（緑色）なものもあります。それらの事項が1つのグループに入れば、「このデータを使って分析をすべき」が導出され、より分析テーマの候補となりうる問題は明確になります。

アフィニティクラスタリング

●　問題の定義 - スターターステートメント

How Might We ～？を直訳すれば、「我々は、どうすれば　XXを　YYすることができるだろうか？」となります。この文章を、スターターステートメントと言います。
「我々はどうすれば異常値の検知率を上げることが出来るだろうか？」
「我々は、どうすれば解約率を下げることが出来るだろうか？」
ある程度、問いをいくつかに絞ることで、この後に続く、分析のために必要なデータを絞り込むことができます。これまで収集したアイデアを参照しながら、このHow Might We?を考えます。いくつかのこのHow Might We?が生まれたら、参加者によって投票を行い、そのうちのいくつかを選定します。

スターターステートメント

■解決策の洗い出し

●　必要データのリスト化

Rose,Thorn,Budで挙げられた問題に関するアイデアは、大きなものから細かなものまで含んでいます。その中には、例えばユーザーの職業と言う属性を必要なデータとして考慮すべき、といった細かいものも含んでいるかもしれません。How Might We? でいくつかに絞り込まれた問題は、それだけアイデアが収束している状態となっていますので、それに向けて、どのような要素を評価すべきかを全員で付箋に貼っていきます。こちらも個人ワークで付箋にアイデアを書き、グループワークで張り付け、確認を行います。

■解決策の絞り込み

●　必要データの選定 - Importance & Difficulty Map

「重要度」、「そのデータの取得のしやすさ」のマトリックスを作り、リスト化された要素をそこにマッピングしていく。最初に「重要度」で横一列に要素を並べ、そのあとに「そのデータの取得のしやすさ」で上下に動かしていきます。左上の象限にある要素が、分析で取得する要素の候補となります。これは全員で合意を行いながら行います。

●　仮説の定義

Importance & Difficulty Mapで分析に必要なデータの関係を想定します。これがデータ分析の仮説となります。なお、後続の「データ収集・加工」プロセスで取得できないと判明したデータは候補から外し、再度仮説を作り直すことになります。

●　データ分析の設計のアウトプット作成

これまでの手法で得られた結果を、アウトプットとしてまとめます。

まとめ

多数かつバックグランドが異なるステークホルダー間で合意を取るのは難しいです。デザイン思考の手法を活用すれば、あらかじめ実施時間が定義された手順でファシリテーションを行うことになり、必ずその時間で一定のアウトプットは出ます。また、デザイン思考のワークショップ参加者は個人ワークで必ずアイデアを出さなければならないので声の大きい人だけの意見が通るわけではありません。グループワークにより全員のアイデアが可視化され、投票により、多数決でアイデアが選出されるため公平感もあり、合意形成プロセスとしても有効です。

参考資料

本ブログの執筆以前より、データ分析に関する考え方は、以下の書籍を参考に学習させていただきました。私の経験と照らし合わせながら理解を深めることが出来ました。ちなみにアクセンチュア アナリティクスはAAIの前身です。

アクセンチュアのプロフェッショナルが教える データ・アナリティクス実践講座（翔
泳社）

アクセンチュア アナリティクス (著)、 工藤 卓哉 (監修)、 保科 学世 (監修)

本物のデータ分析力が身に付く本 (日経BP)

河村 真一 (著)、 日置 孝一 (著)、 野寺 綾 (著)、 西腋 清行 (著)、 山本 華世 (著)、 日経情報ストラテジー (編集)

データサイエンティスト養成読本 ビジネス活用編 (Software Design plusシリーズ)

高橋 威知郎 (著)、 矢部 章一 (著)、 奥村 エルネスト 純 (著)、 樫田 光 (著)、 中山 心太 (著)、 伊藤 徹郎 (著)、 津田 真樹 (著)、 西田 勘一郎 (著)、 大成 弘子 (著)、 加藤 エルテス 聡志 (著)