go/no-go 判定：準備の仕方と誰が判断するか

go/no-go で何を判断するか

go/no-go とは、業務部門が「このバージョンの CRM は、この日に本番環境に移行してよい」と言う瞬間です。あるいは「まだだめだ」と言う瞬間です。テストの最後の形式的な手続きではありません。テストを行った理由そのものです。

良い go/no-go は 3 つの要素から成ります。

• 事実。何をテストしたか、何が合格したか、何がまだ未解決か。記憶からではなく、テスト結果から取り出します。
• 評価。プロセスのオーナーが、このバージョンで自分たちの仕事ができるか、どのような条件付きでできるかを述べます。
• 判断。ステアリングコミッティが、事実と評価を本番稼働日と照らし合わせて検討し、判断します。

うまくいかない go/no-go 会議の多くは、1 つ目の要素が欠けています。誰も数字を持っていないため、課題がどれほど深刻か、あるプロセスがそもそもテストされたのかについて議論になります。このガイドの残りは、会議が始まる前に事実がそろっているようにするための内容です。

終了基準：最初のテスト日の前に合意する

終了基準は、本番稼働してよいほどテストが十分かどうかを決める基準です。最初のテスト日の前に、ステアリングコミッティと合意しておきます。最後になると感情が高ぶり、日程も迫っています。何を基準にするかを決めるには最悪のタイミングです。

多くの CRM 本番稼働で使える基準：

• Critical の課題が未解決で残っていない。
• Must のテストケースがすべて合格している。
• 未解決の High の課題すべてに、業務部門が受け入れる回避策か修正予定日がある。
• スコープ内のすべてのテストケースに結果がある。
• 各プロセスのオーナーがサインオフしている。

言葉の意味をそろえる

基準が機能するのは、全員が同じ尺度を使うときだけです。各重大度の意味を書き出し、テスターにもステアリングコミッティにも同じように共有します。

優先度についても同じようにします。Must のテストケースは、見積の作成やケースの振り分けなど、初日から動かなければならないものを対象にします。Must のテストケースが不合格なら、本番稼働が危うくなります。優先度の決め方については、業務テスターにわかるテストケースの書き方をご覧ください。

テストしないものを書き出す

どの UAT にも対象外のものがあります。後から本番稼働する国、準備が間に合わないレポート、システムテストでしかテストしない連携などです。テストの前に、それを文書にしておきます。そうすれば、go/no-go の場で「対象に含まれていると思っていた」と言える人はいなくなります。

誰が判断するか

参加するのは 2 つのグループで、役割が異なります。

プロセスのオーナーがサインオフする

テスト対象のプロセスやグループごとに、業務部門の 1 人がサインオフします。リードから入金なら営業部長、ケース管理ならカスタマーサービス部門の責任者、請求なら経理の責任者です。彼らはチームに何が必要かを知っており、その結果とともに働くことになります。そのサインオフは「私のチームはこのバージョンで仕事ができる」という意味です。

オーナーは最後の週ではなく、プロジェクトの開始時に決めてください。go/no-go 会議で初めてテストを目にするプロセスオーナーは、読まずにサインするか、もう 1 週間を求めるかのどちらかです。

ステアリングコミッティが判断する

ステアリングコミッティは、本番稼働全体についての判断を下します。通常、業務部門のスポンサー、プロジェクトマネージャー、IT の責任者、そして導入パートナーがいる場合はパートナー側の担当者が加わります。個々のプロセスオーナーには見えないことを検討します。終了する旧 CRM の契約、トレーニング計画、移行の週末、同じ日程の他のプロジェクトなどです。

テストリードは準備するが、判断はしない

テストリードは事実と助言を持ち寄ります。業務部門の代わりにサインオフすることも、判断を下すこともしません。この役割を分けておくことで、本番稼働後に何か問題が起きても、判断が揺らぎません。

レポート：何を含めるか

go/no-go レポートは、テストに参加していなかった人のためのものです。短くまとめます。1 ページにし、詳細を知りたい人のためにその裏付けを添えます。

• 助言。go、条件付き go、no-go のいずれかと、その理由を 1～2 行で。
• スコープ。どのプロセスとユーザーストーリーがテスト対象だったか、何をテストしなかったか。
• テストしたもの。環境、リリース、ビルド。結果はシステムの 1 つのバージョンに属します。
• 数字。合格、不合格、ブロック、未完了のテストケース数。
• グループまたはプロセスごと。同じ数字と、各グループのサインオフ。
• 優先度ごと。Must、Should、Could のテストケースがそれぞれ何件合格したか、どの Must のテストケースが合格していないか。
• 重大度別の課題。未解決、再テスト待ち、クローズ済みがそれぞれ何件か。未解決の Critical と High の課題は名前を挙げて。
• サインオフ。誰が、いつ、どの判断で、どの条件でサインしたか。
• 既知のリスク。最初の数週間に業務部門が使う回避策と、それを誰がサポートするか。

レポートは会議の前日に送ります。事前に自宅で読んだ人は、より良い質問をします。

UAT Studio ではダッシュボードの Go/no-go report には、判定の目安（GO、GO with conditions、NO-GO とその理由）、数字、日ごとの進捗、グループごと・エピックごと・優先度ごとの結果、重大度別の課題、名前付きの未解決の Critical と High の課題、そしてそのラウンドのすべてのサインオフが含まれます。目安は決まったルールに従うもので、あくまで助言です。判断するのはステアリングコミッティです。PDF で共有するか、ステアリングコミッティの資料用にスライドとしてダウンロードできます。

未解決の課題をどうするか

UAT の終わりには、必ず未解決の課題があります。問題は課題があるかどうかではなく、それぞれに判断が下されているかどうかです。会議の前に、毎日のトリアージと同じように、業務部門と開発チームと一緒に確認します。

重大度の変更は慎重に

最後の数日には、Critical の課題を High に下げたいという圧力がかかります。それが正しい場合もあります。回避策が見つかった、そのプロセスがまれにしか使われないとわかった、などです。その場合は、トリアージの場でプロセスオーナーと一緒に公然と行い、理由を記録します。数字を良く見せるために黙って下げることは決してしないでください。本番稼働が最初の週に失敗するのは、そういうときです。

要望は不具合ではない

テスターは、こうだったらいいのにと思うことを見つけます。システムが設計どおりに動いているなら、それは変更要求です。このリリースではなくバックログに入れ、本番稼働の判断材料にも数えません。

UAT Studio ではトリアージで、各課題に重大度、優先度、担当者、そして判断（Fix、Reject、Change request）を設定します。AI test design モジュールがあれば、Issues タブの Summarize with AI が、go/no-go 会議のために未解決の課題の短い概要を作成します。テーマ別に整理し、本番稼働を妨げるものも示します。モジュールがない場合は、Summarize with your own AI で、自社の AI に貼り付けるプロンプトが得られます。

条件付き go

多くの CRM 本番稼働は、条件付きの go になります。システムは十分な水準にあり、本番稼働の前または直後に何かを行うことが条件です。条件が実質的なものである限り、これは妥当な判断です。

良い条件とは：

• 具体的。承認が機能するではなく、50,000 を超える注文の値引き承認が修正され、再テストされている。
• 担当者がいる。1 人の人が名前を挙げて責任を持ちます。
• 期限がある。本番稼働の前、または本番稼働後の最初の数週間のうちの日付。
• 確認される。誰かが完了を確認し、ステアリングコミッティに報告されます。

条件の数に注意してください。2～3 件なら普通です。15 件あるなら、テストが終わっていないということです。条件付き go は、no-go を避けるための手段ではありません。

段階的な本番稼働

1 つのプロセスだけ準備ができておらず、残りは準備ができていることがあります。その場合、そのプロセスを除いて本番稼働するか、1 つの国やチームを後から本番稼働させることができます。それを明示的に決め、後回しにする部分の新しい日付を書き留め、その部分独自の UAT ラウンドとサインオフを計画します。

グループごとのサインオフ

すべてに対して 1 つの署名ではなく、プロセスまたはグループごとのサインオフを求めます。営業部長はケース管理を評価できませんし、評価すべきでもありません。各オーナーは次の 3 つの答えから 1 つを選びます。

• 承認：私のチームはこのバージョンで仕事ができる。
• 条件付き承認：条件が満たされることを前提とします。それぞれの条件を、誰がいつまでに対応するかとともに記録します。
• 却下：本番稼働するには不十分。何があれば答えが変わるかを尋ねます。

ステアリングコミッティが全体像をもとに判断できるよう、サインオフは会議の前に集めておきます。サインオフは 1 つのバージョンに属します。新しいビルドや新しいテストラウンドが続く場合は、もう一度サインオフします。

UAT Studio ではダッシュボードの Sign-off カードには、プロジェクト全体の行とグループごとの行があり、Accepted、Accepted with conditions、Rejected を選べます。日付、時刻、未解決の Critical の課題の件数が記録されます。既定では、Critical の課題が未解決の間は誰も承認できません。No sign-off while Must test cases have not passed にチェックを入れると、すべての Must のテストケースが合格するまで承認もできなくなります。却下はいつでも可能です。サインオフは現在のラウンドに属します。

go/no-go 会議の進め方

テスト日を計画するときに会議も計画し、ステアリングコミッティのカレンダーに日程を入れておきます。1 時間を確保します。一般的な進め方：

1. テストリードがレポートを示します：スコープ、数字、未解決の課題、サインオフ。数字を画面に映して 10 分。
2. 各プロセスオーナーが、なぜそのようにサインしたのか、条件は何かを 1～2 文で述べます。
3. 未解決の Critical と High の課題についての質問：修正、回避策、日付はあるか？
4. テスト以外の質問：トレーニング、データ移行、最初の数週間のサポート、切り戻しの計画。
5. 判断：go、条件付き go、no-go のいずれか。条件、担当者、日付とともに声に出して読み上げます。

判断が no-go なら、計画を立てて会議を終えます。何を変える必要があるか、新しいテストラウンド、次の go/no-go の日付です。計画のある no-go は、プロジェクトの通常の判断です。計画のない no-go は失敗のように感じられます。

意思決定ログ

判断は当日中に書き留めます。何か月も後、インシデントの後や監査の際に、あの未解決の課題を抱えたまま本番稼働すると誰が決めたのか、と尋ねる人が必ず出てきます。その答えは 1 分で見つかるべきです。

意思決定ログには、go/no-go ごとに次のものを記録します。

• 日付と、会議の出席者。
• 判断：go、条件付き go、no-go。
• すべての条件と、その担当者、期限、そして後に完了した日。
• 業務部門が受け入れた未解決の課題と、その理由。
• 判断の根拠となったレポート（その時点のもの）。

意思決定ログはプロジェクトの文書と一緒に保管し、本番稼働後の最初の数週間は、すべての条件が完了するまでフォローアップします。

UAT Studio ではgo/no-go レポートの Save snapshot で、判断した時点のレポートを保存できます。保存後は変更されず、後から Show で再び開けます。すべてのサインオフは、置き換えられたものや取り下げられたものも含めて履歴に残ります。監査人向けには、管理者が Evidence pack をダウンロードできます。レポート、テストケース、結果と課題、すべての課題の履歴、すべてのサインオフ、監査ログが含まれ、ファイルごとにチェックサムが付きます。

無料で使える

終了基準、サインオフ、レポートは、無料の Excel ファイルの CRM 本番稼働のための UAT チェックリストにも含まれています。テスト全体については、Salesforce UAT と Dynamics 365 UAT のガイドをご覧ください。