文書が一度開いたという事実だけでは、置き換えを決められませんでした。インターネットバンキング文書ビューア N社のHTML5移行で、ブラウザ・OSごとに主要フローを点検し、確認した範囲と残ったリスクをリリース判断文書にまとめました。
文書を見る機能は単純に見えます。ファイルが開いて内容が見えれば、終わったように感じられます。しかし実際の業務では、画面で読むことに続いて印刷したり保存したりするフローも必要です。
インターネットバンキング文書ビューア N社は、既存のビューアをHTML5ベースに置き換え、リリースの準備を進めていました。ブラウザとOSの組み合わせが変われば文書の表示とその後の動作も変わり得るため、どの環境で何を確認したかを説明できる根拠が必要でした。
2025年に進めたこの検収の目標は、漠然とした安心を提供することではありませんでした。リリース会議で、確認された事実とまだ確認されていない条件を一緒に検討できるようにすることでした。
テストを始める前に、リリースする対象を固定しました
開発が続いているあいだは、検証対象も変わりやすいものです。最初に確認したファイルと実際に公開するファイルが違えば、以前の結果をそのまま当てはめてよいかから判断し直さなければなりません。
このプロジェクトは、リリース候補ビルド1件を対象に範囲を書面で合意してから始めました。検収結果がどの対象についての判断なのかをはっきりさせておく方式です。
範囲を固定することは、変更を禁じるという意味ではありません。結果がどの条件で適用されるのかを説明するためのものです。対象が変われば、以前に確認した内容と新たに確認すべき内容を区別できなければなりません。
リリース前の検収では、対象の明確さは日程と同じくらい重要です。「検査した」という言葉からどのビルドを確認したかという情報が抜ければ、肝心のリリースする成果物と検証記録の関係が曖昧になります。
文書表示・印刷・保存を、環境の組み合わせと一緒に見ました
重要フローは文書表示、印刷、保存と定めました。各フローを、合意したブラウザとOSの組み合わせで実行しました。
機能の一覧と環境の一覧を別々に持っているだけでは足りません。どの機能をどの環境で実行したかをつないでこそ、抜けている組み合わせを見つけられます。
たとえば、ある環境で文書がきちんと開くという事実は、別の環境での印刷結果までは説明してくれません。逆に、環境を多く用意しても、実際に確認した動作が文書を開くことだけなら、検収の深さは限られます。機能と環境を一緒に見る理由はここにあります。
このプロジェクトでも、組み合わせごとのシナリオ実行結果をもとに欠陥を記録しました。問題の重要度と発生した条件を併せて残し、修正の順序を議論できるようにしました。
除外した範囲も結果の一部として残しました
すべての環境を同じ深さで確認することはできません。限られた日程のなかで、どの組み合わせと動作を優先して検証するかを決めなければなりません。
プロジェクトでは、確認していない環境とフローを除外範囲として記録しました。結果文書に合格した項目だけを示すのではなく、判断の及ばない部分も一緒に残したのです。
確認できなかったという事実は、失敗したという意味ではありません。同時に、問題がないと確認したわけでもありません。この二つを区別してこそ、検証結果を読む人が自分の前提を付け足さずに済みます。
検収の範囲が明確であれば、運用チームも結果をより正確に解釈できます。リリース後に問い合わせが来たとき、すでに見た環境なのか、当時の検証対象外だったのかを確認する出発点ができます。
修正の依頼と修正の確認を区別しました
欠陥を伝えたあとに修正したという返答を受け取ることと、修正結果を自ら実行して確かめることは、別の段階です。
N社のプロジェクトでは、修正分について一度再検証を行いました。最初の確認内容に加えて、修正後の結果を検討する過程がありました。
再検証もまた、確認した修正の範囲と条件のなかで解釈しなければなりません。一つの問題の改善を確認したからといって、他のすべての環境やその後の変更まで確認したとは見なせません。
重要なのは、記録が最後の検収状態を説明しているかどうかです。最初の欠陥一覧だけ、あるいは修正依頼だけが残っていると、リリース時点で何が解決し何が残っているのかを追い直さなければなりません。
最後の成果物は、判断の根拠を集めたリリースメモでした
検証結果、除外範囲、判定の前提と残存リスクをリリースメモにまとめました。リリース可、条件付き可、保留に分ける判断体系のなかで結果を検討し、担当者が署名する手続きを経ました。
この事例で強調したいのは、特定の判定の名前ではなく、判定を説明できる構造です。どの環境を見て、何は確認しなかったのか、どの条件を前提に判断したのかが同じ文書にあるべきです。
文書ビューアの検収は、金融サービス全体のセキュリティやあらゆる運用条件を認証する作業とも区別されます。合意した対象と範囲のなかで実行した結果を届ける仕事です。
HTML5へ技術を変えたことと同じくらい重要だったのは、その変更を公開する根拠を整えることでした。このプロジェクトは「うまく動く」という報告を、どこまで確認し、どの前提で判断したかを説明できる記録に変えました。
