レガシーなアプリケーション基盤を丸ごとストレートコンバージョンしてみた

こんにちは。
RSSでWebアプリケーションを開発している、新卒3年目のK.S.です。
今回は、とあるレガシーアプリケーションの基盤を刷新したお話をしたいと思います。

現在の業務内容

私は現在、グループ会社のとある事業部のアプリケーションの開発に携わっています。未経験で入社し、これまではPHPで書かれたアプリケーションを中心に担当してきました。それは、その事業部のサービスに興味のある法人の方だけでなく、個人の方からもお問い合わせいただく窓口として使用しているアプリケーションです。そのため、個人情報を多く取り扱っています。

行ったこと

「入社1年目社員が社内のレガシーDBを克服する中で見えたRSSの強みとは」や「2025年の崖を越えて~レイスグループの挑戦と展望~」という記事でも取り上げていますが、当社にはレガシーなアプリケーションがまだ残っています。私が担当する事業部は歴史が古いため、使用しているアプリケーションはレガシーなものも多く、今回取り上げたアプリケーションもそのうちの一つでした。

会社全体として改善していこうと動いており、担当する事業部のアプリケーションはこの先、更改も見据えています。今回のアプリケーションは規模が小さく依存関係も少なかったため、新しいことに挑戦しやすい状況でした。そこで、先駆けて改善に動くことになりました。その際に、ただ最新のバージョンにあげるのではなく、新しい技術を導入して刷新しようという話になりました。
刷新後の状態は下記です。

Debian 12
Django 5.2
Python 3.13
MySQL 8.0
Google Cloud / Cloud Run（PaaS構成）

刷新前はPHPの古いWebフレームワークを使用しておりました。社内ではPHPのWebフレームワークであるLaravelの使用事例が多いため、言語はPHPのままLaravelに移行する案もありました。PHPのバージョンやWebフレームワークが変わるため、全て書き直す必要があることは避けられません。そのため、短絡的に「言語を変えず刷新する」という判断は避けました。担当事業部の他アプリケーションにもたらすメリットや、自社の採用方針を考慮し、Pythonの採用を決断しました。PythonのフレームワークとしてDjangoとFlaskが社内では使用されていますが、開発者である私がPythonに触れたことがないことから、Djangoを選択しました。フルスタックフレームワークであること、参考資料が多い点を踏まえた結果です。インフラ管理など運用面での負担削減も考え、刷新後のアプリケーションはPaaS化しました。加えて、GitHub Actionsを活用してCI/CDを導入しました。

難しかった点

実際に刷新に向けて動き出した際に苦戦した点は下記です。

担当事業部との認識の調整
シナリオテストの作成
新技術の導入

それぞれ具体的にどのような点で躓いたのかを説明します。

1. 担当事業部との認識の調整

旧アプリケーションには各種設定を行う管理機能がありましたが、ここにセキュリティ上の課題がありました。アクセス制御がなく社外からもアクセス可能な状態で、さらに事業部内で一つの共有アカウントを用いていました。

この問題を解決するため、個人情報保護の観点から「本当に必要な機能は何か」を事業部と調整しました。私にとって初めてのユーザー折衝だったため、会議の進行や内容説明の準備段階で大きなプレッシャーを感じました。
対話を重ねた結果、実際に使われている機能はごく一部だと判明し、実装すべき機能を大幅に削減できました。
これは、最終的に開発期間の短縮にも繋がる大きな成果でした。

2. ゼロからのシナリオテスト作成

今回の目的は、既存の機能をそのまま新しいアプリケーションで再現する「ストレートコンバージョン」でした。そのため、特に外部に公開されている部分では、旧アプリケーションの挙動を完全に再現する必要がありました。

旧アプリケーションにはシナリオテスト仕様が存在しなかったため、今回ゼロから作成することになりました。画面上の文言やボタン、リンクの挙動までくまなく調べ、文字に起こす作業は骨が折れました。特に、同じフォームでも画面によって入力欄の文言が微妙に違うなど、細部の確認に大変な時間を要しました。

地道な作業ではありましたが、この過程でハードコーディングが原因のリンクエラーなど、旧アプリケーションが抱えていたバグを発見できました。これは大きな副産物でした。

3. 未経験の新技術導入

このプロジェクトでは、社外公開のアプリケーションとしては自社初となるCloud Runを用いたPaaS化や、GitHub Actionsによるデプロイの自動化に挑戦しました。

これまで経験のなかったフォーマッタやリンタ、ユニットテストといった仕組みを導入しました。言語、インフラ、開発プロセスと、多くのことが同時に変わったため、それらを調整しながら進める作業は非常に時間がかかりました。
多くの挑戦がありましたが、そのおかげで、これまで課題だったリリース時の品質を担保できるようになったことに、大きなメリットを感じています。

アプリケーション刷新がもたらした3つの大きな改善点

今回の取り組みを通して得られた、特に大きなメリットは以下の3点です。
それぞれ具体的にご説明します。

保守性を高める依存関係の削減
迅速な障害対応を可能にするログの一括監視
セキュリティを強化する機密情報の保護

1. 保守性を高める依存関係の削減

旧環境では、1台のVMインスタンスに複数のアプリケーションが同居しており、OSをアップデートする際に他のアプリケーションへの影響を考慮する必要がありました。

今回のPaaS化により、アプリケーションごとにOSを独立して管理できるようになりました。そのため、他を気にすることなく継続的なアップデートが行えます。実際に、開発段階でDockerのベースイメージを変更するだけでPythonとOSのバージョンを容易に変更できました。今後の保守性の高さを実感しています。

2. 迅速な障害対応を可能にするログの一括監視

従来は、ログがサーバー上のファイルに書き込まれるだけで、エラーを即時検知する仕組みもありませんでした。
新環境では、ログをCloud Loggingに集約し、エラーレベル以上のログを検知した際にはメールで自動通知する仕組みを構築しました。このおかげで、リリース直後に発生したエラーも即座に検知・対応でき、サービスの安定運用に大きく貢献しています。

3. セキュリティを強化する機密情報の保護

今回の刷新を機に、機密情報は Secret Manager で厳密に管理し、運用担当者のみがアクセスできる状態へと変更しました。外部に公開しているサービスだからこそ、この安全な状態を実現できたことは、何よりの成果だと感じています。

今後

今回、規模は小さいながらーつのアプリケーションが刷新できたことで、同じく社内の小規模なレガシーアプリケーションが刷新に向けて動き始めています。その際に、今回私が実装したアプリケーションを参考にしているプロジェクトもあります。社内でも先駆けて改善に向けて動けたことは、組織への影響という面も含めて大きな成長の機会だったと感じています。

今後は担当事業部のアプリケーションも少しずつ刷新に向けて動いていく予定です。その中で、今回の経験を踏まえ、チームの開発生産性向上に貢献していきたいと思います。