Table of Contents
はじめに
こんにちは、チーム「raccoon」の岡本です。 この記事では、自社プロダクト「360（さんろくまる）」の技術リプレースについてご紹介します。
4月17日に自社プロダクト「360」のリニューアルを行いました。 UIの刷新をメインターゲットとしつつ、同時にCakePHP・jQuery ベースで開発されていた360を、Laravel・React（TypeScript）を中心とした構成にリプレースしました。
リプレースに際し、単なる技術の置き換えではなく、開発体験や保守性の向上を重要な目的と位置付けました。 本記事では、そうした背景や意思決定のプロセス、具体的な取り組み、得られた知見をまとめていきます。
プロダクトと課題
まず、リプレース対象のプロダクトについて簡単にご紹介します。 「360（さんろくまる）」は、360度フィードバックをWeb上で匿名かつ手軽に実施できるプロダクトです。部署や職位を超えたフィードバックを通じて、組織開発や人材育成を支援しています。
こちらのリンクから、フィードバック回答画面のデモを体験できます。
技術的な課題
従来の構成では、CakePHPとjQueryをベースにテンプレートでHTMLを生成し、フロントエンドの動きはjQueryのスクリプトで制御していました。しかしながら、仕様の追加や分岐が積み重なる中で、以下のような問題が顕在化してきました。
- 複数ファイルにまたがる処理が増え、改修時の影響範囲が不明瞭
- 複数のページに共通する処理と、特定のページにのみ存在する処理が混在している...など
- jQueryコードの再利用性や保守性に限界がある
技術スタック
社内ではLaravelでの開発経験を持つメンバーが増えてきており、新人研修や他プロジェクトでもLaravelを使うケースが多くなっています。 プロダクトにおいても、Laravelを採用することでメンバーの流動性を上げることを狙いとしました。
また、フロントエンドについてもReactやTypeScriptによるコンポーネントベースの設計に移行することで、型による支援や状態管理の改善が見込め、開発体験の向上につながると判断しました。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| バックエンド | CakePHP | Laravel |
| フロントエンド | jQuery（一部Vue.js） | React（TypeScript） |
| レンダリング方式 | サーバーサイドレンダリング | Inertia.js によるSPA構成 |
開発体験の向上のための取り組み
フロントエンドの型支援と自動生成
React + TypeScript に移行したことで、型による開発支援の恩恵を受けられるようになりました。そのなかでも特に効果が大きかったのが laravel-typegen の導入です。
このツールは、LaravelのモデルやZiggyのルート情報などをTypeScriptの型として自動生成するOSSで、主に弊社の浦田が開発・保守しています。 これにより、Laravel 側のモデルやルート情報を TypeScript 側で型として扱えるようになり、フロントエンドでも IDE の補完機能をフルに活用できるようになりました。 フロントエンド側で Laravel の route 情報の型を持つことで、APIのエンドポイントやパラメータの型を明示的に扱えるようになるなど、開発体験が大きく向上しました。
CIと静的解析による品質担保
以下のような静的解析・自動チェックツールをCIに組み込みました。
PHP / Laravel
- pint（コードフォーマッター）
- larastan（静的解析）
- PHPUnit（単体テスト/E2E テスト）
- laravel-ide-helper（補完ファイル生成）
JavaScript / React
- ESLint（構文・型チェック）
- Prettier（整形）
- laravel-typegen （モデル型定義などが更新されているか）
- i18n関連の未使用キー検出
これらのチェックによって
- 補完ファイルが常に最新の状態になり、IDEの支援を受けやすくなる
- フォーマッターによってコードの一貫性が保たれる
- テストが自動実行されることで、リファクタリングや機能追加の際の心理的負担が軽減される
- 開発者がビジネスロジックに集中できるようになる
- レビュワーがチェックするべきポイントが減り、負担が軽減される
などのような効果が得られました。
E2EテストとUI差分チェック
Laravel Dusk を用いてE2Eテストを導入しました。 Dusk は Laravel に組み込まれた E2E テストツールで、ブラウザを自動操作してテストを実行することができます。 Playwright などの JavaScript ベースの E2E テストツールと比べ、Factory を使いデータベースの状態を簡単に操作できるので Dusk を選択しました。
特に工夫したのは「スクリーンショットの差分チェック」です。CI上で画面の状態を再現し、以前のスクリーンショットと比較して差分を検出できるようにしました。 下の画像のように GitHub Actions 上で Dusk を実行し、スクリーンショットを取得して差分をチェックし、コメントに残すようにしています。(※ 画像は開発中のものです)
これにより、意図しないUIの崩れを検知しやすくなり、安心してリファクタリングや機能追加ができるようになりました。 表示内容の乱数シードを固定したり、（ImageMagick を用いて）多少の差分は無視するなどの細かな調整も必要でしたが、得られた安心感は大きかったです。
振り返って
今回のリプレースを通じて得られた知見は数多くあります。
- 適切なアーキテクチャ設計は、適切なテストの実行を容易にし、開発の心理的負担を軽減する
- 型とテスト、CIによるチェック体制を整えることで、IDE による支援を受けやすくなる
- UI差分チェックなど、テストの自動化は工数がかかる一方で、安心して改善を進めるためには非常に有効
プロダクトとしての成長に向けて、今後の拡張性・保守性の下地を作れたことに手応えを感じています。
おわりに
今回のリプレースは、単なる技術移行にとどまらず、以下に開発体験を向上させるかというテーマに取り組む機会となりました。
CI・型による支援・アーキテクチャの見直し・テストの充実などを通して、コードの質やチームの心理的安全性、そして新規メンバーのオンボーディングのしやすさまで含めて、開発環境全体を大きく改善できたと感じています。
リプレース以降、さまざまな機能の開発に着手していますが、並行して開発体験の向上にも取り組んでいます。 特に、直近では MCP(Model Context Protocol) サーバーの開発/利用をする事で、LLM による支援で開発効率を上げることに興味があり、試行錯誤をしながら開発を進めています。
開発効率を上げることでプロダクトの成長を加速させることができると思っているので、今後もこれを意識して開発を進めていきたいと思います。
また、リプレースに当たって取り組んだことは他にもありますので、今後も記事としてまとめていきたいと思います。
Yasuaki Okamoto
