はじめに

LegalOn Technologiesが提供する「LegalOn: World Leading Legal AI」は、契約書ドラフト・レビューや案件の管理、法務相談まで、法務業務をワンストップで支援する革新的なサービスです。リリースから1年半、企画開始から約2年半が経った今、プロジェクト立ち上げの背景、開発の進め方、これまでの振り返りや今後の展望、さらには技術面での学びまでを、全9回にわたるブログシリーズとしてお届けしていきます。

前回の記事では、2022年末に始まった製品戦略プロジェクトの背景と「LegalOn」誕生の経緯を、CEOの角田とCPOの谷口へのインタビューを通じて紹介しました。

第2回となる本記事では、CTOの深川、CPOの谷口、そしてリードプロダクトデザイナーの鈴木に、立ち上げ期からリリースまでを支えた意思決定や、たった一年間でリリースまで導いたプロジェクトの進め方について話を聞きました。

深川真一郎：執行役員・CTO
谷口昌仁：執行役員・CPO
鈴木智絵：LegalOn リードプロダクトデザイナー

プロジェクトが本格始動した日

— まずは、新しいプロダクトを作るという大きな意思決定がされるまでの経緯を教えてください。

谷口　2022年の12月に突然、会社の課題を議論する会議に呼ばれたんですよ。私が入社してから3か月目のことでした（笑）。この中の一つだった製品戦略プロジェクトでは、プロジェクトメンバー全員が「今後、プロダクトをどうしていくべきか」についてそれぞれ意見を発表。そこで出たアイディアを私が整理していく中で「LegalOn」構想が生まれました。ちょうど生成AI登場というタイミングだったこともあり、今しかないということで本格的に進めることになりました。

▶　第1回「LegalOn」誕生の裏側：なぜ「LegalOn」開発は始まったのか - LegalOn Technologies Engineering Blog

深川　2023年2月の取締役会での企画承認が、最初の大きなマイルストーンだったと思います。

谷口　ですね。2月に取締役会があって、そこで承認を取って開発を進めないと間に合わない！というかなりタイトな状況でした。それまでに企画の骨子や全体の開発計画、予算まで一通りまとめる必要がありました。ひとつずつ順番にやっていたらとても間に合わないので、初期プロジェクトチームで分担しながら、企画と計画を詰めていきました。

さらに、取締役会前には、取締役一人ひとりに個別にプレゼンを行い、課題や新しいコンセプトを丁寧に伝えて共感を得る、というプロセスを何度も重ねました。既存の主力プロダクトの開発を全面停止して、新しいプロダクトをゼロから作り直すという大きな意思決定だったので、事前に個別に説明しておかないと、絶対に紛糾するだろうなと考えたんです。

もしそこで共感が得られず、取締役会での承認が遅れていたら、2024年4月リリースは到底間に合わなかったと思います。でも、そうした下準備のおかげで、2月15日の取締役会では無事に新コンセプトが正式に承認されました。そして、取締役会の準備と並行して進めていた、プロダクト構想をまとめた巨大なマインドマップも、この時点で完成しました。（参考：https://tech.legalforce.co.jp/entry/legalon-behindthescenes-1）

深川　取締役会自体は、谷口さんの懇切丁寧な取締役行脚のおかげですんなり通りましたね。

そのあとは、当時の開発チームのメンバーに「既存プロダクトの追加開発は止めます。既存プロダクトで契約書業務の支援に特化していた『LegalForce』『LegalForceキャビネ』のコンセプトをマージしてさらにスコープを法務全域に広げて、かつ、AIを軸にした新プロダクトを1年後にリリースします。」と伝える必要がありました。それを伝えたのは、2022年度最終営業日の前日、2023年3月30日だったと思います。

谷口　あのキックオフの準備は本当に大変でした。全開発メンバーに「今の開発をストップしても、これならいける」と思ってもらえるようにしなければならなかったので、プレッシャーも大きかったです。

鈴木　あれは伝説のキックオフでしたねー。

正直、本当に1年でできるのかという不安と、新しいプロダクトを作れるという期待が入り混じった気持ちでしたが、あの日の熱気の中で「チーム全員で、とにかく走り切るんだ」と、覚悟が決まった日だと覚えています。

あの後、PdMによる具体的な企画やエンジニアによる技術検証などが一斉に動き出したんですが、PdMから出てくる企画案はまさに夢と希望が詰まった膨大な量でした（笑）。
プロダクトがあまりにも大きかったため、正直なところ「自分たちは一体何を作ろうとしているんだろう？」という全体像が誰もつかみきれていない、少しフワフワした状態だったんです。

このままだと企画の議論も深まらないし、エンジニアも具体的な設計に入れない。そこで私の大きな役割になったのが、文字情報ではなく「目で見てわかる」プロダクトの全体像を描くことでした。

各PdMが作ってくれた無数のワイヤーフレームをベースにして、重複する機能を整理し、全画面のワイヤーフレームと製品の骨格になるグローバルメニューの叩きを作成しました。細かい矛盾は承知の上で、まず議論の「叩き台」として速度を優先させました。この「全体像の可視化」によって、チーム全体が具体的な認識を持つことができ、プロジェクトが「ちゃんと」動き始めたんじゃないかなと思っています。

深川　エンジニアチームは最初、アーキテクト・テックリード陣を中心にアーキテクチャをどうするかの検討と開発環境を整えることから始めました。既存プロダクトの開発を止めるとはいってもすでにお客様にお伝えしているロードマップもあり、明日からすぐにストップ、とはいかなかったので。そのタイムラグを利用して、エンジニアが本格的に参画したらすぐにビジネスロジックに集中できるように環境を作るぞ、と少数精鋭のメンバーで基礎部分の設計とPoCを行っていった感じです。

このときの技術選定の振り返りはまた別の回でお届けする予定ですのでお楽しみに！

鈴木　それでいうとデザインチームの初手も、デザインシステム「Aegis（イージス）」の刷新でしたね。2月の、新しいプロダクトのコンセプトが決まるか決まらないかくらいの段階で「これはUIも全面的に作り直す必要があるなぁ」と考え、先んじて刷新作業に着手しました。
エンジニアチームがアーキテクチャの検討を進めてくれていたように、デザインチームも来るべき本格開発に備えて、土台づくりを先行して進めていた感じですね。このAegisの開発はそれ自体が大きな挑戦で、詳細は別の記事で紹介しているので、ぜひご覧ください。

note.com

リリースまでのタイムライン

— プロジェクトをどのように進めたか教えてください。

深川　それまで当社は各プロダクトや機能ごとにチームを分割し、スクラムを中心としたアジャイルな開発スタイルを行っていました。しかし、このプロジェクトはいわゆるウォーターフォールの開発プロセスで進めました。新プロダクトの開発ではありますが、「LegalForce」「LegalForceキャビネ」でこれまでやってきたものの蓄積がありましたし、マーケットインの不確実性は相対的に大きくないと判断したためです。それよりも今回不確実性が大きいと思ったのは、以下の2点ですね。

複数のモジュールをワンプラットフォームで使うための仕様・UX・データ設計のブレ
100名を超える大規模チームでの認識のブレ

このようなプロジェクトの性質を考慮すると、いままで慣れた開発スタイルを捨ててでもウォーターフォールで指揮系統を揃えてブレがないようにした方がプロジェクトの成功確率が高まるだろうと判断しました。

具体的なプロジェクトのタイムラインはこんな感じだったと思います。

※コントラクトマネジメント：締結後の契約書管理などをサポートするモジュールであり、既存サービス「LegalForceキャビネ」でのメインコンセプト。

スコープ一次フィルタリング合宿

— やりたいことが山ほどあった中で、初期リリースに何を入れるかはどうやって決めたんですか？

深川　4月5月でやりたいことを洗い出してPRDにまとめたあと、6月に第一次スコープ合宿を実施して、一日かけてリリース対象機能を精査しました。ちなみにこのあと第二次と第三次もあります。

鈴木　まず前提として、「LegalOn」は、当時既に多くの方に使っていただいていた「LegalForce」「LegalForceキャビネ」の上位互換となる製品として位置付けられていました。そこで、

既存プロダクトに存在する落とせない基礎機能
既存プロダクトに存在する欠けると不便な機能
既存プロダクトには存在しない新しいコンセプトを示す機能

の3つに機能を分類しました。

で、予想通りといえば予想通りなのですが、「落とせない基礎機能」だけで工数の多くを消化してしまう見通しになったんです。これだと新プロダクトとしてのコンセプトを体現する機能が、ファーストスコープにほとんど入れられず、「これで差別化ができるのか？これならやらなくてもいいのでは？」という話がでてきました。

谷口　そこで思い切って、「既存プロダクトに存在する欠けると不便な機能」をスコープ外にする判断をしました。その分、新しいコンセプトを体現する機能の優先度を上げたんです。とにかく初期リリースで新しい体験を見せることに集中した判断でしたね。

深川　当時は PRD が約200本もあったんですよ。でも、谷口さんのいう判断軸で合宿後にかなり思い切って絞り込みました。そのおかげで見積もりがある程度現実的になって、あとの工程がスムーズに進みました。それでも大変でしたけど（笑）。

谷口　この捨てる覚悟がなかったら、1年でのリリースなんて到底無理だったと思います。

“動くもの”が生んだ推進力

— ウォータフォール開発だったけど、隔週でデモ動画を社内に公開していたと聞きました。

深川　前述の通り全体としてはウォーターフォールで進めましたが、開発中期では、定められた設計やスケジュール通りに実装することよりも、実際に触れて進捗とプロダクトの状態を確認できることを優先して開発を進めていました。プロジェクト終盤に初めて結合してビッグバンテストをすると不具合が大量に出るかもしれないというリスクや自分達がやっていることによる進捗を感じづらくてモチベーションが保てないのではないかというリスクがあったためです。

これらのリスクをなるべく早めに解消するためには、実際に繋ぎ込んで、動かして、触ることが重要だと考えました。実際これは効果的で、ほんの小さな機能でしたが実際に動くものができたときは現場メンバーとハイタッチして喜びました。形になることの効果を改めて実感した瞬間でした。

谷口　最初にデモ動画を公開したのは、2023年10月の全社定例のときでした。実際に動いているものを見てもらうことで、開発チーム以外のメンバーにも手応えや期待感を持ってもらいたかったんです。それから2週間ごとに新しい動画を出して、全社に進捗を共有していました。

深川　当時の開発現場は、本当に2024年4月にリリースできるのか？という不安が常にあったので、実際に動いている画面を見せられたのは、想像以上に効果的でしたね。

鈴木　本当にそうですね。デザイナーの立場からしても、「動くもの」が早く出てきたのはすごく助かりました。私たちがFigma上でどれだけ精密にデザインを作ったりプロトタイプを作っても、実際に実装されたものを触った時の「手触り感」はどうしても差が出てしまうんです。自分で触って初めて「ここはもう少しこう動いたほうがいいな」といった、デザインデータ上では気付けないことがたくさん見えてくる。早い段階からそのフィードバックループを回せたのはよかったです。

リリースを支えた品質基準

— リリースに至るまで、品質面ではどのような工程を踏んだのでしょうか？

谷口　2023年の10月頃、コントラクトマネジメントモジュールの中の権限管理とかドキュメント管理機能が想像以上に複雑で、このまま品質を落とさずにリリース期日に間に合わせるには、より多くの開発リソースを充てる必要がありました。そこで、「『既存プロダクトには存在しない新しいコンセプトを示す機能』の開発を一旦諦めて、コントラクトマネジメントモジュールの開発を優先しよう」という意見が多く出てきました。

でも、それをやってしまうと、新プロダクトは既存プロダクトのデグレード品でしかなくなってしまう。当初掲げていた「初期リリースで新体験を届けられるか」という判断軸をぶらさないために、既存プロダクトの「LegalForceキャビネ」に相当するコントラクトマネジメントモジュールをファーストスコープから落とす、という決断をしたんです。

深川　泣く泣く諦めましたね…。

鈴木　品質面でいうと、デザイナーチームでは大きく3段階に分けてユーザー体験の検証を行いました。

まず春頃、プロダクトのコンセプトが固まったタイミングで、メインの動線だけをFigmaのプロトタイプにして社内外の人に触ってもらい、コンセプトが伝わるか、体験として違和感がないかを検証。

次に秋頃、機能仕様がほぼ固まり、デザインもFigma上に揃ったタイミングで、今度はデザイナー全員で、プロジェクトの初期に定めた業務フローをベースにして、ユーザーが道に迷って「行き止まり」にならないかをFigma上でチェックしました。幸い大きな問題は見つかりませんでしたが、分かりにくい部分など細かい改善点をたくさん洗い出せたのが良かったです。

そして最後はリリース直前です。社内の法務メンバーに実際に動くプロダクトを触ってもらい、ユーザビリティテストを実施しました。ここで見つかった課題は、たとえバグではなくても障害レベルを付けて管理し、特にユーザーの操作を止めてしまいそうなものは、なんとかリリース前に修正してもらえるようお願いしました。

深川　当社の開発組織では「障害レベル判定基準表」というものを作っていて、障害レベルSからDまで、機能の重要度や影響範囲、影響の深刻度に応じて定義付けしています。
レベルAは例えば主要機能の中のバグで、大半の顧客に影響があるもの。レベルDはあまり使われない機能の中のバグで、顧客影響がほとんどないもの。のような感じです。余談ですが、レベルSは利用した場合に利用できないよりも深刻な影響が発生するものというものです。悪用可能な脆弱性とかですね。

で、もともと設定されていた基準はリリースまでにレベルB以上を修正すれば良いという基準でした。でも、改めてユーザー体験を考えると、「本当にB以上の修正でいいのか？UXが悪くならないか？」という議論になって、レベルCのバグもできる限り修正することにしました。

谷口　リリース判定会議では、特に品質を重視していたので、障害レベルC以下の残件数を確認していたんです。リリース判定は3月からスタートして、4月上旬までに合計4回実施。毎週状況を確認し、最終的にはすべての品質基準をクリアして、4月の1週目に晴れてリリースが決定！

鈴木　そして2024年4月15日、予定通りに正式リリース！正式リリース直前の金曜日の夜かな、記念すべきお客様の第一号テナント発行の瞬間は、オフィスのフリースペースに所属部署関係なく会社のいろんな人が集まって、みんなで谷口さんのクリックを見守りました。リリース判定会議に出ていたメンバーで「せっかくだから用意しようよ」と盛り上がって準備した小さいくす玉を割って、大きいクラッカーも鳴らして、みんなでお祝いしました。

リリース後も、1日1リリースのペースで継続的に機能開発を進めているのはすごいスピード感ですよね。あと、ファーストスコープから落としたコントラクトマネジメントも2024年8月1日に無事リリースできて本当に良かった。

プロジェクトを振り返って

— 今振り返って、「ここをもっとこうしておけば良かった」という点はありますか？

谷口　コントラクトマネジメントのドキュメント管理のところは、もう少し早めに詰めていれば、ファーストスコープに入れられたかもしれないですね…。まあ、振り返ってもこうすれば良かったという完璧な答えがあるわけじゃないんですけどね。

深川　コントラクトマネジメントをスコープから外した判断、僕も正直後悔してるんですよね。やりようによっては何とか間に合わせられたかもしれないなって。

鈴木　デザイン面では、仕様の理解が十分でないまま進めてしまった部分があったなと思っていて。あらゆるユースケースに備えたとても複雑な仕様が多かったのですが、なにせ1年でのリリースという圧倒的なスピードが求められていましたから。その速度を優先するあまり、初めからもっと分かりやすく作れたかもしれない、というのは反省としてありますね。

— キックオフ当日の自分たちに戻れるとしたら、チームに何を伝えたいですか？

谷口　当時は、AIエージェントという言葉自体、まだあまり知られていなかったんですが、私はいずれその時代が必ず来ると思っていました。今でこそ、ユーザーがAIとチャットでやり取りしながらタスクを進めるのが一般的になりましたが、私たちは最初から、ユーザーの指示を待たずに自律的に動く「アンビエントエージェント」の機能を盛り込んでいたんです。
もしあの時に戻れるなら、こういう未来が来るんだという将来像を、もっと魅力的に開発メンバーに語って、UI/UX も大胆に振り切った提案をしていたと思いますね。

鈴木　2023年3月末のキックオフの時点で、割と現実的な、1年後の目標みたいなイメージムービーしか作ってなかったんですよね。もっといろんなものが自動化されたらどうなるかみたいな、かなり先の未来を想像させるようなプロトタイプ・ムービーを用意して、みんなにもっともっと夢を持たせられたら良かったなぁと思ってます。

深川　僕は戻ってもあまり変わらないかな。当時から言ってた「1年間あれば作れる。リリースできる。」って伝えます。でも口ではそうは言ってたけど確信を持ったのは確か作るものがある程度見えてきた4月末か5月くらいだったと思うので、より自信を持って言えると思います（笑）。