仕様書が残っていない既存システムを、どう安全に改修するか

ページ一覧だけでなく、次の要素を一つの関係としてまとめます。

• 公開画面と管理画面
• 利用者、担当者、管理者などの役割
• 登録、更新、公開、検索、問い合わせの流れ
• データベース、ファイル、CSV、API
• メール、定期処理、外部サービス
• ドメイン、サーバー、CMS、認証

詳細な設計書を最初から完成させるのではなく、どの機能がどのデータと利用者へ関係するかを見えるようにします。分からない箇所も空白にせず、未確認として残します。

画面を一つずつ開くだけでは、機能間の関係を把握できません。管理画面で登録し、公開し、一覧と詳細へ表示し、検索し、問い合わせを送り、内容を更新・非公開・削除するまで、担当者が普段行う順序で代表的な操作を通します。

利用者の役割が複数ある場合は、それぞれの権限で同じ操作を試します。例外データ、未入力、公開期間外、過去データも含めます。調査中は本番データを不用意に変えず、複製環境や読み取り中心の確認から始めます。

データベースやCSVには、画面からは分からない規則が残っています。同じ意味に見える複数の項目、特定の値だけで表示されるページ、削除されず状態だけ変わるデータなどを確認します。

現在のデータ件数、値の分布、空欄、重複、関連付けを調べると、仕様書にない運用が見つかることがあります。ただし、存在するデータが必ず正しいとは限りません。代表データを担当者と照合し、意図した規則と、過去の例外や不整合を分けます。

既存コードを読むと、どの条件で処理しているかは分かります。しかし、なぜその条件になったのか、現在も必要なのかまでは判断できません。

ルート、画面、保存処理、取得条件、権限、メール、定期処理、外部連携を追い、変更が波及する場所を整理します。コメントや履歴があれば判断材料にしますが、現在の業務と照合します。コードにあるから残す、使っていなさそうだから消す、という二択にしません。

• 残す：現在の業務に必要で、問題なく動いている
• 直す：役割は必要だが、使いにくさや不整合がある
• 置き換える：目的は必要だが、現在の構造では保守しにくい
• 廃止する：現在は使われず、他機能への影響もない

画面単位ではなく、データ、権限、通知、外部連携を含めて分類します。廃止する場合も、URL、履歴、関連データ、利用者への案内を確認します。

広い範囲を一度に作り直すと、理解できていない規則まで失う可能性があります。まず、代表的な一つの業務フローや機能を選び、入力、保存、表示、検索、通知まで通して改修します。

この作業で、環境の差、テストデータ、公開手順、確認担当、戻し方も確かめます。最初の改修結果をもとに、残りの見積りと優先順位を見直します。調査前の想定を、そのまま全体工数の確定値にしません。

新しく作った代表データだけでは、長年蓄積した例外を確認できません。件数が多い、空欄がある、関連情報が複数ある、古い形式で保存されているなど、条件の異なる既存データを選びます。

改修前後で、一覧、詳細、検索、権限、通知の結果を比較します。自動テストを作れる処理はテストへ落とし、画面や外部連携など人の確認が必要な箇所はチェックとして残します。

調査結果は、画面と機能の一覧、項目定義、権限表、外部連携、公開手順、代表テスト、未確認事項へ分け、後から更新できる形で整理します。

変更した理由と確認結果を残すと、次の担当者がコードを読み直す範囲を減らせます。仕様書を過去の完成品として作るのではなく、現在のシステムと一緒に更新する判断記録として扱います。