先日、こんな素晴らしい記事を読みました。
データ分析屋としてキャリアを積んでいる私にとってAgileの考え方はとても腑に落ちやすいものだった。そもそも、データ分析自体、繰り返しの検証をするものなのだ。
（太字原文ママ）
僕自身はソフトウェアエンジニアではないので、Waterfall / Scrum / Agileそれぞれの開発スタイルの定義や違いはたまたその実践について何か論評できる立場にはなく、エンジニアチームの現場にいたこともあるので「雰囲気ぐらいなら」おぼろげに分かっているという程度の理解レベルです。ただそれでも、この記事で提唱されている「データサイエンスはAgile」という考え方については、僕個人の経験から言っても大いに納得できるものがあります。
実は、ここ1年ぐらいデータ分析の仕事をしていく中で「手戻り」「ロールバック」は是か非か？という議論を目にする機会が何度もあり、その度にこの記事に近い主張をすることが僕にもあったのでした。その点でこの記事はそこにAgileという概念を与えてくれたという感があります。そこで、今回の記事ではAgile（そしてWaterfall / Scrumとの違い）というソフトウェアエンジニアリングの話題にまでは踏み込まずとも、データ分析という営みにおいていかにAgile的なアプローチが重要かという話を、誰か他の人に説明する際の個人的な備忘録としてまとめておこうと思います。勿論、いつもながらですが僕自身の認識不足や誤解などありましたら是非ご指摘ください。
- 「ステークホルダーに醜態は見せられない」完璧主義の罠
- 誰も「真の正解」が分からないからこそ、探索と手戻りの繰り返しで最適解を求めに行くのがデータ分析
- そもそも探索的に手戻りを繰り返すのが統計/機械学習モデリングの本質でもある
- 追記
「ステークホルダーに醜態は見せられない」完璧主義の罠
(Image by Pixabay)
個人的な観測範囲の話ですが、B2Bビジネスなど法人顧客向けのデータ分析を手掛ける業界でよく話題になるのが「どれくらいの完成度でステークホルダーのところにデータ分析結果を持っていくべきか」。これこそまさに正解の全くない問いだと思うのですが、データ分析業務がコンサルティングに近いせいもあってか、いわゆる「最後の最後まで完璧なアウトプットを目指して万全の状態でステークホルダーに披露する」的なスタイルが求められることがままあるように個人的には感じています。
すなわち、世間で言うところの外資コンサルのプレゼン術*1における「この一番大事なKPIのページのタイトルのフォント数が〇〇ではいけない」的なノリで、「この需要予測モデルの値が0.92しか行かないのは見栄えが悪いので説明変数に〇〇と△△を加えて
値を0.95以上にしなければならない」*2的な細かいチューニングをびっしり繰り返す、というような話です。
で、実際にステークホルダーにそのモデルの当てはまりと予測並びに解釈を披露し、さらには業務改善提案を行うと、肝心のステークホルダーたちから「いやこのモデルのこれこれの仮定は現場の感覚に合っていない」とか「このモデルを解釈して得られる知見はむしろこれこれのはずでは」というような指摘が飛ぶことが多いわけです。これ自体は特に珍しいことではないはずです。
ところが、上記のような完璧主義的なコンサルのスタイルに慣れている人たちから見ると、そのようにステークホルダーたちから指摘を受けること自体が「あり得べからざる『しくじり』もしくは『醜態』」と映ることがあるらしく、「ステークホルダーからネガティブな指摘を受けないようにもっと事前のリサーチ・サーベイを徹底していつでも完璧なモデリングや実験結果を提供できるようにするべきである」というような話に発展してしまうケースがままあるようです。
そうなってしまうと、当然ですがデータ分析業務に完璧を期すために例えば「見落としがないようにもっと説明変数を考え得る限り多く加える」とか「分析結果の解釈にステークホルダーとの齟齬がないように可能な限りヒアリングを密に行う」というような話になります。しかし、前者はやり方を間違えれば容易に過学習につながりますし、後者はまだ分析結果が出ないうちにそんなことをしても分析軸がいたずらに増えるだけです。結果として、そのデータ分析プロジェクト自体がスピード感に欠けた鈍重なものになってしまうことがあるとかないとか。。。
誰も「真の正解」が分からないからこそ、探索と手戻りの繰り返しで最適解を求めに行くのがデータ分析
では、どうするのが良いのでしょうか。その答えの一端が、冒頭にご紹介した記事に見えるように思います。すなわち「Agileなスタイルでデータ分析にも取り組む」ということです。言い換えると、
- とりあえずデータ分析してみて得られた仮置きの結果を、逐一ステークホルダーに見せてフィードバックを得る
- 仮置きの結果へのステークホルダーからのフィードバックをもとに、分析のやり方を改善するというプロセスを繰り返す
- これ以上の改善は一旦不要となったところで、最終的なアウトプットをステークホルダーに示す
というような行きつ戻りつのプロセスを経ながら、最終的なデータ分析のゴールに向かう、というやり方です。上記のような完璧主義的なアウトプットに慣れてしまっている人たちから見ると迂遠どころか時間の無駄と映るかもしれませんが、僕の個人的な経験から言えばこのやり方の方が完璧を期してあれこれ手を回したり吟味を重ね倒したりするよりは、よりスピーディーにステークホルダーが求めるゴールにたどり着けるように感じています。
何故かというと、データ分析という営みの宿命として「誰にも『本当のゴール』がどこにあるかは最初のうちは分からない」からです。ありがちなパターンで言えば、
元々の計画では、顧客の経営陣の「うちの会社でもぜひ深層学習とやらを使って凄いことをしてみたい」という要望に応じて「自社のDBに大量に蓄積している1st partyのユーザーデータ」を使って機械学習（深層学習）でユーザーのターゲティングを行うつもりだったが、いざ自社DBの蓋を開けてみたらユーザーデータ測定のバリエーションに乏しく、それ単体ではターゲティングに使うには情報が少な過ぎる。そこで考え方を変えて、自社サービスの購入行動を大きくn通りにカテゴリ分けして、カテゴリごとにユーザーデータを分析してみたところ、カテゴリ間でユーザー行動に大きな差異があることが判明した。そこでさらにユーザー行動を分解してペルソナ化し、それぞれのペルソナに向けてパフォーマンス・ブランディング両面を強化したマーケティングを行うことにした。顧客のマーケティング部門はそれまであまりデータを重視してこなかったので、これはこれで新奇なアプローチであるとしてテストすることになった
というような話です。いかにもありがちな「深層学習ってやつで何か凄いことをしてみたい」*3から始まったデータ分析プロジェクトが、実際に使えるデータの乏しさから方向転換を余儀なくされ、最後はペルソナ別マーケティングという穏当な着地点に落ち着く*4、ということで物の見事に最初の「深層学習」がどっかに行ってしまっています（笑）。B2Bのデータ分析プロジェクトというと、こんな話ばかりというのが僕の印象です。
重要なことは、「深層学習を使う」のはあくまでも顧客の経営陣の当初の願望に過ぎず、顧客にとって本当になすべきことが何であるかは後でユーザーデータをまとめてみるまで見当もついていなかったという点です。この仮想上のケースでは、顧客は行動が大きく異なるユーザーが混在しているということを認識していなかったわけで、それが深層学習の代わりに取り組んだユーザーデータ分析によって炙り出されたということになっています。このように、当初目標を諦めて別方向に探索したことで別の課題が浮かび上がる、ということはデータ分析の現場の「あるあるネタ」の一つです。
その意味で言うと、以前Boxの有名な格言、"All models are wrong, but some are useful" についてこのブログで解説を試みたことがありますが、基本的には同じ文脈の話だと思うのです。神ならぬ身にとっては誰も「真の正解」なんて分かりようがない、なればこそ「よりマシ」で「より役に立つ」解すなわち最適解を求めて、探索と手戻りという試行錯誤を繰り返す。それこそが、データ分析の本質なのではないでしょうか。
例えば「需要予測モデルを構築する」というようなケースでも、ステークホルダーからの要望が「高精度なモデルが欲しい」であったとしても、色々変数を増やしたり減らしたりモデルの予測精度を検証したりした結果、実は「次に当たる施策（変数）がどれであるかを3〜4個に絞り込むのに使えるモデルが欲しい」という要望に変わる、などということは少なくありません。そもそもステークホルダーたち自身がデータ分析で何ができるかを正確には理解していないケースも多いので、その「顧客が本当に欲しかったもの」*5を探り当てるためにも探索と手戻りを繰り返すということは大切だったりします。
そもそも探索的に手戻りを繰り返すのが統計/機械学習モデリングの本質でもある
ここまではマクロな「開発（分析）スタイル」の話として、Agileとか手戻りと探索の繰り返しとかこそが本質だという意見を書いてきました。しかしながら、よくよく考えてみながらそのような手戻りと探索の繰り返しというプロセスは、データ分析のミクロな要素にもあるじゃないかと思い出したのでした。
そう、勾配法です。勾配法では、統計/機械学習モデルの損失関数を最小化するためにパラメータ空間を繰り返し探索し、手戻りを繰り返しては損失関数の最小値（極小値）に向かっていきます。見ようによっては、この最適化の探索プロセスそのものも立派にAgileと言えるのではないでしょうか。そこで、この勾配法と同じノリで実務におけるデータ分析のAgileなプロセスを模式図にしてみるとこんな感じになりそうです。
あるデータ分析のアウトプットが、ステークホルダーにとって真にビジネス要件を満たしている度合いは事前には分からないことが多いわけです。場合によっては、この模式図のように非凸*6かもしれない。。。それを巧みにデータ分析のバリエーション（パラメータチューニングから分析手法の差し替えはたまた着目点の変更など）を変えながら、ステークホルダーにとっての最適点を目指す。最適解を求めて探索と手戻りを繰り返すことこそが、データ分析という営みの本質だと思うのです。
と、いうようなことをこの1年ぐらいずっと考えてきたのですが、冒頭でご紹介した記事で「それはAgileである」と指摘されたことで、色々なことが納得できた気がします。これからは「データ分析とはAgileな取り組みである」ということを、色々な方面に訴えていきたいと思います。
追記
冒頭にご紹介した記事の続編と言いますか、commentary的な記事を書いていただいたようなので、リンクしておきます。興味がおありの方は是非どうぞ。
