現行システム調査で確認すべきポイント：何を・どの順で・どこまで把握するか

古いシステムの保守を引き受けるとき、リプレースの前に現状を把握するとき、障害の原因を調べるときなど、いずれの場面でも最初に行うのは「現行システムを調査する」ことです。

ただ「調査する」と言っても、何から確認するか、どこまで把握すれば十分か、という判断は意外と難しいものです。この記事では、現行システム調査で確認すべき項目を、優先順位とあわせて整理します。

調査の目的を最初に決める

調査を始める前に、「何のために調査するか」を明確にしておくことが重要です。目的によって、確認すべき項目の優先順位が変わります。

保守・引き継ぎが目的 — 担当者が変わっても対応できる状態を目指す。コードと運用手順の把握が優先
リプレースの判断が目的 — 機能の全体像とデータ構造の把握が優先
障害調査が目的 — 問題の発生箇所と原因の特定が優先。全体を広く見るより深く追う

目的が複数ある場合は、まず「保守・引き継ぎ」を優先させると、他の目的にも使える情報が積み上がります。

確認すべき項目

1. 動作環境とインフラ構成

まず「システムがどこで動いているか」を押さえます。コードより先にインフラを確認する理由は、環境が把握できていないと、コードを読んでも動作確認ができないためです。

OS・ミドルウェア・言語のバージョン
サーバ構成（Web・AP・DB が同一サーバか分離しているか）
デプロイ方法（手動か自動か）
バックアップの有無と方式
監視・アラートの有無

特にバージョンは重要です。PHP 5 系・MySQL 5.5 など、サポートが終了した構成はそれだけでリスクの所在を示します。

2. コードの全体構成とエントリーポイント

次にコードの構成を把握します。全体を読む前に「どこから読み始めればよいか」を見つけることが先決です。

ディレクトリ構成とファイルの役割分担
リクエストの入口（フロントコントローラ・ルーティング）
設定ファイルの場所と内容
外部ライブラリ・依存関係の管理方法

フレームワークを使っていればその規約に沿って読めますが、フレームワークなしの古い PHP などは、index.php から require を追っていく必要があります。

3. データベース構造

業務ロジックの多くはテーブル設計に現れます。コードと並行して確認します。

テーブル一覧と主要カラムの意味
テーブル間の関係（外部キー制約の有無にかかわらず）
データ量の規模（行数・容量）
インデックスの設計状況

外部キー制約がなく、コードの中で結合関係を管理している場合は、コードを読まないとテーブル間の関係がわからないことがあります。逆に、コードを読んでいてもテーブル設計が見えないと処理の意味が掴みにくい。両方を並行して確認するのが現実的です。

4. 外部連携

他のシステムやサービスとの接続は、変更時の影響範囲を考える上で重要です。

外部 API の呼び出し先（URL・認証方式）
メール送信の仕組み（SMTP サーバ・送信元アドレス）
ファイル連携（CSV 取り込み・出力先）
決済サービス・物流システムなどの外部サービス

外部連携は変更が難しく、リプレース時に移行が複雑になりやすい部分です。早めに把握しておきます。

5. コードに埋め込まれた業務ルール

長年使われてきたシステムには、マニュアルや仕様書に書かれていない業務ルールがコードの中に蓄積されています。

計算式（料金計算・ポイント換算・税率処理など）
条件分岐が複雑な処理（例外ケースの積み重ね）
コメントに「暫定対応」「修正履歴」が残っている箇所

コメントや変数名に当時の経緯が残っていることがあります。// 2018年の税率変更対応 のような記述は、その処理が業務上の理由で作られたことを示しています。

6. 定期実行・バッチ処理

画面から確認できない処理が存在します。

cron の設定内容と実行スケジュール
バッチ処理の内容（集計・連携・クリーンアップ）
手動で実行されている定期作業（担当者しか知らないことがある）

バッチ処理は月次・年次など低頻度で動くものがあり、通常の動作確認では気づきません。担当者への聞き取りと cron 設定の確認を合わせて行います。

7. 運用手順と手作業

システムの外側に存在する業務ルールです。

画面操作のマニュアル（あれば）
障害時の対応手順
定期的にやっている手作業（CSV の加工・データの手修正など）

「システムがこういう動きをするから、毎月末に担当者がデータを手で直している」という運用は、コードを読んでいても見えてきません。担当者への確認が必要です。

調査結果をどう残すか

把握した内容は、次の担当者が引き継げる形で残します。最初から完成度の高いドキュメントを目指す必要はありません。箇条書きやスプレッドシートでも、情報が残っていれば、何もない状態よりはるかに役立ちます。

インフラ構成図（テキストでも可）
テーブル定義の一覧
業務ルールのメモ（コードのどこに何があるかを含む）
バッチ・定期処理の一覧

「調査が完了してから文書化する」より、「調査しながらメモする」方が現実的です。

どこまで調査すれば十分か

「完全に把握してから動く」を目指すと、調査が終わりません。調査の目的に照らして「この範囲が把握できれば次のステップに進める」という基準を決めることが重要です。

保守・引き継ぎ: 障害が起きたときに原因を追える状態
リプレース判断: 機能の全体像とデータの移行可否が判断できる状態
改修着手: 変更したい箇所の影響範囲が把握できる状態

この基準に達したら、調査を続けながら並行して次のフェーズに進む方が実務的です。

「現行システムを引き継いだが、全体像が把握できていない」「調査から始めてほしい」という段階でもご相談ください。レガシーシステム保守・改善支援からどうぞ。