データ分析のテーマを整理するためのフレームワーク（TIHAM）
最近、次のような質問をいただくことが増えてきました。
「データ分析を始める時にどのような観点でテーマを整理すべきですか？」
「実証計画を考えるときの一歩目がわかりません。教えてください。」
「分析タスクの報告書の見出しはどのようにすべきでしょうか？」
これら3つの質問は背景が異なるものの、会話しているうちにいつも似たような答えやキーワードを口にしていることに気づきました。そこで、自分の頭のなかにおぼろげにあるフレームを取り出してみると、概ね問題設定のロジックを整理することに帰着しそうだなと思いました。
そこで、この記事ではデータ分析のテーマ検討や機械学習タスクの問題設定で考えるべき観点をざっくりと整理してみます。学術的に裏付けのあるものでなく、一人の実務者が多くの壁にぶつかりながら蓄積したものですので、参考程度にご覧いただければ幸いです。
テーマを整理する5つの観点TIHAM
データ分析のテーマを検討するときに、「この観点とロジックが整理されていればひとまずOK」と思える要素を抽象化してみると、5つの観点に整理できました。
その5つの観点とは、目的、課題/アイデア、仮説、アプローチ、施策です。具体的には以下の通りです。
ふと思い立って、アルファベットで強引に略語を作ってみると、TIHAM (Target, Issue/Idea, Hypothesis, Approach, Measures)になりました。語呂が良いのか悪いのかよくわかりません……。世の中にありそうなだと思ったのですが、このワードでググっても出てこなかったのでまとめてみました。
データ分析テーマの検討や機械学習タスクの問題設定を行うとき、これらが言語化されてロジックが見えてくると、それを実行するための期間やリソースを見積ることができます。
何よりも、「そもそもこのタスクを実行すべきかどうか」について基礎的な判断材料が整うため、本来必要なかった分析を行うリスクを軽減することができます。
これら5つの観点は、仮説検証型のプロジェクト全般で考えるべき事項でもあります。したがって、TIHAMはデータドリブンプロジェクトで検討すべきフレームワークとも言えるでしょう。
◆観点の洗い出しとロジックの重要性
これら5つの観点同士のロジックがつながらなかったり、抜け漏れがあったりする場合には注意が必要です。分析のアウトプットをビジネスに活用できない状況に陥るからです。
ありがちな問題としては、データと分析手法が先行していてビジネス上の目的が曖昧なパターンです。シンプルに言うと「目的と手段の取り違え」ということになるのですが、それがいつも簡単にわかるとは限りません。
逆説的ですが、この問題を回避するための一つの方法として、「この分析によって仮説やアイデアの有用性が検証された後、ビジネス上どのようなアクション・施策をとるだろうか。」と問いかけてみる方法があります。ここで答えに窮するなら、目的・課題/アイデア・仮説のいずれかがビジネスの実情に合っていない可能性があります。
この問いを投げかけるべき相手はステークホルダーや自分自身のポジションによってかわってくるでしょう。こうしたこともあり、5つ目の観点として施策を入れています。
この意味で、施策を具体化したときに、「その施策によって課題が解決されて目的を達成できるのか。」と改めてチェックしてみるとよいと思います。
◆目的の重要性とむずかしさ
さて、この5つの観点の中で最も重要なのは目的です。ここがぶれてしまうと価値に繋がらない、手戻りだらけになる、無駄なコストをかけてしまうというリスクが顕在化します。端的には、プロジェクト参加者の誰もが幸せになれない、ということです。
したがって、目的はどのようなプロジェクトでもまず初めに固めるべき事項だと考えています。ところが、「目的を明確にしましょう」と唱えても、クライアントの本音の目的にすぐたどり着けるとは限りません。様々な要因が絡み合うものであり、その引き出しには常に注意を払う必要があります。
◆データ分析が課題解決の最良手段でないこともある
また、データ分析のテーマ整理の観点としながら、データと手法は独立させずにアプローチに包含しました。それには理由があります。
こうしたテーマ検討を行っている中で、課題解決の手段としてデータ分析が適していないとの結論に至ることもしばしばあるからです。機械学習タスクの検討では、この段階で統計的なアプローチでなくルールベースが適当との結論に至るケースもあるでしょう。
データと手法をフレームワークに明記すると利便性が良くなるのですが、手段先行になりがちなため、あえて「アプローチ」としました。
----
以上で述べた観点は手垢のついた自分なりの物差しにすぎませんが、フレームワークとして言語化してみました。
N1の話になりますので、私の経験範囲と仕事の内容を簡単に触れ、その後に5つの観点をもう少し掘り下げてみます。
データ分析が浸透していない分野での分析タスク
私は仕事でデータ分析をやっていますが、データ分析が浸透している領域での仕事はほとんどなく、これまで分析的にデータを活用してこなかったビジネス課題をターゲットにしてきました。これは、データサイエンティストに転身したときからあまり変わっていません。また、データ分析の実務者としてスタートし、今は分析チームのマネジメントをやっています。
これまで取り組んだ仕事の一部を抽象化して書くと次のような感じで、あまねく経験しているとは言えませんが、ここ数年で経験の幅が広がりました。
・SNSデータを用いた観察研究および異常検知。
・業務パッケージ製品への機械学習モジュール組み込み。
・NLPを活用した特殊な検索系システムの要件整理と実証。
・人員配置計画支援のための業務量予測、スコアリング。
・ピープル・アナリティクスのアセスメント、観察研究、意思決定支援。
いずれも新しい分野での試行的な案件が多く、初手として観察研究的なアプローチが必要になるようなものでした。一方、データ分析がビジネスにしっかり組み込まれているWeb企業の中でのデータ分析経験はありません。
分析が浸透していない領域での仕事となりますので、当然ながら分析に適したデータマートや基盤がない場合がほとんどでした。手元にやってくる生データを頑張って加工して分析するような雰囲気です。
問題設定がポイントに
上で述べた仕事は、概ねクライアントへの情報提供から会話が始まり、解決すべき課題を引き出しつつビジネスデータサイエンスのタスクに落とし込む流れとなります。
このようなプロジェクトで重要になるのは、問題設定です。
ビジネス上の課題を見極めながら、データ分析や機械学習を使うことが目的にならないように慎重に解くべき問題を設定する必要があります。議論している問題がそもそも本質的な問題でなかったり、データ分析でない手段で解決できたりすることも多いからです。
したがって、クライアントと会話をするときには、業務課題や背景を引き出しつつ、並行して分析タスクとしての実験アプローチを頭の中で組み立てていくことになります。その結果、データ分析タスクに落とし込める時もありますが、そうでないこともあります。また、意思決定支援と機械学習を活用した仕組み作りの話が混在することもしばしばあり、それらの文脈をより分けることも必要になります。
こうした会話をしている最中に、クライアントから引き出した要望やコメントを冒頭に提示したTIHAM、すなわち目的、課題/アイデア、仮説、アプローチ、施策の5つの要素に振り分けていきます。クライアントがこの5つの順に目的と課題を綺麗に示すことができれば話は早いのですが、いつもそうとは限りません。
このTIHAMの中で分析者が中心になって考えるのはアプローチではありますが、クライアントからアプローチへの「思い」が出てくる場合もあります。また、目的、課題、仮説が曖昧な場合もありますので、私たちの方から積極的に整理し言語化することが重要です。
「目的」は重要だが難しい
データ分析を行う際に、ビジネス上の目的を明確にすることは重要です。これは当たり前なことに思えるかもしれませんが、結構難しい思案でもあります。時として人は目的を見失う場合もありますし、目的を持っていたとしてもプロジェクトメンバー間でコンセンサスがとれていないこともあるからです。
素直に考えるとまず明確にすべきは目的ということになるのですが、「目的は何ですか？」と直球を投げてもすぐ本質に近づけるとは限りません。特にまっさらのプロジェクトでは、様々な質問を投げかけ、関係者の状況を把握しつつ、言語化していく必要があります。
◆不明瞭な目的
初見の会話で目的が不明瞭だからといって匙を投げるのは、お互いにとってもったいないと思うようになりました。私は元SEということもあり、何事も0,1でビシビシ決めたいタイプでした。アプリケーション開発においては、要件や仕様が曖昧なものは後に大問題を引き起こすからです。そこで、曖昧でどこに行きつくかわからないような会話は苦手としていて、時間の無駄とすら思っていた時期もありました。
しかし、そういった態度と思考プロセスは、自分自身のみならずプロジェクトを硬直化させることに気が付きました。お恥ずかしい話ですが、このことを学んだのは30代後半のことでした。
あるミーティングに参加していたとき、クライアントの他にコンサルタントと私が同席する場面がありました。そのミーティングは曖昧な会話が続く上に話題が左右上下に飛び、私はメモを取るだけで精一杯になっていました。一方、同席していたコンサルタントの方は、傾聴と核心を突く質問を織り交ぜて場の雰囲気を醸成し、最終的にはクライアントの目的を自然に引き出していました。その様子は私の目には魔法のように見え、目から鱗がボロボロ落ちたのでした。そして、心を入れ替えたというわけです。
もちろん、本当に目的のない活動というのもありますので、その辺の見極めは必要かなと思っています。
◆大きな目的と小さな目的
目的には大小さまざまなものがあります。
大きな目的として、組織戦略やビジネス上の大上段の目的を考えることもあるでしょう。例えば、「従業員のキャリア自律を促す」とか「防災のソフト対策を強化し減災につなげる」など。こうしたふんわりした目的はデータ分析まで距離があるのですが、ここであきらめるのは時期尚早です。むしろ、大上段の目的を把握しておくのは重要なことであり、新しいプロジェクトであるほど、後々効いてきます。
こうした大きな目的が明らかになった場合、その目的がビジネス上重要であることを確認した上で、ブレイクダウンをしていくことになります。
一方、割と具体的な目的が設定される場合もあります。例えば、「30代従業員のエンゲージメントを向上させる」とか「見積作業の誤りや手戻りを減らして作業を効率化する」などです。これらに対して数値的なKPIまで落とし込むのが理想的です。
ところで、これら具体化された目的を取り上げたとき、「なぜそれを達成しないといけないのだろう。」と深掘りして考えてみることは有益です。一見よい目的に見えても、それが経営方針や事業戦略を考える上で優先事項でないこともあるからです。ダイアナ・キャンダーの名著「STARTUP」の表現を借りると、”片頭痛級の問題”でなければ人はコストをかけてまで動かないでしょう。
理想としては、大きな目的と小さな目的を関係性に着目して構造化し、抜け漏れがないことを確認するのがベターだと思います。マーケティング系のタスクであれば、売上に繋がる要因をツリーで分解していくことなど。
一方、全く新しい案件ではスクラッチで事柄の関係性を整理することになります。
◆目的の議論だけに終始すると……
ただ、目的の話に留まりすぎると煮詰まって先に進まない事態になるので注意が必要です。その場にいるメンバーが必ずしもロジカルな問題整理に慣れているわけでもありませんし、会話にロジックを求めすぎると本音が出てこなくなることもあるからです。
また、目的の議論をしているときに、ふとクライアントからアイデアや施策が出てくることもあります。もし、そういった場面に遭遇したとき、みなさんはどう感じるでしょうか？
エンジニア寄りの思考特性を持っている人は、「話題が違うしいきなり話が飛んで困るな……」と思うこともありますね。私もそういうことには敏感な方です。
しかし、最近ではこういう話が出たときには「本音を聞けるチャンス！」と思って受け止めるようにしています。経験則ではありますが、こうした会話はポジティブになることが多く、発言者の「思い」が出てくるからです。その思いを止めてしまうと口が重くなってしまいますし、楽しくありません。
逆説的に言えば、会話だからこそこういった展開に価値があるのだと思います。
もし、5つの観点を順に尋ね、1問1答ですべてが見えるのであれば、ミーティングでなくフォーマットを文字で埋めれば事足りるでしょう。ただ、それですべてがうまくいくとは限りません。
目的の議論は尽きませんが、世の中の事例を研究して考えることも発想を広げる一つの方法だと思います。例えば、以前にスターバックスの事例をもとに、データ活用の広がりを検討した記事を書いていますので、こうした記事も参考にしていただければと思います。
「課題」の広がり
言葉としての「課題」はやや曖昧なところがあり、会話をする上で注意が必要です。何が正しい定義かという定義論を展開するのもよいのですが、プロジェクトメンバーや組織の中で共通認識が取れれば十分だと思います。
ビジネスの現場では、課題の定義として「目標と現状のギャップを問題といい、そのギャップを埋めるための具体的に実行すべきこと」と言われることもあるでしょう。一方、手持ちの新明解国語辞典によれば、「解決を求められている問題」という定義もありました。私は前者の意味で課題という言葉を使うようにしています。
多様性のあるチームを組むときこそ、こういった言葉の揺れがありそうだと想定して、会話の内容を整理していく必要があると考えるようになりました。ただ、会話の中で相手の話を遮って「それは言葉の使い方が違う」とバッサリやるのはよくないと思っています。
あくまで傾聴の中で言葉の波を頭の中や手元で整理していき、あるところからホワイトボードなどを使って言語化してコンセンサスをとる、という方法を試みるようにしています。最近はZoom会議が多いので、共通編集ができるSharePointやGoogle Workspaceの各種ファイルを利用しています。
◆仮説検証型のアプローチで取り上げる話題は多種多様
TIHAMで考えているのはデータ分析のテーマでありますが、より広い視点に立つとビジネスにおける仮説検証型の問題設定のためのフレームワークとも言えます。仮説ドリブンでビジネスの目的に近づこうという話ですね。
ところで、こういったタスクで検証したいことは、思いのほか幅が広いということが分かってきました。
例えば、ピープル・アナリティクスで「ハイパフォーマの業務経験と行動特性を明らかにする」というお題目があったとします。これは仮想ケースですが、相当に広がりがあります。
プロジェクトの目的が現状把握やメカニズムを理解することなら、課題のレベルに置かれるのは「論点」になります。先のほどの例で、ハイパフォーマ群とそうでない群の業務経験や行動特性の違いを調べるなら、その論点は「業務経験と行動特性の違いによってパフォーマンスに違いは生じるか否か。」という問いになります。
また、そのことは与件として、最も影響のある事項を抽出したいということもありえます。この場合の論点は「パフォーマンスに最も影響を与える業務経験や行動特性は何か。」ということになるでしょう。
これに対して、具体的な課題解決を目指すフェーズでは少し様相が異なります。例えば、ハイパフォーマの秘訣を明らかにし、それを人材育成につなげて組織パフォーマンスを改善する、といったような目的がある場合です。この場合、課題のレベルに置かれるのは文字通り「解決すべき課題」ということになります。
これらの他に、対象業務についてピープル起点での組織パフォーマンス予測を行いたいというアイデアもあるでしょう。この場合、目的とのリンクが重要にはなりますが、業績予測をもとに組織長がリソース配分を検討するなどの展開が考えられます。
◆会議スペースに降りてきたアイデアを拾う
最後の例で取り上げたアイデアは、本来目的からブレイクダウンされるべきものではあるのですが、『「目的」は重要だが難しい』で述べたように、目的の議論は一筋縄ではいかない場合も多いのが実情です。
むしろ、課題レベルの議論をしているとき、ふと会議スペースに降りてきたアイデアが突破口になることもあります。人は問題点を掘り下げているときよりもアイデアを考えているときの方がポジティブですし、会話が活発になります。このようなアイデアを大切にしつつ、その背景を探りながら目的に到達すれば良いでしょう。
もし目的とリンクしなかったらどうするか？ この場合、アイデアをきちんと残しつつ一旦脇におき、議論を再開すれば問題ありません。コストをかける前に気づくことができたのはよいことですし、そのアイデアは後で役に立つかもしれません。
以上のように課題レベルで議論されることは多種多様です。その発想を広げるために、観点としてあえて課題とアイデアを並べて書きました。
「仮説」という難問
データドリブンプロジェクトや仮説検証型のタスクで肝となるのが「仮説」です。仮説なくして実験・実証を行うことはできないからです。その一方で、業務規程やプロセスに準じたウォーターフォール型でのワークスタイルに慣れた方には、なかなか馴染みのない言葉ではないでしょうか。
かく言う私もSE/PdMからデータサイエンティストに転じたときには、まったくイメージできずに四苦八苦しました。特に、統計的・帰納的な文脈で仮説を立てるのが相当に難しかったです。
ビジネスにおいても仮説を起点とした議論の重要性は説かれていて、例えば、「仮説思考（内田和成著）」ではその重要性と考え方を丁寧に解説しています。本書によれば、仮説思考は網羅思考と対比されるもので、仮説を「まだ証明はしていないが、最も答えに近いと思われる答え」と説明しています。確かに、この定義はわかりやすいと思いました。
ところで、この仮説を洗い出すために「仮説は何ですか。仮説を立ててみてください。」と投げかけても答えに窮するのではないかと思います。少なくとも、データドリブンプロジェクトに初めて参加するメンバーは戸惑う人が多いでしょう。とはいえ、仮説はプロジェクトの目的と課題に紐づくものですから、メンバーで考える必要があります。もし仮説が出てこないのであれば、議論ができるメンバーを連れてくることも工夫点の一つだと思います。
ビジネスでの仮説構築の難しさを生む別の側面として、「間違ってはいけない意識」「試行錯誤的なプロセス・文化がない」という点も大いに影響すると考えられます。仮説は間違う可能性があることが前提で、不確かなものです。だからこそ、こうしたプロジェクトで検証してみるわけですが、不確かなことを口にするのを苦手としている人もいるでしょう。
こうした状況では、ディスカッションの場での心理的安全性を確保すると、うまく回るようになると考えています。
一方、誠実に考えようとする人ほど、日常業務で飛び交っていない言葉を聞くと立ち止まってしまうのではないでしょうか。この場合、ある程度時間をかけて仮説のイメージを持てるような工夫をするとよいと思います。
その工夫の一つとして、TIHAMでは仮説を次の2つに大別してみました。
◆問題掘り下げ型
仮説検証型のプロジェクトでは、問題の原因を探るための調査を行うこともあります。すなわち、課題/アイデアで具体化したことの位置づけや重要性を確かめるために、一歩下がってビジネスの問題点を深掘りするようなタスクです。
このような場合は、今起きていると想定されることや根本原因の候補を洗い出すことが仮説の導出に繋がります。
例えば、ピープル・アナリティクスでいえば、「組織の中で一体何が起きているのか」ということを想像してみるとよいでしょう。データドリブンでなくとも、その道の経験者であればある程度仮説を持っているはずです。例えば、エンゲージメントであれば「○○代、△△職のエンゲージメントがやや低いが、それは・・・・といった背景があるからだろう。」といった感じです。
このように、仮説を立ててと言われると答えに窮する場合であっても、質問の表現や角度を変えてみるだけで、仮説が湧き出てくることもあります。
◆課題解決型
取り組むべき課題があり、それを解決するための方法がワークするかを確かめるようなタスクもあります。一言でいうと、仮説的なソリューションの検証ということになります。
人はソリューションに期待するものですし、エンジニアの人にとってもソリューションの検証というのはイメージしやすいのでないかと思います。
データサイエンスのタスクでいえば、機械学習をシステムに組み込むとか、予測モデルを作るようなものが、こちらの課題解決型に入ります。また、誤解を恐れず言えば、アジャイルなシステム開発も仮説検証に基づく課題解決アプローチだと言えるでしょう。
ただ、ここで取り上げる仮説というのは、必ずしも技術的な打ち手に限らないことを念頭におく必要があります。
仮説検証の「アプローチ」
TIHAMで取り上げるアプローチは、仮説を検証するための一連の方法を包含したものです。データ分析であれば、分析方針、データの種類と収集方法、分析手法、評価方法を整理したもので、実験デザインとも呼ばれます。まさに、データサイエンティストの主戦場だと言えるでしょう。
アプローチを考えるためには、PythonやRでモデルを構築する方法を知っているだけでなく、仮説を検証するための一連の実験方法を学ぶ必要があります。もちろん、問題設定に合わせて適切な技術を選択できる目利きも必要になるでしょう。
以前に投稿した以下の記事は、データサイエンスのアプローチを考えるための武器に関する情報を並べたものと言えます。
仮説の検証方法として、必ずしもデータサイエンスのアプローチが妥当だとは限りません。場合によりインタビューやエスノグラフィーなどの定性的な調査方法を必要とする場合もあるでしょう。
アプローチは調査の目的に従う、という原則を持って柔軟な発想を持つべきだと考えています。
意義ある「施策」に繋がってこその仮説検証
最後に5つ目の観点「施策」を取り上げます。
今日においては、PoC (Proof of Concept)という形で実証プロジェクトが組まれることは珍しくなくなりました。しかし、ビジネス上の目的を整理しないままとにかく実験してみよう、分析してみようというプロジェクトもあります。学ぶためにひとまず走るという状況も考えられなくはないのですが、目的が不明瞭なプロジェクトは分析完了後に窮地に立たされることが多いです。
こういった問題に陥らないためにTIHAMの観点で考えることは大切です。しかしながら、パワーポイントで小ぎれいに目的・課題からアプローチに至るシナリオを描いたとしても、それが実情に合わないものなら絵に描いた餅にしかなりません。
そこで、テーマ検討の時点で仮説検証後のアクション、すなわち施策を具体化してみると、こうした問題に陥るリスクを軽減することができます。仮説が正しかった場合、正しくなかった場合それぞれにおいて、次にとるアクションを具体化してみるのです。このために必要な問いはシンプルに次のようなものです。
「分析結果が得られた後、具体的にどのようなアクションをとるでしょうか。次の一歩目として何をやりますか。」
この問いは非常に強力で、不確実性・リスクを浮かび上がらせてくれます。この問いに対するもっともリスクが高い答えは「結果を見て考える。」というものです。逆に理想的な答えはTIHAMで洗い出した課題の解決に繋がり、かつ、目的に沿った施策が述べられることです。
もし、ここで考えた施策が課題解決や目的に繋がらない場合は、目的と課題の設定に問題があるのだと気づくことができます。
まとめ
この記事では、データ分析のテーマを整理するための観点をフレームワークにまとめてみました。その観点は「目的、課題/アイデア、仮説、アプローチ、施策」から構成されるもので、頭文字をとってTIHAMとしました。
テーマを検討する上でこれらのロジックを押さえておけば、ビジネスに意義のあるデータドリブンプロジェクトを始められるでしょう。また、ここで整理した観点は、データ分析に限らず仮説検証型のプロジェクトでも大切な観点だと思います。
以前、問題設定について記事を書きましたが、その難しさや学び方を述べたものの、考えた方のポイントについては整理できていませんでした。TIHAMは問題設定を議論する上で一つのフレームワークとして活用できるものだと考えています。
最後まで読んでいただき、ありがとうございました。