Flow Designerを使えば、現場の担当者がドラッグ&ドロップでフローを修正できます。ベンダーやSIerに依頼せずに変更できるのは大きなメリットですが、その分「誰が、いつ、何を変えたか」「変えた結果、どこに影響したか」が見えにくくなります。本記事では、Flow Designerでの変更に伴うリスクと、それに備えるテスト設計を整理します。
Flow Designerの検証だけで業務動作を保証できますか？
設計時の検証と、実際の入力・転送先・業務条件での試験は確認範囲が異なります。検証機能の対象を確認したうえで、必要な顧客経路を実行して期待結果と照合します。
1. Flow Designerの変更で起きやすいリスク
- 分岐条件の設定ミス：条件の順序や変数の比較条件を誤り、意図しない経路に流れる
- フローのバージョン取り違え：検証したバージョンと公開したバージョンが異なる
- 共通設定の影響：営業時間やキューなど、複数フローが参照する設定の変更
- 外部連携の変化：HTTPリクエストなどで外部システムを参照する処理の失敗
- Webex製品群との組み合わせ：Webex Callingやデジタルチャネルとの連携部分
2. テスト設計の考え方
2-1. フロー単体とエンドツーエンドを分ける
Flow Designer上の検証は、フローの設定や構成に問題がないかを設計時に確認するものです。ただし、それだけでは次のような業務上の動作までは確かめられません。
- 実際の番号に発信したとき、顧客が聞く案内が正しいか
- 実際の入力に対して、意図した転送先・キューに到達するか
- 営業時間や共通設定など、業務条件との組み合わせで正しく動くか
そのため、静的な検証で設定の誤りを減らし、実通話の試験で業務要件を確認するという2段構えにします。試験項目の作り方はIVRのテスト項目をどう作る？をご覧ください。
2-2. 変更の種類ごとに試験範囲を決める
| 変更の種類 | 試験範囲の目安 |
|---|---|
| ガイダンス文言の差し替え | 該当メニュー＋前後の遷移 |
| 分岐・メニューの追加 | 該当フローの全分岐 |
| 共通設定（営業時間・キュー）の変更 | 参照している全フロー |
| 外部連携処理の変更 | 正常時・エラー時の両経路 |
2-3. 公開の前後で同じシナリオを流す
公開前に検証環境で、公開直後に本番で、同じシナリオを実行します。公開したバージョンが意図どおりかを確かめる最後の砦です。
| シナリオ | 入力・条件 | 期待結果（案内） | 期待結果（到達先） | 公開前 | 公開後 |
|---|---|---|---|---|---|
| 例：営業時間内・1番 | DTMF 1 | 「お支払いの…」 | 請求キュー | 合/否 | 合/否 |
| 例：営業時間外 | 時間外に発信 | 時間外案内 | 切断 | 合/否 | 合/否 |
| 例：無入力 | 入力なし×規定回数 | 再案内→終了案内 | 切断 | 合/否 | 合/否 |
期待結果の決め方は電話試験の期待結果をどう決める？、検証環境と本番を比べる考え方は電話システム移行の比較試験で解説しています。
3. 運用ルールの例
- フロー変更時は、変更内容と影響範囲を簡単に記録してから公開する
- 主要経路の試験シナリオを用意し、変更の有無にかかわらず定期実行する
- Webex側のプラットフォーム更新情報を確認し、更新後にも主要経路を試験する
まとめ
Flow Designerの手軽さを活かすには、手軽に変えても安全な仕組みが必要です。設計時の検証と実通話での試験を役割分担し、変更の種類に応じた範囲で公開前後に同じシナリオを実行することで、スピードと品質を両立しやすくなります。
CC Assuranceのサービス
Cyara Velocity：公開前後に同じシナリオを自動発信で実行し、案内と到達先を期待結果と照合します。