問題設定のアンチパターン（続・データアナリストの頭の中）

昨日は、「データアナリストの頭の中」と題して、データ分析の問題設定のコツをお伝えしました。自分なりの方法論をまとめたものです。

こちらの図は、自分としては納得できる流れになっているのですが、人によってはまどろっこしいと思われるかもしれません。そこで、「何でここまでやる必要があるんだっけ？」と改めて考えてみたところ、数々の過去の失敗プロジェクトの記憶がよみがえってきました。

ちょうどよいので、問題設定のアンチパターンとして記事にしてみたいと思います。3点ほどにまとめました。

①解くべきでない課題に取り組むのはツライ

まず代表的なアンチパターンは、「解くべきでない課題に取り組む」ということです。図でいうと以下のような状況ですね。

課題らしきもの――つまり解くべきかわからないものに一生懸命取り組んだとしても、ビジネスに役立つことはありません。万が一上手くいったとしても、それは「たまたま」ということになります。シニアのエンジニアやデータアナリストの方でしたら、このアンチパターンをどこかで経験されていることと思います。

私の例をざっくりあげてみると、以下のような話がありました。どちらも、取り組むべきでないテーマに取り組んでしまったのが失敗の原因です。まさに徒労ですね。

• ハイパフォーマーの分析を行ったが最終レポーティングの場で議論が紛糾し、最終的に「やらなくてよかったプロジェクトだ」と評価された。

• 長期間かけて特殊業務の異常を検知するAIを開発しビジネス上の有効性も確かめられたが、ミス自体を許さない組織文化の壁を壊せずストップとなった。

これを回避するには、解くべき本音の課題を見つけるということです。言葉にするとシンプルですが、これが実に難しい話です。トップダウンであるべき姿から描いていく王道なアプローチもありますが、それでは上手くいかない分野もあります。ボトムアップに行う場合は、ステークホルダーとの対話が何よりも大切になってきます。

データアナリスト自身がこのアンチパターンの発生を認識できることが大切だと考えています。

②場当たり的な対応になるパターン

2つ目のアンチパターンは、課題を技術的な課題に落とし込めなかったときに発生する問題です。ビジネスの課題は明確になっているものの、それを解くための観察が足りていないことで生じます。

図にすると以下のような形になります。先ほどよりもだいぶマシですが、課題を解決できる確率は低い状態だといえるでしょう。私自身、データ分析を始めて数年間はこの状態に留まっていました。

それでは、ビジネス課題と使い方が分かっているいくつかの技術が出会うと何が起こるのでしょうか？

一つのパターンは、技術者たるデータアナリストが、手持ちの武器（ハンマー）で叩ける課題をさがしてしまう、というものです。使い方を知ってうれしくなってしまうのですね。これで上手くいくときもあるのですが、課題に対して必ずしも最良の結果が得られるとは限りません。また、技術的課題に落とし込む前にソリューションに走ってしまうと、非効率になってしまうこともあります。

私も機械学習の予測モデルを使えるようになった頃に同じような状態になりました。SEからデータサイエンティストに転身した後だったので、「こんなことができるんだ！」と感動しつつも、教師なし学習などの他の手法が分からない時期がありました。

このような状態だと目の前に提示された課題の解決手段に乏しく、有効な打ち手をなかなか見つけることができません。この例でいうと、明確に目的変数が与えられないと何もできない、ということになります。

このアンチパターンを回避するには、第一にビジネス課題を技術的課題に落とし込むプロセスを必ず挟むということです。

一般的なITシステム開発で例えると、業務要件からシステム化要求事項にブレイクダウンすることに相当します。データ分析の場合は、取り組むべき課題の種類を特定し、データによるアプローチが可能か判断しつつ、メカニズムを想像することが大切です。いずれも、課題の構造を抽象化してひも解くわけで、観察力が鍵になります。

また、技術的な打ち手が限られるという問題については、時間をかけて武器を増やして対応していくしかありません。こればかりは一足飛びに解決できないので、地道に学んでいきましょう。もし、プロジェクト運営で問題になるなら、分析アプローチを俯瞰できる人材をアサインすべきです。

③事例だけで発想すると夢見がちになる

3つ目のアンチパターンは、技術的な理解を飛ばして事例だけで発想する、というやり方です。図にすると以下のような形ですね。

ビッグデータブーム、第3次AIブームなど、バズ的なビジネストレンドが発生したとき、このパターンがいたるところに出現していたのを目撃しています。このアンチパターンは、技術者不在の時に発生しやすいものです。ごくまれに上手くいくこともあるとは思いますが、大半のケースでPoC止まりになったり、技術チームが引き継いだ後に炎上したりします。

事例を学ぶことは重要ですが、それを深く掘り下げることが大切だと考えています。そのために、ビジネスのユースケースレベルでの考察に加えて、技術的な背景をおさえなくてはなりません。

当然のことながら、表に流通している「事例」の中を深く除くことは難しいため、事例にある文章だけに頼ると限界があります。そのため、実務経験を通して抽象的な整理が必要になってきます。

まとめ

前回の記事に続いて、問題設定のアンチパターンを取り上げてみました。残念がなら、これらを回避するお手軽な方法は持ち合わせていません。

しかし、経験を積み上げることで徐々に回避できるようになる、ということは身をもって学んでいます。また、データサイエンティストの育成経験も踏まえても、この壁を乗り越えた方はたくさんいました。

少し先になるかもしれませんが、壁を乗り越えるためのヒントをまとめていきたいと思います。