翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 技術基盤のワークストリーム
<a name="tech-foundation"></a>

このワークストリームには、変更すると大規模なリワークが必要な決定事項が含まれるため、慎重な設計、幅広い協議、DevOps プロセスとテストへの先行投資が重視されます。

技術基盤のワークストリームは、検出とロードマップ、設計、構築、テスト、本番稼働開始後のサポートの 5 つのフェーズで構成されています。

![コンタクトセンターの移行における技術基盤のワークストリーム](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-migration-connect/images/tech-foundation.png)


## 検出とロードマップ
<a name="tf-discovery"></a>

このフェーズでは、以下の情報を収集し、ワークショップをスケジュールします。
+ 現状のマッピング — システムや機能を調べ、データを収集し、SME と面談してコンタクトセンターの現状を把握する。
+ 予定されている設計とギャップ評価 – コンタクトセンターのすべてのエージェントとお客様にとって理想的なエクスペリエンスを決定し、プロジェクトのスコープを決定する。
+ ギャップの解消計画 — コンタクトセンターの将来の状態を構築およびデプロイするためのロードマップを概説する。

ワークショップの参加者: 
+ プロジェクト管理者
+ ビジネス、ソリューション、テクニカル、セキュリティアーキテクト
+ インフラストラクチャプラットフォームの所有者

## 設計
<a name="tf-design"></a>

このフェーズでは、設計ドキュメントを作成します。設計アーティファクトを作成するための独自の規則やプロセスがある場合もあります。設計ドキュメントには、Connect Customer の設定、ネットワーク、セキュリティの 3 つ以上のセクションを含めることをお勧めします。確認と承認の作業を効果的に行うために、各セクションには異なる専門性を持つステークホルダーグループが存在する可能性が高いため、これらの 3 つの領域について個別のドキュメントを作成することをお勧めします。ステークホルダーには、アーキテクト、セキュリティおよびコンプライアンスチーム、プラットフォームの所有者を含める必要があります。

## 構築
<a name="tf-build"></a>

このフェーズでは、DevOps ツールを使用して安定リリースを標準化および管理することで、Infrastructure as code (IaC) の原則に従います。手動のビルドプロセスを採用することは、たとえそれがビルドの迅速な開始に役立つとしても避けてください。これは、ビルドがより複雑になり、テスト環境や本番環境に昇格するにつれて、安定性に対するリスクが高まり、バグの数が増加する可能性があるためです。独自の DevOps ツールがない場合は、すぐにオンにできる AWS CodePipeline や AWS CodeBuildなどの AWS ツールを使用することをお勧めします。これらのツールの設定にかかる労力をプロジェクトのスコープに組み込んでおくことで、ツールが長期的に有益なものとなり、DevOps の原則に従うことができるようになります。少なくとも 3 つの AWS アカウント (開発、テスト、本番稼働) に分けて構築することをお勧めします。DevOps ツールと自動化は、これらの環境でコードを移動する際に役立ちます。

## テスト
<a name="tf-test"></a>

テストフェーズは次の 3 つのサブフェーズで構成されます。

1. ユニットテスト — 個々のインフラストラクチャコンポーネントをテストして、それらが適切で、設計仕様の範囲内であることを確認します。実施者: デベロッパー

1. 統合テスト — Microsoft Active Directory (AD) ID 管理サービスなど、統合の境界を形成する項目をテストします。実施者: デベロッパー

1. 製品テスト — インフラストラクチャ全体における機能ジャーニーのエンドツーエンドのテスト。例えば、各エージェントイベントがセキュリティモニタリングツールに記録されている、通話が行われている、通話の録音が適切な Amazon Simple Storage Service (Amazon S3) バケットに保存されていることをテストします。実施者: 機能テストチーム

## デプロイ
<a name="tf-deploy"></a>

ユーザージャーニーの本番稼働がスケジュールされている場合、インフラストラクチャがライブトラフィックを処理できる状態になっている必要があります。デプロイフェーズでは、 AWS サービスクォータが予想されるコールボリュームと同時エージェント数を満たし、番号の移植または通話料無料番号サービス (TFNS) の再指定が完了し、ライブトラフィック量が増えるにつれてバックエンドシステムのヘルスがモニタリングされるようにすることに重点を置いています。また、セキュリティおよびコンプライアンスチームは、各自の視点からプラットフォームがライブトラフィックに対応できる状態にあることを確認する必要があります。

## 本番稼働開始後のサポート (PGLS)
<a name="tf-post"></a>

プロジェクトチームは、新しいコンタクトセンターが本番稼働してから最初の数週間は、通常業務 (BAU) サポートチームとエンドユーザーとの連携を続けます。プロジェクトチームは、ユーザーが新しいシステムを使い始める際のサポートを行い、BAU サポートチームと一緒に問題のトラブルシューティングに取り組み、フィードバックに基づいてサポートドキュメントを改善します。