業務システムの変更履歴はどう残す？保存した人と実際に変えた人を分ける

「保存した人」と「値を変えた人」を分ける

保存は、利用者が画面の内容を送るなどの操作です。値の変更は、数量などの対象項目が前の状態と違う状態になることです。保存を押しても、対象の数量を変えていない場合があります。履歴に何を残すかは、この二つを分けて決めます。

この例の従来挙動では、値の違いがなくても、保存を押した人がヘッダーの最終保存者へ入ります。したがって、その表示が担当Yになっていても、担当Yが数量を変えたとは説明できません。逆に、「最終保存者」という表示がYであること自体は、最後に押した人を表す目的なら矛盾しません。その表示だけから、別の意味の「数量変更者」を読み取ることが問題です。

既存の「最終更新者」欄を使うなら、何が起きたときに更新され、注文明細の変更まで表すかを開発先へ尋ねます。項目名だけで判断せず、同じ注文で二つの操作を行ったときの記録を見せてもらいます。

数量変更と、その後の無変更保存を同じ項目で比べる

担当Xが数量を変え、その後で担当Yが値を変えず保存する、順番のある二操作です。Xは先の数量変更者、Yは後の保存者を照合するための仮の呼び名です。「架空注文A」も、二操作が同じ注文に属することを示す説明用の名前です。実際の注文番号や利用者IDではありません。

数量の欄を横に読むと、先の操作は4から7へ変わり、後の操作は7のままです。最後の保存者の表示を読むと、XからYへ変わります。この二種類の変化を混ぜず、数量変更を説明する材料がどこに残るべきかを話し合います。数量以外の明細や価格まで変わったと補うことはしません。

後から答えたい質問を、注文・明細・項目へ結ぶ

最初の質問は「誰が保存したか」ではなく、「問い合わせを受けた注文の、どの明細の数量を、誰が何から何へ変えたか」です。注文全体だけを示す記録では、複数の明細のうち何が対象かが分からないことがあります。対象をたどれる注文・明細・項目の対応を、開発先とそろえます。

そのうえで、変更の前後、変更した人、変更の発生時点、処理の結果を何で説明できるかを尋ねます。この架空例には時刻の値を置いていません。説明用の時刻を実測のように足さず、時点の表し方と、後から記録された場合の扱いを発注条件として決めます。

変更理由を後から知る必要があるなら、数量変更の記録だけで分かるのか、別の業務上の理由も必要かを確認します。理由が未確認の本例から、「誤入力を直した」「上司が承認した」「顧客が依頼した」と推定しません。理由の記入を求める場合も、誰がいつ入力し、どの変更へ対応させるかまで相談します。

残す差分と、残さない秘密情報を一緒に決める

数量の問い合わせに答えるために、注文のすべての項目を丸ごと複製する必要があるかを考えます。今回必要なのが対象明細の数量であれば、何を前後で比べたいかを指定し、顧客情報や他の明細まで無条件に残す依頼へ広げません。項目の追加が必要になったら、その目的と閲覧範囲も一緒に見直します。

パスワードや認証トークンなどの秘密情報が、履歴へ入らない扱いも決めます。画面で隠れていても、記録や検索結果に値が出ればよいとはいえません。開発先へ、対象項目、残さない値、必要な伏せ方、確認する場所を同じ資料で伝えます。実際の秘密情報を説明用の注文へ入れて試す必要はありません。

OWASPのLogging Cheat Sheetは、目的に応じた記録の範囲、秘密情報の扱い、記録とアクセスの確認を考える参考になります。ただし、主にセキュリティ上の記録を扱う資料です。本稿の業務履歴に特定のデータベース方式や保存年数を指定した資料としては使いません。OWASPの記録設計の説明と適用範囲を読む

閲覧・保存期間・処理への負担を、業務の条件へ結ぶ

誰が履歴を見るかは、受注担当と業務責任者へ確認します。自分の担当注文だけか、問い合わせを調べる責任者も見るか、外部の保守担当へ何を見せるかは別の条件です。履歴を表示できることから、全担当・全注文を検索できる権限まで自動で付けません。

必要な期間は、どの時期の問い合わせへ答えたいか、会社の情報管理や適用する契約などを確認して決めます。本例では期間は未確認であり、一律の年数は置きません。運用担当には、いつを起点に、何を残し、期限後に何をどう扱うかを、記録本体と必要な複製を含めて尋ねます。

記録を追加したときの処理への負担も、注文の保存や問い合わせの仕事で説明します。普段と集中時にどの操作を行い、どこを測って判断するかを決め、開発先に実現方法と制約を回答してもらいます。許容値が未決定のまま、「影響なし」「十分速い」とする説明だけで条件を確定しません。

開発先の回答で、今回の範囲と保留する条件を更新する

「最後に保存した人だけを表示する」という回答なら、数量を変えた人への問い合わせをその表示だけで解決できるかを再確認します。できないなら、必要な明細の変更を残す方法、今回追加する範囲、運用上の制約を求めます。表示名を変えただけで、過去の変更まで追えるようになったとは判断しません。

「明細の変更前後を残せる」という回答なら、対象明細と項目、実際の変更者、後の無変更保存で記録がどうなるかを見せてもらいます。保存ボタンの操作履歴も残す案であれば、操作の記録とデータ変更の記録をどう見分けるかまで答えてもらいます。

方法や保存範囲が未確定なら、決まった項目と、誰の回答を待っている項目を分けます。技術方式の名前を先に選ぶのではなく、二操作の後にどの質問へ答えられる必要があるかを開発先へ渡してください。回答で条件が変わった場合は、その版と必要な確認操作も更新します。

図で、数量の変更と後の保存の関係を読む

解説図を原寸で見る

図から判断すること：数量変更を説明するときは、4から7への変化と、その変更をした担当Xを対応させます。担当Yは後で保存していますが、明細数量は7のままです。最終保存者Yという表示だけから、数量変更者をYへ置き換えないでください。

図を読んだ後の行動：対象の明細と項目、前後の値、変更者・時点を何で説明できるようにするかを業務責任者と決め、無変更保存を含む二操作を開発先の確認条件へ渡します。図だけで実装方法や試験合格を認定することはできません。

自動更新・同時操作・保存失敗は別の条件として尋ねる

この架空例は、人が順番に二操作を行う条件です。実際の業務で自動取込みや一括更新もあるなら、それを誰のどの処理として追うかを別に尋ねます。人の最終保存者だけを当てはめず、対象の変更と処理元をどう対応させるかを確認します。本例に自動更新があったと追加する説明ではありません。

複数の担当が同時に開く場合や、保存が失敗する場合も、別の確認ケースとして扱います。値が反映されなかったのに変更完了の記録だけ残らないか、処理と履歴に食い違いが出たときに誰が調べるかを、開発先とそろえます。順番や結果を確認できない記録を、推測で一本の変更経過へつなぎません。

履歴を修正・削除する必要が出る運用も、誰が何の根拠で行い、元の経緯をどう確かめるかを決めます。履歴画面があることだけで、記録の正しさや、不適切な閲覧・変更への対策が確認できたことにはしません。

二操作の後でも、数量変更者を説明できるか確かめる

合意した条件を、許可された試験環境と架空の注文で確かめます。対象の版、注文と明細、利用者と役割、記録する項目、画面と確認資料をそろえ、期待する結果を先に書きます。次の操作は今後の確認方法で、本稿で実システムへ実行した結果ではありません。

1. 数量を変える保存を行う。試験用の担当Xが対象明細の数量を4から7へ変えます。合意した履歴で、その明細・項目・前後値・変更者を説明できるかを確かめます。
2. 値を変えず後から保存する。試験用の担当Yが数量7のままで保存します。その後も、先の数量変更をXの変更として説明できるかを確認します。最終保存者の表示がYでも、数量変更の記録をYへ取り違えないことが要点です。
3. 無変更保存の扱いを照合する。保存操作を記録する方針なら、値の変更がない操作として見分けられるかを確かめます。その方針が未決定なら、先に合意を求めます。
4. 閲覧範囲と残さない値を確かめる。合意した役割で必要な履歴を見られるか、許可していない範囲を見られないか、秘密情報が記録や表示へ出ないかを、決めた条件で確かめます。

期待した記録と実際の結果が違う場合は、対象の版・明細・操作順・差の箇所を開発先へ返します。修正の連絡だけで完了にせず、変更に関係する条件をそろえて再確認します。一般的な受入条件の組立ては、受け取るものと確かめ方を発注前にそろえる方法も参照できます。

まとめ：一件の変更と、後から答えたい質問から始める

変更履歴を頼むときは、まず「どの注文の、どの明細の、何の変更を、後から誰へ説明したいか」を決めます。保存ボタンを押した人と、数量を実際に変えた人は同じとは限りません。先の数量変更と後の無変更保存を分けて、必要な記録を具体化してください。

残す差分と残さない秘密情報、履歴を見せる担当、保存条件、処理への負担も、今回の仕事へ結び付けます。未確認の方式や結果を説明の都合で埋めず、開発先の回答で発注範囲と確認方法を更新します。

最初の一歩：受注担当と、後から調べたい変更を一件選び、「最後の保存者だけで答えられるか」を確認してください。足りなければ、二操作の前後値と変更者をどう説明できるようにするかを、IT発注担当から開発先へ尋ねます。