長年Avayaで運用してきたコンタクトセンターをクラウドへ移す場合、改修を重ねた現行IVRの動きが、設計書と一致していないことがあります。その状態で新基盤を作ると、切替後に「前はこう動いていた」という指摘が出やすくなります。本記事では、移行の品質を客観的に示すための動作同等性検証の進め方を整理します。
Avayaからの移行で何を同等とみなしますか？
現在の装置や画面そのものではなく、維持すると決めた着信、分岐、転送、例外時の業務が成立することを確認します。変更する仕様は、承認された要件として分けます。
0. 同等性を先に定義する
検証を始める前に、現行の動作を1つずつ次の3つに分類します。
| 現行の動作 | 判定 | 移行先の期待結果 | 承認者 |
|---|---|---|---|
| 例：営業時間外は時間外案内→切断 | 維持 | 同じ案内・同じ切断 | 業務責任者 |
| 例：3番→旧窓口へ転送 | 変更 | 新窓口キューへ接続 | 業務責任者 |
| 例：FAX案内メニュー | 廃止 | メニューから削除 | 業務責任者 |
「維持」は新旧で同じ結果になること、「変更」「廃止」は承認された新要件どおりであることを確認します。判定がないまま比較すると、意図的な変更と不具合の区別がつきません。
1. なぜ「同等性」の検証が難しいのか
- 設計書と実装が乖離している（長年の追加改修）
- 時間帯・祝日・混雑時など、条件によってしか通らない経路がある
- ガイダンス文言や待ち時間など、「仕様」として明文化されていない挙動がある
- 移行先の製品では、同じ設計でも実装方式が異なる
つまり新旧の設計書を突き合わせるだけでは不十分で、実際の通話挙動を比べる必要があります。
2. 動作同等性チェックリスト
フェーズ1：現行（Avaya）の棚卸し
- [ ] 全着信番号と、その用途・想定呼量を一覧化した
- [ ] 実際に発信し、主要経路のガイダンスと遷移を記録した
- [ ] 営業時間外・祝日・臨時休業時の挙動を記録した
- [ ] 無入力・誤入力・タイムアウト時の挙動を記録した
- [ ] あふれ呼・転送・コールバックなど例外経路を洗い出した
- [ ] CTI・CRM・録音など連携システムを特定した
フェーズ2：移行先での構築・比較
- [ ] 現行の記録をもとに、試験シナリオ（期待結果つき）を作成した
- [ ] 同じシナリオを移行先（Webex CC / Five9 / NICE CXoneなど）で実行した
- [ ] ガイダンス文言・順序の差分を確認した（TTS化による読み方の違いも含む）
- [ ] 0章の判定表（維持・変更・廃止）に沿って、差分を記録した
- [ ] 連携システムへのデータ受け渡し（顧客ID、選択メニューなど）を確認した
新旧環境を同じシナリオで比べる方法は電話システム移行の比較試験｜Velocityで旧環境と新環境を確認するで解説しています。
フェーズ3：切替前後
- [ ] 本番番号の切替直後に、主要経路を一巡して確認した
- [ ] 負荷がかかる時間帯の挙動（待ち呼、あふれ）を確認した
- [ ] 切替後一定期間、定期的な自動発信で監視した（参考：電話システムの変更前後を継続監視する）
- [ ] 問題発生時の切り戻し判断基準を決めておいた
3. 移行先による注意点
以下は一般的な注意点です。実際の挙動は、採用するAvaya製品・構成と移行先の版によって異なるため、両方の公式資料で確認してください。
- Cisco Webex Contact Center：Flow Designerでの再構築時、既存のサブフロー的な構造をどう表現するかで挙動が変わりやすい
- Five9：IVRスクリプトとスキル設定の組み合わせで振り分けが決まるため、ルーティング結果まで確認する
- NICE CXone：Studioで細かく再現できる分、ロジックの写し間違いが起きやすい。分岐条件単位での確認が有効
4. 同等性検証を「移行後の資産」にする
移行のために作った試験シナリオは、そのまま移行後の回帰試験に使えます。クラウド基盤はベンダーのアップデートが継続的に入るため、移行は品質保証のゴールではなくスタートです。シナリオを自動化しておけば、移行後も同じ品質基準で監視を続けられます。
まとめ
Avayaからの移行では、「同等とは何か」を先に決め、現行の挙動を記録し、同じシナリオで新旧を比べることが基本です。記憶や古い設計書だけに頼らず、実際の通話で確認した記録が、切替判断と社内調整の根拠になります。
CC Assuranceのサービス
Cyara Velocity：旧環境・新環境に同じシナリオで発信し、案内・分岐・到達先の差分を記録。作ったシナリオは移行後の回帰試験にもそのまま使えます。