プロジェクトでの変化
- 障害対応時間短縮
- 機能追加リードタイム短縮
- コードベースTypeScript化で型整備
課題
直すたびに、別のどこかが壊れる。仕様書もほとんど残っていませんでした。オフショア側とは時差と言語の壁があり、ちょっとした修正でも数日から数週間かかります。コードには型がなく依存関係もどこにも書かれていないため、社内のエンジニアが手を入れることもできません。リリースのたびに障害が出て、その対応で次のリリースが遅れる。この繰り返しになっていました。修正できる人がいないという状態を断ち切るには、コードベースと運用の流れを両方作り直すしかありませんでした。
アプローチ
- 01 現行アプリのユースケースを画面単位でリバースエンジニアリングしました
- 02 Laravel + Inertia + React で「サーバ起点・SPA体験」の構成を採用しました
- 03 TypeScript化でAPI入出力を型で固定し、退行を防いでいます
- 04 Dockerでローカル〜本番までの再現性を担保しました
- 05 社内エンジニアが手を入れられるよう、コードレビュー基準とドキュメンテーション方針を策定しました
- 06 リリースフローを GitHub Actions ベースで自動化し、手作業による事故を構造的に排除しています
成功要因
- リバースエンジニアリング
- 仕様書が乏しい現行アプリを画面単位で読み解き、機能の根拠を社内で説明できる状態に戻しました。
- Inertiaによる結合
- InertiaJSでLaravel側ロジックとReact側UIを密結合させ、SPA体験とサーバ起点の分かりやすさを両立しました。
- TypeScript型での退行防止
- API入出力をTypeScriptで型固定し、修正のたびに別箇所が壊れる状況を構造的に解消しました。
- 再現可能な開発環境
- Dockerでローカル〜本番の差異を抑え、調査と修正の往復コストを下げました。
ソリューション
InertiaJS を間に置き、Laravel のロジックと React のUIをつなぎながらSPAの体験を作りました。型は TypeScript で共有します。ここが効いて、後から機能を足すときの手戻りが目に見えて減りました。作り直した後は社内のエンジニアが直接コードを触れるようになり、障害対応も機能追加も短くなっています。どこに何があるか分かる。その状態に戻せたことが、いちばんの成果です。
