📑
管理画面リニューアルで、脆弱性対策&高速な開発環境を実現

kkaznor1
2025/03/12に公開
こんにちは、GENIEE CHAT機能開発チームリーダーの鎌原です。
GENIEE CHATでは現在、管理画面のリニューアルプロジェクトが進行中です。
デザインそのものもモダンに変わっていますが、それ以上にライブラリやディレクトリ構成などが大きくブラッシュアップされました。

本記事では、この移行のプロジェクトの概要と気をつけたポイントや学んだこと・反省点等をご紹介させていただきたいと思います。

 移行プロジェクトの概要移行前の管理画面には主に2つの課題がありました。

 1. 脆弱性の更新対象のパッケージが多く、手間がかかる弊社ではプロダクトの脆弱性を定期的に確認して、都度対応を行っております。

GENIEE CHATの管理画面だけでも対象のパッケージが2,300件ほどあり、脆弱性が発生する可能性が高く、対応パッケージが多く保守工数を逼迫してしまう問題がありました。

 2. 機能開発を行う際の影響範囲が大きい新機能の開発やUI改善を行う上で既存で使用しているライブラリの更新対象が非常に多く影響範囲が全体に及んでしまう問題です。

プロジェクトの開始前の時点で、機能要望としてメイン機能であるシナリオ画面のUI改善がありましたが、改善するにはライブラリ自体を変更して画面全体を作り直す必要がありました。

また、管理画面全体で使用されているテンプレートの修正が必要でシナリオ画面だけでなく、画面全体の更新も行う必要がありました。
対処としては以下の二つを考えました。
機能開発毎にリファクタリングを行い、機能開発毎にアップデートしていく
管理画面をリプレースする
結論としては、2の管理画面をリプレースすることに決めました。

リプレースの方が楽しそうというのも気持ちとしてはありますが、
シナリオ画面のリファクタリングは見積もりとして年単位でかかり、リプレースとほぼ影響範囲、工数が変わらない
追加でReactのバージョンアップやモジュールバンドラの変更を行うことを考慮すると、リプレースより工数がかかる
など投資対効果を見て元が取れるという判断です。

リプレースには一定リスクがあり、失敗するリスクを回避をするため、移行の流れを検討することになりました。

 移行の流れと進捗移行手順の大きなテーマとしては、旧管理画面を稼働しながら、新管理画面へのスムーズな移行を可能にするということになります。

そのうえで、下記の4つの点を注意しました。
バックエンドAPIはそのまま維持しつつ、画面だけの変更に開発スコープを絞る。
旧管理画面に慣れているCSチームはじめ多くユーザーとのトラブルを防ぐため、移行期間を長めにとり、段階的な移行を実施する。
管理画面移行中の機能開発は止めない。新管理画面の下地ができた時点で旧管理画面の機能開発をコードフリーズし、新管理画面に1本化することで、二重開発を防ぎつつ、移行を促進する。
後方互換性の徹底。旧管理画面で保存されたデータを問題なく、新管理画面でも扱えることをレビューやテスト等で確認するように徹底しました。
続いて具体的な移行手順についてです。

新しい新管理画面用の環境を用意した上で、移行のフェーズを下記の6つに分けました。
Phase 1: 新管理画面へのルーティング設定を追加する。これにより、URLを知っている人のみがアクセスできるようになります。
Phase 2: フェーズ2、旧管理画面に新管理画面へのリンクを追加。これにより画面上から新管理画面へのアクセスが可能になります。
Phase 3: デフォルトの遷移先を新管理画面に変更。これによりログイン認証後の遷移先を新管理画面に変えることで、ユーザーのデフォルト利用の管理画面が新管理画面となります。
Phase 4 (サービスアウト手順1): 旧管理画面へのリンクを削除。ここから画面上で旧管理画面にアクセスができなくなります。
Phase 5 (サービスアウト手順2): ルーティング設定を削除し、URLを知っていてもアクセスができなくなります。
Phase 6 (サービスアウト手順3): 開発リソースの削除する。
現時点では、Phase 3まで完了しており、旧管理画面のリソース削除に向けて現在対応中となります。

 成果
 脆弱性改善脆弱性改善についてですが、これだけありましたライブラリの脆弱性ですが、Criticalは一つもなくなり、また対象パッケージ数も4分の1まで減らすことができました。

 開発環境改善モジュールハンドラをwebpackからviteに変更したこともあり、全体的に高速化されています。概算ですが、ローカル環境での起動にかかる時間は、30秒から1秒に短縮されています。開発時のHot reloadの速さも 20秒から 1秒に短縮され、ビルド時間も 53.18秒から 17.90秒に改善されています。

定性的にも、ディレクトリ構成がわかりやすく整理されており、編集箇所や影響箇所が改善されております。また、使っているライブラリも新し目のものが多いので開発していても楽しく、学べる物が多いと実感しています。

管理画面の新規機能による開発も進んでおり、ある開発では、これまでCSの方が1時間以上掛かっていた作業を1分強で完結できるようになるような機能も作られております。

 振り返り・反省点このプロジェクトを通しての反省になります。

よかったと思った点は以下のとおりです。
スピード感のあるコミュニケーション：PMが後手に回ってしまうと開発も遅くなってしまうので、とにかく早く潰すことが割とできたと思います。
見積もり逆算意識：締切を明確に意識しつつ、見積もりにはバッファーをつけることで、期日までの納品を問題なく達成することができました。
意思決定の経験値を積めた：個人的なことではありますが、意思決定をする経験値を積むことができました。もちろん小さな失敗を重ねることはありますが、かなり良い経験値となりました。
改善ができたと思った点としては、大きく分けて、チケット管理ツールとAIツールの活用方法に伸び代があると感じました。
まず、JIRAとスプレッドシートのタスクの二重管理が起きてしまっていました。ビジネス側からのレビューシートや細かい修正要望をスプレッドシートで管理しつつ、進捗自体はJIRAでも管理をしていた関係で、ここの非効率さが出てしまったと思っています。また、ステータスと実工数の管理が甘く、振り返りをした際に定性的な情報ベースでの振り返りがメインとなってしまっているので、もっと定量情報を収集できたのではないかと思っています。
またAI系のツールの活用も、今後進めることができればと思っています。チケット管理やテスト項目の過不足チェックなど、効率化の余地はあると思っています。

 今後の展望プロジェクトの今後として、チームとしては旧管理画面リソースの完全削除と新管理画面での機能開発を進めていきます。（先程共有したすでに2つある脆弱性についても潰していきます）
また個人的には、技術力はもちろん、マネジメントやビジネス思考など掛け算的にこれからも伸ばしていき、自分自身と開発・ビジネスチームの生産性の向上により貢献していきたいと考えています。