はてなのMackerelが明かす、機械学習プロジェクトに潜む2つの「不確実性の山」を乗り越えるコツ：手掛かりは「スクラム」「ゲームソフト開発」（2/2 ページ）

2019年8月29〜31日に開催された「builderscon tokyo 2019」のセッション「われわれはいかにして機械学習プロジェクトのマネージメントをすべきか」で、はてなの「Mackerel」のディレクターが機械学習技術の開発における「不確実性」のマネジメント術を説明した。

[高橋睦美，＠IT]

MLプロジェクトならでは、もう一つの不確実性の山「テスト工程」

　前述の不確実性コーンに従えば、PoCは不確実性の山だが、そこを乗り越えれば後は粛々と開発が進むだけ……と思える。だがそうではなかった。「テスト工程がもう一つの山場で、ここにも不確実性が潜んでいた」（粕谷氏）

　そもそもテストは何のために行うかというと、あらかじめ定めた「完了の定義」をソフトウェアが満たしているかどうかを検証、確認するためにある。ただMackerelの場合、そもそも「何をもって完了と見なすか」という問題があったという。例えば「普段の傾向」とは何か、「普段の傾向からどれくらい外れたら異常と見なすのか」を一律に決めるのは難しく、人によっても、管理対象によっても異なる。ここをどこまでチューニングし、人間の直感に合わせて「いい感じ」に落とし込むかが問われることになるわけだ。

　「ML関連プロジェクトの場合、どんなに突き詰めても誤検知は発生し得るものであり、『精度は100％にならない』前提がある。どこで『いい感じ』にするかを考える必要がある」（粕谷氏）

　Mackerelの場合は特に、過検知と検知漏れという2つの誤検知のトレードオフを考え、どこまで許容するかのチューニングがポイントになったという。そもそもサーバ監視サービスという性質上、起きてもいない異常を夜中に何度も警告し、そのうち誰にも信用されなくなる「狼少年」状態になることだけは避けたかった。そこである程度の検知漏れを許容し、その部分は外形監視など、ML以外の監視手法を使って保証する考え方で、「監視を育てていく最初の『入り口』としてMLを使う形であれば、多少の監視漏れはよかろうと判断した」という。

　「偽陽性と偽陰性のトレードオフをどうするかは難しい問題で、判断はプロダクトの特性によって異なるだろう。Mackerelの場合は、検知漏れを許容して他の検知手法で検知すればいいという具合にバランスを取ったが、例えば医療の画像診断ならば検知漏れの方が恐ろしいことなので、誤検知はある程度許容し、後の精密検査で判定すればいいという考え方になるだろう」（粕谷氏）

　こうして過検知と検知漏れのバランスについて指針を立てた後は、MLが出したアラートと、人間の目や直感で得られた結果や判断理由が一致するかどうかを検証し、人手でアノテーションを付けてスプレッドシートにまとめ、ひたすら地道にチューニングを進めていった。ここが、不確実性のもう一つの山場になったという。

スプレッドシートにまとめたアラートの例（講演資料から引用）

　「普通のソフトウェア開発ならばテストケースがあるので、『このくらいのペースで消化していくと、いついつにはリリースできるか』を精度高く見通せるが、どこまでやればチューニングが終わったといえるのか、終わりが定量的に判断できないので、『いつリリースできるか、テスト工程がいつ終わるか』の判断が非常に難しかった」（粕谷氏）

　そこで取った作戦が、「β版戦略」だ。一部の顧客に先行公開して、ユーザーのフィードバックを得ながら段階的に改善し、正しい判定ができているかを確認することにした。ただ、たとえβ版といえどもそれなりの精度は求められる。Mackerelでは、顧客をダイレクトに支援するチームと連携して「先行お試し公開」の実情を正直に伝え、顧客の理解を得ながらさらなるチューニングを進めていったという。

　広報部門などとも調整し、「2018年12月」という大まかなマイルストーンを立て、2週間単位でスプリントを繰り返すスクラム開発で、チューニングの状態を振り返りつつ、いつ出せるかを判断していったそうだ。「スクラムで現状認識しながら繰り返し判断するのは、やりやすい良い手法かなと思う」と粕谷氏は振り返った。

　ただ最後の最後で、「さらなる不確実性」に遭遇した。Pythonライブラリのバージョンアップに伴って誤検知が増加する問題が発生し、「公開1週間前になって、急きょリリースを延期することにした。最終的にリリースしたのは年明けになったが、リリースの1週間前になってもまだ、こんな不確実なことが起きるのかと、正直面白かった」出来事だったそうだ。

不確実性のマネジメント、手掛かりはスクラムやゲームソフト開発

　こうしてプロジェクトを振り返ってみて、このように不確実性をはらんだものをビジネスとして展開する上でどのようにマネジメントしていくべきか、粕谷氏なりのポイントを挙げた。

　まずは「不確実性の山がどこにあるのかを正しく認識することが大事」と粕谷氏は述べた。チューニングの終わりが見積もりにくいMLプロジェクトの場合、一般的なソフトウェア開発のアプローチに当てはめても同じようにいくとは限らない。あらかじめ山がどこにあるのか分かっていればそれなりに対処できるし、スプリントでリリースまでの時期を判断、報告すれば周りとの調整もできるため、特性を理解するのが重要だとした。

　MLプロジェクトの場合、PoC工程とテスト工程以外は普通のソフトウェア開発と変わらないが、最初と最後だけは大きく不確実性が高まることが特徴だ。その中で、どのようにマネジメントを進めていくべきか――実は、世の中に幾つか参考になる手掛かりがあるという。

　一つは「スクラム」だ。「やはりスクラムは、ML開発においても有用だと思う。スクラムはもともと、野中郁次郎氏の『新製品開発プロジェクトのための新しい手法』に関する論文に触発されたジェフ・サザーランド氏が体系化したものだ。そもそもうまくいくかどうかも分からない、不確実性の高いプロジェクトを管理するための手法なのだからML開発とも相性が良いし、事実われわれもスクラムをベースとして開発を進め、結果としてうまくいったと思う」（粕谷氏）

　もう一つは「ゲームソフトの開発」だ。「ゲームのテストの際には、定性的な『手触り』も重視しながら、細かくチューニングしていく。定量的な品質と、定性的な人間の直感とのバランスをどう取っていくかという部分はMLの開発と似ているのではないか」と粕谷氏。また、最近はゲームの発売日をはっきり明言しないケースが増えているが、これも、大まかな目標は置きつつ、具体的なリリース日はスプリントで判断していくMackerelに似ていることに振れ、「世の中のさまざまな手掛かりや事例を集めながら、自分たちの現場に適用していくのがいいのではないか」と講演を締めくくった。