移行テストは通ったのに、リハーサルで人が詰まった

移行テストでは、決めた項目が全部正しく移っていました。自動化も動いていました。

それでも本番の1週間前にリハーサルをやったら、ログインできない担当者が3人出ました。

原因をたどると、役職を起点にしたユーザーと権限の設計に行き着きました。旧システムの役職と権限を1対1で対応づけていたのに、実際の現場では兼務や異動があり、役職と権限がすでにずれていました。

テストが見ていたのは「データが正しく移ったか」。リハーサルが見ていたのは「その人が、その日から仕事を始められるか」。

同じ移行プロジェクトの中に、別の質問を持つ工程が2つあります。

テストとリハーサルは、同じものを2回やっているわけではない

移行テストは、開発者かベンダーが、決めたシナリオで確認します。この項目は移った。この自動化は動いた。この画面は表示された。

確認しているのは「仕様通りに動くか」です。仕様通りに動くことは必要条件ですが、十分条件ではありません。

リハーサルは、実際に使う人が、実際の権限で、実際の業務の手順でシステムに触れる工程です。ここで初めて、テストのシナリオに入っていなかった動きが出ます。

兼務で複数の権限グループに属している人。異動でメールアドレスが変わった人。

旧システムでは1つの画面で完結していた作業が、新システムでは2つの画面をまたぐことに、本人がまだ気づいていない場面。

テストは仕組みを見ています。リハーサルは人を見ています。

仕組みが正しくても、人がその仕組みで最初の1日を過ごせるかは別の話です。

テストが通っているのに現場が止まる。よくある話です。

サンドボックスでは、この差が消えない

「テスト環境で連携も含めて確認したから大丈夫」と思いたくなりますが、そこにも落とし穴があります。

HubSpotの公式ドキュメント（2026年7月27日更新）は、サンドボックス環境の制約をはっきり書いています。本番で使っている外部連携は、サンドボックスに自動では接続されません。

加えて、レコードのIDは環境ごとに変わるため、サンドボックス内で連携先とのやり取りを追いたい場合は、別に「External record ID」のような項目を用意する必要があると案内されています。

つまり、テスト環境で「連携は動いた」と確認できても、それは本番の連携先と実際に話した結果ではありません。

本番の外部連携、本番の権限、本番のメールサーバー。この3つが揃った状態で一度動かしてみないと、テストが見ていない不具合はそのまま本番に持ち込まれます。

ただし、本番で動かすときは、顧客に何も届かない形に絞るのが条件です。

触るのは、社内で作ったテスト用のレコードだけ。メールの送り先は社内のアドレスに限る。自動化は、条件に合ったレコードが勝手に対象に入らない設定にして、テスト用のレコードを手で登録して動かす。連携先に書き戻る件数は、動かす前に数えておく。

終わったらテスト用のレコードを消し、連携先にも残っていないかを確かめる。

具体的な設定の方法はツールと連携の作りによって違いますが、この5つを決めないまま本番で動かすと、リハーサルがそのまま顧客への誤配信になります。

1週間前という距離が、直せる時間と環境のずれの両方を決める

リハーサルを1週間前にやるのは、この距離が2つの条件を同時に満たすからです。

まず、見つかった不具合を直す時間が残っています。

権限グループを1つ直す、通知の宛先を直す。この程度の修正は数日でできます。1週間あれば、直してもう一度確認する時間まで取れます。

同時に、本番と環境がずれるほど長くはありません。

1か月前にリハーサルをやると、その間に4月や10月の異動期をまたぐことがあり、権限の割り当てが変わり、旧システムのデータも動きます。せっかく見つけた不具合が、本番までにまた別の形に変わっています。

リハーサルは、本番に一番近い状態で、本番の前に一度だけ失敗しておく工程です。

近すぎれば直す時間がなく、遠すぎれば見ているものが本番と違う。1週間は、その両方を満たす、最後の窓です。

ただし、1週間で足りるのは、見つかる修正が権限や通知の宛先くらいの軽いものである場合です。

データの移し直しがあり得る規模の移行なら、1週間前の1回では直しきれません。その場合は、もっと前にもう1回リハーサルを置き、1週間前の回は確認だけにします。

もう1つ、リハーサルの前に決めておくことがあります。何が見つかったら稼働を延ばすか、それを誰が決めるかです。

たとえば、ログインできない人が残る、自分の案件が見えない、連携が止まる。こうした業務が止まる不具合が、本番までに直して再確認できない見込みなら延期する。

判断するのはプロジェクトの責任者と、現場側の責任者の2人。

ここを決めずにリハーサルをやると、見つかった不具合の重さを、本番前日に議論することになります。

リハーサルで確認するのは、動くかどうかではない

だから、リハーサルのチェックリストは、移行テストのチェックリストを再利用するだけでは足りません。

移行テストが見るのは「データは正しいか」「自動化は動くか」。リハーサルで見るのは、それとは別のことです。

代表的な権限パターンを持つ担当者が、実際にログインできるか。ログインできたあと、自分の案件が見えて、編集できるか。この2つは分けて確かめます。

ログインできない原因はアカウントの発行やライセンスの割り当て、シングルサインオンの設定にあることが多く、権限の不備はたいてい「見えない」「編集できない」として出るからです。

旧システムでは1つの作業だったものが、新システムでは何画面に増えたか。外部連携は、テスト環境ではなく本番の接続先と、社内のテスト用レコードで実際にデータをやり取りできるか。

どれも、仕様書のレビューでは出てきません。人がシステムの前に座って、初めて出てきます。

移行の設計そのものを見直す話は、CRM移行で「全部の項目を移したい」と言われたらに書きました。

そこで決めた設計が、実際に人の手で動くかどうかを確認する工程がリハーサルです。

移行テストが確認するのは、仕組みが仕様通りに動くかどうか。リハーサルが確認するのは、人がその仕組みで最初の1日を過ごせるかどうかです。本番の1週間前という距離は、見つかった不具合を直す時間と、本番との環境のずれを抑える時間の両方を満たす窓になります。

今週、リハーサルの参加者リストを見てください。

開発チームと管理者だけで組んでいたら、それは移行テストの再演です。代表的な権限パターンを持つ現場の担当者を、最低1人は入れてください。

関連する記事

リハーサルの次に来るのは、稼働後の最初の2週間です。稼働日でプロジェクトを終えると、リハーサルで直したはずの詰まりが、別の形で戻ってきます。

その動き方は稼働後2週間のフォローを「質問受付」にすると、定着は止まるに書きました。

同じカテゴリの記事は「CRM・SFA」にまとめています。