TL;DR
- 具体的な数値や実例を用いた事前準備で、“説得力” のある合意形成を実現
- リプレイス専任チーム体制の構築で、“推進力” を確保
- 段階的リリースで “影響を局所化” し、リスクを最小化
- 不要コードの早期削除によって、“既存仕様の調査コスト” を削減
- プロセス標準化により、“品質と速度” を両立
- リプレイス目的の達成基準を明確にし、“曖昧さ” を排除
- 改善タスクを定期的に実施し、“技術負債” を着実に解消
はじめに
こんにちは、リプレイスチームでバックエンドをメインに担当している内藤です！
私は、これまで1年ほど Web アプリケーションのリプレイスプロジェクトに携わってきましたが、その過程で「やって良かった」と実感できる取り組みを多く得ることができました。
リプレイスに関する技術的な情報は世の中に多くありますが、プロセスにフォーカスした話は意外と少ないと感じています。実際、我々も最初は「どう進めれば上手くいくんだろうか？」と悩むことが多かったです。
そこで本記事では、現場での経験をもとに、特に効果的だった7つのポイントを厳選してご紹介します。「これからリプレイスに取り組む方」や「現場でのヒントを探している方」が、少しでも迷いなく前進できる材料になれば幸いです👋
前提
今回リプレイス対象となったのは、CakePHP × jQuery で構築されたレガシーな Web システムで、NestJS × Next.js を用いたモダンな構成へと置き換えることになりました。このシステムは、レバテックにとって事業の中核を担うシステムであり、日々の業務遂行に欠かせない重要な基盤となっています。
主なリプレイスの理由は、以下の2点です。
- サポート切れ技術の利用によるセキュリティリスク
- 変更容易性の低さによる開発速度の低下
なお、刷新対象は約20画面に及び、比較的大規模なリプレイスプロジェクトとなっています。
ここからは、こうした背景のもと、実際にどのようにリプレイスを進めていったのか、具体的な取り組みや工夫についてご紹介していきます。
その1. 事前準備で “説得力” を持たせる
リプレイスプロジェクトを始める際、最初に越えるべき壁は「なぜ今リプレイスが必要か？」を社内で納得してもらうことです。ここで重要なのは、抽象的な説明ではなく、具体的な数値や実例を用いて説得力を持たせることです。
まず、我々はリプレイスを行わなかった場合に発生し得るリスクを明確に示しました。たとえば、直近でどれだけのセキュリティリスクが潜んでいるか、そしてそのセキュリティリスクが実際に突かれた場合に事業へどの程度の影響が及ぶかという観点で、現状を整理しました。（※ 我々は金額面での損失試算までは行いませんでしたが、必要に応じてそうした定量的な試算も有効だと考えています。）
さらに、変更容易性の低いシステムが事業に与える影響についても、既存コードを分析し、どの部分が変更容易性を下げているのかを具体的に整理しました。その上で、「コード品質が低いとバグが15倍多発し、問題解決にかかる時間が2倍以上に増加する」といった研究結果などの客観的データを交えて説明することで、納得感を高めました。
加えて、既存システムの現状を正確に把握するために、コードの複雑さや依存関係を詳細に調査し、その調査結果を基にリプレイスに必要な期間や工数の大まかな見積もりも作成し、関係者に提示しました。
これらの情報を総合的に示すことで、「リプレイスを実施しなかった場合のリスク」と「リプレイスに投下するべきリソースや期間」のバランスを関係者が具体的にイメージできるようになり、プロジェクトの必要性や緊急性を納得してもらうことができました。リプレイス推進の土台を固めるうえで、最初にこの「腹落ち感」を得ることが、後のプロジェクト進行にも大きく寄与したと感じています。
その2. 体制づくりで “推進力” を確保する
当初、我々のチームはリプレイスを進めたいと思いながらも、日々の運用保守業務と並行して対応していたため、どうしてもリプレイスの優先度が下がり、後回しになってしまうことが多々ありました。おそらく、同じような状況に悩んでいる方も少なくないのではないでしょうか？
こうした状況を受けて、「グループリーダーが現場の声を開発部全体に届けてくれたこと」、そして「リプレイスが開発部の年度最優先課題として位置づけられていたこと」も後押しとなり、他チームとの人員リソース調整が進み、最終的には「リプレイス専任のチーム」を立ち上げることができました。専任チームの発足により、リプレイスに必要な意思決定や作業のスピードが格段に向上し、それまで停滞しがちだったプロジェクトも着実に前進するようになりました。
役割を明確に分担し、専任チームがリプレイスの推進力となる体制を築いたことは、プロジェクト成功の大きな要因だったと感じています。もし今、日々の業務とリプレイスを兼任で進めている方がいれば、ぜひ一度「専任体制」の導入を検討してみてください。（そんな簡単な話ではないとは思いますが...
その3. 段階的リリースで “影響を局所化” する
リプレイスを進める上で、私たちは一度に全てを切り替えるのではなく、画面単位で区切って段階的にリリースする「ストラングラーフィグパターン」を採用しました。これは、既存システムの一部機能を新しいシステムに少しずつ置き換えていくことで、全体の移行リスクを抑えつつ、現場への影響を最小限にとどめる手法です。
今回 ProxyLayer として ALB を使って新旧リクエストを振り分けることでストラングラーフィグパターンを実現しました。その上でユーザ影響が少なく比較的リプレイスしやすい機能（FAQ や問い合わせフォームなど）から着手し、問題がなければ次の対象へと範囲を広げていきました。これによって各リリースごとに影響範囲を明確にコントロールでき、トラブル発生時も迅速な対応が可能になりました。
この「影響の局所化」によって、現場の心理的な安心感も生まれ、結果的にプロジェクト全体の推進力にもつながったと感じています。
その4. 不要コードの早期削除で “既存仕様の調査コスト” を減らす
リプレイスを進める中で、改めて実感したのが「不要なコードはできるだけ早く削除すること」の重要性です。
我々のチームは、まずアクセスログをもとに、過去半年間一度も利用されていない API を洗い出しました。さらに、その API が本当に呼び出されていないかを確認するため、対象 API に追加でログを仕込み、2ヶ月間ログ出力がないことをチェックした上で削除を進めました（我々のサービスは1ヶ月で1サイクル機能が利用されるため、2サイクル未使用なら問題なしと判断）。また、リプレイスが完了した箇所についても同様の手法で古いコードを速やかに削除し、現段階で約30本の API / 1,500行のコードを削除しています（まだ削除できそうなところはたくさんありますが…）。
このように、不要なコードを減らしたことで、リプレイスチームにとっては移行対象の機能が把握しやすくなっただけでなく、運用保守チームにとっても管理すべき範囲が明確になり、障害対応やメンテナンスの際に本来不要なコードを気にする必要がなくなるなど、副次的な効果もありました。
リプレイスのタイミングで不要コードを積極的に削除し、運用対象をスリムに保つことは、プロジェクトの健全な推進と現場の負荷軽減に直結する有効な施策だと実感しています。
その5. プロセス標準化で “品質と速度” を両立する
リプレイスを効率的に進めるためには、「プロセスの標準化」が不可欠だと感じています。特に複数人で作業する場合、各メンバーが独自の進め方をすると、認識のズレや無駄な手戻りが発生しがちです。
私たちが定義した標準プロセスは、外部仕様調査 → 内部仕様調査 → 要件定義 → ドメインモデル図作成 → シーケンス図作成という一連の作業内容の目的や手順、流れをテンプレート化したものです。以下にサンプルで外部仕様調査プロセスの例を示します。
このように各フェーズにおいて、目的、やること、成果物、メンテナンス要否などを明示して管理しています。主旨からはズレますが、「メンテナンス要否」を定義しているのも実はこだわりポイントです。ドキュメントが形骸化して、当事者がいなくなったとき、「チームとして何をメンテナンスしていくべきなのか分からない」というのは本当によくある話なので…😢
この標準化によって以下のようなメリットが得られました。
- 品質の均一化: 一貫したプロセスでプロジェクト間のばらつきを削減し、品質を均一に保つ
- 明確な指針: 各フェーズの作業内容を可視化し、混乱や誤解を防ぐ
- 効率的なプロジェクト管理: 進捗管理やリソース配分、リスク管理を効率的に行う
さらに重要なのは、「プロセスをチーム全員で改善し続ける仕組み」を作ったことです。我々は、画面単位でのリプレイス完了後の振り返り会において、随時テンプレートを更新しており、これにより標準プロセスが形骸化せず、常に現場の実態に即した最適なプロセスを維持できています。
こうした標準化と継続的な改善の積み重ねが、品質を守りつつ、無駄なくリプレイスを前進させる大きな力になっていると感じてます。
その6. リプレイス目的の達成基準を明確にし “曖昧さ” を排除する
リプレイス後の評価は、「保守性が上がっているはずだ」「セキュリティリスクは減っているだろう」といった定性的な表現に偏りがちですよね。我々のチームもこの定性的な評価にモヤモヤを抱えていました。そこで、完了基準を「出来る限り定量的」に設定することを重視しました。
まず内部品質については、SonarQube for IDE の指摘事項がゼロであることを最低限の基準にしています。SonarQube for IDE は、IDE 上でリアルタイムにコード品質をチェックできるので、バグやセキュリティリスク、コードスメルをその場で検出・修正でき、日々のコーディング段階から品質を高めるのにとても役立っています。
もともとリプレイス前のコードベースでは、「Maintainability（保守性）」の Severity（深刻度）が Blocker や High（参考）の指摘が合計で約5,000件ありましたが、現状ではそれを0件まで抑えることができています。
また、セキュリティ面では、AeyeScan というクラウド型の Web アプリケーション脆弱性診断ツールを CI に組み込み、リリース前のチェックを必須としています。AeyeScan は、Web アプリケーションに対して自動で脆弱性診断を実施し、SQL インジェクションや XSS などの主要な脆弱性を検出できるサービスです。CI/CD パイプラインに組み込むことで、開発中から本番リリース前まで一貫してセキュリティチェックが行えるため、ヒューマンエラーによる脆弱性の見逃しを防ぐのに非常に有効です。
このように、定量的な基準を明確にすることで、「自信を持ってリプレイスが完了したと言える状態」を実現できています。曖昧な評価基準のままだと、具体的に何が良くなったのかが分かりづらくなってしまうので、こうした明確な完了基準の設定は重要だと考えています。
その7. 改善タスクを定期的に実施し “技術負債” を解消する
リプレイスを進めている最中でも、どうしても技術負債は一定のペースで溜まっていきます。 だからこそ、リプレイスとは別に、その過程で新たに生まれた負債も定期的に解消することが重要だと感じています。
我々のチームでは、画面単位でリプレイスを進めていますが、各画面のリプレイスが完了するタイミングで、2週間ほど改善タスクに集中する期間を設けています。たとえば直近では、CI の実行時間短縮やフレーキーな CI の改善、テスト間の依存関係の排除によるテストの独立性向上など、日々の開発効率や品質に直結する改善に取り組みました。
実際にリプレイスを進めてみると、どれだけ設計や準備をしても、新しいシステムにもやはり完璧ではない部分が出てきます。「リプレイス作業の合間に時間があればやろう」と有耶無耶にするのではなく、「リプレイスの節目ごとに改善にしっかり時間を割り当てる」ことで、新たな負債の蓄積を防ぎ、チーム全体の開発体験も向上しました。結果的に、リプレイス作業自体もよりスムーズに進むようになったと実感しています。
おわりに
今回は、1年間のリプレイスプロジェクトで「やって良かったと実感した7つのポイント」をご紹介しました。
リプレイスは技術的な挑戦だけでなく、チーム体制やプロセス、そして関係者との合意形成など、様々な側面での工夫が求められる複雑なプロジェクトです。我々も最初は手探り状態でしたが、この記事で紹介したような取り組みを通じて、着実に前進させることができたと実感しております。
プロジェクトごとに状況は異なりますが、この記事が少しでも皆さんがリプレイスプロジェクトに取り組む際の参考になれば幸いです👋
Discussion