CADDi x MNTSQ イベントレポート 〜レガシー産業のDXに取り組むスタートアップの開発って楽しい？〜
去る9月7日に、レガシー産業のDXに取り組むスタートアップの開発って楽しい？ が開催されました。
「モノづくり産業のポテンシャルを解放する」CADDi（製造業DX）と、
「すべての合意をフェアにする」|MNTSQ≪モンテスキュー≫（契約業務DX）との合同イベントであり、両社のエンジニアによるパネルディスカッション形式のイベントです。
75分間のイベントですが、ディスカッションのお題をやむなく1つ削るほどの盛り上がりを見せました。このレポートでは、その内容をダイジェストでお届けします。
もっと話を聞きたい部分があれば、ぜひ末尾のリンクから、各社にカジュアル面談を申し込んでください。
登壇者
両社から、エンジニアが2名ずつ登壇しました。
MNTSQのサービス
大企業の契約業務をサポートするSaaS「MNTSQ CLM ※」を開発しています。
※ Contract Lifecycle Management: 作成から失効にわたる契約の一生を自動管理し、契約プロセスの高速化とリスク把握をすること
CADDiのサービス
以下、ディスカッションの一部をご紹介します。
「ToBビジネスの難しさ・楽しさは？」
CADDi高藤さんの「Aが課題だとお客様が言っていたとしても、本当に本質的な課題がAなのかどうかは疑問を持たないと、意味のないものを作ってしまうことが起こり得る」という話は印象的でした。
一方MNTSQでは、西村が話したように、エンタープライズ法務という誰も挑戦していなかった領域を開拓していっているという関係上、仮説を立てて1ヶ月かけて実装した機能をドラスティックに廃止したりすることもあるようなフェーズです。何が問題か、どんなプロダクトを作るのかといった根底部分から議論が日々行われています。
CADDi猿田さんが最後にまとめてくださったのが「ToBビジネスは、一般に想像されるよりもユーザーのことがよく見えるので、実際にプロダクトを使って効率化・改善していく様子を観察しやすいのが、楽しさの一端である」ということでした。
「ドメイン知識に対する共通認識をどうやってもつの？」
両社とも、社内オンボーディングを非常に手厚く行っているということが分かりました。
CADDi猿田さんによると、「製造業のサプライチェーンのオペレーション、CADDiが何をやろうとしているか、図面の書き方・見積もりのオペレーションを学べる教材を用意したりしている。バックグラウンドが製造業の人も社内に何人かいるため、Slackで聞けば答えてくれる。他にも、エンジニアが会計や、世の中の基幹システムの勉強会をしたりしている」ということでした。
MNTSQ稲村からは、「ドメインが深くなると、通り一遍の開発では限界がある。企業法務部で実務経験のあるメンバーも社内にいて、自分の専門外の領域に関する理解を重視している」という発言がありました。
ドッグフーディングは両社ともしていて、CADDiさんでは顧客からの要望を優先するために、社内から出てくる要望を後回しにしているという話が印象的でした。自分達で強い感情を持って使っている様子が頭に浮かびました。
「エンプラ攻略どうやっている？」
個社開発ではなく、ほかの顧客に横展開できる機能を開発する重要性に加えて、無形のサービスを提供することの重要性が語られました。
MNTSQ稲村からは、製品の機能としてはなるべく共通の規格化された自分たちのベストプラクティスを築くことに軸足をおきつつ、プロフェッショナルサービス（契約を分析して得られるインサイトを示したり、導入支援を行ったりするなどの個社向けのコンサルティング）を提供して、機能とバランスをとってお客様に満足いただけるようにしている、ということをお話ししました。
CADDi猿田さんからは、そうした無形のサービスに関連して、顧客オンボーティングの重要性について、最初のログインで躓いているとか古いPCを使っていることがわかったので純粋な機能以外での対応が重要だったケースについてお話がありました。
また、SaaSの導入に関する意思決定プロセスに時間がかかることがあるので、価値の説明や売上拡大・コスト削減についてパートナーシップをもって密に提案・交渉することがあるとのことでした。
関連してコンサルティング費用についてご質問がありましたがこの点は対照的で、MNTSQは現時点ではプロフェッショナルサービスの費用は取らず、各製品単位でのプライシングを設計している一方、CADDiは明確にプライシングしていることはなく、月額利用料に含めたり図面料に応じた従量課金という形をとっているということでした。
「技術スタックについて知りたい！機械学習を使っているの？」
まず技術スタックについては、CADDiは言語ではTypeScript/Python/Rust、またWebアプリケーションなのでGraphQL、RestfulAPI、gRPCといったプロダクトに合ったプロトコルで開発をしているとのことです。
ドメインという言葉には敏感となっていて、どの言語を使っていてもビジネスのルールや難しさについて価値を発揮できる設計や、いわゆるDDDを明確に表現することに力を入れているということでした。
一方MNTSQは、開発のスピードが出せること、比較的枯れていることを重視して、言語はRuby on Rails/Python、データベースはSQL、検索はElasticSearch、コンテナはDockerを利用しています。
MNTSQでは自然言語処理で契約書を解析してユーザーのアクションにつなげることをコアにしているため、立ち上げ期からプロダクトに組み込んでいましたが、現在はサービスに価値をもたらすためのモジュールとして位置づけられています。
基盤的なチーミングからフィーチャーベース・サービスベースでのかかわり方に推移していっています。
CADDiは機械学習については、図面の情報解析に開発投資を続けており、サプライチェーンが長いことで図面から自動で読み取るべき情報が非常に多いことからチャレンジしているということでした。
昨年11月にAI Labを立ち上げて類似図面検索やOCRを登載しているほか、継続的に開発を行えるようMLopsを整備しているということです。
技術的な切り口で語りたいことがたくさんあるからか、ここで参加者間のディスカッションが自然発生的に始まり、議論が盛り上がりを見せました。
MNTSQ稲村「ベクトル検索エンジンを入れているのですか？」
CADDi猿田さん「OpenSearchを利用して、図面に書かれた表や材料などを検索したいと思っています」
CADDi猿田さん「MNTSQで契約書の類似の判定をするときどうするのか興味があります」
稲村「ドキュメントの全体、個別要素、タイトルなどの本質情報が似ている、という様々な観点で検索・サジェストの体験に分けて使い分けています」
CADDi高藤さん「解析という観点で、インプットするファイルの件数などで処理に時間がかかることやwebの1リクエストで終わらないものもあるのでqueueに積むなど工夫をしているが、MNTSQではどうしているのですか？」
西村「今のMNTSQは大量の契約書を随時捌くことには向いていないので、根本的に変えることを検討しています。現段階では検索が主眼になっていて初期導入した後はパイプラインが頻繁に走ることはないですが、今後は随時契約書が取り込まれる未来があり、滞りなく解析が走る仕組みを構築するところです」
稲村「検索についてはインデクシングの即時反映といった改善が最近のポイントで、そのためにDBでその機能をもつ場合がありますね」
CADDi猿田さん「うちの話かなというか、インデクシングの即時反映って聞いたような話だなという感じです。当社でもSalesが頑張って売ってきた結果、過去の図面を数十万枚もらってきてエンジニアが『うっ、ちょっと待って』となったりします」
CADDi高藤さん「正直似た課題感を抱えていますね」
「社内でアノテーション部隊がいるの？」
この観点では、アノテーションを内製するのか社外に出すのか会社ごとに異なるとしても、アノテーションにあたってのドメイン知識や、限られたリソースでの開発の優先順位付けとして事業インパクトを考慮する、というのが共通した要素だということが言えそうです。
稲村から、アノテーション部隊を自社で抱えていることがMNTSQの強みの一つだとして、「弁護士・企業法務経験者・パラリーガルなどのリーガルバックグラウンドを持つ人間が業務知識に基づいてアノテーションできること、MLエンジニアも用語の定義について理解しながらモデルやロジックを調整したりしていること、アノテーションの難易度に応じてROIについて吟味しながら開発の判断を行っていること」をご回答しました。
CADDi猿田さんは「受発注サービスをやっていて見積もりのオペレーションがあったためデータ入力部隊はBPOでまかないつつドメイン知識をインストールしてもらっている。機械学習の優先順位については悩みがある」ということでした。
「図面に入れる情報は多種多様にあるため、たくさん読み取れるからこそオペレーションに活かせるところがある一方、データの枚数も欲しいのが悩みどころで、一番インパクトのある部分から順にやっているところだ」という補足もありました。
「社外の人は知らないけど、社内でよく使われるドメインの言葉ってありますか？」
この質問に対しては、CADDi猿田さん・高藤さんが「めちゃくちゃある」と声をそろえていたのがとても印象に残りました。
「DDDでは『ユビキタス言語』と呼ばれる言葉の定義はあるものの、社内で本当に選んで良いか考えている」とのことで、「当時は知らなかったが一般的な用語が実はあったりしてリファクタリングをしないといけないこともあったりする。プロダクトを技術的に直す面だけでなく、DDDではビジネスも巻き込んで議論する部分がある」ということを語っていらっしゃいました。
一方MNTSQは、お客様が真剣にFBをくれるという点について稲村が実感を語っていました。
「この（たとえば契約書類型の）定義は適切ではないのではないか？」という実務に則した的確なFBが返ってくるため、受注が進むにつれてお客さんに製品を育ててもらっている部分も大きいということです。
「SaaS開発体制について（スクラム、開発サイクル、テスト）」
CADDiでは、会社全体として基本的にスクラム開発で開発を行っているためDRAWERでも同様で、サイクルは1週間のスプリントではあるものの、QAのプロセスを挟んだりして2週間に1回に遅れることもある、ということでした。
スクラムは一般には1チーム7～8人程度と言われているところ、CADDiでは人数が増えてきて10人以上のエンジニアがいるチームもあり、LeSS（Large-Scale Scrum。1つのバックログで、複数のチームがいるのが特徴）という手法で進めているとのことです。
MNTSQは、明確にスクラムと定義してはいないもののそれに近い体制で、2週間に一度のデプロイサイクルとなっています。これは、ユーザーごとに環境があることや、顧客への影響やメンバー内の負荷を考えて隔週土日にデプロイすることになった、という経緯からです。
人数的にはPdMを含めて十数名で、テストについては、ユニットテストレベルではCIを使って自動で回しています（RailsなのでRspecを利用）。
E2Eの自動テストはまだできておらず、今後の課題というところです。
「MNTSQの開発で面白いところとしては非常にオープンに議論が行われていることで、例えば権限管理の開発ではSalesやCSも巻き込んで進めた」という事例が西村から紹介されました。
「評価指標はどうしているの？」
追加で上記のご質問があったため、MNTSQ稲村からは、「タスクに応じて、Precision/Recallの精度を見たりランキング指標を使ったりする」という回答をしました。
CADDi猿田さんは、「図面解析ではテーブルデータ（表に書かれた材質など）が正しく取れているかをテストしているほか、類似図面検索の精度テストでは目検がまだある」ということでした。
これについて稲村から、「メトリクスで測る場合と実際のデータを見てエラー分析をする場合の2つのプロセスがあり、同じ -1点 でも拒否感の強いものと『これは難しいから妥協しても良いだろう』というものがあるので、数字には出ない誤りの差を意識している」という実感が語られました。
猿田さんからは「究極はお客さんに聞かないとわからない。こうなるとカスタマーサクセス的な話になってしまいますね」というコメントがなされました。
終わりに
事業ドメインは異なるものの、似たような課題感や悩みを抱える同士であることがわかったり、社内オンボーディングや開発体制について課題を解決するために積極的に取り組んでいて共感する部分も多かったからかあっという間に時間がたってしまい、ここで終了時刻となってしまいました。
「あと30分は欲しかったね」という感想を残してパネルディスカッションは終了となりました。
全体として非常に活発な議論が交わされたイベントとなったと思います。
CADDiの猿田さん、高藤さん、どうもありがとうございました。
CADDi、MNTSQとも積極採用中です！ ご興味もたれた方はぜひ採用ページをご覧いただき、カジュアル面談をお申込みいただけると嬉しいです！