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