「Schemaドリブン」で量産体制へ。バックエンドは一度捨てて作り直した
浪山氏の開発チームは、案件ごとにWeb募集サイトを構築しながら、SaaS化に使えそうなパーツを抽出していった。そこで抽出して共通化した「Schemaファイル」を元に「Schemaドリブン方式」で開発することで、より多くの案件を高速にさばけるようになっていった。
Schemaドリブン方式では、共通のSchemaファイルによってデータやAPIの構造を最初に定義し、それに従ってフロントエンドやバックエンド、DBスキーマを実装する。一度Schemaファイルを作成すれば、次の案件では少しの書き換えで構築できるため、金太郎あめのようにWebサイトを量産できるアプローチだ。
浪山氏らはまず、フロントエンドをJSON Schemaを元に構築し、バックエンドとDBスキーマはPrisma Schemaを元に構築した。Prismaは、スキーマをベースにDDLを記述してDBへの反映やコード生成を自動化できるNode.js向けのORMで、Prisma Schemaはその定義ファイルにあたる。
フロントエンドには、JSON Schemaを元に申し込みフォームのUI画面を構築できる「React JSON Schema Form」（RJSF）というライブラリを採用し、独自に改良。案件を重ねるごとにコーディングが必要な箇所が減っていき、現在はほぼすべての画面がJSON Schemaのみで作れるようになった。
バックエンドとDBスキーマについては、当初Prisma Schemaを基にDBとAPIを自動実装しようと考えた。Prisma Schemaを1つ作れば、テーブルもエンドポイントも自動で生成される仕組みだ。APIにはREST APIではなく、Prismaと相性のよいGraphQLを選んだ。
ところが、このアプローチは案件ごとの構築には向いているものの、SaaS化には適さないことがわかった。というのも、個別の案件用のコードを生成してしまうと、SaaSの基盤に載せられないためだ。SaaS化では、1つの基盤に案件ごとのスキーマを追加していく形になる。加えてGraphQLも、データストアのようなシステムには適するが、保険のWeb募集には過剰だった。
そのため、SaaS化にあたってはPrismaを廃止して、コード生成という発想自体を捨てた。
SaaS基盤は、「安定性の高い堅牢なシステムにする必要があった」と浪山氏は振り返る。そこで、バックエンドの言語をNodeから、後方互換が安定しているJavaへ変更した。Nodeではライブラリのバージョンアップで後方互換が壊れることが多かったためだ。あわせて、契約情報はJSON形式で管理するスキーマレス方式に刷新した。
具体的には、案件ごとのバリデーションチェックを通った内容を、そのままJSON形式でDBに格納する仕組みだ。案件ごとに異なる項目が来てもDBのカラムを増やす必要がなく、そのまま保管できるメリットがある。バリデーションはSchema Validatorで定義しており、一部Schemaドリブンを残した形だ。
ただし、JSONのまま格納するとアプリの処理では扱いにくい。そこで、処理で使う一部の項目のみ、他の列から計算した値を仮想カラムに自動展開する「Computed Column」で展開している。補償開始日や保険料といった特別な意味を持つ項目を、JSONカラムから自動的に抜き出してアプリから使えるようにする仕組みである。
その他、アーキテクチャをモノリスからマイクロサービスへ、実行環境をCloud RunからGKEへ、DBをPostgreSQLからSpannerへと変更し、安定したSaaS基盤を目指した。
