目標の精度を達成して、顧客にも受け入れられて、納品も終わったのに、半年後に見たら誰も使っていなかった。
機械学習の案件で一番こたえるのは、この終わり方だと思っています。失敗して怒られる方がまだ分かりやすいです。数字の上では成功しているので、何が悪かったのかを自分で探しに行かないと分かりません。
この記事では、精度が出たのにビジネスが動かないというパターンについて書きます。技術的な失敗ではないぶん、事前に防ぐには別の見方が要ります。
目次
1. 目標を達成したのに使われなかったモデル
ある業務で、担当者が目視で仕分けていた作業を機械学習で自動化する、という案件がありました。
要件は明確で、精度の定義も事前に揃えていました（この定義を揃え損ねて揉めた別件は認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に書きました）。モデルは目標を上回る結果を出し、検収も問題なく通りました。
しばらくして状況を聞いたところ、現場では従来通り人が目視で仕分けていました。モデルは動いてはいるものの、出力は参考程度に見られているだけでした。
このとき私が最初に思ったのは「精度が足りなかったのだろうか」でした。実際に運用データで測り直してみましたが、検証時とほぼ同じ数字が出ていました。技術的には問題がありません。
問題は別のところにありました。
2. 使われなかった三つの理由
現場の担当者に話を聞いて分かったのは、次の三つでした。
間違えたときに誰が責任を取るのかが決まっていなかった。 目視なら、間違えたのは担当者です。モデルが間違えた場合、その結果をそのまま採用して問題が起きたら誰の責任になるのか。ここが決まっていないので、結局は人が全部確認することになります。確認するなら、最初から人がやるのと手間は変わりません。
なぜその判断になったのかが説明できなかった。 仕分けの結果を後から問われたとき、「モデルがそう判断したので」では通りません。現場の担当者は、上司や取引先に説明する必要がある立場でした。説明できない道具は、精度が高くても使えません。
業務の流れに入っていなかった。 モデルの出力は別画面で確認する形になっていました。担当者からすると、いつも使っているシステムとは別の場所を見に行く必要があります。忙しいときに、わざわざ開きません。
三つとも、精度とは何の関係もありません。そして三つとも、着手前に確認できたはずのことです。私は「何を予測するか」は詰めましたが、「予測結果をどう使うか」を詰めていませんでした。
3. 精度はビジネス指標の代理でしかない
この件以降、目標設定の順番を変えました。
以前は、まず技術的な指標を決めていました。再現率を何%にする、という形です。今は、先に業務側で何が変わったら成功なのかを決めます。
たとえば「仕分けにかかる時間を月あたり何時間削減する」といった形です。そこから逆算すると、必要な精度も自然に決まります。人の確認をどこまで減らせるかが時間削減に直結するので、確認が不要になる水準はどこか、という問いに変わります。
この順番にすると、技術指標だけでは足りないことがすぐ分かります。時間を削減するには、間違えたときの扱いを決めておく必要がありますし、確認しやすい画面も要ります。最初から、それらが目標に含まれることになります。
もう一つ変わったのが、達成できなかった場合の判断です。ビジネス指標から入ると、「精度が目標に届かなかったが、それでも月10時間は削減できるので導入する」といった判断ができます。技術指標だけを置いていると、届いた・届かなかったの二択になり、惜しい結果が全部失敗に見えます。
このあたりは予算の考え方とも似ていて、何をもって良しとするかを先に決めておく話です。機械学習案件で費用が読めなくなる問題は機械学習プロジェクトにおける予算管理の成功要因に書きました。
4. 運用に乗る形まで設計する
もう一つ、着手前に確認するようにした項目があります。
間違えたときの扱い。 モデルが誤った場合に、業務としてどう処理するのか。誰が気づいて、誰が直すのか。ここが決まっていないと、結局は全件確認になります。全件確認するなら自動化の意味がないので、そもそも案件として成立しているかを確認する項目でもあります。
説明の必要性。 出力の根拠を人に示す必要があるかどうか。必要なら、モデルの選び方が変わります。精度がわずかに落ちても、判断根拠を出せる手法を選ぶ方が実際には使われます。ここを聞かずに複雑なモデルを選ぶと、後から作り直しになります。
どこに表示されるか。 既存の業務システムの中に出るのか、別の画面になるのか。別画面になる場合、それでも見に行く動機があるかを確認します。たいていありません。
誰が運用するのか。 データが変われば精度は落ちるので、再学習が必要になります。顧客側にできる人がいないなら、保守として引き受けるのか。ここを曖昧にしたまま納品すると、後から無償の運用支援が発生します。
どれも技術的な検討ではなく、業務側への質問です。エンジニアとしては聞きにくい部類の話ですが、聞かないと今回のような終わり方をします。
5. まとめ
機械学習の案件が、精度は出たのに成果につながらないとき、原因はたいてい次のどれかでした。
- 間違えたときの責任と手順が決まっていない。 結果として全件確認になり、自動化の意味が消える。
- 判断の根拠を説明できない。 説明責任のある立場の人は、説明できない道具を使えない。
- 既存の業務の流れに入っていない。 別画面は見に行かれない。
- 運用の担い手が決まっていない。 精度は必ず落ちるので、誰が直すかまで含めて設計が要る。
これを防ぐには、技術指標より先に業務側で何が変わったら成功なのかを決めることだと思っています。そこから逆算すれば、必要な精度も、必要な運用の形も自然に決まります。
モデルの精度を追いかけるのは楽しいですし、分かりやすい成果でもあります。ただ、その数字が何の代理指標なのかを見失うと、数字だけが立派なまま誰にも使われないものができあがります。
案件に固有のリスクの洗い出しはリスクマネジメントの役割とプロジェクトの成功に、そもそもデータが使える状態になっていない問題は集めるだけのデータはゴミと同じ──活用しなければ意味がないに書きました。プロジェクト管理全体の枠組みはITプロジェクトマネジメントの基礎とその重要性にあります。