こんにちは。GVA TECH株式会社の法務手続きクラウド開発チームのhyozziと申します。
法務手続きクラウド開発チームは、一般人も法務手続きを自分でできるように支援するサービスを提供しています。（GVA 法人登記、GVA 登記簿取得、GVA 商標登録 等）
現在「GVA 法人登記」は利用社数30,000社を突破しました。しかし、その裏側では、既存のコードベースを完全に作り直す大規模なリプレイスプロジェクトがありました。
プロジェクトの目的は、従来の構造では対応が難しかった「複数種類の登記を組み合わせて同時申請する機能」の実現です。
この複雑な問題を解くために、私たちは最も重要なことにフォーカスを当て直しました。それは、常に隣にいる司法書士というドメイン専門家の知識をシステムの核に据え、フレームワークに依存しない堅牢なコアロジックを構築することでした。
本日は、この大規模改修で私たちが特に重要視した、以下の3つの成功原則についてお話しします。
- ドメイン専門家と二人三脚で開発する意味
- コアビジネスロジックをフレームワークから分離した理由
- テストコードベースで実現した、ビジネスロジックのコード安全性
採用技術 (Tech Stack)
ちなみに、チームで採用している技術は以下です。
- Infra：AWS EKS 等
- BE：CakePHP, Laravel, Ruby on Rails, AWS Lambda
- FE：Vuejs, Nextjs
- DB：Mysql, Postgresql, DynamoDB, AWS S3
- CICD：Github Actions
- Observability：Loki, Grafarana, Mackerel
「GVA 法人登記」とは
「GVA 法人登記」は、変更登記申請が必要な方が司法書士に依頼せず、ご自身で申請できるようにサポートするサービスです。
大規模改修を経た現在、対応する会社の種類も「株式会社」、「有限会社」、「合同会社」、「一般社団法人」まで増えています。
対応可能な登記の種類も数十件に及びます。主な種類は以下の通りです。
- 本店移転 (管轄内・管轄外)
- 役員の氏名・住所変更
- 募集株式の発行 (増資)
- 役員変更 (新任・辞任・重任・退任・死亡：取締役、代表取締役、監査役)
- 剰余金等の資本組入れ (増資)
- 目的変更
- 株式分割
- 支店の設置・移転及び廃止
- 商号変更
- ストックオプション
なぜ「GVA 法人登記」の大規模改修が必要になったのか
「GVA 法人登記」は2019年1月に初リリースされました。私が同年6月に入社した当時は、まだ対応する会社の種類は株式会社のみ、登記の種類も本店移転、募集株式の発行だけで、種類を徐々に増やしているフェーズでした。
その後、商号変更、目的変更、役員変更など一つずつ種類が追加されましたが、複数の種類を同時に申請する機能は、既存の構造では対応できないという問題に直面しました。
そこで、ユーザーの利便性を高め、現実世界の司法書士の業務の流れにより近づけるため、様々な種類を組み合わせて同時に申請できる機能を提供するためのプロジェクトが始まりました。
既存のメインロジックを完全に新しく作成しなければならない大規模な改修であり、他社も提供しない機能だったため、市場での優位性を確立するためにも絶対に成功させなければならないプロジェクトでした。
ドメイン専門家と一緒に開発する
設計段階から始める「共通言語」の確立
GVA TECHには、常にドメインの専門家である司法書士が近くにいます。私たちの開発チームも、司法書士の方と二人三脚で開発を進めています。（ドメイン専門家が常にそばにいる環境に、私はいつも感謝しています）
私はコードベースに司法書士の考え方を最大限に盛り込みたいと考えました。
そのため、要件をそのまま受け入れるのではなく、設計の段階から以下を司法書士の方に継続的に確認しました。
- なぜこのような仕様にならなければならないのか？
- この用語は、他の状況でも使用されるのか、将来的に異なる解釈の余地があるのか？
- 新しい登記種類が追加された場合、どの部分が変更されるのか？
- パターン化できる共通部分があるかどうか？
用語はコードの意図となります。この意図が、ドメイン専門家が当然と思っていた意図と異なる場合、深刻な問題が発生する可能性があります。
例えば：「就任」という用語のドメインの深さ
（登記知識がない開発者だと仮定した極端な例です）
「取締役が代表取締役に就任」する機能を実装する場合、開発者は「就任」をこの一つのケースだけに限定して理解し、次に進むかもしれません。
しかし、実際の役員変更登記における「就任」には、上記のケース以外にも以下のような多様なパターンがあります。
- 「取締役以外」が「代表取締役」に「就任」
- 「取締役以外」が「取締役」に「就任」
- 「監査役以外」が「監査役」に「就任」
このように「就任」は、誰が就任するかによって異なる解釈と動作が必要になります。
もし、最初のケースだけを想定して実装していた場合、後から「取締役以外」の人が就任する機能を追加する際に、柔軟に対応するのが難しくなるでしょう。（運良く簡単に済めば良いですが 笑）
私たちは、要件をそのまま受け入れるのではなく、その根底にある意味やドメイン知識を理解することに意識を集中しました。
ドメイン専門家の思考に合わせたシステム構造化
上記のような対話を重ね、司法書士の方の思考プロセスに類似したシステムになるようにドメインを分離して設計しました。
開発者が任意にドメインを統合したり分離したりしないよう、主要ドメインを先に設定し、詳細を詰めていくアプローチを取りました。
司法書士の持つ知識と実務観点を開発者が完全に理解するのは非常に困難です。しかし、それをシステムでどう具体化させるか、今後拡張性のあるシステムを作るためにどう仕様書に落とし込むか、お互いに相談して決める過程は非常に楽しかったです。
専門用語と開発用語の統一化 (ユビキタス言語の確立)
仕様が固まった後、私は最初に 用語集（Glossary） を作成しました。
これは、司法書士が使用する用語をそのままシステムに組み込むため、そして一緒に開発するメンバーの用語が混ざり合わないようにするためです。
一つの仕様書を見ていても、開発者ごとに異なる英語表現を使う可能性は十分にあります。もし、同じ用語がコードベースのあちこちで違う英語表現で実装されていたらどうでしょうか？
リファクタリングも難しくなり、機能の追加や修正も困難になるでしょう。
そこで、仕様書に登場するすべての用語をcamel、snake、pascal、kebabケースなどで整理し、候補群を決めてチーム内で議論しました。誤解が生じたり、多義的な表現がある用語は、司法書士の方に確認を依頼しました。
その結果、誰もが一つの表現でコードを作成できるようになりました。
（司法書士の方から教えていただいた会社法の英訳がとても役に立ちました）
コアのドメインロジックを「フレームワーク」から分離する
設計する際に最も重要視したことの一つは、コアのビジネスロジックをフレームワークに依存しないように分離することでした。
フレームワークは変化し、陳腐化します。一方、コアとなるビジネスロジックは、法務というドメインの根幹に関わるため、そう簡単には変わらず、高い安定性が求められます。
既存のコードはフレームワークと強く結びついていたため、フレームワークを深く知らないと理解できない抽象化されたコードがあったり、フレームワークの仕様変更が直接的な影響を及ぼしたりしていました。
そこで、以下の3点を主な視点として方向性を設定しました。
- フレームワークを問わず、堅牢なコードベース
- 言語仕様と基本設計の原則さえ理解すれば誰でもメンテナンス可能なコードベース
- フレームワークを変更しても、ドメインロジックはそのままマイグレーション可能
この前提に基づき、ドメインロジックは独自のサービスレイヤーで分離し、フレームワークの仕様はドメインロジックの外側で動作するように設計しました。
テストコードを核に据え、ビジネスロジックの安定性を確保する
この大規模改修を進めるにあたり、チームで重点的に議論したテーマの一つが、テストケースを先行して作成するアプローチでした。
テストケースを先行させる理由として、以下のようなメリットがあると考え、チームで共有しました。
- 作成するコードが正常に動作するかを随時確認しながら進めることができる。
- コードベースが絶えず変わり続ける中でも、入力と出力が明確であれば、リファクタリングを同時に継続することができる。
- 実装後にテストで見つかるバグの修正期間を大幅に短縮できる。
当時はTDD（テスト駆動開発）のサイクル（赤→緑→リファクター）が、プロジェクトの進行とともにチームに作成コードへの自信を植え付けるという考えが強くありました。
現在ではTDDを絶対視しているわけではありませんが（テストの重要性には強く同意します）、当時は社内で開催されたTDDワークショップに参加するなど、テストコードの良い導入方法について積極的に工夫をしていました。
そこで、システムを大規模に改修するこのタイミングで、テストケースが明確な部分に TDDの考え方を試験的に導入してみようという方針になりました。
私たちは、司法書士の方との連携により、テストケースの作成を進めました。ユーザーが入力できる値とそれによって生成されるべき値がシートで作成され、私たちはそれをテストコードとして実装しました。
その結果、現在、メインロジックの コードカバレッジは 95% を超えています。1,800項目を超えるテストコードが、この高いカバレッジをもって、ビジネスロジックの揺るぎない品質を保証しています。
高いカバレッジに支えられ、テストコードを回しながら開発を進めることができ、リファクタリングも臆することなく果敢に進めることができるようになりました。
開発とリファクタリングを並行する
開発が進む中でも、コードベースは改善され続けました。実装しながら、オブジェクトをもっとうまく管理する方法、レイヤーを分ける方法、責任を分離したりデータを渡す方法などをチームメンバーと議論し、実装とリファクタリングを繰り返しました。これもテストコードが動作を担保してくれたから可能だったと思います。
テストコードの構造も、より書きやすく、管理しやすいように改修を続けました。
テストケースを先に作成したのは、プロジェクト全体を通して非常に良い決定だったと確信しています。
まとめ
本日は、「GVA 法人登記」の大規模改修プロジェクトを通して、私たちが実現したかったこと、そして成功に導いた以下の3つの原則についてお話ししました。
-
ドメイン専門家との協調: 司法書士の知識を「共通言語」としてシステムに組み込み、拡張性の高いドメイン設計を実現しました。
-
FW非依存設計: コアとなるビジネスロジックをフレームワークから分離し、変化に強くメンテナンスしやすい堅牢なコードベースを確立しました。
-
テストコードベースの開発: 1,800項目を超えるテストコードでビジネスロジックの堅牢性を担保し、大規模なリファクタリングを可能にしました。
この改修により、現在の「GVA 法人登記」は、複数種類同時申請機能という市場優位性のある機能を実現し、対応範囲も「株式会社」に留まらず、多様な法人種別に対応できるようになりました。
私たちはこれからも、司法書士、弁護士、商標専門知識を持った方々、そしてビジネス・CSチームと連携し、より多くの方々が法務手続きを簡単に行える未来を目指して開発を続けていきます。
「GVA 法人登記」について、さらに詳しい記事もございますので、ぜひご覧ください。
登記申請の常識をアップデートする~「GVA法人登記」の仕掛け人が語るこれまでとこれから~
Discussion