既存システムの改修では、現在見えている画面を再現すればよいように見えます。しかし画面には、入力値の保存方法、公開条件、権限、定期処理、通知、削除時の扱いまでは現れません。
一見使われていない項目が、別画面の検索や帳票に利用されていることもあります。反対に、画面にボタンがあっても、現在の業務では使われていない場合があります。
私たちは、画面とコードを読めば仕様が分かるとは考えません。今動いているものをすべて正解ともせず、何のために存在し、誰が、いつ、どのデータで使うのかを、実際の操作や担当者の話と照らして確認します。
最初に、システムの全体像を棚卸しする
ページ一覧だけでなく、次の要素を一つの関係としてまとめます。
- 公開画面と管理画面
- 利用者、担当者、管理者などの役割
- 登録、更新、公開、検索、問い合わせの流れ
- データベース、ファイル、CSV、API
- メール、定期処理、外部サービス
- ドメイン、サーバー、CMS、認証
詳細な設計書を最初から完成させるのではなく、どの機能がどのデータと利用者へ関係するかを見えるようにします。分からない箇所も空白にせず、未確認として残します。
実際の業務順で操作する
画面を一つずつ開くだけでは、機能間の関係を把握できません。管理画面で登録し、公開し、一覧と詳細へ表示し、検索し、問い合わせを送り、内容を更新・非公開・削除するまで、担当者が普段行う順序で代表的な操作を通します。
利用者の役割が複数ある場合は、それぞれの権限で同じ操作を試します。例外データ、未入力、公開期間外、過去データも含めます。調査中は本番データを不用意に変えず、複製環境や読み取り中心の確認から始めます。
データから、暗黙の規則を探す
データベースやCSVには、画面からは分からない規則が残っています。同じ意味に見える複数の項目、特定の値だけで表示されるページ、削除されず状態だけ変わるデータなどを確認します。
現在のデータ件数、値の分布、空欄、重複、関連付けを調べると、仕様書にない運用が見つかることがあります。ただし、存在するデータが必ず正しいとは限りません。代表データを担当者と照合し、意図した規則と、過去の例外や不整合を分けます。
コードは、理由ではなく現在の処理を示す
既存コードを読むと、どの条件で処理しているかは分かります。しかし、なぜその条件になったのか、現在も必要なのかまでは判断できません。
ルート、画面、保存処理、取得条件、権限、メール、定期処理、外部連携を追い、変更が波及する場所を整理します。コメントや履歴があれば判断材料にしますが、現在の業務と照合します。コードにあるから残す、使っていなさそうだから消す、という二択にしません。
残す・直す・置き換える・廃止するに分ける
- 残す：現在の業務に必要で、問題なく動いている
- 直す：役割は必要だが、使いにくさや不整合がある
- 置き換える：目的は必要だが、現在の構造では保守しにくい
- 廃止する：現在は使われず、他機能への影響もない
画面単位ではなく、データ、権限、通知、外部連携を含めて分類します。廃止する場合も、URL、履歴、関連データ、利用者への案内を確認します。
最初の改修は、小さく通して確認する
広い範囲を一度に作り直すと、理解できていない規則まで失う可能性があります。まず、代表的な一つの業務フローや機能を選び、入力、保存、表示、検索、通知まで通して改修します。
この作業で、環境の差、テストデータ、公開手順、確認担当、戻し方も確かめます。最初の改修結果をもとに、残りの見積りと優先順位を見直します。調査前の想定を、そのまま全体工数の確定値にしません。
既存データを使った回帰確認を用意する
新しく作った代表データだけでは、長年蓄積した例外を確認できません。件数が多い、空欄がある、関連情報が複数ある、古い形式で保存されているなど、条件の異なる既存データを選びます。
改修前後で、一覧、詳細、検索、権限、通知の結果を比較します。自動テストを作れる処理はテストへ落とし、画面や外部連携など人の確認が必要な箇所はチェックとして残します。
今回分かったことを、次の仕様へ残す
調査結果は、画面と機能の一覧、項目定義、権限表、外部連携、公開手順、代表テスト、未確認事項へ分け、後から更新できる形で整理します。
変更した理由と確認結果を残すと、次の担当者がコードを読み直す範囲を減らせます。仕様書を過去の完成品として作るのではなく、現在のシステムと一緒に更新する判断記録として扱います。
この方法が向いているケース
- 過去担当者が不在で仕様書も十分にない
- 長年改修を重ねた管理画面や業務システム
- 既存CMSへ新しい機能やサイトを追加する
- データ、権限、検索、通知が複数画面にまたがる
- 現行システムを止めずに段階改修する
全面再構築を先に検討するケース
現在の環境が保守期限を迎えている、セキュリティ上利用を続けられない、データ構造が業務と大きく合わない場合は、部分改修を重ねるより再構築が適することがあります。
それでも現行業務とデータの調査は必要です。古い画面をそのまま再現するのではなく、残すべき業務と不要な慣習を分けて新しい要件にします。
着手前チェック
- 公開画面、管理画面、利用者、データ、外部連携を棚卸ししたか
- 代表的な業務フローを実際に通したか
- 既存データの空欄、重複、例外を確認したか
- コード上の処理と現在の業務を照合したか
- 機能を残す、直す、置き換える、廃止するに分けたか
- 最初の改修を小さく通して影響を確認したか
- 既存データを使う回帰確認があるか
- 変更理由、確認結果、未確認事項を残したか
