オンプレミスによるUCの導入

　オンプレミスによるUCの導入は、企業ネットワーク内にサーバを配置する伝統的なモデルだ。

　自社のサイトに信頼性の高い、低遅延で低ジッタなWANやインターネット接続がない場合、クラウド型、またはクラウドおよびオンプレミスのハイブリッド型は意図した通りに機能しない可能性が高い。このような場合、低遅延の接続をコントロールしやすいオンプレミスによる導入が妥当な選択肢となる。

　管理者がインフラレベルでUC環境を完全に制御する必要がある場合も、オンプレミスによるUCの導入が最適だろう。カスタマーコンタクトセンターを管理する企業は、エンドユーザーのアプリケーションをより適切に制御し、電話サービスや料金オプションに関してより柔軟性を持たせるために、オンプレミスのUCプラットフォームを必要とする可能性がある。

　クラウドやハイブリッドによる導入の場合、サービスプロバイダーが提供する価格設定や導入オプションに翻弄されるため、企業は柔軟性を失うことになる。オンプレミスによる導入のコストは、小規模オフィス向けの機器の場合は4000ドルからであり、大企業向けの機器は数百万ドルに及ぶこともある。

　オンプレミスによる導入が適していると判断した企業では、サーバやデバイス、アプリケーションを最新の状態に保つ責任を組織とUC管理者が負うことになる。アップデートが新機能を追加するものであれ、新たに発見されたセキュリティ上の欠陥を修正するものであれ、その責任は社内の管理者が負うことになる。従業員が過重労働に陥っている場合、この種のアップデートやパッチ適用が大幅に遅れる可能性がある。

　さらに、大規模なソフトウェアのアップデートでは、高額な先行投資と管理者の労力を必要とする場合がある。そのため、最新かつ最も安全なUCアプリケーションを従業員に提供しようとする企業には、クラウドまたはハイブリッドによる導入の検討をお勧めする。

　クラウドモデルやハイブリッドモデルに押され、オンプレミスモデルの人気は低下している。それでも、幾つかの一般的なユースケースにおいて、オンプレミスは依然として最良の選択肢だ。

パブリッククラウドによるUCの導入

　クラウドコンピューティングは、過去10年間にわたり企業のIT分野に変化を起こしてきた。しかし、IT部門が、UCアプリケーションをパブリッククラウドのホスト型またはUC as a Service（UCaaS）アーキテクチャに本格的に移行しはじめたのは、ここ数年の話だ。クラウドの採用率が他の用途より低い主な理由は、UCアプリケーションにおいて、ストリーミングメディアをリアルタイムに送受信する際に、低遅延の接続が必要とされているためだ。

　WANやインターネット接続が成熟し、信頼性が高まるにつれ、IT部門はアプリケーションやデータをクラウドに移行し始めた。今では多くの企業が、パブリッククラウドを社内インフラの延長として扱っている。

　この傾向が続く中、企業は他の全てのビジネスアプリケーションとともに、UCサービスをクラウドに移行することへの関心を高めている。これにより、複雑なオンプレミス型のUCサーバを維持する際のインフラ負荷が減少する。実際、SaaSクラウドモデルを使用するUCの導入においては、デスクフォンやビデオ会議デバイスなどのオンプレミスのUCエンドポイントハードウェアのみに対処すればよい。

　その他の全てのUCコンポーネントやサービスはクラウドで管理されるため、基盤となるインフラの障害やサーバ管理、UCプラットフォームのアップグレードについて心配する必要はない。これらの責任はサービスプロバイダーにある。さらに、新機能やサーバソフトウェアをサービスプロバイダーがアップグレードするため、最新かつ最高のコミュニケーションツールに迅速にアクセスできる。

　UCaaSの導入について評価する際、企業はさまざまな費用を考慮する必要がある。企業には、デスクフォンやビデオ会議デバイスなどのエンドユーザーデバイスが必要となる。これらのハードウェアは、直接購入するか、参加するベンダーやテクノロジーパートナーを通じてリースすることになる。

　ライセンス費用は、ユーザーが使うUCアプリによって異なり、通常はアラカルト方式である。選択肢として、音声やビデオ会議、Web会議、チャット、ファイル保存などが含まれる。一般的に、これらのサービスはユーザー1人当たり月額数ドルから50ドル以上の費用がかかる。

　テレワークが増えている企業にとって、UCaaSプラットフォームの展開モデルは適している。パブリッククラウドにUCアプリケーションを集中的に配置することで、ユーザーはVPNソフトウェアを使用せずに世界中のどこからでもUCサービスにアクセスできる。これにより、UCサービスのアクセスが簡素化され、ユーザーが企業公認のUCアプリを使用する可能性が高まり、シャドーITのリスクも低減する。

　クラウドUCの展開が失敗するケースとしては、オフィスやリモートオフィスとクラウドサービスプロバイダー（CSP）の接続が不十分であったり、冗長性が欠如していたりすることが挙げられる。これらは特に、世界中にリモート拠点を持つ大規模で地理的に分散した組織にとって懸念事項だ。一部の拠点ではクラウドUCの利用に十分な接続性があるかもしれないが、全ての拠点で必要な低遅延、高スループット、冗長性を確保することはサービスプロバイダーにとってほぼ不可能と考えられる。

　音声通信に大きく依存する企業にとっては、オンプレミスまたはハイブリッドUCのオプションが、より信頼性が高いものの、サポートに必要な複雑さとコストが増すため、より適しているかもしれない。

ハイブリッドオンプレミスとクラウドUCの展開

　既にオンプレミスUCサーバに大きな投資をしている企業で、パブリッククラウドUC市場を試したい場合、ハイブリッドモデルが適している。多くの企業は、音声やコンタクトセンターサーバなどの重要な部分をオンプレミスに保持しながら、チームチャットやWeb会議、ファイル共有などの機能をクラウドに移行する選択をしている。これにより、IT部門はオンプレミスUCの多くの設備投資（CAPEX：CAPital EXpenditure）利用しながら、遅延に敏感でないサービスをクラウドに移すことが可能だ。

　新しいUCツールが登場するにつれ、IT部門はそれらを社内に展開するか、CSPを通じて展開するかを選択できる。ハイブリッドなUCの展開モデルは、全ての選択肢を保持したい企業にとって理想的だ。しかし、ハイブリッド展開は多くの組織にとって暫定的な措置とみなされるべきだ。最終的には、完全にホストされたUCサービスがオンプレミスと同じくらい信頼性が高く、機能が豊富だと認識されるだろう。そして、ハイブリッド展開の魅力は次第に薄れると予想される。

　技術的な障害を除けば、正しいUC展開モデルを決定する際は、主にそれを使用する人々に判断が任されるべきだ。エンドユーザーやネットワークおよび音声エンジニア、ITマネジャーは協力して、現在のUCアプリケーションでエンドユーザーが何を使用しているか、また何を変更したいかを話し合い、エンドユーザーのニーズを把握することが望ましい。このステップを踏むことで、新しいUCプラットフォームでユーザーがどのツールに興味を持つのかを評価できる。

　例えば、多くのビジネスユーザーは、オフィスの外で働く時間が多いか、よりモダンなチームチャットコミュニケーションツールを使用しているため、固定電話を使用しなくなっている。その場合、管理者はUCアプリケーションと展開方法を適宜調整すべきだ。

　新しいUCプラットフォームをクラウドまたはオンプレミスに展開する際、企業は次の2つの移行方法から選択できる。

完全移行

　全てのユーザーを一度に新しいUCプラットフォームに移行する。この場合、IT部門は一定期間、2つの異なるUC展開をサポートする必要がない。このアプローチの主な欠点は、全ユーザーを新システムに切り替えるため、移行期間が集中することだ。移行期間中に重大な問題が発生すると、組織全体に大きな影響を与える可能性がある。

ローリング移行

　部門ごとまたは建物ごとに段階的に移行を完了する。この方法では、新しいUCプラットフォームでの潜在的なミスや問題を管理する余地があり、全ビジネスに影響を与えることなく対応できる。この方法は実行に時間と労力がかかるが、問題が組織全体のUCユーザーに影響を与えるリスクを軽減する。

　いずれの移行方法を選択するにせよ、UCのような重要なビジネスツールを展開する際には、本稼働前にできるだけ多くのバグを解消することが重要だ。パイロットプログラムはこの目標を達成する優れた方法だ。

　UCアプリを異なる方法で使用する小規模だが多様な従業員を選択すると、新しいUC展開でのハードウェア、ソフトウェア、設定の問題を把握しやすくなる。中規模および大規模企業でパブリッククラウドやハイブリッドで展開した経験から、この段階で収集されたエンドユーザーからの情報は最終展開において非常に価値があることが分かった。特に、企業ごとに大きく異なる特定の機能を微調整する際には有用だ。