MNTSQのPM & UI/UX Designerとして2019年を振り返る

こんにちは。MNTSQ（モンテスキュー）というリーガルテック ・カンパニーのCo-FounderでPM & UI/UX Designerをしているikutaniです。

会社としてはほぼ1年目ということで本当に色々ありました。事業上のトピックを最初に簡単にまとめつつ、今日はプロダクト開発現場に焦点をあてて振り返っていきたいと思います！

まずはさらっと事業上のトピックを。

1年で起きた事業上の変化

1. 創業者がフルコミット化し、社員も入社
2. 法律事務所向け事業がPoCを経て本導入され、立ち上がってきた
3. 資本業務提携によって事業を大幅に加速させ、2つ目の事業を立ち上げ中

1. 創業者がフルコミット化し、社員も入社
MNTSQは2018年11月に設立したばかりで、2019年1月時点では創業者4人はまだ前職との稼働調整の最中で、夜や休日を使ってMNTSQにコミットしている状況でした。そこから徐々にコミットできる時間を確保していって、2019年7月にようやく創業者全員がフルコミットになりました。
社員も入社し、まだ9名ではありますがこの1年でちゃんと会社になったなぁと思います。

2. 法律事務所向け事業がPoCを経て本導入され、立ち上がってきた
1st Productなので当然ですが、2019年の前半は事業立ち上げに全てのリソースを投下しました。五大法律事務所の1つである長島・大野・常松法律事務所（NO&T）とのPoCを経て本導入が決定。導入後もサポートや協議、改善を重ね、所内でより使われるプロダクトになるため現在もがんばっています。

3. 資本業務提携によって事業を大幅に加速させ、2つ目の事業を立ち上げ中
2019年10月21日に、「トップクオリティのリーガルナレッジを持つ長島・大野・常松法律事務所（NO&T）」と「トップレベルの機械学習・自然言語処理技術を持つPKSHA Technology」の2社と資本業務提携を行いました。
8億円という資金に加え、各業界のベスト・プラクティスを継承したプロダクト作りができる座組みを整えることに成功し、エンタープライズ事業への参入を決定しました。

現在では以下の2つの事業に取り組んでいます。

さて、ではプロダクト開発について振り返っていきます！

がんばった部門 Vol.1 「OCRえぐい」

言わずと知れた鬼門の1つ。締結済みの契約書や紙面で交わされたものなどはスキャンされて画像PDFで保存されるため、OCRで文字認識をしなければなりません。

まだ日本語OCRの精度は高いとは言えないので、OCRの誤認識が存在する前提でモデルを作ったり、膨大な契約書を学習したりルールを見つけることで法務ドキュメントに特化したOCRの補正を実施したりしています。

とても泥臭い領域ですが効果は出ていて、今後も継続して取り組む予定です。

がんばった部門 Vol.2「多様なファイル処理」

MNTSQのプロダクトは、アップロードされたあらゆるファイルに対して「解凍・リネーム・変換・情報抽出・PW解除」など様々な処理を行います。zipなどの圧縮ファイルを解凍する場合は、zipファイル内のフォルダ構成などもそのまま反映する形で登録しますし、既存ファイルとの差分だけを見つけて反映するような処理も行なっています。

ファイル処理の種類が多い、というのも大変ではあるのですが、それ以上に、「世の中には本当にいろんなファイルがある」という事実との戦いが大変でした。

ファイル形式だけ見てもエクセルマクロ（xlsm）、古いバージョンoffice（doc, xls, ppt）、謎の圧縮ファイル（zipx, 7z, rar）など様々ですし、それ以外にも、現場ではよく使われるパッと見は異常なファイルがたくさんあります。

# 例
・ファイル名が超長くて中身が空のテキストファイル
・Word, Excel, PDF readerで見れば普通だが、ファイル処理は異常に時間がかかるもの
・とても変わったpwロックがかかったもの

これらについて、新しい種類を見つけるたびに対処法を調査して根気強く対応を決めて実施していくのは骨の折れる仕事でした。

がんばった部門 Vol.3「厳しめのパフォーマンス要求」

法務デュー・ディリジェンス案件では、一度に数百件のファイルが含まれるzipがアップロードされたり、1案件あたり数千件のファイルが格納されたりします（しかもフォルダ構造のネストは深めです）。

アップロード処理やファイル処理では、メモリを食いつぶしてしまわないようにしなければなりませんし、リードタイムが長くなりすぎないようにしなければなりません。本番はオンプレなので、micro-serviceとして切り出せばいいというわけでもなく、データ設計や実装でカバーしています。

ファイルの情報や解析結果をリスト化するための各種GET処理では、フォルダ構造やナチュラルソートを考慮した実装になっているので、かなりレイテンシーを気にしながら実装判断をしています。

よかった部門 Vol.1「初期設計が当たった」

1st Productの開発は大急ぎで始まりましたが、プロダクト特性を考えたときに、大きく「Application / OCR / Analyze」3つのService domainに分割できるだろうという考えで、疎結合を保てるように以下を決めました。

## 初期設計の方針
1. Service Domainごとにコンテナを分けてApplicationのみがDBを持つ
2. ApplicationがAPIを提供し、OCRとAnalyzeはAPIを使って情報の取得と結果のPOSTを行う
3. Analyzeはいくつかのプロセスにいずれ分化していくだろうが、初期はかなり変動が予想されるのでtimestampを使った簡易管理程度に留める
4. Frontendはbackendと切り離して、ApplicationのAPIを使って実装する

## 技術選定
Application: Rails, Vue.js
OCR: Java
Analyze: Python

結果としてこの初期設計は当たっていて、3つのService domainは独立して効率よく開発を進めることができています。生谷、安野、堅山の3名がそれぞれ独立して開発を進めるために合意すべきことがAPIだけ というのはとてもメリットがありました。

これから、ファイル処理とAnalyzeプロセスの複雑化が起きると思われるので、そのタイミングで何か考え直すかもしれません。また、エンタープライズ事業でも共通の技術基盤を使いたいので、その観点で見直しを入れるかもしれません。

2019年秋頃に、たまたま海外の同系統の有名どころサービスをやっている方とディスカッションをする機会があったのですが、設計がとても似ており「最初から正解を引けたっぽいな」と少し安心しました。

よかった部門 Vol.2「CI高速化とテストへの投資」

MNTSQは、基本的に複利で効いてくるものについては早めから積極的に投資する方針です。このnoteでは扱いませんがドキュメント文化を根付かせるための整備にもだいぶリソースを投下しましたし、それと同様にCIの高速化はリソースを投下することを早い段階から決めていました。

我々はdockerを使っていて常にApplication/OCR/Analyzeの3コンテナを毎回initから作っていると異常に時間がかかってしまうという状況でもあったのである種必然ではあるのですが、18分ほどかかっていたCIが5分ほどになり、一時は2.5分ほどまで圧縮することができました。

開発リソースの割り当てとしては、CI高速化と処理パフォーマンスの向上にRailsチームリソースの2割程度は定常的に割り当てているかと思います。

次にテストについて。スピードアップかつ仕様がガンガン変わるスタートアップにとって自動テストをどこまで書くかは常に議論になりがちですが、基本的にはテストは必要で、「どこまでをテストスコープにすべきか」を状況に合わせてチームで共通認識を持っておくことが重要だと考えています。

プロダクトの特性上、「多様かつ大量なドキュメントがちゃんと処理できるか」という準備が大変なテストや、フォルダ階層とナチュラルソートを考慮した複雑なテストは自動化してしまった方がはるかに効率が良いし安全です。自動テストを行うべきスコープはテストコードを書き、マニュアルテストをすべきところは外部のテストベンダーに依頼してデプロイ前のQAプロセスを回しています。

おかげで開発プロセスやコードベースは割とHealthyな状態を保てているのではないかと思います。

よかった部門 Vol.3「セキュリティ・ポリシー」

リーガルテック・カンパニーとして、取り扱うデータの機密性が異常に高いことから、初期からセキュリティは超強くしようという合意がありました。

これは私の持論ですが、セキュリティ・インシデントは大体以下の3つが起きないようにすることが重要です。

1. 利便性の低さから来るルール破り
2. 不注意の発生
3. 脆弱性の考慮漏れ

githubでセキュリティー・ポリシーを策定し、上記の3つの観点から見つかった課題があればissueとして記録してポリシーのupdateという形で解決していきました。定期的に行なっているヒヤリハットレビュー会との相乗効果で、どんどんインシデントの種は潰れてきていると感じています。

悔しい部門 Vol.1「ファイルアップロードのトラブル」

MNTSQのプロダクトは、ファイルがアップロードされることから始まるので、そこでつまづいてしまうと利用が起きません。また、初体験の印象が悪いと、そのままずっと利用を敬遠されてしまいます（先生方はとても忙しいですしね）。

とある案件で特殊なファイルが含まれるzipがアップロードされた時、ファイル処理に異常な時間とメモリを消費してシステム全体の動きが緩慢になってしまったタイミングがありました。また、ある操作の仕方だとアップロードがうまくいかないという少し想定外のバグが発生したこともありました。

監視プロセスのおかげですぐに気付いて解消できたのは良かったものの、マイナスインパクトがとても大きいので、もう少しうまくやりたかったなと思っています。

悔しい部門 Vol.2「フロントエンドの技術テコ入れ」

Frontendの実装は基本的に私が行なっているのですが、とても動きやすい反面、もう少し技術的にはやれることがあったのにできなかったなぁと思っています。

Vue.js, Vuex, Vue-Router, Element-UIあたりを利用していて、
CSSはプリプロセッサーなどは使わず、各コンポーネントの中にscoped styleとしてベタ書きする形で実装しています。ガンガンデザインも変えるのであまりComponentsを細分化することはせず、使い回しをしたいところだけ必要最小限の粒度でComponent化する方針で進めていました。

そこまでは良かったのですが、Frontendでもけっこういろんなことをやっていて↓

1. 大容量ファイルをパフォーマンス高く表示するためのチューニング
2. 複雑な解析ステータスに応じたコミュニケーション分岐
3. そこそこ複雑な配列操作やオブジェクト変換（表示都合に合わせたAPI開発はしないので）

もうちょっと技術を使えば効率良い実装ができるケースが今もたくさんあるでしょうし、型がないゆえのつらさも少し感じ始めました。TypeScriptは遅かれ早かれ入れることになるという合意は初期からあったのですが、私がProductionのコードを職務として書くのは初めてで、Vue.jsをゼロから入門してすぐリリースに間に合わせなきゃいけなかった事情もあり、ひよってしまいました。反省ですね。。

足元で時間が取れていないので入れられてないですが、早めに入れていこうと思っています！

プロダクト作りの文化

このあたりは、1年間かけてきっちりプロダクトに向き合える組織文化のスタートラインに立てたかなと思います。ここから人数が増えてもこの文化が崩れることなく、むしろ今以上に文化が強化されているような状態を作っていきたいなと思っています。

1. プロダクトに関する意思決定
2. 全社員がプロダクトを触ってフィードバックを集め、githubを使う
3. CXヘビー

1. プロダクトに関する意思決定
役員の4名が良い感じに噛み合っていて、弁護士と機械学習エンジニアとデザイナーがそれぞれの専門性と事業経験を持ち寄りながら意思決定をしています。
元々コア機能の1つとして謳っていたものでも足元でバリューが出せないと判断すれば潔く捨てますし、敬遠されるほど骨の折れる機能でもプロダクトが出すべきバリューから見て本当に必要だと判断されればやりきりました。
特に難しい意思決定についてはドキュメントを使ってお互いの考えをまとめてきてディスカッションするのでログが残っている というのもGoodだと思っています。

2. 全社員がプロダクトを触ってフィードバックを集め、githubを使う
自分の専門職務に集中しすぎてプロダクトから距離が離れてしまうような状況を防ぎ、全員でプロダクトとユーザのことを考えているチームにしたいので、全社員で最新のプロダクトをロールプレイングしながら触ってフィードバックを溜めるロープレ会を隔週で実施しています。溜まったフィードバックはもちろんプロダクト作りに活かされますし、「ここは何故こうなってるの？」という質問にも答えてユーザ理解を深める時間にもなっています。

3. CXヘビー
現在は役員4名がCX（カスタマーサクセス）業務を行なっており、法務デュー・ディリジェンス案件が新しく始まるたびに、1案件につき1名担当役員がついて状況の把握とフォローを行なっています。プロフェッショナル・ファームの特性上、あまりサポートを使い倒す感覚に慣れていない方が多いので、こちらからフォローをすることで困ったときに頼ってもらえる関係値の構築を心がけています。

2020年はプロダクト開発を加速したい

ここまで2019年を振り返ってきましたが、正直2019年の後半は資本業務提携に関するアレコレや新体制に関する準備などで、なかなかプロダクトのデザインや開発に僕が使えている時間は少なかったです。

ようやく資本業務提携関連の対応も落ち着いてきて、組織として行うべき各活動のベースとなる仕組みの導入はあらかた終わってきたので、ここからさらにプロダクト開発を加速していきます。

まだ設立2年目のスタートアップなのに2つ目の事業を立ち上げるというのはチャレンジングですが、いろんな企画が持ちあがる中でうまく全体設計と優先順位をマネジメントしつつ、小さい開発で大きなバリューが出せるように進めていこうと思っています。

最後に。

MNTSQ社は常に優秀な仲間を募集しています。

リーガルテック市場、コーポレート・アイデンティティ、組織、採用についての資料を公開したので、良かったら是非見てみてください。

We're Hiring !!!