はじめに

こんにちは、株式会社キカガクの茂木です。私は社内で、法人向けプロダクト「キカガク for Business」の開発チームに所属しています。

2024 年度の新卒ではありますが、今回こちらのプロジェクト紹介記事の担当をさせていただきました。

■ 新卒 1 年目に書いた記事はこちら tech.kikagaku.co.jp

弊社では 2023 年 10 月から 2025 年 4 月にかけ、NoSQL の Firestore から RDB である PostgreSQL への大規模なリアーキテクチャを進めておりました。

この記事では「Road To RDB」と題し、プロジェクト内容に関連する 3 点についてご紹介します。

移行の背景
導入で期待する効果
プロジェクト進行における苦労

なお、技術的な内容は、以下の記事にまとめております。

Road To RDB 〜NoSQL から RDB へ〜技術編

対象読者

この記事は、以下のような方を対象としています。

NoSQL と RDB のどちらを利用するか検討されている方
NoSQL から RDB への移行を検討されている方
DB 移行について具体を知りたい方

短くまとめると

今回の移行プロジェクトの要点は 3 つです。

NoSQL での運用が大変だった！
新機能開発と運用を並行していたため、リソースが不足していた！
RDB 移行により、機能追加や運用への柔軟な対応が可能になっていく！

ここからは、これらのポイントについて詳しく解説していきます。

移行の背景

弊社では 2017 年の設立当初から対面研修を実施しております。

しかし、 2020 年に弊社も例に漏れず、コロナ禍の影響を受け、収入が減少しておりました。

その影響に立ち向かうため、一刻も早く e ラーニングを開発し、オンラインでの研修も可能にする必要がありました。

そこで、DB に NoSQL の Firestore を利用すれば手軽に実現できると考え、プロダクトを立ち上げました。実装に求められるスピードとプロダクトの質や運用を天秤にかけた当時の判断としては、最善の技術選定だったと考えています。

しかし、この選択が今は技術的負債となってしまい、3 つの大きな問題を引き起こしました。

リクエストとデータ加工の負荷

「キカガク for Business」は、多くの法人様にご利用いただく中で、データ取得やアプリ上でのデータ加工、表示のパフォーマンスが課題となっていました。

1つの画面を表示するために、クライアントから DB への通信回数が多くなってしまう。
大量のデータをアプリケーション側で加工する必要がある。
これらの処理時間が長くなるほど、画面の読み込み時間が長くなる。

このように、システム構成と DB が、大規模な利用に耐えうる設計ではなかったのです。

集計と変更にかかる時間

「キカガク for Business」では、法人様からのご要望に応じて、特定のデータの集計や変更を行うことがあります。しかし、Firestore の特性上、

Firestore の GUI では、インデックスを貼らない簡単な集計しかできず、そこに該当する以外の集計にはスクリプトが必要となるため、集計が複雑でした。
NoSQL の特性として、非正規化されたデータを保持しているため、あるデータの変更が他のデータに与える影響範囲が広く、データの変更に手間と時間がかかっていました。
例えば、特定のドキュメント ID を変更するために 1 日以上かかることもありました。

など、運用が複雑かつ大変でした。

インデックスの過剰な設定

Firestoreでは、複雑な条件で検索するためにインデックスが不可欠です。「キカガク for Business」では、管理画面でユーザー情報を確認する際に、フィルター機能を利用します。しかし、フィルター条件は選択肢の数に応じて指数関数的に増加します。Firestore でこれらの条件に対応するには、多くのインデックスを設定する必要があり、1 ページに対して 100 個以上のインデックスが必要になることもありました。 インデックスが不足するとエラーが発生し、画面が表示されないため、漏れなく実装するために多くの工数を費やしました。

これらの問題点から、RDB への移行を決断しました。

次に、プロジェクト進行における苦労についてご紹介します。

導入で期待する効果

リクエストとデータ加工の負荷 → リクエストは 1 回！データ加工は BE で！

従来の構成では、データ変更に多くの手間がかかり、データ表示にも複数回のリクエストが必要でした。

RDB に移行することで、データ構造が固定化され、データの変更もテーブル内のデータを変更するだけで済むようになります。また、データ取得時の加工処理を BE 側に移すことで、FE のコードは表示に集中できるようになり、コードも大幅にスッキリしました。

集計と変更にかかる時間 → SQL の一括集計で楽々！

従来の構成では、非構造化データのため、データの集計に時間がかかっていました。

RDB ではデータが構造化されるため、テーブルを見ればデータが分かりやすく、SQL を活用することで、集計や変更が容易になります。

インデックスの過剰な設定 → インデックスは適量に！

従来の構成では、複雑な検索条件に対応するために、多くのインデックスを設定する必要がありました。

RDB への移行により、不要なインデックスを作成する必要がなくなり、GraphQL と SQL を活用することで、フィルター条件も容易に適用でき、管理コストも大幅に削減できます。

その他のメリット

弊社に蓄積された学習データの活用もしやすくなります。

弊社では、データ分析に BigQuery を利用していますが、これまでは Firestore のデータを非同期で構造化データに変換して連携する必要がありました。RDB に移行することで、DB のデータをそのまま集計に利用でき、情報把握や分析が効率化されます。

運用と要望改善、RDB 化の三足の草鞋をどう履きこなしたか

「キカガク for Business」では、

法人様からの保守・運用
機能要望の検討と実装

を日々の業務として行っていました。しかし、今回の RDB 化に伴い、三足目の草鞋を履くことになり、

リソース不足
開発効率の向上

という課題が浮き彫りになりました。

これらの課題に対応するため、3 つの施策を実施しました。

開発効率の見える化

これまで、弊社チームでは「開発効率性」を表す指標を定めていませんでした。そこで、本プロジェクトを遂行するにあたり、開発効率性の指標を急ピッチで作成しました。

そこで、元々導入していた StoryPoint（issue にかかると思われる工数）から稼働に対する個人進捗を算出し、チームとしての「開発効率性」（開発生産性とも言えます）を出す形にしました。また、これを GAS (Google App Script ) で GitHub と連携しつつ実装し、スプレッドシートでバーンダウンチャートとともに見える化しました。

※画像はイメージです。

生成 AI の積極導入

DX 教育を事業とする弊社では、社内 RAG の開発と Cursor の導入をしており、生成 AI のトレンドを追うために、積極的に情報交換を行っています。

社内 RAG 「キカバディ」

弊社では AI 開発から社内基盤を支えるチームがあります。

その一環として社内専用の生成 AI プラットフォーム「キカバディ」というものが開発されています。

主な機能は、社内の各種数値指標の確認、業務効率化のアプリケーションの搭載、各種生成 AI からモデル選択をできるフリーチャットとなっています。他にも AI を活用した実験的プロジェクトを蓄積するなど活用の幅が広がっています。

プラットフォーム部の業務では、フリーチャットを利用したコーディングや設計の相談を主に利用しています。

Cursor の導入

キカガクでは AI エディタとして Cursor を 2025/4 に導入しました。

Cursor の導入については以下の記事にまとめてあります。

Cursor & Devin から学ぶ、組織の AI 導入における５つの勘所

自動補完の機能に始まり、実装をチャット機能に任せることや rules の整備などの機能的な活用のみならず、ナレッジの共有を社内 Slack, Notion で実施するなど、情報交換も積極的に実施しております。

こういった活動により、RDB 化以外の業務があっても、少しずつ開発効率を向上していくことが出来ました。

技術キャッチアップのしやすさの向上

弊社のプロダクトは、元々 FE のみで構成されていたため、BE の技術に関してはキャッチアップからのスタートでした。そのため、開発経験のあるリードメンバーが設計・環境構築を行い、その後、各エンジニアが技術をキャッチアップしながら実装する形をとっていました。また、リソース不足に合わせて新規メンバーを採用するにあたり、技術キャッチアップの壁はドメイン知識の習得と共に厚いものでした。

そのため、チームでは以下のことに力を入れています。

開発ドキュメントの整備
- フロントエンドでは rule や usecase、バックエンドでは Architecture や Development のようにディレクトリを分け、開発時にこれらのドキュメントを見れば実装できるように整備
- ↓ドキュメントに対するチームメンバーからのポジティブなフィードバック↓

tech.kikagaku.co.jp

Notionでの開発ルールの管理
- 意思決定を記録する Architecture Decision Record (ADR) を導入し、過去の決定事項を振り返れるようにしました。
勉強会、開発合宿の実施
- フルリモートのため、全員で集まる時間を作っています。