Implement New Voicemail Solutions with Exchange Unified Messaging

[アーティクル]
08/25/2016

コミュニケーションとコラボレーション

ユニファイドメッセージングへの移行を計画する

Jeff Goodwin

概要 :

ボイスメールの簡単な歴史
移行を計画する際の考慮事項
移行戦略
複数のサイトが直面する課題

従来のボイスメールシステムからユニファイドメッセージングプラットフォームへの移行は、厄介なプロジェクトになる場合があります。ただし、適切に計画を立てることによって、エンドユーザーの作業が中断される可能性を最小限に抑えつつ、非常に簡単にこの移行作業を完了できます。実際、

このような移行プロジェクトを遂行する際は、サービスの中断を最小限に抑えることが最も重要です。

移行作業を行ううえで、何を計画すればよいかを把握するには、まず、なぜボイスメールが企業でミッションクリティカルなアプリケーションと考えられているかを理解する必要があります。この基本的な情報は、ユニファイドメッセージングへの移行時に実装する必要がある機能や、それらの機能が管理者にとってなぜ重要であるかを理解するのに役立ちます。

ボイスメールの簡単な歴史

旅の出発点がわからなければ、目的地にたどり着くための計画を立てることはできません。まず過去にさかのぼり、ボイスメールシステムの概要を簡単に説明します。具体的には、ボイスメールシステムの起源、およびボイスメールシステムがどのように設計されたかを紹介します。ボイスメールシステムを最初に開発した人物については議論が分かれていますが、最初に市販されたボイスメールシステムは VMX と呼ばれるもので、この正式名称は Voice Message Exchange でした。

当初 VMX は、現在使用されている電子メールと同じように、企業内にいる他の従業員と音声でコミュニケーションを取るための手段として設計されました。このシステムでは、メッセージの送信、メッセージの転送、メッセージへの返信などのコマンドが提供されました。メッセージが録音された場合は、そのことがユーザーに通知されました。通知方法には、発信 (特定の電話番号を使用してユーザーを呼び出す) や未再生のメッセージがあることを知らせるライト (ユーザーの電話機に組み込まれているインジケータが光る) など、さまざまな方法がありました。

VMX の評判が高まるにつれて、組織ではボイスメールシステムどうしをネットワーク経由で接続するようになりました。これによって、従業員が全社規模の配布リストにブロードキャストメッセージを送信できる、全社規模のボイスメールソリューションが提供されました。

もちろん、ボイスメールシステムとの対話方法を提供するために、タッチトーンユーザーインターフェイス (TUI) を作成する必要がありました。これらの TUI は長年の間に変化を遂げ、残念ながら現在では、ボイスメール用の標準的なインターフェイスは存在しません。携帯電話にボイスメール機能が備わっている場合、「ボイスメールを聞くには 1 を押してください」のようなメッセージを耳にしたことがあるでしょう。ボイスユーザーインターフェイス (VUI) を使用する音声主導型のボイスメールシステムの普及に伴い、TUI 自体の重要性は以前よりも低くなっています。ただし、ユーザーが使用する特定のインターフェイスには、TUI が付属していることもあるので、これらを軽視しないようにしてください。

現在普及しているエンタープライズボイスメールシステムでは、分散型と集中型という 2 つのアーキテクチャが使用されています。図 1 のシアトル、ニューヨーク、およびオースティンのオフィスでは、分散型ボイスメールアーキテクチャが使用されています。このアーキテクチャでは、各サイトにボイスメールシステムが配置されます。これに対して、ロンドン、パリ、およびグラスゴーのオフィスでは、集中型のモデルが使用されています。このアーキテクチャでは、PBX インフラストラクチャがネットワーク経由で接続され、ロンドンの集中管理された場所にすべての通話がルーティングされます。どちらのモデルにも長所と短所はありますが、分散型モデルでも、ボイスメールシステムどうしをネットワーク経由で接続して、サイト間でメッセージを配信できることに注意してください。

図 1 2 つの一般的なボイスメールアーキテクチャモデル (画像をクリックすると拡大表示されます)

組織で分散型モデルを使用する理由は、主に 3 つあります。それは、ローカルでの可用性を確保する必要があること、使用する異種 PBX システムをネットワーク経由で接続できないこと、およびダイヤルプランを統一すると制限が発生することです。

組織によっては、ネットワーク障害が発生した場合でも、ローカルの PBX とボイスメールシステムを引き続き正常に実行し、サイト内でボイスメールシステムの機能をすべて提供できるようにする必要があります。また、その場合、音声自動応答装置 (IVR) システムも問題なく動作し、外部のユーザーも引き続きメッセージを録音できる必要があります。つまり、実質的にはエンドユーザーに一切影響を与えず、通常どおり動作を継続するということです。この説明には聞き覚えがあるかもしれません。上記の理由は、多くの組織で、Microsoft® Exchange Server を実行するサーバーをローカルに配置するのと同じ理由です。組織でリスク評価を実施して、ローカルでサービスを提供する必要があるかどうかを判断することをお勧めします。

買収によって組織が拡大すると、多くの場合、リモートサイトには、インフラストラクチャの残りの部分にネットワーク経由で接続できない PBX プラットフォームが残ります。この場合、組織では PBX を別の機器に変更するか (これはコストのかかるプロジェクトになる可能性があります)、サイトの環境を変更せずにボイスメールプラットフォームをネットワーク経由で接続することによって、シームレスなボイスメッセージ交換を提供できます。また、サードパーティ製のサーバーを使用して、異種ボイスメールシステムどうしをネットワーク経由で接続することもできます。

PBX どうしをネットワーク経由で接続するには、統一されたダイヤルプラン (UDP) が必要です。UDP を使用すると、電話とボイスメールの内線番号の重複を防ぐことができます。図 1 では、シアトル、ニューヨーク、およびオースティンで使用されている内線番号の範囲が重複しています。この理由は、米国内サイト用の UDP が存在しないからです。内線番号の範囲を 7 桁または 10 桁に拡張して UDP を作成することもできますが、これによって他の問題が発生します。

まず、各電話のダイヤルテンプレート、PBX のすべてのユーザーの内線番号、およびボイスメールシステムと連動するすべてのアプリケーションを変更することが必要になる場合があります。また、従業員は、すぐそこにいる同僚に電話をかける場合でも、7 桁または 10 桁の番号を思い出してダイヤルしなければならないので、フラストレーションの発生につながる可能性があります。

このような基本的な機能や設計上の問題点は、長い年月をかけて改善されてきましたが、ボイスメールの基本原理は変わっていません。メッセージ交換、ネットワーク、通知方法、ユーザーインターフェイス、およびアーキテクチャはすべて重要な要素であり、移行を計画する際には、これらを考慮する必要があります。

移行を計画する

ユニファイドメッセージングに移行すると、ユーザーがボイスメールを使用する方法から、アーキテクチャの設計方法、管理者が行う管理作業に至るまで、組織のあらゆる部分に変化がもたらされます。ユニファイドメッセージングシステムに移行する際は、これらすべての変化に対処する必要があります。移行を計画する際に考慮する必要がある項目のチェックリストを次に示します。

メッセージネットワーク従来のボイスメールプラットフォームから Exchange ユニファイドメッセージングに移行する組織では、共存期間を設ける必要があります。既にメッセージネットワーク (異なる複数のボイスメールシステムを相互運用するシステム) が組織に展開されている場合は、既存のシステムにユニファイドメッセージングシステムを追加するだけで済みます。複数の場所に個別のボイスメールまたは PBX システムを展開している組織では、メッセージネットワークを使用することを強くお勧めします。

インフラストラクチャユニファイドメッセージングのインフラストラクチャを設計する場合、ネットワーク要件、テレフォニーの統合、サーバーの配置などについて決定を下す必要があります。基本的な展開戦略に詳しくない場合は、以前の記事「Exchange Server 2007 を使用してユニファイドメッセージングを展開する」(technet.microsoft.com/magazine/cc137737) を参照してください。

自動応答多くのシステムには、たとえば、日中と夜間、および部門間で異なる、複数の自動応答機能が備わっています。従来のボイスメールシステムの自動応答を反映するには、組織の通信チームと協力して作業を行う必要があります。

未再生メッセージの通知実装するソリューションで、未再生のメッセージがあることを知らせるインジケータを使用しなくても問題ないと思われるかもしれませんが、ユーザーがこの機能を必要とする可能性は大いにあります。そのため、メッセージがあることを通知するこの赤色のライトとユーザーをどのように関連付けるかも重要です。さいわい、数社の企業によって、Exchange Server 用のメッセージインジケータアプリケーションが開発されました。

FAX のサポート多くの従来のボイスメールプラットフォームでは、FAX の受信がサポートされています。Exchange ユニファイドメッセージングでも FAX の受信機能がサポートされているので、新しく展開するシステムでもこの機能をサポートすることをお勧めします。

音声自動応答装置一部の従来のボイスメールプラットフォームでは、Exchange ユニファイドメッセージングで再現できない音声自動応答装置 (IVR) アプリケーションがサポートされています。適切な代替システムが見つかるまでは、このシステムを残しておくことをお勧めします。

管理 Exchange ユニファイドメッセージングは、Active Directory® と Exchange メールボックスサーバーの役割に依存します。このため、ユニファイドメッセージングの展開が、管理作業やシステム要件などにもたらす影響を考慮する必要があります。

ユーザーインターフェイス新しい UI を展開する際は、ユーザーを対象としたトレーニングを実施する必要があります。Exchange ユニファイドメッセージングでは、多くの携帯電話プロバイダとよく似たインターフェイスが使用されるので、ほとんどのユーザーが直感的に操作を行うことができます。また、音声認識機能も使用されるので、ユーザーはタッチトーンを使用する必要がありません。Exchange Server では、この機能を Outlook® Voice Access と呼んでいます。

トレーニングユニファイドメッセージングに移行すると、ユーザーがコミュニケーションを取る方法やボイスメールを使用する方法が一新されます。ユーザー向けのトレーニングを実施し、UI だけでなくベストプラクティスについても説明することによって、ユーザーがより効率的な新しい方法を使用してコミュニケーションを行うことができるようにする必要があります。たとえば、ユーザーは、電子メールの受信トレイにあるボイスメールをどのように操作したらよいかや、ユニファイドメッセージングに関するいくつかの詳細設定をどのように構成したらよいかを理解していない場合があります。

実際的な移行戦略

大規模な組織でユニファイドメッセージングソリューションへの移行作業を行う場合、いくつかの課題に直面するに違いありません。ただし、私はユニファイドコミュニケーションに 10 年間携わっており、組織の要件が非常に具体的である複雑な移行作業でさえ、無事に成功するのを目の当たりにしてきました。

組織のサイトが 1 つであるか複数であるかにかかわらず、次の 5 つの基本手順に従って移行戦略を考えると役立ちます。

ソリューションを計画および設計します。
ユニファイドメッセージングサーバーの役割をインストールして構成します。
パイロットグループを移行します。
パイロットグループから返されたフィードバックに基づいて設計を変更します。
ユーザーを移行します。

もちろん、複数のサイトを所有する組織は、通常 1 つのサイトのみを所有する組織は遭遇することがない、いくつかの課題に直面します。これらの課題については、補足記事「複数のサイトが直面する課題」で別途説明します。

ソリューションの計画と設計は、移行プロセスの最も重要な段階です。このプロジェクトは、ユニファイドメッセージングチームに任命することをお勧めします。ユニファイドメッセージングチームには、通信、Active Directory、Exchange、ネットワーク、セキュリティ、トレーニング、プロジェクト管理などに関する専門知識を持つ、組織のさまざまな部門の代表者を含める必要があります。これによって、組織の既存の PBX、ボイスメール、および電子メールインフラストラクチャの詳細を把握できます。

設計が完了したら、ユニファイドメッセージングサーバーの役割をインストールして構成できます。ユニファイドメッセージングサーバーは、既存のボイスメールシステムと共存させる形でインストールできます。文書化されたベストプラクティスに従って、作業を進めるようにしてください。

これで、ユニファイドメッセージングサーバーをテストする準備ができたので、小規模なパイロットユーザーグループを指定して、新しいシステムに移行します。このグループは、25 ～ 50 人のユーザーで構成することをお勧めします。グループに含めるユーザーは慎重に選択してください。IT 部門と通信部門のスタッフから、部門管理者と販売員に至るまで、さまざまなグループのユーザーで構成されるパイロットグループを作成するようにします。このように広い範囲のユーザーを含めることによって、設計が目的に合っているかどうか、どのような要件を考慮すればよいか、ユーザーにはどのようなトレーニングが必要であるかなどの判断をより適切に下すことができます。

パイロットグループからフィードバックを受け取ったら、テスト中に発見されたすべての問題に対処できるように、設計を変更する必要があります。具体的には、考慮事項に関するセクションで説明した項目を再度確認し、組織の要件に合わせて、これらの項目に適切に対処します。通常、この段階で最もよく発生するのは、トレーニングに関連する変更であることに注意してください。

最後に、ユーザーを移行します。システムを完全な運用環境に移行する方法については、多くの考えと戦略があります。主な 2 つの方法論は、段階的な移行とフラッシュカットです。

数週間から数か月にわたってユーザーコミュニティを段階的に移行すると、従来のボイスメールシステムのユーザーとユニファイドメッセージングのユーザーとの間にどこにも接続されないボイスメールが生まれます。これにより、ユーザーどうしがボイスメールを使用してメッセージを転送できなくなります。また、設計にメッセージネットワークソリューションを含めなかった場合、一部のビジネスコミュニケーションが中断されます。これらのコミュニケーションが必要である場合は、初期設計にメッセージネットワークソリューションを含めることをお勧めします。

フラッシュカット移行の場合、すべてのユーザーを一度に移行します。一般に、組織ではこのような移行を週末に行います。これは、システムをテストし、構成を変更し、深刻な問題が発生した場合は移行前の環境に戻すことができる時間を確保するためです。

どちらの方法を使用する場合でも、パイロットグループから挙げられた一般的な質問と回答に基づいて、ヘルプデスクスタッフのトレーニングを実施するようにしてください。また、ヘルプデスクスタッフが、ユーザーの有効化、ユーザーが有効であるかどうかの確認、パスワードの変更など、主要な作業を確実に行うことができるようにする必要があります。

移行のチュートリアル

これから移行のサンプルを紹介しますが、環境をユニファイドメッセージングに正常に移行するうえで最も重要なのは、内部および外部ユーザーの作業をできる限り中断することなく、ユーザーのボイスメールボックスを従来のボイスメールプラットフォームからユニファイドメッセージングに移行することです。

図 2 は、組織のアーキテクチャを詳しく示しています。ここでは、この混合型 Exchange アーキテクチャには変更を加えません。米国に拠点を置くオフィスのプライマリデータセンターは、シアトルにあります。オースティンの IT アプリケーションはすべてシアトルから提供され、ニューヨークオフィスではローカルの Exchange サービスが提供されます。米国のオフィスでは、異種 PBX インフラストラクチャが使用されているので、オフィスごとに異なるボイスメールシステムが展開されています。技術的に考えると、PBX インフラストラクチャをネットワーク経由で接続して、集中管理された場所からボイスメールを提供することはできません。一方、ヨーロッパのオフィスの場合は、集中管理されたデータセンターがロンドンにあります。ヨーロッパの IT アプリケーションと通信アプリケーションは、すべてこのデータセンターから提供されます。

図 2 移行前のサンプルアーキテクチャ (画像をクリックすると拡大表示されます)

ボイスメールインフラストラクチャ全体は、Octel (現在は Avaya) プラットフォームに基づいています。すべてのボイスメールシステムは、Octel Analog Networking (OAN) を使用して、ネットワーク経由で接続されています。OAN は、アナログ電話回線と長距離電話を使用して、ネットワーク経由でボイスメールメッセージを送信するための専用ネットワークプロトコルです。このアーキテクチャを使用すると、サイト間、つまり全社規模のボイスメッセージングが可能になります。

複数のサイトが直面する課題

複数のサイトで構成される組織は、ユニファイドメッセージングを展開する際、非常に多くの課題に直面します。さいわい、既に他の組織が直面したいくつかの課題から、解決策を導き出すことができます。この記事ですべての課題を取り上げることはできませんが、さまざまな組織の作業にかかわった際に遭遇した最も一般的な課題について説明します。

集中管理された Exchange Server アーキテクチャと混合テレフォニー環境を使用している

分散環境の設計は簡単です。これを行うには、ユニファイドメッセージングサーバーを配置し、それを各サイトのローカル PBX と統合します。では、集中管理された環境、さらには混合環境の場合はどうでしょうか。サイトでローカルのユニファイドメッセージングサービスを提供する必要があるかどうかを考えてみてください。ローカルでユニファイドメッセージングサービスを提供すると、集中管理された Exchange サーバーにそのサイトから接続できなくなりますが、引き続き自動応答機能が提供されるので、外部のユーザー (おそらくその多くは顧客です) はメッセージを録音できます。どちらを取るかは、そのサイトがどの程度ミッションクリティカルであるか、およびソリューションをどれくらい簡単に管理できるかによって異なります。

サイトでローカルのサービスを提供する必要がある場合は、サイトにリモートユニファイドメッセージングサーバーを配置することをお勧めします。また、その必要がない場合は、ローカルサイトに SIP ゲートウェイをインストールできます。Exchange ユニファイドメッセージングには柔軟性があり、PBX インフラストラクチャをネットワーク経由で接続する必要はありません。また、統一されたダイヤルプランも必要ありません。

現在 Exchange アーキテクチャをアップグレードしている最中である

多くの顧客は、Exchange インフラストラクチャをアップグレードしている最中にユニファイドメッセージングへの移行を開始することをためらいます。ユニファイドメッセージングに移行することが既に決定している場合は、Exchange サーバーのアップグレード中に移行に踏み切ることをお勧めします。アップグレード計画に従って作業を進めれば、プロジェクトが大幅に複雑になることはありません。

10 人未満のメンバで構成される小規模なサイトが多数あり、その一部のサイトには PBX が配置されていない

ローカルに PBX が配置されている小規模なサイトでは、ローカルサイトに SIP ゲートウェイをインストールすれば問題ありません。ローカルに PBX が配置されていないサイトでは、テレフォニー技術を使用して、集中管理された PBX に通話を転送することによって、ユニファイドメッセージングシステムに通話をルーティングできます。つまり、ほとんど費用をかけずに、組織の小規模なリモートサイトにユニファイドメッセージングサービスを展開できます。

重要なことを 1 つ述べておくと、実はこのような小規模なサイトは、移行の優れた実験台になります。一般的な移行戦略の 1 つに、ネットワークの境界から中核となる部分に向かって移行を進める方法があります。まず小規模なサイトを移行してから、ユニファイドメッセージングチームと協力して事後分析を実施し、どの部分が正常に機能したか、およびどのような問題が発生したかを把握します。これによって、次のサイトを移行する際に、この結果を反映できます。

ユニファイドメッセージングチームは、ネットワークの境界から中核となる部分に向かって移行を進めることにしました。どのサイトでも、ユニファイドメッセージングサーバーを配置する際は、Exchange Server アーキテクチャに従うというベストプラクティスに基づいて作業を行います。チームでは、考慮事項に関するセクションで説明した項目を考慮しながら、サイトごとに独自の計画ドキュメントを作成します。このドキュメントは、サーバーのインストールと構成、ユーザーのトレーニング、移行戦略の計画などに使用します。

チームは、サイトごとにユーザーをユニファイドメッセージングシステムにフラッシュカットし、今後も使用を続ける IVR アプリケーションをサポートするために、代替ソリューションが見つかるまで従来のプラットフォームをそのまま使用する計画を立てました。また、あるサイトの移行後、30 日間待ってから、次のサイトを移行することにしました。この期間は、さらに多くのユーザーを移行し、ヘルプデスクサポートへの問い合わせが増える前に、各サイトを新しいプラットフォームに適合させることを目的としています。

まずは、オースティンオフィスを移行します。オースティンの電子メールはシアトルから提供されるので、チームは、ユニファイドメッセージングサーバーの役割をシアトルにインストールし、オースティンに SIP ゲートウェイをインストールして PBX 統合を提供します。従来のボイスメールプラットフォームはネットワーク経由で接続されているので、メッセージネットワークサーバーをインストールすることによって、ユニファイドメッセージングプラットフォームをネットワーク経由で接続する必要があります。その後、ユーザーが新しいシステムに関するトレーニングを受け、移行がスムーズに進行したので、次はニューヨークオフィスを移行することにしました。

ニューヨークオフィスには、独自のメールボックスとハブトランスポートサーバーが配置されています。そのため、ベストプラクティスに従うと、ニューヨークにユニファイドメッセージングサーバーをインストールする必要があります。このサーバーは、移行計画のドキュメントに従ってインストールします。インストールしたサーバーは、メッセージネットワークサーバーノードとしてボイスメールネットワークに追加されます。このオフィスのユーザーもトレーニングを受け、ユニファイドメッセージングにスムーズに移行できました。

シアトルオフィスには、オースティンの移行段階で展開したユニファイドメッセージングサーバーが既に配置されています。チームは、シアトルオフィスとオースティンオフィスをサポートするのに十分なボイスメールポートがサーバーに実装されていると判断しました。シアトルのユーザーもトレーニングを受け、ユニファイドメッセージングに移行できました。

ヨーロッパのアーキテクチャは、はるかに簡単に設計できます。PBX インフラストラクチャをネットワーク経由で接続し、Exchange を集中管理します。ユニファイドメッセージングサーバーをロンドンに展開し、各サイトを小規模なサイトから順に移行します。図 3 は、最終的なアーキテクチャを示しています。

図 3 移行後のサンプルアーキテクチャ (画像をクリックすると拡大表示されます)

計画に従うことの重要性

私はこれまでに何度も、ユニファイドメッセージングへの移行が失敗した原因を解明するよう依頼されたことがあります。これらの組織の多くでは、1 つ以上の重要な規則が守られていませんでした。

まず、ユニファイドメッセージングは、単なるボイスメールシステムではないことを忘れないでください。これはミッションクリティカルなアプリケーションなので、それを意識して移行作業に取り組む必要があります。また、ユーザーは、ボイスメールテクノロジを使用して情報交換を行います。ユニファイドメッセージングはビジネスアプリケーションなので、この記事で説明したすべての考慮事項を念頭に置いて移行を計画してください。

ユニファイドメッセージングに移行する際は、必ず通信チームの協力を仰ぐ必要があります。通信チームは、企業のインフラストラクチャに統合されているテレフォニーアプリケーションに最も精通しています。

ユニファイドメッセージングに移行する際は、これがエンタープライズソリューションであることを前提とした計画を立ててください。最初の段階で 1 つのサイトを実装している場合でも、常に全体像を念頭に置いて作業する必要があります。たとえば、1 つのサイトを実装する際に、他のサイトにメッセージネットワークをインストールしなかった場合、ユーザーどうしのコミュニケーションに影響を及ぼすことがあります。もちろん、これはたいへんな作業になるので、すべての IT アプリケーションを考慮したアーキテクチャを設計する際は、専門家に相談することをお勧めします。

最後に、トレーニングの重要性を軽視しないでください。ユニファイドメッセージングに移行すると、ユーザーがコミュニケーションを取る方法やボイスメールを使用する方法が一新されます。自分にとって直感的に理解できるものでも、他の人が同じように理解できるとは限りません。最もスムーズに移行を完了するには、適切なトレーニングを実施する必要があります。

Jeff Goodwin は、The VIA Group のシニアテクノロジストです。専門分野は、Exchange とユニファイドメッセージングの設計と展開です。連絡先は jgoodwin@theviagroup.com (英語のみ) です。

目次

その他のリソース