MNTSQの機械学習エンジニアの仕事の進め方

こんにちは、リーガルテックのスタートアップであるMNTSQ（モンテスキューと読みます）取締役をしています堅山です。
面談等で質問を頂く機会も多かったので、これから何回かに分けて、MNTSQで機械学習エンジニアがどのように仕事をしているのかについて話していきたいと思います。

今日はまず、MNTSQで心がけている仕事の進め方の話を紹介したいと思います。

もくじ（予定）
-  （今回）MNTSQの機械学習エンジニアの仕事の進め方
- 契約書解析を支える技術
- MNTSQの機械学習エンジニアの2週間

MNTSQってどんな会社？

リーガルテックベンチャーのMNTSQは、足元では法律事務所の法務デューディリジェンスという業務を効率化するソフトウェアをSaaSの形で提供しています。

法務デューディリジェンスは、M&Aにおいて対象企業を買収検討する際に、買収される会社の契約書を確認し、問題がないかを確認するプロセスです。法的な効力のある契約書は現状ではほぼすべて紙で保存されていますから、対象企業からスキャンされたPDFファイルが送られてくる事が多く、これを確認するのは非常に骨が折れるプロセスでした。
MNTSQは、ソフトウェアと機械学習の力で、法務デューディリジェンスにおけるファイル管理の問題を解決し、OCRで内容を検索可能にし、さらにリスクのある条項や契約者名などの重要な情報を抽出しています。

さらに、法務デューデリジェンスの効率化で培った解析技術を用いて、一般企業に対しても製品を提供していくため、新たなプロダクトを鋭意開発中です。

つまり、MNTSQはエンタープライズ・トップファームのお客様を対象とした、法務領域のSaaS企業です。そのため、以下のような性質があります

エンタープライズユーザーの高い期待値に答え続ける責任
エンタープライズユーザーにとって、既存の機能の安定性は重要です。MNTSQを仕事道具として使っているユーザーにとっては、例えば検索機能に関して、オーバーオールの検索性能が上がっていたとしても、徳衛のクエリで今まで検索できていたドキュメントが見つからなくなることがとても嫌な変化の場合もあります。仕事道具になっているソフトウェアには、複数のオペレーションが依存していたりするので、変更が業務の進め方に影響を及ぼしてしまったりするわけです。
仕事道具であるということは大きなネットワーク効果をもたらすためビジネス的にはGoodですが、ソフトウェアの開発に関して気を使う部分が増えるのは間違いありません。例えば、Microsoft Officeがいかに後方互換性に注力してシェアを維持しているかを思い浮かべる必要があります。

一方で、MNTSQはSaaSであることから、将来の継続的な機能追加に期待してお金を払っていただいている側面があります。安定性を優先して新機能をリリースできないのでは意味がありません。安定性とプロダクトの継続成長を高いレベルで両立させる必要があります。

機械学習では簡単に解けない難しいタスクも存在
法務領域で契約書を読み解くには、非常に難しいタスクがたくさんあります。枚挙にいとまがないのですが、具体例をあげると、他の契約書を参照していて、読み解くのに必要な情報がひとつのドキュメントで完結しなかったり、非常に複雑な表をOCRした上で解析しないといけなかったりします。

簡単な方の表でこんな感じです

MNTSQでの仕事の進め方

そこで、MNTSQでは以下のことを意識した仕事の進め方がされています

データによる意思決定の徹底
機能の安定に対する期待に答えつつ、新機能を提供し続けるため、現状より一部機能の精度が下がるような変更、機能を減らすことは明示的な決断のもと導入を決定するようにしています。
そのため、各機能開発では、影響範囲を精査し、変更による精度の変化をモニタし、Github Issueを使ってプロダクトチームも含めたディスカッションを行っています。そのため、各機能開発では、影響範囲を精査し、変更による精度の変化をモニタし、Github Issueを使ってプロダクトチームも含めたディスカッションを行っています。

常に改善をリリースし続ける
SaaSですから、「今後もこのプロダクトを使い続けていってよい」という感覚をユーザーに持ってもらえることを大切にしています。そのためには継続して機能が開発され続けることを、リリースを通じて感じて貰う必要があります。
数ヶ月だまって開発して大きな機能を出すよりも、一部のスコープに絞ってでもリリースする、ということを心がけています。

インパクトを計測する
スタートアップの限られたリソースで小さく継続的なリリースを続けるためには、どこから取り組むべきか、を常に考える必要があります。
例えば、全ての契約書タイプで考えるとprecisionは50%でも、実は全体の30%を占める契約書タイプでは90%でした、といったことがわかれば、じゃあとりあえずそこだけリリースできるかを検証しよう、といった意思決定ができます。
逆に、例えば「条項同士の参照関係をより高度に解析しよう」といった面白そうなタスクでも、実はこれが発生する契約書は全体の1%でした、となればやらないという意思決定をします。

技術的不確実性を高速に検証し、素早く仮説を修正する
法務領域の自然言語処理タスクは非常に幅広く、「できるかわからない」という領域がまだまだ非常に大きい状態です。予測を立てた上でプロダクトの価値仮説を考え、製品を作り始めますが、さまざまな不確実性が存在し、事前にすべて予測することはできません

- 実際のデータの多様性がどれくらいあるか
- 十分な教師データを作れるか
- どこまで精度が出たらユーザーの助けになるか
- 実際にどれくらい精度が出るか

実際に重要なのは、技術的な不確実性を素早く計測し、このタイプのタスクは解けないかも、とわかったらプロダクトの価値仮説を素早く修正するところまで素早くフィードバックすることです。
例えば、契約書に書かれているある数値まで取る想定だったが、複雑なかかれ方をしていて、取れない場合がある。そういった場合に、実はどこに数値が書かれているかまでわかるだけでも嬉しい場合があるんだということを発見していく、といったプロセスに価値があると考えています。

次回予告

次回は、実際にMNTSQでは何してるの？という「契約書解析」のタスクの全貌に迫っていきたいと思います！
お楽しみに〜

MNTSQでは機械学習エンジニアを積極採用しています！

MNTSQ, Ltd.の会社情報 - Wantedly