B-log

コンサル→ベンチャー。ビジネス系のネタ。

機械学習プロジェクトで、予め精度の保証を求めてはいけない:ビジネスサイドから見たAIプロジェクトのコツ

機械学習プロマネは、普通のプロマネとちょっと違う

最近、機械学習とかAIを使ったプロジェクトに関わる機会が増えてきました。
世の中的にも、機械学習を使ったプロジェクトは増えているように思います。
 
自分は機械学習の専門家ではありませんが、
多少は数字やデータに強いので、純粋ビジネスサイドと機械学習・データサイエンティストの橋渡し的な役割でプロマネをさせていただく機会をいただいています。ありがたいことです。
 
そして、そのような役割の人間からすると
機械学習プロマネって、ちょっとこれまでのやり方と違うな」と思う瞬間が結構あります。

予め精度の保証を求めてはいけない

その一つが、機械学習を使って予測・判断のモデルを構築するプロジェクトにおいて、「予め予測精度の保証を求めてはいけない」ということです。
 
機械学習を使って、予測モデルを作るプロジェクトで
ビジネスサイド「それって、どれくらい精度出るの?」 
データサイエンティスト「やってみないとわからないです」
みたいなやり取りが発生し、 
結果、お互いモヤモヤが残る。
 
こんな場面に遭遇したことある方、少なくないはずです。
 
これには、構造的な背景があると思っています。  

機械学習プロジェクトの大まかな流れ

そもそも、機械学習のプロジェクトは、大まかに以下のような流れを取るようです。
 

f:id:f-bun:20210331110731p:plain

①ビジネス上の課題定義 > ②データ収集 > ③分析・モデル構築 > ④システム開発 > ⑤運用
 
今回は、上記の①とか②の段階で「精度を求めてはいけない」という話です。
 
例えば、「会計ソフトのデータから、倒産リスクを予測する」というモデルを構築するとします。その場合、
 
「①ビジネス上の課題定義」では、
  • そもそもなぜ倒産リスクを予測したいのか
  • 「倒産リスク」とは何年後の倒産リスクなのか
  • 具体的に、そのアウトプットを使ってどんなことがしたいのか
  • なぜ、今の手法のままではいけないのか
などを定義します。
 
「②データ収集の工程」では
  • 考えられる変数(特徴量)は何か
  • どういったデータが取得可能か(社内/外)
  • それは、過去および未来に渡って、どれくらいの期間取得が可能か
  • データ量は、機械学習に十分か
などの検討に加え、実際の学習用のデータを作る泥臭い作業が待っています。
 
これらを経て、
「③分析・モデル構築」の工程で初めて、様々な試行錯誤を経て、精度XX%の倒産予測モデルが構築されます。
 

なぜ、事前に精度を求めてはいけないのか

冒頭の
ビジネスサイド「それって、どれくらい精度出るの?」
データサイエンティスト「やってみないとわからないです」
というやりとりは、このプロセスに沿って理解するとわかりやすいです。
 

f:id:f-bun:20210331110748p:plain

データサイエンティストの言い分
まず、データサイエンティストからすると、
実際、「③分析・モデル構築」の工程に入らないと、精度はわからないことが多いでようです。
これは、単に予防線を張っているわけではなく、実際わからないことが多いようです。
 
その理由を聞くと
  • 「①ビジネス上の課題定義」におけるビジネス側のリクエストがフワフワしている。
  • 「②データ収集」を少なくとも予備的にやってみないと、データがどれくらい集まるのかわからない(そしてその結果としてデータの質と量が確保できないと、良いアウトプットは出ない)。
  • それを踏まえて「③分析・モデル構築」でモデルに実際入れてみないとわからないことが多い。世の中の一般的な水準も、そこまで確立されていない。
  • 機械学習は、セールスとかより「頑張れば数字上がる」に限界があるところ、不確実な状況下で予め精度を示すとそれが(不可能なのに)目標化して自分の首を絞めることになる。
あたりが主要な理由なようです。
 
ビジネスサイドの言い分 
他方で、ビジネスサイドからすると
  • そもそも、何らかの施策を打つんだから、投資対効果を知りたい。せめて精度の目処は欲しい。
  • ちゃんとスケジュール引きたい。
  • 「①ビジネス上の課題定義」「②データ収集」と、「③分析・モデル構築」の初期だけでも、相当時間を投資することになりそう。だから尚更早めに目処が欲しい。
なので「それって、どれくらい精度出るの?」と聞きたくなってしまう。
 
 
この2つによって、不幸な行き違いが生まれるのだと思います。
 
 

解決の方向

基本的な方向は「3パターンくらい、ゆるく、見立てを共通認識とする」

では、どうするのか。
 
結論としてお勧めしたいのは、
「楽観 / 悲観 / 中間シナリオ くらいのゆるさで、精度の見立てを分析サイドとビジネスサイドで共通認識として形成すること」
です。
 
実際、データサイエンティストに聞いてみると、実際は、楽観 / 悲観 / 中間シナリオ くらいなら、経験に照らして見立てを出せるケースが多そうです。
 
ただし、この見立ては外すことも多そうなので、約束・目標とするのは抵抗があるとのこと。
なので、事前の精度の見立ての必要性に関する共通理解の下、あくまで「見立て」であって「コミットメント」ではないことを強調しつつ共通認識を形成する
そうすれば、(変数の振れ幅大きくて難しいのですが)プロジェクトを設計・遂行できると思うのです。
 

データサイエンティストに求められること

そのために、データサイエンティストには
  • なぜ、精度を予め保証できないのか(上述のような理由)
  • 世の中的にもそんなもんだということ(できれば、具体的な事例ベースで)
を、ビジネスサイドに対して(どうか「こいつアホだ」と諦めずに)分かりやすく説明いただけると嬉しいです。
 
そして、
  • ビジネスサイドは、ビジネス上の課題解決にすごいプレッシャーを負っていることへの理解
  • ビジネス(特にオペレーションレイヤー)って内部/外部環境のちょっとした変化で打ち手変わるから、リクエスト(課題定義)が曖昧なのは仕方ないこともあることへの理解
  • プロジェクト設計上必要なら、「参考程度ゆるい見積」として楽観 / 悲観/ 中間の3パターンくらいで、精度の見立てを提供できること
を示してくれると、もっと嬉しいです。
 

ビジネスサイドに求められること

逆に、ビジネスサイドの人間としては
  • 上述のような理由から、事前に精度を保証させるのは無理っぽいということ
  • それは世の中的にもそんなもんで、今自分の前にいるデータサイエンティストの腕が悪いのでは決してないこと
をしっかり理解する必要があると感じています。
その上で、
  • とはいえ、ビジネスとしては課題を解決したいこと(その向こうにお客さんや世の中がいること)
  • プロジェクト設計はしたいから(「見立てが外れても俺のプロマネ力でどうにかしてみせる!」という気概を持って)「参考程度ゆるい見積」として楽観 / 悲観/ 中間の3パターンくらいでいいから、見立てがほしいこと
を、データサイエンティストに誠実に伝えなくては、と思っています。
 
そして可能な限り、統計や機械学習の勉強をして、見立ての背景にある変数や、各シナリオの成立条件について理解できるようになりたいと思っています。
(「最初の一冊」には「文系AI人材になる―統計・プログラム知識は不要」がオススメ)

 

 そうはいうものの、、

ただ、そうはいうものの、こういうコミュニケーションは、現状としてどうしても限界があります。
 
なぜなら、ビジネスサイドは「数式アレルギー」ある人多すぎるし、
他方でデータサイエンティストは、「正確だが難しい数式」か「過度に簡略化した比喩」や「こういうもんです!」で説明しがちで、「ちょうどいい塩梅」の説明ができる人が少ない(気がする)からです。
 
なので、その間に立てる人材になれれば、あと5年くらいはバリューの出しどころがあるんじゃないかなぁ、と個人的には思っています。
 
<<関連記事>>
そもそも「精度」って書いちゃいましたが、ビジネスサイドがなんとなく使う「精度」には色々な意味合いがあります。その辺も解説しました。


ビジネスサイドの人に 「文系AI人材になる」はホントおすすめ