株式会社Atsumell様｜サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

項目	内容
クライアント	株式会社Atsumell様
業界	SaaS / BtoBプラットフォーム
支援対象	SIerと協力会社(BP)をつなぐマッチングプラットフォーム「Atsumell」
支援期間	2025年4月〜2026年2月（約11ヶ月）
体制	のべ4名（同時稼働は最大2〜3名）
支援範囲	機能開発、データアクセス基盤の刷新、認可設計の再構築、データベースマイグレーション

すでに多くのユーザーが利用している稼働中プロダクトに対して、機能開発を続けながら基盤そのものを作り替える必要がありました。具体的には次の5点です。

• 開発を止められない。 基盤の作り替えが必要なことは分かっていても、機能開発を止めて改修に専念する選択肢がなかった
• データアクセスが Supabase クライアントの直接呼び出しに依存しており、認可ロジックが RLS（Row Level Security）やデータベーストリガーに散在していた。DB 側に隠れた副作用が多く、変更の影響範囲が読みにくい状態だった
• マッチングプラットフォーム固有のデータ整合性問題。 協力会社が人材情報を後から編集すると、発注側が見ていた応募内容と食い違ってしまう
• 1ユーザーが複数の企業に所属できない構造で、実際の利用実態に合っていなかった
• 参画メンバーが時期によって入れ替わるため、個人の頭の中に設計が閉じてしまうと後続が止まる

こうした「動いているものを壊さずに作り替える」局面は、システム刷新の進め方で整理している基幹システムの刷新と同じ構造の難しさを持ちます。止めて作り直せるなら簡単ですが、事業が動いている以上その選択肢は取れません。

選定理由

稼働中プロダクトの基盤刷新は、「作り替えられること」だけでは足りません。リリースを止めずに移行できること、そして担当エンジニアが入れ替わっても設計が引き継がれることの2つが同時に求められます。

当社が担ったのは、この2点を設計で担保する役割でした。具体的には、呼び出し側の契約を保つ中間層を用意して段階移行を可能にしたこと、認可条件やデータ設計の判断根拠をコードとドキュメントに残す運用を持ち込んだことです。短期参画のメンバーがいても積み上げが効いたのは、この方針を最初に決めていたからです。

開発体制や契約形態の考え方については要件定義は準委任契約が基本でも整理しています。

1. 応募データの「時点保全」をスキーマで解決

UI上の注意喚起ではなく、データベース設計で解きました。応募が発生した時点の人材情報・チーム構成をまるごと保存するスナップショット用テーブルを新設し、生成と紐付けを PostgreSQL のトリガーに寄せることで「アプリ側の呼び忘れによる不整合」の余地そのものを消しています。

新テーブルを足すだけで終わらせず、すでに存在する全ての人材・チーム・応募レコードに対する遡及データ生成も同時に実施し、「機能追加後に過去の応募履歴が空白になる」事故を防ぎました。あわせて、実際のクエリの形に合わせた複合インデックス設計と、変更があったときだけ新バージョンを切る差分チェックによるデータ肥大化の抑制まで組み込んでいます。

この仕組みは現在もプロジェクトのアーキテクチャドキュメントに中核機能として記載され、後続開発の設計前提になっています。

2. データアクセス基盤を Prisma へ段階移行 ─ 呼び出し側を壊さない2層構造

Supabase クライアントの直接呼び出しを、Prisma を使った Repository 層へ移行しました。ポイントは、数十箇所の呼び出し側を一斉に書き換えない設計にしたことです。

Repository（Prisma）と Legacy Gateway（Prisma の結果を従来の Supabase 形式へ変換する層）の2層構造を用意し、既存コードから見た戻り値の形を保ったまま裏側だけ差し替えられるようにしました。これにより、テーブル単位・画面単位で少しずつ移行を進め、移行途中でもいつでもリリースできる状態を維持しています。

移行の正しさは「Prisma で書き込んだデータを従来の経路で読み出して一致するか」を検証するテストで担保しました。また移行フェーズでは、本来望ましくない既存の挙動もあえてそのまま維持し、その判断をコミットに明記しています。改善と移行を混ぜないという規律が、リグレッションの切り分けを容易にしました。

3. 認可ロジックをデータベースからアプリケーション層へ引き上げ

auth.uid() を参照する RLS ポリシーとユーザー作成時のデータベーストリガーを撤去し、同等の制御をアプリケーション側の高階関数へ移設しました。サーバー・クライアントの双方から同一経路で企業スコープを適用できる形にしています。

さらに、複雑に絡み合っていたプロジェクト／案件のアクセス条件をコード上に仕様として明文化した上で、判定・データ収集・呼び出し口の3つに分割して再実装しました。必要なデータを一度だけ取得してから判定する構造にすることで、権限チェックのたびに発生していた多重フェッチも解消しています。

4. 稼働中データベースの主キー変更を、段階的マイグレーションで安全に実施

1ユーザーが複数の企業に所属できる構造へ移行するため、稼働中テーブルの主キーを複合キーからサロゲートキーへ変更しました。影響範囲が広く失敗できない変更のため、「キー構造の変更 → セキュリティポリシーの更新 → バックアップ列を追加した上でのデータ書き換え」の3段階に分割し、各段階でロールバックの余地を残しています。

5. 使われなくなった仕組みを、データベース定義まで含めて撤去

機能を足すだけでなく引き算も行いました。使われなくなった「オファー」機能をメールテンプレート・画面・列挙型の定義まで含めて削除（純減 約1,200行）、二重管理になっていたプロジェクト公開ステータスの廃止（約3,100行の削除）など、負債を残さずに畳む作業を継続的に実施しています。

6. 依頼されていない安全面の手当て

• ログイン後に元のページへ戻す機能を実装する際、リダイレクト先を無検証で使わずパス検証処理を新規作成し、オープンリダイレクトを防止
• PDF 生成機能で自ホスト以外の URL を弾く検証を追加し、任意 URL の PDF 化（SSRF）を封鎖
• PDF 生成のために一度追加した外部ライブラリを、既にテスト用途で導入済みのライブラリで代替できると判断して依存ごと削除
• メール配信サービスのレート制限を運用で踏んだ際、並列送信から間隔を挟んだ直列送信へ設計を作り直し

約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。

参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、先に入ったメンバーが構造を残していたからでした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。

この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。

大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。

この事例からの示唆

稼働中のサービスでも基盤は入れ替えられる。 前提は、呼び出し側の契約（戻り値の形）を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。

メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについてはシステム開発の失敗から立て直す方法でも整理しています。

要件が固まりきらない領域ほど、データ設計で制約を表現する。 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては要件定義の進め方を参照してください。

よくある質問

Q. 稼働中のサービスを止めずに基盤刷新はできますか。 A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。

Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。 A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。

Q. どのくらいの規模・期間の支援ですか。 A. 約11ヶ月、のべ4名（同時稼働は最大2〜3名）です。プロジェクトの規模や費用感の考え方はシステム開発とはで解説しています。

関連する支援領域

• システム刷新の進め方｜検討・計画から移行までの方法 — 稼働中システムを止めずに刷新する判断基準
• 業務システム開発の要件定義とは？進め方・手順を7ステップで解説 — 要件を仕様に落とす工程
• システム開発の失敗から立て直す方法 — 体制・引き継ぎで詰まったときの選択肢

同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、開発のご相談からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。