仕様書はある。ソースコードも動いている。それでも、次の改修で何を変えてよいか誰も言い切れない。文書が残っていないからではなく、文書、実装、現場運用がそれぞれ別の時点を示しているためです。
この状態で仕様書だけを正と決めれば、調査は速く見えます。しかし、実装にしかない分岐や現場の補正が後から見つかると、見積もりの前提から崩れます。実装だけを正と決めても、廃止予定の処理と必要な処理を区別できないことがあります。
調査ではまず、各証拠が何を示すかを確認し、残った差分を誰が判断するかを決めます。食い違いを見つけた時点を終点にせず、次の判断へ渡せる状態まで整えるのが仕事です。
- 対象業務、対象システム、見る期間、調査後に決めることを固定する
- 仕様書、実装、現場運用を別々の証拠として集める
- 資産同士の関連と稼働実績を照合する
- 食い違いを差分台帳へ残し、判断する人と期限を決める
必要な根拠がそろい、残った不明点の判断者と期限が決まった時点で、調査を次の工程へ渡します。
三種類の証拠を混ぜない
証拠ごとの時点と出所を失わないよう、現行調査の材料を次の三種類に分けます。
- 宣言された仕様：設計書、要件定義書、議事録、変更票に書かれた内容
- 実装された挙動：ソースコード、設定、DB定義、API、バッチが実際に行う処理
- 運用上の補正：担当者の判断、Excel台帳、手作業、マスタ調整で補われる処理
三つは同じ事実の別表現とは限りません。設計書にない処理が実装され、その出力を現場が表計算で補正しているなら、三つとも現状を説明する別の証拠です。各証拠には、出所、対象期間、確認できた挙動、判断が必要な差分を残します。
例として、請求の締め日が休日に重なった場合を考えます。設計書は「前営業日へ移す」、実装は一部の取引区分だけ「翌営業日へ移す」、運用手順は月またぎを避けるため表計算で日付を戻す。この三つを一文へ丸めると、誰かの判断を仕様として誤記します。
証拠から判断へ
調査範囲を先に固定する
材料を集め始める前に、対象業務、対象システム、見る期間、調査後に決めることを固定します。「受注から請求まで」と「受注登録画面だけ」では、必要なログも確認者も違います。目的が保守移管なのか、刷新方式の選定なのかでも、必要な深さは変わります。
範囲を固定しない調査は、見つけた資料の量で進捗を測りがちです。どの判断に使うか決まっていなければ、資料数だけを根拠に未確認事項が減ったとは判断できません。
- 対象業務と開始点、終了点を決める
- 対象に含むシステムと周辺ファイルを決める
- ログや変更履歴を見る期間を決める
- 調査後に下す判断を一文で置く
最初に集める資料と聞く相手
範囲を決めたら、次の四群から必要な資料を選びます。資料名を無制限に並べず、調査後の判断に使うものから集めます。
- 業務：業務フロー、操作手順、締め処理カレンダー、担当者が使う表計算や台帳
- アプリケーション：機能一覧、画面一覧、設計書、ソースコード、設定ファイル、ジョブネット
- 外部連携：インターフェース一覧、API定義、ファイルレイアウト、共有データの定義
- 運用：障害票、変更票、実行ログ、監視設定、デプロイ手順、ロールバック手順
聞く相手も資料の種類に対応させます。業務責任者にはルールを残す理由、実務担当者には直近の例外処理、保守担当者には変更の経緯、運用担当者には定期処理と障害時の戻し方を聞きます。「業務を一通り説明してください」より、「直近で手作業へ戻した一件を、入力から結果まで見せてください」と頼む方が、文書にない補正を見つけやすくなります。
資産の関連と稼働実績を照合する
ファイル一覧だけでは、使われている資産と残っているだけの資産を分けられません。日立のプログラム資産棚卸サービスも、資産間の関連情報と稼働ログを合わせて、業務に必要なプログラム資産を洗い出す方法を説明しています。[1]
この考え方を現行調査へ広げると、確認対象は「何があるか」から「何が何を呼び、いつ動き、その結果を誰が使うか」へ変わります。呼び出し関係があっても稼働していない処理と、ログには出にくい月次処理を同じ基準で捨てることはできません。関連と稼働の両方を見たうえで、業務担当者の確認へ戻す必要があります。
ログから判断できる範囲は、保存期間、監視対象、例外処理の記録範囲で決まります。観測できなかった資産は「未使用」と断定せず、確認待ちとして台帳へ残します。
差分台帳を仕様確認の入口にする
調査の成果を新しい仕様書へ急いで清書すると、未決事項が文章の滑らかさに埋もれます。先に作るのは、食い違いを食い違いのまま残す差分台帳です。
以下は、月末締め処理を中心にした記入例です。根拠、確認者、未決事項、決定を列として残すと、合意済みの内容と判断待ちの内容を混ぜずに仕様書を書き始められます。
| 対象 | 確認できた証拠 | 食い違い | 次の判断 |
|---|---|---|---|
| 休日にかかる締め日 | 設計書、条件分岐、運用手順 | 前営業日、翌営業日、手作業補正の三通りがある | 月またぎ請求を許す取引区分と承認者を決める |
| 納品予定日の外部連携 | API定義、送信ログ、連携先仕様 | 定義名と実際に送る項目名が異なる | 連携先と正式な項目名、移行時の互換条件を合意する |
| 棚卸差異の在庫補正 | 補正画面、操作ログ、表計算台帳 | 補正値は残るが理由は表計算にしかない | 理由コードと承認記録を新システムへ持たせるか決める |
現行システム調査を終える条件
現行システム調査の完了条件は、次の判断に必要な不確実性を管理できていることです。未確認の範囲、業務への影響、確認する担当者、期限が決まれば、残件を次の工程へ安全に渡せます。見積もりや刷新方式の前提を変える未確認事項だけは、解消するまで判断を保留します。
- 01対象範囲
対象業務の開始点と終了点、含めるシステムが合意されている。 - 02根拠
調査後の判断に影響する処理について、文書、実装、運用のどこまで確認したかを示せる。 - 03差分
食い違いが、決定済み、判断待ち、追加調査のいずれかに分類されている。 - 04引き継ぎ
判断待ちと追加調査に担当者と期限があり、次の工程へ渡す資料が決まっている。
「観測できなかった」と「使われていない」を区別できない項目は、廃止候補へ自動で移しません。未確認として残し、追加調査か業務判断へ戻します。
調査期間を見積もる前に数えるもの
調査期間は、システムの年数だけでは決まりません。見積もり前に、対象業務の数、関係するアプリケーションと外部連携の数、確認できるログの期間、判断が必要な差分と関係者の数を数えます。判断者が複数いる場合は、確認順序と日程も見積もり条件になります。対象が小さくても、月次処理の確認には次の実行日まで待つ必要があります。
Formula AIで扱う現行システム資産と確認工程
Formula AIは、業務資料と現行システム資産の読み解き結果から仕様を組み立て、生成と読み取り専用の検証を別の工程として扱います。[2]
たとえば、締め日の条件分岐をソースコードから読み取っても、それだけで残す仕様は決まりません。設計書の意図、実装された条件、運用で行う補正をそれぞれ根拠として残し、業務責任者が決めた内容を仕様へ反映します。その後、関連する画面、ルール、テストを同じ変更の単位で確認します。
差分台帳があると、AIへ渡す材料と人が決める項目を分けられます。読み解き結果、業務判断、生成物、検証結果のつながりが残るため、後から「なぜこの仕様になったか」へ戻れます。
Formula AIの工程は製品の仕組み、公開している出力例は生成成果物の一覧で確認できます。
よくある質問
- 最初にどの資料から集めればよいですか
- 調査後に下す判断へ直結する資料から始めます。刷新方式を決めるなら業務フロー、機能一覧、外部連携一覧、ジョブネット、変更票、直近の障害票をそろえ、例外処理がある業務は担当者の台帳と操作手順も確認します。
- ヒアリングは誰から始めますか
- 対象業務の実務担当者から、直近の例外処理を一件見せてもらいます。その後、業務責任者へルールを残す理由、保守担当者へ実装の経緯、運用担当者へ定期処理と復旧方法を確認すると、同じ処理を四つの立場から照合できます。
- 調査期間はどう見積もりますか
- 対象業務、アプリケーション、外部連携、確認できるログ期間、判断が必要な差分と関係者を数えます。特に、次回実行まで確認できない定期処理と、判断者が決まっていない差分を先に分けると、待ち時間を含む工程を見積もれます。
まず一つの業務ルールで差分台帳を作る
最初からシステム全体を棚卸しする必要はありません。直近で問い合わせや手作業が発生した業務ルールを一つ選びます。仕様書の記述、実装の条件、現場の補正を一行ずつ書き、食い違いと判断者を差分台帳へ置きます。
一件を埋めても「次の判断」が具体的に書けなければ、調査範囲か聞く相手が足りません。そこが、追加資料を集めるべき場所です。
合意した仕様を変更後も保つ方法は、要件トレーサビリティで変更影響を追える状態の作り方で続けて整理しています。