システムの修正後に検証を依頼されたとき、私はすぐにテストを始めるとは限りない。最初に確認するのは、どのファイルが最新版なのかという点だ。内容以前の問題に見えるが、ここが曖昧なままでは、どれだけ丁寧に検証しても結果を信用できない。
「DX経営ゲーム」の開発でも、開発用のフォルダー、検証作業で作成したファイル、仮想マシン上で動いているファイルなど、複数の場所に関連データが存在していた。名前が同じでも、更新日時や内容が一致しているとは限りない。
修正担当者が直した場所と、検証担当者が配信した場所が違えば、古い版を検証することになる。その状態で不具合を再現すると、「修正されていない」という誤った報告になる。逆に、たまたま別の作業版で問題が消えていれば、本来の修正版を確認しないまま合格を出す危険もある。
今回は、Dropbox配下にある開発フォルダーを正本とすることを明確にした。以後は、そのフォルダーから個人編を動かす仮想マシンへ反映するという流れに統一した。
正本を決めた後、ファイルを仮想マシンへコピーし、アプリケーションを再起動した。そして、サーバー内での確認に加え、外側からアプリのURLへアクセスし、HTTPステータスが200になることを確認した。ここまで終えて、ようやく画面や機能の検証に入れる。
この順番には理由がある。たとえば画面が開かなかったとしても、原因はプログラムの不具合とは限りない。ファイルの反映漏れ、サービスの再起動忘れ、起動失敗、接続先の間違いなどでも同じ現象が起こりる。配信と疎通を先に確認すれば、少なくとも「修正版が動作環境に届いていない」という可能性を切り離せる。
私は、検証対象を特定する情報も結果の一部だと考えている。最低限、コピー元、反映先、再起動の成否、確認したURL、確認日時が必要だ。可能であれば、ファイルの更新日時や配信サイズ、リビジョン番号も残する。後から結果を見返したときに、何を検証したのか説明できる状態にするためだ。
今回の作業では、正本からの反映、再起動、仮想マシン内での確認、/appへの疎通までを一続きの工程にした。その後に実画面の監査を行い、静的ファイルの404やスマートフォン表示のはみ出しが解消されたかを確認している。
もし先にブラウザだけを開いていたら、古い画面がキャッシュされていたり、古いファイルが配信されていたりしても気づけなかったかもしれない。画面上の結果だけでなく、そこへ至る配信経路を確認したことで、修正内容と検証結果を結びつけられた。
正本の一本化は、単なるファイル整理ではない。開発者、検証者、運用者が同じ対象を見ていることを保証するための取り決めだ。これがないと、「こちらでは直っている」「そちらでは直っていない」という会話が続く。双方の主張が正しくても、見ている版が違えば結論は出ない。
文書についても同じ問題がある。実装の正本が決まっていても、仕様書やマニュアルが別の場所で更新されていれば、利用者へ古い説明を渡してしまう。今回の確認では、参加者画面の実装と、システム仕様書、参加者マニュアル、システム設計書を照合した。AI相談、採用、DX効果の表示、イベントの個別影響、製造原価報告書、キャッシュフロー計算書などが、現行実装と文書の両方に反映されているかを確認している。
この照合で大切なのは、ファイルが存在することではなく、内容が一致していることだ。たとえば画面に新しいタブがあっても、マニュアルのタブ一覧に書かれていなければ、利用者は機能に気づけない。APIに新しい項目があっても、仕様書に記載がなければ、次の改修で意図せず削除される可能性がある。
正本を定める対象は、ソースコードだけではない。仕様、操作説明、テスト条件、配信手順も含めて、どこを現在の基準とするのか決める必要がある。全部を一つのファイルへ集めるという意味ではなく、役割ごとに正式な保存場所を決め、変更時に一緒に更新するという意味だ。
継続開発では、仕様変更や機能追加が重なるほど、似たファイルが増える。急いでいると、手元にあるものをそのまま使いたくなる。しかし、その数分の省略によって、数時間の再調査が発生することがある。
検証の品質は、テスト項目の多さだけでは決まりない。正しい対象を、正しい環境へ反映し、その環境が応答していることを確認する。この入口が整って初めて、その後の結果に意味が生まれる。
今回の経験から、修正確認の最初の質問は「直っているか」ではなく、「どの版を確認するか」だと改めて感じた。最新版という言葉を人の記憶に任せず、場所と手順で定義することが、確実な検証の第一歩になる。