見た目はOK。でも公開して大丈夫？
業務シナリオで決める
Webサイトの検収条件

「何を確認したら完了なのかを、先に分けておこう。検収には、納品物の受領、機能の確認、請求の条件など複数の意味が使われる。まず自社の契約や発注書で何を指すかを確認しよう。」

「合意した制作範囲がそろったか、利用者と担当部署が主要な用事を進められるか、残件を踏まえて今公開してよいか。この三つを分けると、判断する人と必要な証拠を整理できるよ。」

「残件を許容できるかは契約、影響、組織の判断によるよ。一般的な記事だけで支払いや責任の条件を決めず、合意した文書を起点にしよう。必要なら契約担当などにも確認したい。」

「完了条件と承認者を最初に書いておくとよいね。公開の許可と契約上の検収が同じ手続きなのかも確認しよう。言葉だけで済ませず、今回何を判断するのかをそろえるんだ。」

「ページが開くことと、用事が終わることは別なんだ。誰が、何のために、どの状態まで進むかを書こう。GOV.UKも利用者、必要なこと、目的を含むユーザーストーリーを説明している。^［1］」

「候補の条件を読み、仕様書を取得して社内検討に持ち帰るところまでつなげよう。一覧と詳細が表示されても、選んだ製品と資料の型番が違えば、その用事は終わらないよ。」

「そう。今回のシナリオは、用途から候補を絞り、電源などの条件を確かめ、同じ製品の現行資料を取得する。実際の業務担当に、判断に必要な条件が何かを聞いて組み立てよう。」

「公開前の確認だけでは将来の成果を約束できないよ。『対象製品を間違えず担当部署へ相談できる』なら、その時点で観察できる。事業目標と、今確かめられる結果を分けよう。」

「まず主要な用事を少数選ぼう。製品選定、採用情報の確認、企業情報の照会など、サイトの役割に合わせる。選んだ対象と、今回は対象外にした用事も記録しておこう。」

「観察できる結果、試す条件、残す証拠を組み合わせよう。GOV.UKの受入条件も、利用者のニーズを満たしたかを確かめる結果の一覧として説明されている。^［1］」

「選んだ製品と同じ型番の現行資料が開き、資料名と改訂情報が分かる、という結果にできる。試した製品、資料の版、環境、確認者を残せば、あとで同じ条件を再現しやすいよ。」

「必要な証拠は用事ごとに違う。資料なら型番と版、相談なら担当部署で受け取れた内容、更新なら対象の変更前後など。個人情報を不要に残さず、判断に必要な範囲を選ぼう。」

「想定する利用者が理解できるという期待を満たすか、条件を見直そう。必要な説明追加と将来の新機能を分けて話す。曖昧な結果を、その場の都合で合格に寄せないことが大切だよ。」

「実在の顧客情報を便宜的に入れないでね。承認されたテスト情報、送信先、実施時刻を制作側と合意しよう。本番担当者へ予告なく通知を飛ばすと、確認作業が業務の混乱になるよ。」

「どこまで処理が進むかを確認しよう。テストが本番案件や顧客への連絡として扱われない方法が必要だね。本番でしか確認できない部分は、担当者と範囲・時刻を限定して実施する。」

「そう。誰が受け取り、何を確認し、終わった後にどう扱うかまで準備しよう。権限やセキュリティなど専門的な確認が必要な範囲は、業務の受入試験とは別に担当を置くんだ。」

「公開日に間に合わせるための試験でも、許可のない送信や処理は避けよう。試験できなかった範囲を記録し、代わりの確認方法や実施判断を責任者へ相談することが大切だよ。」

「実際には途中で戻ったり、条件が分からないまま候補を開いたりする。主要な用事ごとに、起こりそうな選び直しや中断を一つ足してみよう。最初から無限のケースを作る必要はないよ。」

「候補がないと分かり、相談先や条件の見直しへ進めるかを確かめよう。『正しく進む』『間違いに気づく』『戻ってやり直す』という三つの見方が役立つよ。」

「その状態が合意した使い方に合うかを確認しよう。気になったことを好みで並べず、どの用事が止まるかを書くと、修正の必要性を相談しやすいんだ。」

「利用者の困り方はシナリオで見て、技術的な旧新URLの対応は移行担当の表を参照する方法がある。同じ確認を二重に増やさず、どの結果を誰が確認するかを結び付けよう。」

「期待した結果との違い、対象外だった条件、新しい要望に分けよう。試験範囲を明らかにすれば、確認していない動作まで保証せず、次に判断することを残せるよ。」

「対象者、利用状況、契約で合意した範囲から主要な環境を選ぼう。無制限に組み合わせを増やすより、重要な用事を確かめられる計画にする。パソコンでの確認をスマートフォン確認の代わりにはしないでね。」

「画面幅や拡大の状態など、問題に関係する条件も残そう。全環境で確認したのか、一部の代表環境なのかを明確にすると、後で『そこも見たはず』という行き違いを減らせるよ。」

「W3CのEasy Checksは、そうした基本的な確認を案内している。ただし通過しても重大な障壁が残る場合があり、包括的な評価ではないと説明しているよ。^［2］ 簡易確認と適合評価を混ぜないでね。」

「扱う情報や影響に応じた専門的な確認を別に設けよう。小さな画面変更でも、権限や機微な情報に関わるなら目視だけでは足りない場合がある。このシナリオは専門評価の代わりではないんだ。」

「問題の件数より、業務への影響を見よう。型番違い一件でも誤選定につながる。業務を妨げない余白調整が複数ある状態とは違うから、影響する用事を書き出すんだ。」

「呼び方はチームに合わせてよいよ。重要なのは、主要な用事を完了できるか、誤情報や想定外の情報閲覧につながらないか。公開を止める理由を具体的に残そう。」

「使える代替手段、対応者、期限、再確認者をセットにしよう。代替手段が利用者に伝わらなければ、社内では軽微でも利用者には行き止まりだよ。残す判断も承認が必要だね。」

「この例では旧条件で選定されるおそれがあるため、公開前修正を選ぶことにしよう。技術担当が原稿を確定し、制作担当が差し替え、営業が再確認する。実案件は契約と影響に基づき責任者が判断するよ。」

「発注側の公開責任者が確認結果を見て決めよう。不在に備えた代理承認者と連絡方法も決めておく。判断する人がいないまま、作業する人だけに任せないことが大切なんだ。」

「まず合意した期待結果と照合しよう。最新版の取得を約束したのに旧版が開くなら不一致。未合意の履歴表示や比較機能なら、追加の検討になる場合がある。役立つ要望かどうかとは別の分類だよ。」

「それも一律には決められない。議事録、画面案、見積もり前提、受入条件から、目的について何を合意していたかを確認しよう。認識の違いを先に事実として整理するんだ。」

「期待結果との不一致、解釈を確認中、追加改善に分け、確認中のものには判断者と期限を置こう。公開前日に納期か品質かという対立になる前に、合意内容を見直せるよ。」

「まず事実を共有しよう。『比較機能が欲しい』だけでなく『型番の違いを見るため別画面を往復している』と残せば、小さな説明の改善で解決できるかも検討できる。分類と対応策は分けて相談しよう。」

「制作側とWeb担当だけの確認では、後工程が抜けやすいね。受け取る部署にも参加してもらい、製品と内容を識別して次の担当へ回せるか、一件のテストとして通そう。」

「必要な情報があるか、誰へ回すか分かるか、試験を本番案件と混同しないかを見てもらおう。受信したという記録だけで、業務で処理できるとは限らないからね。」

「権限を与えた担当が、社内の承認を経て更新できるかは別だよ。改訂済み資料なら、原稿確定、公開前確認、差し替えを一度つなごう。直後に必要な更新から試すとよいね。」

「その場合は情報の責任者を決めることが先だよ。見つかった課題を全て機能の不具合にせず、原稿管理や担当分担の問題も分けると、依頼すべき作業が明確になる。」

「本番に残す情報、後処理するテスト情報、判断の証拠を区別しよう。削除や通知の停止は対象と担当を確かめて行う。試験が終わったからと、証拠まで一括で消さないようにね。」

「発注担当が技術的な診断まで背負う必要はないよ。『この製品の、このリンクから旧版が開く』と、現象と再現条件を書くほうが伝わる。原因は調査後に追記すればよいんだ。」

「影響する用事と、判断した人も残そう。画像を添えるなら対象が分かる範囲にし、不要な個人情報を含めない。記録を見れば、何を根拠に判断したかが追える状態にしたい。」

「修正した状態と、期待する結果を再確認した状態を分けよう。誰がどの条件で確かめたかを残して閉じる。直した場所に関連する資料やリンクへ影響していないかも必要に応じて見るんだ。」

「そう。対象範囲、結果、残件、未確認、承認者をまとめれば、何を判断したかが分かる。『問題なし』の一言より、保証していない範囲まで明らかにするほうが実務に役立つよ。」

「修正後に試し直す時間がなくなってしまうよ。指摘を出す締切と、直したものを再確認する日を組み合わせよう。テスト開始日だけでなく、確認が終わるまでの日程が必要だね。」

「うん。開始前に期待結果、環境、テスト情報、修正の扱いをすり合わせる。実行後は残件と再確認結果をまとめ、公開後に確かめることまで担当へ引き継ごう。」

「変更範囲が小さく、外部連携もないなら、ページ、リンク、日時、担当の確認に絞れる場合もある。確認の量はページ数だけでなく、扱う情報と影響に合わせて決めよう。」

「そのとおり。通常の業務シナリオとは別の専門確認が必要かを判断しよう。小さい変更という理由だけで、影響の大きい部分の確認を省かないようにしたい。」

「確認した範囲、結果、条件付きで残す事項、承認した人を共有しよう。確認していないことまで保証する必要はないよ。公開後の担当と再確認事項もそろうと、制作の完了を説明しやすくなる。」

「今回の範囲、利用者にしてほしい行動、受け取る部署、公開希望時期を持ち寄ろう。未確定でもよいよ。仕様書や見積もりがあれば、合意済みと考える部分も示すと整理しやすい。」

「型番違い、重要情報の欠落、部署で処理できない状態など、自社で受け入れられない結果を書いてみよう。制作側も、見た目の調整と業務を止める問題の優先順位を付けやすくなる。」

「受入シナリオ、試験範囲、公開前後の役割を一緒に整理しよう。承認する人と操作する人を分けておけば、作業が終わったことを公開許可と取り違えずに済むよ。」

「まず主要な用事を一つ選び、開始条件と合格する結果を書こう。その小さな一行から、必要な試験、担当、証拠が見えてくる。安心して判断するための準備を、制作の途中から始めよう。」