翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ユーザージャーニーのワークストリーム ユーザージャーニーのワークストリームには、労力や影響を最小限に抑えて変更または取り消しを行うことできる決定事項も含まれます。ユーザージャーニーの基本的な構築から始めて、最終製品に到達するまで頻繁かつ迅速に反復することに重点が置かれています。最終的なユーザージャーニーが最初に提案されたものと全く同じになることは稀であるため、このワークストリームではアジャイルで反復的なアプローチが適しています。 ユーザージャーニーのワークストリームは、検出、設計、構築、テスト、デプロイ、本番稼働開始後のサポートの 5 つのフェーズで構成されています。 ![コンタクトセンターの移行におけるユーザージャーニーのワークストリーム](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-migration-connect/images/journey.png) ## 発見 このフェーズでは、既存のユーザージャーニーフローと設計を収集し、それらをコンタクトフロー構築チームに渡します。これらが存在しない場合や、新しいユーザージャーニーを設計する場合は、ワークショップにステークホルダーを集め、次のようなビジュアルキャプチャツールを使用してユーザージャーニーのフレームワークを共同で開発します。 + ビジュアルキャンバスツール — Microsoft PowerPoint、Microsoft Visio、draw.io などのツールを使用します。ワークショップに参加しているすべてのステークホルダーとキャンバスを画面共有します。ブロックや決定ポイントを追加してエンドツーエンドのユーザージャーニーを構築し、後で確認する必要があるステップ (キューイングメッセージのオーディオファイルの正確な文言やインポートなど) のプレースホルダーを追加します。プレースホルダーを確認する必要がある所有者の名前を追加します。 + 問い合わせフローデザイナー – draw.io や Visio などの描画ツールを使用する代わりに、Connect Customer に含まれている[問い合わせフローデザイナー](https://docs.aws.amazon.com/connect/latest/adminguide/concepts-contact-flows.html#concepts-visual-editor)を使用して、画面共有でユーザージャーニーを開発および文書化することを検討してください。後で確認する必要があるステップ (キューイングメッセージのオーディオファイルの正確な文言やインポートなど) には、[プロンプトブロック](https://docs.aws.amazon.com/connect/latest/adminguide/play.html)プレースホルダーを使用します。シンプルな[text-to-speech (TTS) ](https://docs.aws.amazon.com/connect/latest/adminguide/text-to-speech.html)プロンプトブロックを使用して、ステップを確認する所有者を記録します (例えば、「John Smith が提供するキュー A メッセージ .wav ファイル」）。これにより、ユーザージャーニーとルーティングロジックのエンドツーエンドのテストを並行して実行できます。 ワークショップの参加者:  + プロジェクト管理者 + ビジネスアーキテクトとソリューションアーキテクト + ビジネスアナリスト + サービスラインの所有者とオペレーター ## 設計 設計ドキュメントはオプションです。ドキュメントは、コンタクトフローのサイズと複雑さによって異なります。直感的でわかりやすいフローチャートインターフェイスを備えたコンタクトフローデザイナーを使用すると、ジャーニーが自己文書化され、コンタクトフローの実際の構築を表すことができます。これにより、ユーザージャーニーの迅速かつアジャイルな開発における信頼できる単一の情報源が確保されます。それ以外の場合は、コンタクトフローのスタンドアロン設計ドキュメントが時間の経過とともに実際の構築から逸脱しないように、変更管理を徹底して行う必要があります。 ## 構築 Connect 顧客設定は、Infrastructure as Code (IaC) ツールで[AWS CloudFormation テンプレートと APIs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_Connect.html) を使用して利用できます。DevOps ツールを使用して、セキュリティプロファイルや問い合わせフローなどの Connect Customer コンポーネントを構築および管理します。コンタクトフローデザイナーを使用してフローを設計する場合は、IaC DevOps ツールにフローを組み込み、JSON ファイルとして手動でエクスポートすることができます。 **注記** また、他の AWS アカウントの作成中に開発環境で問い合わせフローの構築を開始し、Connect Customer インスタンスの準備ができたら、フローをテスト環境と本番環境にエクスポートすることもできます。 ## テスト テストフェーズは次の 2 つの連続したサブフェーズで構成されます。  + 機能テスト – Connect Customer で問い合わせフローが作成されると、アジャイルスプリントを繰り返し実行します。実施者: 機能テストチーム + ユーザー受入テスト (UAT) — コンタクトフローが機能テストに合格した後にのみ実施されます。実施者: クライアントのビジネスユーザー (専任チームまたはサービスラインビジネスユニットのユーザー) ## デプロイ このフェーズでは、ユーザーがログインできるように、エージェントとユーザーの認証情報が Connect Customer 本番稼働用インスタンスにアップロードされます。コンタクトフローは、前のフェーズの UAT テストに合格した後にのみアップロードしてください。Connect Customer ダッシュボードで一時的な電話番号を取得し、問い合わせフローに割り当てます。これらの電話番号はプロジェクトチームにのみ表示され、プロジェクトチームはその番号を使用してテストコールを行います。多くの場合、プロジェクトチームはこのプロセス中にいくつかの UAT スクリプトを実行します。このアプローチでは、システムが本番稼働し、実際のエージェントがワークフローにアクセスできるようになる前に、ユーザージャーニーの準備 (パイプクリーン) のテストを行います。本番稼働の予定時刻になると、この一時的な番号はお客様が使用するパブリックにルーティン可能な番号に置き換えられます。この時点で新しいシステムに切り替わります。必要に応じて、番号を従来のサービスラインに切り替えて、変更をロールバックすることができます。 ## 本番稼働開始後のサポート (PGLS) プロジェクトチームは、新しいコンタクトセンターが本番稼働してから最初の数週間は、サービスラインのステークホルダー、通常業務 (BAU) サポートチーム、エンドユーザーとの連携を続けます。プロジェクトチームは、ユーザーが新しいシステムを使い始める際のサポートを行い、BAU サポートチームと一緒に問題のトラブルシューティングに取り組み、お客様やエージェントのフィードバックに基づいてコンタクトフローを改善します。