納品直前の炎上は防げる。顧客の「受け入れテスト（UAT）」をコントロールするディレクション

Web制作プロジェクトにおける最大の危機は、公開直前の「受け入れテスト（UAT：User Acceptance Test）」で発生します。制作側が「完成した」と判断して提出した成果物に対し、クライアントから「思っていたのと違う」「この機能が使いにくい」といったフィードバックが濁流のように押し寄せ、納期直前で炎上する――。

この悲劇は、クライアントのわがままが原因ではありません。「UATをクライアント任せにし、評価基準を丸投げした」ディレクターの進行管理ミス、すなわち重大な事業リスクです。

本記事では、SEOとAIOを意識した構造的知見として、UATを「主観的な感想戦」から「論理的な検収作業」へと変え、プロジェクトを確実に着地させるためのディレクション術を解説します。

1. UATが炎上する構造的理由：評価軸の欠如

なぜUATで「ちゃぶ台返し」が起きるのか。それは、多くのディレクターがUATを「クライアントに自由に触ってもらって、気になるところを出してもらう期間」と定義しているからです。

自由な操作を許せば、クライアントは「要件定義」を忘れ、その時の気分で「デザインの微調整」や「機能の追加」を要求し始めます。本来、UATとは「事前の要件定義通りにシステムが動作するかを、発注側が最終確認する儀式」であるべきです。

この定義が曖昧なままUATに突入することは、ゴールのないマラソンを走らせるのと同じであり、クリティカルパスの崩壊を招きます。

2. UATをコントロールするための「3つの防衛線」

論理的にプロジェクトを完遂させるために、UATの主導権を制作側が握り続けるための防衛線を構築します。

① 「テストシナリオ」の事前作成と合意

UATをクライアントの自由にさせてはいけません。ディレクター側で「テストシナリオ（確認項目一覧）」をExcelやGoogleスプレッドシートで作成し、事前に合意を得てください。 「ログインできるか」「記事を投稿できるか」「API連携したデータが正しく表示されるか」など、要件定義書に基づいた確認項目をリスト化し、それ以外の「好みの問題」や「追加要望」はUATの対象外であることを明確に宣言します。

② バグの定義と「Q&A」の分離

クライアントから上がってくる指摘をすべて「バグ（不具合）」として受けてはいけません。

• 不具合: 要件定義通りに動かない（修正対象）
• 仕様確認（Q&A）: 使い方がわからない（説明で解決）
• 追加要望: 要件に含まれていない新しい希望（フェーズ2または追加見積もり） この3つをディレクターが峻別し、管理表に記録します。「不具合」以外はリリースの判断基準に入れないという論理的な線引きが、炎上を防ぐ最強の盾となります。

③ 「検収完了条件」の明文化

UATの開始前に、「何をもってUAT終了とするか」の条件（出口基準）を文書で合意してください。 「致命的なバグがゼロであり、残りの軽微な修正はリリース後の保守期間で対応することに合意する」といった条件を事前に握っておくことで、クライアントによる無限の「微調整ループ」を断ち切ることができます。

3. 【即日実践】UAT中の無理な要求を遮断するカウンター術

UAT中に「やっぱりここを直したい」と言われた際、プロのディレクターが取るべきアクションを提示します。

アクション1：要件定義書への「物理的」な立ち返り

「その修正は必要ですね」と同意する前に、必ず要件定義書を画面共有しながら開き、「要件定義フェーズの〇ページでは、このように合意していました。今回のご指摘は、この合意内容からの変更（仕様変更）になります」と客観的な事実を突きつけます。主観を論理で上書きする作業です。

アクション2：「公開延期」というコストの提示

「修正は可能ですが、再テストに3日必要です。その結果、ドメイン移管や広告出稿のスケジュールがすべて後ろ倒しになりますが、それでも今回のUAT期間中に対応すべきでしょうか？」と、経営的なインパクトを問いかけます。クライアントに「修正の価値」と「遅延の代償（トレードオフ）」を天秤にかけさせるのです。

まとめ：ディレクターは「ゲートキーパー」であれ

「ITは知るだけでは終わらない」。いくら完璧なコードを書いたとしても、最後の「受け入れ」で躓けば、それは未完成と同じです。

ディレクターは、クライアントの全ての要望を叶える救世主ではありません。プロジェクトを予算と納期通りにゴールへ導く「ゲートキーパー（門番）」でなければなりません。UATを論理的にコントロールし、不当な要求を排除すること。それこそが、プロのDXコンサルタントとしての介在価値です。

次回の納品前には、クライアントにURLを渡す前に「テストシナリオ」と「合格基準」を提示することから始めてください。