機械学習プロダクトで「スクラム」的開発をやってみてわかったこと
こんにちは、MNTSQというリーガルテックの役員をしている堅山といいます。
今回のエントリでは、機械学習プロダクトにおけるアルゴリズム開発の現場で、スクラム的な手法をとりいれたらうまく行ったよ、という話を紹介したいと思います。あくまで、「的」なので、完全にスクラムなんや、という感じではないのをご了承ください。
さて、MNTSQでは、大量の契約書をNLPや機械学習を用いて解析しているのですが、解かねばならないタスクがたくさんあります。契約書からの範囲抽出（タイトル、契約締結日、契約期間、契約者 etc...）や、第一条、第二条といった条文の構造の分析、各条項のリスク分析など、多岐にわたり、これらのタスクを高速に実装していく必要があります。（詳しくは以下の前回のエントリをみてください！）
解決したい課題
初期の開発においては臨機応変にスケジュールや優先順位を引いていたのですが、進めていくうちに以下の点がわかってきました。
1. 各メンバーがその機能開発にフォーカスできることが重要
あるタスクに紐づく特定のデータに対して様々な方向から分析したり、手法を試したりしていくので、細切れにいろんなタスクが入ると、分析の文脈が切り替わることとなり生産性を大きく低下させます。
2. 一つのタスクにずるずる時間を取られてしまうことが起きがち
日本語のリーガルドキュメントというニッチなデータを対象としていることから、あまり先行例が見つからないタスクなどもあり、どれくらい時間をかければどのような精度が出るのかなど検討がつきにくく、例えば、もう少しやれば精度が上がるかも、というような形でサンクコストに引っ張られてずるずる期間が伸びるといったことがおきがちでした。
そこで、スクラムを参考にした開発を行うのがよいのではないか、ということで、取り入れてみることにしました。
スクラムって？
そもそも「スクラム」というのはソフトウェア開発におけるチーム開発の手法の一つです。「スプリント」という一定期間に取り組む範囲を決めて、決めたスコープの実装に集中する機能を作っていくサイクルを何回もまわしていくことで、プロダクトを実装していきます。ざっくり書いていくと…
1. (Product Backlogの作成) プロダクトオーナーが機能レベルの優先順位を決め
2. (Sprint Backlogの作成) スクラムマスターを中心に、チームがProduct Backlogの中から次のスクラムで実装する機能について、実際のタスクに分解していき
3. (Sprintの実施) チーム内で一定期間の「スプリント」期間を通じて実装を進め、リリース判断をする
という構造です。「スプリント」内では、毎日の状況確認(デイリースクラム)と、定期的なレビューが走ります。
（このへん、会社によっても違う部分があると思います。プロダクトオーナーとスクラムマネージャーは、スタートアップだと分離しているところは少ないかもしれません。弊社も分離してないですね。）
期間を限定し、ゴールを明確に決め、リリース判断をする機会がきちんと生まれるということで、課題の解決にぴったりと判断しました。
一方で、2 weekという時間を切ってしまうことで、チャレンジングなR&D的なタスクに取り組めなくなるのではないか、という危惧もありました。
結果
- 2 weekごとのリリースサイクルごとに定期的に新しいモデルや機能をリリースできるようになった
- ロードマップ(=Product Backlog)を策定することで、むしろ一定の工数をR&D的なタスクに割り振り続けるということができるようになり、安定して一定の時間を使えるようになった
どんな感じでやってるか？
機械学習を中心としたプロダクトでは、機能の中心をモデルの精度が担う場合も多くあり、まずはモデルを作ってみて、どのような精度が出るか、ということを検証するところからはじまると思います。
ロードマップ
MNTSQでは、作りたい機能群のうち、機械学習モデルの精度検証が必要な機能だけを集めて、ロードマップを引き、これがProduct Backlogの役割を果たしています。機械学習モデルの開発では、まずそもそもデータセット作成が前工程としてあります。MNTSQでは機械学習部分に携わるのは、「機械学習チーム」と「リーガルチーム」であり、後者がアノテーション基準の定義と、データ作成を行っているので、その状況に合わせてどのタスクから取り組むかをが変わってきます。週に1度、ロードマップを両チーム合同で確認し、データセット作成の状況や、優先順位の確認を行っています。ここで、どれくらいの工数が必要そうかも簡易に見積もり、R&D的なタスクの割合が一定程度になるように調整も行います。
スプリント
MNTSQでは「スプリント」の単位をリリースサイクルに合わせて2 weekとしています。ここからSprint Backlogをどう作るか、なのですが、まず機械学習モデルの構築では、データ自体を分析しないと期間内で何をすればいいか決められないという側面があると思います。
例えば、あるタイプの契約書は書き方が定型化されており正規表現でも簡単に精度が出せそう。のこりは機械学習でときたいが、その部分だけだとデータが足りないのでアノテーションしてもらおう、などといったことはデータを分析しないとわかりません。そのため、機能レベルに紐付いたやりたいタスク定義と、そのデータを揃えたら、まず「スプリント」には入ってしまいます。
さらに、MNTSQでは、各ロードマップ項目(=Product Backlog上の項目)の開発に携わる機械学習エンジニアは多くの場合、1人としています。つまり、ある実現したいタスク（例：契約書から条を切り出したい）があり、それに対してデータセットが用意され、1人のエンジニアがそこにスプリント期間没頭する、という進め方をしています。
MNTSQでは、すでに実用的な精度に達しているタスクもたくさんあるのですが、「できたらすごく嬉しいが、どんな性能になるかよくわからん」という分散の大きいタスクがまだまだたくさんある状況なので、これらの分散を小さくし続けることが、事業仮説の精度を上げるのに一番効くと考えています。そのためには検証プロセスをできるだけ並列で回すことにフォーカスしたいと考えており、1人で1つのタスクを解くというのはそのためです。
ただもちろん、複数の機械学習エンジニアが同じタスクに取り組むというのは、「精度を上げる」局面では、例えば各人の作ったモデルをかけ合わせてEnsembleして精度向上するなど非常に効果的だと思っているので、一度実施したタスクについては、再度実施する際は前回の担当者と違うメンバーが担当するようにもしています。
定期レビュー
その代わり、定期レビューを厚めにやることを重視しています。普段もやりとりは活発ですが、週に1度、現状の精度や間違えた例をもちより、機械学習チームとリーガルチームが全員で合同で、ディスカッションする機会を作っています。
ここで、ドメイン知識を共有し、精度を高める方法を議論します。例えば、「事業の譲渡」と「事業譲渡」は違うので、一律で助詞を無視する前処理はよくないね、という指摘や、この言い回しはかなり特殊なので、学習データからのぞいてよさそうなど、色々なアイデアがでるようになりました。
さらに、機械学習モデルが限界事例をあぶり出す場合もあり、法的な内容のディスカッションをしたりもします。間違えた例は許容可能か、アノテーションは正しいのかなど、様々な視点で検討することができ、最終的にリーガルチームからユーザーの目線をインプットすることで、リリースできそうかを判断します。
まとめ
機械学習モデルの開発は特に不確実性が高く、MNTSQのような初期のスタートアップでは、どれくらいの精度が達成できるか見当がつけにくいタスクも解く必要があります。これらの不確実性をマネジメントするのに、スクラムという形式は非常に有効だと感じており、今後も発展させていきたいと思っていますMNTSQでは機械学習チームに参画いただけるアルゴリズムエンジニアを募集しています！