学習教材を提供する事業には、社内の業務管理、受講者が使うマイページ、新規の申込受付、決済情報の更新、学習データの分析、英語学習サービスの管理画面、教材の出題システムといった複数のアプリケーションが存在します。それぞれが異なる時期に、FuelPHPやRuby on Railsといった異なるフレームワークで作られてきました。これらを開発・保守しながら、新しく作るものはLaravelとNext.jsの組み合わせに揃えるという方針で技術の収束を進めています。決済情報に触れる申込受付については、Terraformによる独立したインフラ定義とコンテナのビルド環境を整え、Railsで作られていた分析基盤も、同じ構成へ作り替えている途中です。英語学習サービス向けには、動画の変換サービスと連携した配信基盤を構築しました。
- 保守対象の技術を段階的に減らす
- 新規開発の構成を一つに定め、改修の必要が生じた既存アプリから順に寄せていくことで、世代の異なる技術の並存を計画的に解消しています。
- 決済に関わるアプリだけを隔離
- 申込と決済情報を扱う仕組みだけは別のインフラとして定義し、ほかのアプリを変更しても決済の環境には触れない構成にしました。
- 教材動画の配信基盤
- 英語学習サービス向けに、動画を変換して配信するまでの流れを運営者が管理画面で完結できる基盤を構築し、教材の追加を運営側だけで行えるようにしました。
- 複数のアプリを並行保守しながら収束
- FuelPHPやRuby on Railsなど世代の異なるフレームワークで作られた複数アプリを稼働させたまま、新規開発はLaravelとNext.jsに揃える方針を立てました。停止を伴わない収束の進め方です。
- 分析基盤の作り替えを同じ構成で
- Railsで作られていた学習データの分析基盤も、他のアプリと同じLaravel・Next.jsの構成へ寄せる作業を進めています。保守できる技術の幅を意図的に狭める判断です。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
技術の収束を事業計画に組み込む
事業の歴史が長くなるほど、時期ごとに違う技術で作られたシステムが並び、それぞれに詳しい人が減っていくのが典型的な状況です。一度にすべてを作り直すのではなく、新規開発の構成を一つに決め、既存システムは変更の頻度、担当者の属人性、セキュリティ更新の停止状況を基準に優先順位を付けて順次寄せていきます。技術の収束は開発チームだけの課題ではなく、採用のしやすさや外部パートナーの選択肢の広さにも影響するため、経営計画の中で年度ごとの目標として扱うのが望ましい進め方です。
個人情報と決済を扱う部分の分離は投資対効果が高い
受講者の個人情報やカードに関わる情報を扱う機能は、事業全体の中でも事故の影響が最も大きい部分です。この機能だけを専用のインフラに置き、更新の権限と手順もほかのシステムから切り離しておくと、日常的な改修が決済の安全性を脅かすことがなくなり、監査や取引先への説明でも整理がつきます。カード番号そのものは自社で持たず、決済代行の仕組みに委ねる形が広く採られています。守るべき範囲を狭く限定することは、セキュリティ投資を抑えつつ水準を高める現実的な方法です。一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。
関連するサービス
関連するインサイト
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開