仕様書がないシステムを改修していい？現行動作と期待動作を分ける確認表

「この検索結果、先月分も表示するように変えてほしい」。

小さな改修に見えても、現行の動作を説明する仕様書がないと、何を変えて何を残すべきか迷います。

改修に進む前に、実際に観測した動作、業務側が期待する動作、まだ確認できていない条件を分けて1枚にしましょう。

資料不足のときは「調べた事実」と「変える約束」を分ける

古い資料は調査の手がかりです。

実際に試した動作には、対象環境、入力条件、確認日を添えます。

コードや設定は動作の理由を調べる材料にし、業務上の意図は判断できる担当に確認します。

問い合わせの発言をそのまま全ユーザーの要件に広げると、権限や帳票に想定外の影響が出ることがあります。

ベターな対処｜変更したい動作を確認表にする

架空の社内検索画面を例にします。依頼は「先月分を見たい」です。

検証環境で条件を限定して確認し、業務担当との合意事項を同じ表に並べます。

合意前の項目には、その時点の扱いと確認先を残します。

確認項目	観測した動作	期待動作と合意状況
対象月の初期表示	一般利用者で開くと当月が初期表示	当月の初期表示を維持することで合意
先月の検索	月を切り替える操作がない	対象月を選べるようにする。当月と先月を選択可とすることで合意
他部門データ	試した一般利用者では自部門だけ表示	先月も自部門だけ。別の権限での条件は管理担当が確認中
CSV出力	画面で当月の結果をCSV出力できた	先月を出力対象に含めるか、帳票の業務責任者が確認中

この表なら、先月分を表示するという依頼と、表示した先月分をCSVに出してよいかという別の判断を切り分けられます。

調査結果が増えたら、元の依頼を上書きせず、判断した日・役割・理由を記録します。後から話が変わったとき、どの条件で改修を決めたのか追えます。

目指したい対応｜合意した条件を受け入れテストにする

変更範囲と維持する動作を両方試す

受け入れテストでは、業務側と決めた条件を入力と期待結果に置き換えます。

「先月を選ぶと自部門の先月データを表示する」に加えて、「初期表示は当月のまま」「他部門のデータは表示しない」を確認します。

月の計算を変更するなら、1月から見た先月が前年12月になる条件も候補です。

表示するデータがない月の画面も、期待する挙動を先に決めておきます。

未確認が残る場合の進め方を決める

権限や外部へのデータ出力に関わる未確認事項は、影響する範囲のリリース判断に含めます。

今回の例でCSVの扱いが未合意なら、検索だけを独立して提供できるかを確認します。

共通処理を使っていてCSVにも先月データが出るなら、業務判断が得られるまで反映を保留します。

範囲を絞る場合も、対象外の機能が本当に変わらないことを検証します。

コピーして使える記録欄

対象の機能／観測時の環境と入力／観測結果／期待結果／確認先と合意日／受け入れテストの結果

記入例（架空）

対象・観測結果｜検証環境で一般利用者として検索画面を開いたところ、当月分のみ表示された。

期待結果・合意｜初期表示は当月のまま。先月を選ぶと自部門の先月分だけ表示することで業務担当と合意。

受け入れテスト｜先月分を検索し、自部門のデータだけが表示されることを確認。先月分のCSV出力は業務担当に確認中。

注意点｜本番に反映する前に戻し方を確かめる

リリース後に期待どおり動かなかった場合の判断条件、戻す手順、確認者を決めます。

データ更新を伴う改修では、プログラムを戻す手順と、更新済みデータをどう扱うかを別に確認します。

検証には架空データや許可されたデータを使い、テスト記録に実データを写す必要がある場合は、社内ルールに従って管理します。

まとめ｜小さな改修でも「何を変えたら完了か」を先に決める

確認表に現行動作と期待動作を並べると、調査で分かったことと、業務側の判断が必要なことが見えます。

改修前にまず、変更する動作を1つ、維持する動作を1つ、未確認事項を1つ書き出すところから始めてみてください。

関連記事と参考資料

調査の手がかり自体が見つからないときは、こちらも参考になります。
引き継ぎ資料ゼロから始めるシステム調査の教科書

システムや関連資産の棚卸しにはIPAの台帳サンプルが使えます。この記事の動作確認表は、改修範囲の合意を目的とした独自例です。
IPA「中小企業の情報セキュリティ対策ガイドライン」付録6（2026年11月8日確認）