採用管理システム（ATS）を、初期版のフルスタック構成から、LaravelのAPIサーバーとNext.jsフロントに責務を分離した構成へ移行しました。OpenAPIからOrvalでAPIクライアントを自動生成し、ワークスペース選択、候補者一覧、招待承認、パスワードリセットなどを実装しています。外部のLLMワークフロー基盤と連携するパラメータセット管理をUseCase層に実装し、求人ごとにAI処理の入力値を設定・有効化できるようにしました。
- 旧版を残したまま並行リアーキテクチャ
- フルスタック構成からAPI分離型へ、旧版を稼働させたまま並行して作り直し、切り替えのリスクを抑えています。
- UseCaseをクラス単位で分離
- 業務処理をUseCaseごとにクラスとして分離し、画面やAPIの都合から独立してテスト・変更できる構造にしています。
- LLM連携をパラメータセットとして抽象化
- 外部のLLMワークフロー基盤への入力をパラメータセットとして抽象化し、非エンジニアが求人ごとにAIの挙動を調整できるようにしました。
- ページ単位の進捗の見える化
- READMEにページ単位の進捗表を維持し、移行の完了状況をチームで共有しています。
- OpenAPIからクライアントを自動生成
- LaravelのAPIサーバーが公開するOpenAPI定義からOrvalでフロント側のAPIクライアントを生成し、型と呼び出し口を手書きしない構成にしました。定義を変えれば生成物が追従するため、API仕様とフロントの実装がずれにくくなります。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
想定例: フルスタック構成からAPI分離型に移るタイミング
フロントとバックエンドを1つのフレームワークでまとめる構成は、立ち上げ期には開発速度の面で有利です。一方で、複数のクライアント（管理画面、外部連携、モバイル）から同じ業務処理を呼びたくなった時点で、APIとして切り出す方が全体の見通しが良くなります。切り替えの判断は「今困っているか」ではなく「次に増やす利用者や連携先が何か」で行い、OpenAPIのような契約を先に固めてからフロントを作り直すと手戻りが減ります。
想定例: 作り直し中の二重運用をどう乗り切るか
既存システムを止めずに作り直す場合、一定期間は新旧両方が動き、データや認証をどちらが持つかで混乱が起きやすくなります。ページや機能の単位で「新側に移行済み」「旧側で稼働中」を一覧にして常に更新し、利用者への案内と切り替え日を明確にすることが、二重運用の期間を短くする近道です。旧版の停止条件も最初に決めておき、ずるずると並行稼働が続かないようにします。
関連するサービス
関連する業種
関連する開発ガイド
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
- 要件定義とは何をすることか — 発注前に整理したい5つのこと要件定義はシステムで何を実現するかを合意する工程です。発注前に整理したい目的と成功条件、現状業務の流れ、利用者と権限、扱うデータ、やらないことの5つを、想定例を交えて解説します。
- Webシステム開発でよくある失敗10選と回避策Webシステム開発で中小企業が陥りやすい10の失敗を、要件・契約と費用・進め方・運用の4つの場面に分けて想定例とともに紹介し、発注側が事前にできる回避策を解説します。
他の開発事例
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開