PHPシステムのLaravel移行

きっかけ

知り合いからの紹介で、あるベンチャー企業のシステム改修に携わることになりました。

そのシステムは、社内の業務管理と顧客向けのコンテンツ配信が一体になった、いわば「何でも入り」の仕組みでした。長年にわたって機能が追加され続けた結果、全体像を把握している人が社内にもいない状態。PHPで書かれてはいるものの、フレームワークは使われておらず、書き方もかなり古い。

「新しい機能を追加したいが、既存コードに手を入れるのが怖い」── そんな状況を打破するために、Laravelへの移行を進めることになりました。

一緒に考えたこと

まず取り組んだのは、既存コードの解読です。

ドキュメントはほとんどなく、変数名や関数名から意図を推測するところから始まりました。古いPHPの書き方 ── グローバル変数が飛び交い、同じ処理があちこちにコピーされている。「なぜこの分岐があるのか」がコードだけでは読み取れない箇所も多く、現場の担当者に一つひとつ確認していく作業が続きました。

特に複雑だったのが、独自の広告配信と集計の仕組みです。自社で広告を発行し、複数のメディアと契約して配信し、その成果を集計する。この一連の流れがコードの中に暗黙のルールとして埋め込まれていました。ドキュメント化されていないビジネスロジックを、コードと対話と現場の記憶を頼りに掘り起こしていく。地道ですが、ここを丁寧にやらないと移行後に「前はできていたのに」という事態になります。

技術だけでは解決できない。現場を知っている人の言葉を聞いて、初めてコードの意味がわかる。このプロジェクトは、まさにそういう仕事でした。

つくったもの

既存のPHPシステムをLaravelに移行し、保守性と拡張性を持ったシステムに再構築しました。

コード基盤の刷新 ── フレームワークなしで書かれていたPHPコードを、Laravelの設計規約に沿って整理しました。ルーティング、認証、バリデーション、データベース操作といった基盤部分をLaravelの仕組みに載せ替えることで、コードの見通しが格段に良くなりました。次に触るエンジニアが「何がどこにあるか」を迷わない構造です。

広告集計の再設計 ── 最も複雑だった広告配信・集計の仕組みを、Laravelのデータベース機能を活かして再設計しました。ピボットテーブルを導入してデータの関連性を整理し、集計クエリを最適化。以前は表示に時間がかかっていた集計画面の表示速度も大幅に改善しました。

アクセス解析の独自実装 ── 外部の解析ツールに頼らず、システム内部に独自の解析機能を組み込みました。広告経由のアクセスやコンバージョンの流れを、管理画面からリアルタイムで確認できる仕組みです。自社のビジネスに特化した指標を、自分たちの手で追えるようになりました。

何が変わったか

特に喜んでいただいたのは、集計周りの改善でした。

以前は集計画面を開くたびに待たされていた表示が、体感で明らかに速くなった。データの切り口も増え、ピボットで柔軟に集計を組み替えられるようになったことで、「今までは見えていなかった数字が見えるようになった」との声をいただきました。

独自の解析機能も好評でした。外部ツールでは取れない、自社のビジネスフローに沿った数字をダッシュボードで確認できる。データに基づいた判断がしやすくなったとのことです。

そしてなにより、「コードに触れるようになった」こと。以前は機能追加のたびに「どこに影響が出るかわからない」という恐怖がありましたが、Laravelに移行したことで、変更の影響範囲が明確になり、安心して機能開発を進められる状態になりました。

ふりかえり

レガシーシステムの改修は、新規開発よりも難しい場面が多いです。ゼロから作るなら自分で設計できますが、既存システムには「なぜそうなっているか」という歴史がある。その歴史を無視して作り直すと、必ず見落としが出ます。

だからこそ、コードを読むだけでなく、現場の人と対話する時間が大切でした。画面の向こうにある業務の流れや、担当者が日々感じている不便を理解して、初めて正しい移行ができる。

「システムが古くなってきたけど、どうすればいいかわからない」「触るのが怖いコードがある」── そんな状態でも大丈夫です。まずは現状を一緒に見るところから始めましょう。

visitor@sai: /works
  
   ██████╗  █████╗ ██╗
  ██╔════╝ ██╔══██╗██║
  ╚█████╗  ███████║██║
   ╚═══██╗ ██╔══██║██║
  ██████╔╝ ██║  ██║██║
  ╚═════╝  ╚═╝  ╚═╝╚═╝
    株式会社 才 (SAI Inc.)

  --------------------------------------------------
  
  ██╗    ██╗  ███████╗  ██╗       ██████╗   ██████╗    ███╗   ███╗  ███████╗
  ██║    ██║  ██╔════╝  ██║      ██╔════╝  ██╔════██╗  ████╗ ████║  ██╔════╝
  ██║ █╗ ██║  █████╗    ██║      ██║       ██║    ██║  ██╔████╔██║  █████╗
  ██║███╗██║  ██╔══╝    ██║      ██║       ██║    ██║  ██║╚██╔╝██║  ██╔══╝
  ╚███╔███╔╝  ███████╗  ███████╗  ╚██████╗  ╚██████╔╝  ██║ ╚═╝ ██║  ███████╗
   ╚══╝╚══╝   ╚══════╝  ╚══════╝   ╚═════╝   ╚═════╝   ╚═╝     ╚═╝  ╚══════╝

  Type 'help' to see available commands.
  Type 'gui'  to return to visual mode.
  --------------------------------------------------
visitor@sai:/works$ cat system-refactoring
── PHPシステムのLaravel移行 ──

きっかけ

知り合いからの紹介で、あるベンチャー企業のシステム改修に携わることになりました。



そのシステムは、社内の業務管理と顧客向けのコンテンツ配信が一体になった、いわば「何でも入り」の仕組みでした。長年にわたって機能が追加され続けた結果、全体像を把握している人が社内にもいない状態。PHPで書かれてはいるものの、フレームワークは使われておらず、書き方もかなり古い。



「新しい機能を追加したいが、既存コードに手を入れるのが怖い」── そんな状況を打破するために、Laravelへの移行を進めることになりました。



一緒に考えたこと

まず取り組んだのは、既存コードの解読です。



ドキュメントはほとんどなく、変数名や関数名から意図を推測するところから始まりました。古いPHPの書き方 ── グローバル変数が飛び交い、同じ処理があちこちにコピーされている。「なぜこの分岐があるのか」がコードだけでは読み取れない箇所も多く、現場の担当者に一つひとつ確認していく作業が続きました。



特に複雑だったのが、独自の広告配信と集計の仕組みです。自社で広告を発行し、複数のメディアと契約して配信し、その成果を集計する。この一連の流れがコードの中に暗黙のルールとして埋め込まれていました。ドキュメント化されていないビジネスロジックを、コードと対話と現場の記憶を頼りに掘り起こしていく。地道ですが、ここを丁寧にやらないと移行後に「前はできていたのに」という事態になります。



技術だけでは解決できない。現場を知っている人の言葉を聞いて、初めてコードの意味がわかる。このプロジェクトは、まさにそういう仕事でした。



つくったもの

既存のPHPシステムをLaravelに移行し、保守性と拡張性を持ったシステムに再構築しました。



コード基盤の刷新 ── フレームワークなしで書かれていたPHPコードを、Laravelの設計規約に沿って整理しました。ルーティング、認証、バリデーション、データベース操作といった基盤部分をLaravelの仕組みに載せ替えることで、コードの見通しが格段に良くなりました。次に触るエンジニアが「何がどこにあるか」を迷わない構造です。



広告集計の再設計 ── 最も複雑だった広告配信・集計の仕組みを、Laravelのデータベース機能を活かして再設計しました。ピボットテーブルを導入してデータの関連性を整理し、集計クエリを最適化。以前は表示に時間がかかっていた集計画面の表示速度も大幅に改善しました。



アクセス解析の独自実装 ── 外部の解析ツールに頼らず、システム内部に独自の解析機能を組み込みました。広告経由のアクセスやコンバージョンの流れを、管理画面からリアルタイムで確認できる仕組みです。自社のビジネスに特化した指標を、自分たちの手で追えるようになりました。



何が変わったか

特に喜んでいただいたのは、集計周りの改善でした。



以前は集計画面を開くたびに待たされていた表示が、体感で明らかに速くなった。データの切り口も増え、ピボットで柔軟に集計を組み替えられるようになったことで、「今までは見えていなかった数字が見えるようになった」との声をいただきました。



独自の解析機能も好評でした。外部ツールでは取れない、自社のビジネスフローに沿った数字をダッシュボードで確認できる。データに基づいた判断がしやすくなったとのことです。



そしてなにより、「コードに触れるようになった」こと。以前は機能追加のたびに「どこに影響が出るかわからない」という恐怖がありましたが、Laravelに移行したことで、変更の影響範囲が明確になり、安心して機能開発を進められる状態になりました。



ふりかえり

レガシーシステムの改修は、新規開発よりも難しい場面が多いです。ゼロから作るなら自分で設計できますが、既存システムには「なぜそうなっているか」という歴史がある。その歴史を無視して作り直すと、必ず見落としが出ます。



だからこそ、コードを読むだけでなく、現場の人と対話する時間が大切でした。画面の向こうにある業務の流れや、担当者が日々感じている不便を理解して、初めて正しい移行ができる。



「システムが古くなってきたけど、どうすればいいかわからない」「触るのが怖いコードがある」── そんな状態でも大丈夫です。まずは現状を一緒に見るところから始めましょう。

visitor@sai:/works