長く使ってきたシステムを見直すとき、「新しく作り直すか」「そのまま使うか」だけで決めると危険です。既存システムには、画面、データベース、帳票、CSV、メール通知、権限、運用手順、例外対応が積み重なっています。
引き継ぎで最初に見るべきなのは、コードだけではありません。業務とデータです。
初回調査で見るもの
| 領域 | 確認すること |
|---|---|
| 業務 | 誰が、いつ、何を入力し、何を出力しているか |
| 画面 | 管理画面、公開画面、検索、CSV、帳票 |
| DB | テーブル、主キー、外部キー、文字コード、履歴 |
| 認証 | ログイン方式、権限、退職者対応 |
| 外部連携 | API、メール、決済、ストレージ、OAuth |
| インフラ | サーバー、OS、ミドルウェア、SSL、DNS |
| 運用 | バックアップ、ログ、監視、復旧手順 |
| 開発 | リポジトリ、デプロイ手順、依存ライブラリ |
この情報がない状態で「作り直しましょう」と言うと、業務上必要だった例外処理やデータの意味を落とす可能性があります。
選択肢
既存システムの対応は、おおまかに4つあります。
1. そのまま保守する
不具合修正や軽微な改修にとどめる方法です。業務への影響が少なく、費用も抑えやすいです。
一方で、古いランタイム、脆弱な依存ライブラリ、属人化したデプロイ手順が残る場合があります。
2. 部分的に置き換える
帳票出力、検索、管理画面、CSV取込など、問題の大きい部分から置き換えます。
既存のDBや業務を残しながら改善できますが、新旧システムの境界を設計する必要があります。
3. データを移行して作り直す
業務要件を整理し直し、新しいシステムへ移行します。
自由度は高いですが、データ移行、並行稼働、切替、ロールバック、利用者教育まで含めて計画が必要です。
4. 外部サービスへ移す
CMS、SaaS、業務サービスへ移す方法です。
保守負担を下げられることがありますが、既存データの移行、権限、API、帳票、費用、解約時のデータ取り出しを確認します。
データ移行で見ること
データ移行では、テーブルをそのまま移せば終わりではありません。
- 削除済みデータの扱い
- 文字化け
- 添付ファイル
- 重複データ
- 旧仕様の値
- 過去の履歴
- 集計済みデータ
- 外部IDとの対応
- 個人情報の扱い
移行後に「画面は動くが過去データが合わない」という状態になると、業務では使えません。
切替と復旧
本番切替では、戻せる設計が重要です。
現行システム調査
↓
バックアップ取得
↓
試験移行
↓
利用者確認
↓
本番移行
↓
一定期間の並行確認
↓
旧環境の保管・停止切替時刻、停止時間、移行後の確認項目、失敗時の戻し方を事前に決めます。
よくある失敗
- ソースコードだけ見て、業務を見ない
- DBの値の意味を確認しない
- バックアップが取れていると思い込む
- 退職者アカウントや共有アカウントを残す
- 古い帳票やCSV出力を軽視する
- ドメイン、SSL、メール、DNSを最後に思い出す
- 旧システムの停止条件が決まっていない
シオラボならどう進めるか
最初は、動いているものを止めずに調査します。画面、DB、ログ、リポジトリ、運用手順を確認し、残す機能、直す機能、移す機能を分けます。
Rails、PHP、CMS、Excel、外部API、データベースは、業務の流れと合わせて読みます。AIや新しい技術を使う場合も、既存システムのデータと運用を理解していることが前提です。
選定指針
- 業務は安定しているが保守者がいない: まず引き継ぎ調査
- 一部の帳票や検索だけ困っている: 部分置き換え
- 古い環境でセキュリティ更新が難しい: 段階移行
- 業務そのものを変える: 作り直しも候補
- SaaSで十分な業務: 外部サービス移行も検討
既存システムの引き継ぎは、古いものを延命する仕事ではありません。業務とデータを読み解き、次の運用へつなぐ仕事です。