学習サービス事業の業務システム群（レガシー刷新と統一）

学習教材を提供する事業には、社内の業務管理、受講者が使うマイページ、申込の受付、決済情報の更新、学習データの分析、教材の配信といった複数のアプリケーションが存在します。それぞれが異なる時期に、FuelPHPやRuby on Railsといった異なるフレームワークで作られてきました。これらを開発・保守しながら、新しく作るものはLaravelとNext.jsの組み合わせに揃えるという方針で技術の収束を進めています。決済情報に触れる申込の受付については、Terraformによる独立したインフラ定義とコンテナのビルド環境を整え、Railsで作られていた分析基盤も、同じ構成へ作り替えている途中です。教材の動画については、変換サービスと連携した配信の基盤を構築しました。

保守対象の技術を段階的に減らす: 新規開発の構成を一つに定め、改修の必要が生じた既存アプリから順に寄せています。一斉に作り直す計画は、その期間に新しい機能を出せなくなるため事業側の合意が得られません。改修の機会に合わせて寄せる方式なら、通常の開発予算の中で技術の収束を進められます。
決済に関わるアプリだけを隔離: 申込と決済情報を扱う仕組みだけを別のインフラとして定義しました。守るべき範囲を広げるほど、日常の改修すべてに高い注意が必要になり、開発の速度が全体で落ちます。範囲を狭く限定することは、安全性を高めながら他のアプリの改修を軽く保つための両立の手段です。
教材動画の配信基盤: 動画を変換して配信するまでの流れを、運営者が管理画面だけで完結できる基盤にしました。教材の追加のたびに開発側の作業が必要な構成では、コンテンツを増やす速度が開発の空き状況に縛られます。教材数が事業の価値に直結する領域では、運用の内製化そのものが投資の目的になります。
複数のアプリを並行保守しながら収束: FuelPHPやRuby on Railsなど世代の異なるフレームワークで作られた複数アプリを稼働させたまま、新規開発はLaravelとNext.jsに揃える方針を立てました。停止を伴わない収束の進め方です。
分析基盤の作り替えを同じ構成で: Railsで作られていた学習データの分析基盤も、他のアプリと同じLaravel・Next.jsの構成へ寄せる作業を進めています。保守できる技術の幅を意図的に狭める判断です。

この種のシステムで検討する論点（想定例）

以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。

技術の収束を事業計画に組み込む

事業の歴史が長くなるほど、時期ごとに違う技術で作られたシステムが並び、それぞれに詳しい人が減っていくのが典型的な状況です。一度にすべてを作り直すのではなく、新規開発の構成を一つに決め、既存システムは変更の頻度、担当者の属人性、セキュリティ更新の停止状況を基準に優先順位を付けて順次寄せていきます。技術の収束は開発チームだけの課題ではなく、採用のしやすさや外部パートナーの選択肢の広さにも影響するため、経営計画の中で年度ごとの目標として扱うのが望ましい進め方です。

個人情報と決済を扱う部分の分離は投資対効果が高い

受講者の個人情報やカードに関わる情報を扱う機能は、事業全体の中でも事故の影響が最も大きい部分です。この機能だけを専用のインフラに置き、更新の権限と手順もほかのシステムから切り離しておくと、日常的な改修が決済の安全性を脅かすことがなくなり、監査や取引先への説明でも整理がつきます。カード番号そのものは自社で持たず、決済代行の仕組みに委ねる形が広く採られています。守るべき範囲を狭く限定することは、セキュリティ投資を抑えつつ水準を高める現実的な方法です。一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

使った技術・扱った領域

Laravel
PHP
FuelPHP
Ruby on Rails
Next.js
React
Nuxt
Vue
TypeScript
Prisma
MySQL
PostgreSQL
Terraform
ECS
Docker
GitHub Actions

技術から他の事例を探すそれぞれの技術を選ぶ理由

他の開発事例

開発事例17件をすべて見る

監修: フィリット・コンサルティング株式会社公開 2026.09.13