一般的なシステム開発のリスク管理をそのまま機械学習の案件に持ち込むと、うまくいきません。私は何度かそれをやって、毎回同じところで足を取られました。
理由ははっきりしていて、機械学習の案件には「やってみないと分からない」が構造的に残るからです。普通の開発なら、設計して作れば動くかどうかは事前に判断できます。機械学習では、データを見て、学習させて、評価するまで結果が分かりません。この不確実性は、努力や経験である程度まで下げられますが、ゼロにはなりません。
この記事では、機械学習の案件に固有のリスクを四つに絞って書きます。リスク管理の一般的な手順はプロジェクトのリスク管理：失敗を防ぐための戦略にまとめてあるので、そちらを前提にします。
目次
- 精度目標が決まっていないというリスク
- データが来ない、来ても使えないというリスク
- PoCで動いたものが本番で動かないリスク
- 顧客が期待しているものがずれているリスク
- 不確実性を見積もりにどう入れるか
- まとめ
1. 精度目標が決まっていないというリスク
私の経験では、これが一番よく燃えます。
普通のシステム開発なら、要件を満たしているかどうかは動作で判断できます。機械学習では、そこが連続量になります。精度80%は成功なのか失敗なのか。この合意がないまま進めると、モデルができた後に「思っていたより使えない」という話になります。そして、その時点では手遅れです。
厄介なのは、着手前の段階では顧客も自分たちも、何%が妥当なのかを知らないことです。データを見ないと分からないので、決めようがない。だから決めないまま進む、という力が働きます。
対策として今やっているのは、絶対値ではなく判断基準の方を先に合意することです。たとえば「現在は人が目視で仕分けていて、その精度がおおよそこのくらい。これを下回るなら導入しない」という形にしておきます。数字そのものは後から埋まりますが、何と比べて良し悪しを判断するのかは最初に決められます。
さらに、途中に必ず「ここで一度評価して、続けるかどうかを決める」という区切りを入れます。ここを入れておかないと、精度が出ないまま最後まで走り切って全損する形になります。
2. データが来ない、来ても使えないというリスク
学習データを顧客から提供してもらう案件では、これが常に上位に来ます。
まず、単純に遅れます。個人情報の取り扱いや社内の承認で、想定より時間がかかることが多いです。私は以前これで1か月半持っていかれたことがあります。この失敗の詳細はプロジェクトのリスク管理：失敗を防ぐための戦略に書きました。
そして、届いた後に別の問題が出ます。
- 量が足りない。 事前に聞いていた件数と、実際に使える件数が違う。欠損や重複を除くと半分になる、というのはよくあります。
- ラベルがない、または信用できない。 教師あり学習をやるつもりだったのにラベルが付いていない。付いていても、付けた人によって基準が違う。
- 本番と分布が違う。 過去の一時期のデータだけが提供され、それが現在の状況と乖離している。
対策として効いたのは、契約の前に少量のサンプルを見せてもらうことです。全量でなくていいので、実物を数百件見る。ここで分かることが多すぎるので、これをやらずに見積もりを出すのはもう避けるようにしています。
それでも見えない部分は残るので、データが想定と違った場合に何をするかを先に決めておきます。ラベルを自分たちで付け直す工数を持つのか、スコープを縮めるのか。決めておかないと、その場の勢いで無償対応することになります。
3. PoCで動いたものが本番で動かないリスク
PoCの段階では手元で自由にやれるので、割と良い数字が出ます。問題はその後です。
本番環境では、データの入り方も、処理できる時間も、扱える計算リソースも違います。PoCで1件あたり数秒かかっていた処理が、本番では秒間何十件をさばく必要がある、といったことが後から分かります。モデルの精度は十分なのに、速度で使えないという結末です。
もう一つ多いのが、運用の担い手の問題です。モデルは作って終わりではなく、精度が落ちてきたら再学習が要ります。それを誰がやるのか。顧客側にできる人がいないなら、保守として引き受けるのか。ここが曖昧なまま納品すると、後から無償の運用支援が発生します。
このあたりは、PoCの段階で本番の構成をどこまで見ておくべきかという話でもあります。動くものはもうできていたのに、本番用の構成図を描いていたに、その判断で迷ったときのことを書きました。
対策としては、PoCの終了条件に「本番想定の負荷で測る」を入れておくことです。精度だけを終了条件にすると、この問題は必ず後工程に持ち越されます。
4. 顧客が期待しているものがずれているリスク
これは技術的なリスクではありませんが、影響は一番大きいかもしれません。
機械学習という言葉に対して、相手が何を想像しているかは人によってかなり違います。統計的な予測を期待している人もいれば、人間と同じ判断ができるものを期待している人もいます。後者のまま進むと、どれだけ良いモデルを作っても評価されません。
私が採用面接で毎回「機械学習って何ですか」と聞いているのも、同じ理由からです。この言葉の理解が揃っていないと、その先の会話が全部ずれます。この話は面接で毎回「機械学習って何ですか」と聞いているに書きました。
顧客に対しては、初期の段階でできないことの方を明示するようにしています。「このデータからは、この項目は予測できません」を先に言っておく。前向きな話だけをして契約すると、後で必ず戻ってきます。
5. 不確実性を見積もりにどう入れるか
最後に、これらをまとめてどう見積もるかの話です。
やってみないと分からない部分がある以上、精度を約束する形の請負契約は本来かなり危険です。だからといって「分かりません」では受注できないので、どこかで折り合いをつけることになります。
私がやっているのは、フェーズを切って、フェーズごとに判断する形です。まずデータの調査だけを短期で行い、そこで見えたことを踏まえて次の見積もりを出す。最初から全工程を一括で見積もらない、というやり方です。
これは顧客にとっても悪い話ではありません。データを見た結果「これでは無理です」と早い段階で分かるなら、そこで止める方が損失は小さくて済みます。逆に一括で受けてしまうと、無理だと分かった後も走り続けることになります。
もう一つは、試行回数を工数として明示することです。機械学習は一発で当たる前提の作業ではないので、「何パターン試すか」を見積もりの単位に入れます。ここを暗黙にすると、際限なく試すことになって工数が溶けます。計算リソースの費用も同じ理由で膨らむので、予算の側の話は機械学習プロジェクトにおける予算管理の成功要因に分けて書きました。
6. まとめ
機械学習の案件に固有のリスクは、私の経験では次の四つに集約されます。
- 精度目標が合意されていない
- データが来ない、または使えない
- PoCの結果が本番で再現しない
- 顧客の期待と実際にできることがずれている
どれも、後から気づくと取り返しがつかない種類のものです。共通する対策があるとすれば、早い段階で実物を見て、区切りを入れて、判断のタイミングを作っておくことだと思います。不確実性そのものは消せないので、消せない前提で止められる場所を用意しておく、という考え方になります。
リスク管理の一般的な手順はプロジェクトのリスク管理：失敗を防ぐための戦略に、それを組織として続けるための話はリスク管理の重要性：ITプロジェクトでのベストプラクティスにあります。プロジェクトマネジメント全体の中でのリスク管理の位置づけはITプロジェクトマネジメントの基礎とその重要性をご覧ください。