古い管理画面を業務を止めずに改善する進め方
「担当者が変わるたびに『この画面、実は使ってない項目が半分ある』と言われる」「新しい機能を1つ足すだけなのに、既存のどこに影響が出るか誰も把握していない」「フレームワークのバージョンが古すぎて、簡単な修正すら躊躇する」——長年運用してきた社内管理画面について、こうした相談をよく受けます。
管理画面は顧客の目に触れないため、事業側の優先順位が上がりにくく、気づけば5年・10年と大きな手を入れないまま継ぎ足しを重ねている会社が少なくありません。その結果、画面ごとに実装方針がバラバラ、使われなくなった機能が残ったまま、新機能を1つ足すのに数週間かかる——という状態に陥ります。厄介なのは、この画面を止めて作り直す時間的余裕がほとんどのケースで無いことです。この記事では、業務を止めずに古い管理画面を段階的に改修する進め方を整理します。
「継ぎ足しレガシー」の管理画面に共通する症状
古い管理画面が抱える問題は、遅さのような単一の症状ではなく、複数の問題が絡み合っていることがほとんどです。
- 実装方針がバラバラ: 担当者が変わるたびに違う書き方・違うライブラリが追加され、同じような機能が画面ごとに別の作り方で実装されている
- 使われていない機能が残り続ける: 過去の業務フローの名残で誰も使っていない画面・項目が残っており、新しく入った担当者が「消していいのか」判断できず放置されている
- 依存ライブラリ・フレームワークが古い: セキュリティアップデートが止まったバージョンのまま動いており、新しいライブラリを入れようとすると衝突する
- 仕様がコードにしか残っていない: なぜこの項目がこの画面にあるのか、ドキュメントが無く聞ける人もいない状態になっている
- 触るのが怖い: テストが無い・影響範囲が読めないため、簡単な修正でも「触ったら別のところが壊れるのでは」という不安から着手できない
これらは個別に直そうとすると際限がなく、かといって全面刷新は現実的な予算・期間に収まらないことが多いです。まずは症状を一覧化し、どれが業務に実害を及ぼしているかを切り分けるところから始めます。
全面刷新ではなく段階改修を選ぶ理由
「もう限界だから作り直そう」という判断は一見わかりやすいですが、実際には大きなリスクを伴います。
- 業務が止まる: 全面刷新には数ヶ月〜1年以上かかることが多く、その間も日々の業務は止められない。並行運用や移行期間が発生し、かえって負荷が増える
- 仕様の取りこぼし: 長年の運用で積み重なった「実は重要な例外処理」がコードの中にしか残っておらず、作り直す過程で見落として本番トラブルになる
- 予算が読みにくい: 全体を一度に作り直す見積もりは規模が大きいほど不確実性が増し、想定より膨らみやすい
こうしたリスクを避けるため、私たちが基本方針として提案するのは段階改修です。稼働中の画面はそのまま動かしながら、業務インパクトの大きい箇所から順にリプレイスまたはリファクタリングしていきます。裏側の技術基盤(Railsのバージョンアップやデータベース設計の見直しが必要な場合はそちらも参照)を並行して整えつつ、画面単位で少しずつ置き換えることで、業務を止めるリスクを最小化しながら着実に前に進められます。
業務動線から優先順位をつける
段階改修を進める上で最も重要なのが、「どこから直すか」の順番です。技術的にきれいに直せる箇所と、業務インパクトが大きい箇所は一致しません。
- 利用頻度の高い画面から着手する: 月に数回しか開かない管理画面より、毎日複数人が使う受発注・顧客対応画面の改善効果が圧倒的に大きい
- 業務の詰まりどころを聞き取る: 「本来この画面でできるはずの作業を、別のExcelやスプレッドシートで代替している」箇所は、UIの使いにくさが業務プロセスを歪めているサイン
- 新機能追加の頻度が高い領域を優先する: 今後も改修が続く見込みの画面は、早めに整理しておくほど後続の開発コストが下がる
- リスクの高い画面を後回しにしない: 影響範囲が読めず誰も触りたがらない画面ほど、実は放置コストが一番高い。優先度は低く見えても計画に含めておく
私たちは着手前に、実際にその画面を使っている現場担当者へのヒアリングを必ず行います。開発側の目線だけで「技術的にきれいな設計」を優先すると、現場の業務フローと噛み合わない改修になりがちだからです。
技術改善とUX改善は両輪で進める
古い管理画面の改修は、コードを新しいフレームワークに移植するだけでは終わりません。
- 技術改善: 古いフレームワーク・ライブラリの更新、実装方針の統一、テストの追加による安全な変更の担保
- UX改善: 継ぎ足しで生まれた無駄な入力項目の削減、業務フローに沿った画面遷移への整理、頻繁に使う操作への導線短縮
技術基盤だけを刷新して画面のUIをそのまま移植すると、「新しくなったのに使いにくさは変わらない」という結果になりがちです。逆に見た目だけ整えても、裏側が古いままでは次の改修がまた同じ苦労になります。私たちは改修に入る前に、現場の業務フローを一緒に整理し、技術的な作り直しと画面設計の見直しを同じ計画の中に含めるようにしています。
外部に依頼するときの進め方
管理画面の改修を外部チームに依頼する場合、いきなり実装に入らず、次の順番で進めるのが安全です。
- 現状の棚卸し: 画面・機能の一覧化、使用頻度、依存ライブラリのバージョン、テストの有無を確認する
- 業務ヒアリング: 実際に使っている担当者から、業務フロー・困りごと・不要になった機能を聞き取る
- 優先順位の合意: 業務インパクトと改修コストを突き合わせ、着手順を発注者と合意する
- 段階的なリリース: 画面単位・機能単位で小さくリリースし、都度動作を確認しながら次に進む
この進め方は、既存プロダクト改善で外部チームが最初に見る観点で解説している全体診断の考え方と地続きです。特に「遅さ」が主症状の場合は遅い管理画面の改善も参考になります。私たちはこうした改修をモダナイゼーションや保守・運用のサービスとして提供しており、Rails/React/Next.jsなどで運用中のプロダクトへの改修実績があります。
まとめ
- 古い管理画面の問題は「遅さ」のような単一症状ではなく、実装方針のばらつき・不要機能の残存・古い依存関係が絡み合っている
- 全面刷新はリスクが大きく、業務を止めずに画面単位で少しずつ置き換える段階改修が現実的
- 優先順位は技術的な直しやすさだけでなく、利用頻度や業務の詰まりどころといった業務動線から決めるべきで、技術改善とUX改善は両輪で進める必要がある
「触るのが怖くて何年も手を入れていない管理画面がある」という状態でも、まずは現状の棚卸しから始められます。torcheees では1〜4週間の「既存プロダクト診断」で改修の優先順位と概算費用をご提示します。継続的な改善支援も承っています。お問い合わせフォームからお気軽にご相談ください。