採用活動を管理するSaaSを、初期版のフルスタック構成から、APIサーバー（Laravel）とフロント（Next.js）に役割を分けた構成へ作り直しました。API定義からOrvalでクライアントを生成し、ワークスペースの切り替え、候補者の一覧、招待の承認、パスワードの再設定といった機能を新構成で実装しています。外部にあるLLMのワークフロー基盤とつなぐ部分は、求人ごとにAIへ渡す値を設定して有効化できる「パラメータセット」として抽象化し、業務担当者が自分で調整できるようにしました。
- 止めずに作り直す並行移行
- 旧版を稼働させたまま新構成を並行して構築し、ページ単位で移行状況を一覧化して共有することで、切り替えのリスクと利用者への影響を抑えました。
- 業務処理をUseCase単位で独立
- 一つひとつの業務処理を独立したクラスとして実装し、画面やAPIの形が変わっても業務ロジックを変えずにテスト・再利用できる構造にしています。
- AIの挙動を設定として業務側へ
- 求人ごとに異なる評価観点をコードではなく設定値として管理画面から扱えるようにし、エンジニアを介さずにAI処理を調整できる運用を可能にしました。
- API定義からクライアントを生成
- APIの定義を先に決め、そこからフロント側のクライアントコードをOrvalで生成する流れにしました。画面とAPIの型が常に一致するため、two-repo構成でも仕様の食い違いが実装中に表面化します。
- フルスタック型からの責務分離
- 一つのフレームワークに同居していたフロントとデータアクセスを、Laravelのapiサーバーとnext.jsのフロントへ分けました。業務処理を画面以外の入口からも呼べる構造にするための分割です。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
MVPの構成を「いつ」作り直すか
フロントとバックエンドを一つのフレームワークにまとめた構成は、MVPを素早く世に出す段階では最適な選択です。作り直しの判断は現状の不便さではなく、次に増やす利用者や連携先から逆算して行います。モバイルアプリや外部連携など、同じ業務処理を複数の入口から呼びたくなる時点が典型的な転換点です。その前に作り直すと過剰投資になり、後に回すと連携ごとに場当たり的な実装が積み上がります。事業計画の中で連携先の増加時期を見通し、それに合わせて技術投資を計画することが望まれます。
作り直しの期間に事業を止めないための運用
既存の利用者がいるSaaSを作り直す場合、新旧両方が動く期間の運用設計が成否を分けます。機能ごとに新旧どちらが稼働中かを示す表を保ち、利用者にはいつ切り替わるかを事前に伝える方法があります。旧側をいつ止めるかの条件も初期に合意しておかないと、並行稼働が長引いて開発チームの負荷が増え続けます。作り直しは技術プロジェクトではなく、顧客対応と営業活動を含む事業全体のプロジェクトとして計画する必要があります。
関連するサービス
関連する領域
関連するインサイト
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- 開発の内製化ロードマップ — 外注から自社チームへ移行する手順外注に頼っていた開発を自社チームへ移す手順を、現状の棚卸し、最初に内製化する領域の選定、採用と技術顧問の活用、コードとドキュメントの引き継ぎ、並走期間、移行後の外部パートナーの使い方まで段階的に解説します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開