はじめに
こんにちは。楽楽明細開発チームのtkktです。
楽楽明細は2013年のサービス開始以来、10年以上の運用を続け、現在では1万を超えるお客様にご利用いただいています。
しかし、この成長の裏側では、長年の機能追加や複雑化による技術的負債が蓄積し、
新機能追加のたびに調査やテスト工数が増大するなど、サービスの成長スピードを阻害する課題に直面していました。
今回は、その課題を乗り越えるために取り組んだシステム刷新の一部をお話ししたいと思います。
目次
刷新の背景
長年の運用により、システムには以下のような課題が生じていました。
古いフレームワーク利用によるリスク
- サポート終了が迫り、セキュリティリスクが高まっていた
- 周辺のミドルウェアやライブラリのバージョンアップも妨げられていた
開発効率の低下
- 度重なる機能追加によりコードが複雑化
- 影響調査やテストに多くの工数が必要
- 本番環境での障害やインシデントも少なくなかった
- 当初の開発メンバーが離職しており、仕様把握が難しくなっていた
顧客数増加による影響
- 操作の多様化でこれまで出なかった不具合が顕在化し、障害対応工数が増加
- クラスタ数の増加でリリース時間も長くなっていた
さらに、手動テスト中心だったため、開発全体の工数に占めるテスト工数の比率が大きくなり、改善活動に時間を割けない状況もありました。
こうした背景から「今後の安全性・開発効率を確保するには刷新が必須」となり、プロジェクトが動き出しました。
実際の取り組み
刷新の第一歩として、利用者が限定的な一部機能を対象にしました。
セキュリティリスクが高く、既存システムからの切り離しが容易だったためです。
移行は二段階で実施しました。
- 第1弾：既存アプリ内の処理を新フレームワークに書き換え、まずは安定稼働を実現
- 第2弾：本体アプリから切り離して独立稼働させ、フロントで受けたリクエストを新アプリに振り分ける構成に変更
この二段構えにより、障害や不具合発生のリスクを抑えつつ、新基盤への移行を進めることができました。
リリース後の課題と改善
第1弾リリース直後には、想定外の問い合わせや不具合対応に苦労しました。
特に、利用者環境に依存する問題（ブラウザ拡張機能やセキュリティソフトの影響など）が発生し、リクエストがアプリに届かないケースでは原因調査に時間を要しました。
チームでは、問い合わせいただいたお客様に協力いただき、スクリーンショットやコンソールログを取得して原因を特定するなど、地道な調査を重ねました。
その経験を踏まえ、以降はフロントエンドの操作状況やエラーを分析できる仕組みを導入。さらに次の段階では、システムの監視基盤を強化し、不具合の早期発見と原因特定をしやすくする取り組みを進めています。
成果と効果
刷新の効果は、コード品質やテスト体制の改善に顕著に表れています。
コードの複雑度が大幅に改善
- 刷新前は数十クラスで「変更すると誤修正を招きやすい」と評価される状態
- 刷新後はそうした箇所がほぼ解消され、多くのクラスが低い複雑度に
テスト体制の強化
- リリース前はテストの大半が手動で、カバレッジは全体で30％程度
- 刷新部分では自動テストを整備し、カバレッジが80％を超える水準に向上
- フロントエンドとバックエンドを分離したことで、テストのしやすさも格段に向上
刷新直後は不具合対応が発生しましたが、マイナーリリースを重ねて早期に収束。現在ではアプリケーション起因の不具合は減り、安定性が高まっています。
今後の展望
刷新はまだ道半ばです。
今後は、サポートが終了していくフレームワークやライブラリを計画的に置き換えるとともに、アーキテクチャの刷新にも取り組んでいきます。
機能や要件によっては、新しいサービス基盤への移行も視野に入れています。
また、アプリケーションの稼働環境についても改善を進め、より柔軟かつ効率的に運用できる仕組みを整備する予定です。
さらに、組織全体としてもAIを積極的に活用しており、刷新の過程でも開発効率化や品質向上に役立てていく方針です。
まとめ
今回紹介した取り組みは、まだ刷新プロジェクトの一部に過ぎません。
今後も継続して改善を進め、お客様により安心して利用いただけるシステムを目指すとともに、開発者にとっても挑戦しがいのある環境を築いていきます。
