はじめに

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

ラストを飾る今回は、「LegalOn」の品質作りに焦点を当て、プロジェクト開始からリリース、リリース後の品質への取り組みを振り返ります。QAチームがどのように試行錯誤し、課題を乗り越え、品質を追求してきたのか、CTO深川が以下の3名に話を聞きました。

岡登陽平（推進力担当：プロジェクト終盤よりjoinしリリース判定）
福島茂雄（経験担当：当時QAリード/PMO）
島根義和（知見担当：当時SETリード）

QA体制の立ち上げからリリース

深川　ついにシリーズブログも最終話を迎えました！今回は「品質編」ということで、皆さんにお話を伺いたいと思います。それぞれ参画時期が違うかと思いますが、2023年3月31日のキックオフから、2024年4月15日のリリースまでの取り組みを、ざっくり教えていただけますか？

福島　振り返ってみると、当初は「本当にリリースできるのかな」と感じていました（笑）。普通にやってたら到底間に合わない。だからこそ、優先順位付けが何よりも大事だと考えていました。

2023年4月～5月はまだQAエンジニアが揃っておらず、私が中心となってQAチームの体制づくりと業務分担を進めていました。当時はMiroで整理された要件リストを見ながら「LegalOn」の全体像をどう要件に落とし込むかを、ひたすら議論していた記憶があります。

深川　要件定義の段階から、QAエンジニアが深く関わっているのは印象的ですね！

福島　はい。PMOのような立場でプロセス設計に関わっていたんですが、「スピード重視」と「品質保証」をどう両立するかは常に課題でした。ビジネス側の「要求」と、それを具体的な「要件」に落とし込む作業を明確に分けるように意識しました。また、全体で統一的なプロセスを厳格にするよりも、各チームがスムーズに動けるよう、ある程度進め方を任せる判断をしました。これはスピードを優先するためでしたね。

島根　2023年6月以降から、QAエンジニアが徐々に参画し始めましたよね。この頃から、詳細設計やテストケースの設計が加速していきました。

福島　このとき、QAチームに伝えたのは、「QAエンジニアは単なるテスターではなく、要件定義や仕様作成の段階から一緒に品質を作り上げていく役割」だということです。特に、要件定義のレビューに参加してもらって、仕様をテスト可能なレベルまで引き上げる作業に注力しました。2022年からQAチームで取り組んできた、仕様検討会や要件定義の整理方法が、ここでかなり活きて、プロジェクト全体に広がっていったのは良かったなと思ってます。

深川　ファーストプロダクトである「LegalForce」時代から積み重ねてきたQAチームの取り組みや蓄積されたノウハウが「LegalOn」開発の中で華開いたのは感慨深いものがありますね。

テスト戦略の確立と実装遅延への対応

島根　私は2023年7月から8月にかけて、テスト種別を整理し、テスト戦略の基本的なドキュメント作成を行いました。正直、最初は抽象的すぎてあまり実用的じゃなかったと反省しています……。 APIテストやE2Eテストの自動化も当初は検討していたのですが、リリースまでの期間が限られていたため、基盤構築のみに留まり、テストケースの作成までには至りませんでした。福島　デリバリーを最優先するという判断でしたね。リリースまでの期間を考えると、自動化によるレバレッジがすぐに効く段階ではなかったため、リリース後の2024年度以降に本格的に取り組むことにしたんです。

深川　「LegalForce」やセカンドプロダクト「LegalForceキャビネ」の新規開発をストップしていたという関係もあって、デリバリーは非常に重要な局面でしたね。開発の遅れでテスト開始も押してしまうこともあったと思いますが、そこでは何か工夫された点はありましたか？

福島　実装が始まってしばらくは、各チームのモジュールやフロントエンド〜バックエンド間が結合されておらず、目に見えるものがあまりなく、テストできるものがほとんどない状況もありました。一方で、スケジュールリスクや結合時のリスクを考えると、最後に初めて結合してビッグバンテストをするのではなく、少しずつでもテストをしていきたいと考えていました。そこで、QAエンジニアからは、「たとえ小さな機能でも良いので、テスト可能なものを出してほしい」と開発者に働きかけました。また、システムテストや受け入れ基準、リリース判定基準についても、この頃から検討を始めました。

それから、進捗を定量的に把握するため、要件定義の完了数、テスト設計書の作成数、テスト実行数などを見える化するメトリクスを導入しました。これは開発を促すための施策でもありました。

深川　テストデータの準備もかなり大変でしたよね。

島根　はい。テスト環境やテストデータの準備もこの時期に進めました。特に契約書の大量データ作成には、過去のプロジェクトで使っていたツールを応用したり、パートナーさんにもご協力いただいて、なんとか対応できました。

福島　11月から12月にかけてテストが本格的に始まりましたが、テストに足踏みするチームに対しては「スモークテスト」を推奨し、完璧でなくても動かせる部分からテストを開始するように促しました。

リリースに向けた最終準備とリリース後の評価

深川　岡登さんは2024年1月から参画されましたよね！当時のプロジェクトの状況を見て、率直にどう感じました？

岡登　入社前に聞いていた話では、「入社してくれる頃には既にテストフェーズに入っているはず」と聞いていたんですが、実際に来てみると「まだこれからじゃん！」といった感じで、話が違うな、と感じましたね（笑）。プロダクトもチーム構成もかなり複雑で、全体像をつかむのに時間がかかりました。

深川　嘘を言うつもりはまったくなかったんですが、進捗が遅れて結果的に嘘になっちゃいました…（笑）。とはいえ、テストも本格的に始まった時期がそれくらいで、リリースを見据えて動き出していた時期ですよね。リリースに向けてどのように準備しましたか？

岡登　「リリース判定基準」を作ってリリース時に達成すべきゴールを明確にしました。1月の時点では草案はあったのですが、まだ確定はしていない時期でした。2024年2月の初旬から末にかけて基準を完成させ、その後は担当者を割り振り、リリース直前の判定会議までその基準値を満たすための作業をひたすら続けましたね。福島　3月半ばからは、リリース判定会議を合計4回実施しました。毎週チェックポイント会議を行いながら進捗を確認し、4月15日のリリースを決めました。

深川　リリースしてから、何か想定と違った点はありましたか？

岡登　たしか第1回の記事でCPOの谷口さんも言っていたのですが、正直、リリース前は「リリース後に何か深刻な障害が起きるかも…」と覚悟していました。でも実際には想像していたよりも安定して稼働し、無事ユーザーに提供することができました。残念ながら全く障害が発生しない、ということにはできませんでしたが、障害対応のガイドラインや体制も事前に決めてあったので、発生した障害は迅速に解消することができたと思います。

福島　本当ですね。プロジェクト計画書通り、要件定義書を満たしていた点はクリアしていましたし、特に心配していた性能面も予想以上にうまく動いたと感じています。

深川　良い意味で予想が裏切られたんですね。うまくいったのはなんでだと思いますか？

福島　要因の一つは、QAエンジニアが要件定義書のレビューにかなり時間をかけたことだと思います。QAエンジニア全員が自分たちのサービスや機能を深く理解し、「このバグは絶対に出してはいけない」というポイントをしっかり押さえた上で、開発者と一緒になって品質を作りこめたのが良かったと思っています。性能面については特別なことはしていませんが、アーキテクチャの良さが功を奏したのかもしれません。

岡登　そうですね。全てのテストを完璧に行うのではなく、「プロダクトとしてどう振舞うか」に絞ってテストを組み立てたのも良かったと思います。その分、本当に必要なところに注力して、しっかりやり切れた！という実感があります。結果的に、ユーザーに価値を届けられたんじゃないかなと。

島根　QAチームだけでなく、開発に関わった全員が「品質を上げるのは自分ごと」という気持ちを持ってくれていたのが、すごく大きかったと思います。誰かに任せっきりにせず、チーム全体で取り組めたからこそ、ここまでの成果に繋がったと私も思います！

福島　個人的には、フィーチャーフラグの運用やAPIテストの網羅性なんかでは、正直ちょっと不安だったところもあったんです。でも、そこが致命的な問題にならなかったのは、やっぱりエンジニアの皆さんが本当に頑張ってくれたからだと思います。最後の最後まで、開発者とQAエンジニアが一緒になって粘り強く作りこみ、テストをやり切った。その積み重ねがいまの安定稼働に繋がっていると実感しています。

深川　他のブログでも、リリース後に大きな障害がなかった点が本当にすごいことだと、大変評価されてました。本当におつかれさまでした！

リリース後の改善と今後の品質への取り組み

深川　リリースしてからのことも聞いていきたいと思います。リリースから一年以上経ちましたが、この一年で改善された点などはありますか？

島根　自動テストの導入が進み、QAエンジニアが自らPlaywrightでコードを書くようになりました。これにより、QAチームとしてのスキルアップにもつながっていると感じますし、E2Eテストの自動化カバレッジも、当初と比べるとだいぶ上がってきました。

岡登　開発者にも変化があって、今では各チームが自分たちでテストを主体的に進めるようになってきました。トップダウンではなく、「自分たちが品質を担保する責任がある」という意識が自然に芽生えていて、現場のマインドセットとして根付いてきたのかなと。とても良い流れができているんじゃないかと思っています。

深川　素晴らしいことですね！これから「LegalOn」の品質をさらに高めていく上で、皆さんそれぞれどんな展望を持っていますか？

岡登　「LegalOn」を世界で通用するプロダクトにするために、品質の面でどう貢献していくかは大きなテーマです。技術的な側面だけでなく、ビジネス要求や海外の顧客のニーズを理解して、どのような品質が必要で、それをどのように作りこむべきかをさらに考えていく必要があります。あと、AIなどの最先端技術もうまく取り入れながら、組織としてのレバレッジを高め、人材育成にもつなげていけたらと思っています。

福島　私は、いわゆる「不具合がどれだけ少ないか」だけじゃなくて、製品がどれだけお客様に価値を届けられているか、そこまで測れるようにしていきたいです。AIを使って不具合分析をもっと効率化したり、「当たり前品質」だけじゃなく「魅力的品質」まで可視化できると理想ですよね。売上データや営業評価、商談で刺さった機能、ユーザーからのフィードバックなども分析して、「どこに価値があるのか」をしっかり把握していくような品質保証を目指したいです。

島根　今はUIテストが中心ですが、今後はロジックそのものを検証できるようにしていきたいですね。たとえば、UIを介さずに裏側の処理やロジックがちゃんと動いているかを確認するようなテストとか。あと、将来的には自然言語で記述したテストケースがそのまま自動実行できるような仕組みも視野に入れています。これによって、人の手を介さずにテストが実行できる世界が来るかもしれません。ただ、すべてを自動でやればいいという話でもないので、人の目や感覚でしか気づけない「違和感」には、引き続き人が関わり続ける必要があると感じています。

深川　ありがとうございます。では最後に、全体を振り返って、一言ずつお願いします！

福島　率直に言って、本当に勉強になりました。このプロジェクトでは、全員で知恵を持ち寄って品質保証に取り組むことができて、「品質保証はテストだけじゃない」と実感できたのが何よりうれしかったです。今後も、開発者と肩を並べて一緒に課題に向き合っていくような、そんなQAエンジニアのあり方を他のプロジェクトでも広げていきたいです。

島根　品質って、QAチームだけの話じゃないんですよね。「LegalOn」の開発に関わった全員が、本気で品質に向き合ったからこそ、良いプロダクトが作れたとあらためて思っています。

岡登　「LegalOn」はリリースされて、もう1年半経ちますが、プロダクトとしても、開発組織としても、まだまだ大きな伸びしろを感じています。生産性も、プロダクトの価値も、もっともっと高めていけるはず。これから、その成長を後押しする存在になっていきたいと思っています。

全9回にわたってお届けしてきたシリーズブログ、いかがだったでしょうか？

開発当時の取り組みや、各リード陣の意思決定の背景について、リアルにお伝えしてきました。「なるほど～」とか「あー、わかるわかる」といった、どこかで共感していただけるポイントがあったら嬉しいです。そしてこのブログが、少しでもプロダクト開発に携わる皆さまのヒントや参考になっていれば幸いです。最後まで読んでくださって、本当にありがとうございました！