つい先日、一部の事業部（40~50人規模）を対象にZooｍPhoneを導入した。
当社はグローバルで事業を展開しており、その都合でどうしても避けられないのが「時差の壁」だ。
特に、夜中にかかってくる海外からの電話対応は、日本のメンバーにとって地味に大きな負担だった。
「どうやったら、夜の着電を無理なく海外拠点に転送できるか？」
「メールやチャットじゃなくて、ちゃんと電話でつながる仕組みをどう作るか？」
そんな課題をきっかけに、Zoom Phoneの導入に踏み切った。
選んだ理由はシンプルで、既に全社でZoomを使っていたからだ。
Zoom MeetingやZoom Webinarと同じUIで操作でき、しかも管理コンソールも一元化できる。
「どうせならこの流れで電話もZoomにしてしまおう」という発想だった。
ただし、このプロジェクトは単なる「電話アプリの切り替え」では終わらなかった。
導入を進めるなかで、10DLCという規制の壁にぶつかり、USテナントでのライセンス調達に翻弄され、既存のDialpadやTeamsとの兼ね合いにも頭を抱えることになった。
結果的には「電話をどう使うか」という技術の話以上に、
「どうやって拠点間で合意形成を進めるか」
「どうやって規制や契約の制約を乗り越えるか」
という情シスならではの立ち回りが求められるプロジェクトになった。
このブログでは、そんなZoom Phone導入のリアルを、成功も失敗も含めて記録していこうと思う。
最初の壁：10DLC規制
Zoom Phoneを導入して最初に直面した大きな問題、それが 10DLC規制 だった。
アメリカでは、企業がSMSを送る際に「10桁のローカル番号（10DLC）」を使う場合、キャリアに事前登録をしないといけない。スパム対策のために導入された仕組みだが、実際には手続きがやたら複雑で、登録が済まないとSMSが一切送れないという厳しい制約になる。
日本テナントでZoom Phoneを使い始めた僕らは、当然SMSも使える前提で設計していた。
ところが、いざ検証を進めると「SMSが飛ばない」という事態に直面。調べてみると10DLCに引っかかっていて、簡単に解決できる問題ではないことが分かった。
「え、じゃあ日本テナントではSMS使えないの？」
「登録に数カ月かかるなら、そもそもこのタイミングで進めるのは無理じゃない？」
正直この時点で、計画が頓挫しかけた。
でもここで止まってしまうと、夜間の電話転送も始められない。
そこで発想を切り替えた。
- 日本テナントでは電話中心に利用する（発着信、ボイスメールなど）
- SMSは海外拠点のZoomテナントを活用して検討する
- 当社の海外拠点では、日本法人とは別テナントで既にZoomを利用していたため
つまり、「全部を一気に解決する」のではなく、「できるところから分担して進める」戦略に切り替えたのだ。
この判断が、結果的にプロジェクトを前に進める突破口になった。
情シスの仕事って、技術で解決できることよりも、制約をどう受け止めて次の一手に変えるかが勝負だな、と改めて実感した瞬間だった。
USテナントでの検証劇
日本テナントでSMSが封じられたことで、矢面に立つことになったのが USテナント だった。
ここでSMSを動かして、グローバル拠点での本格運用につなげる――そういう役割分担だ。
ライセンス問題との戦い
ところが、ここでもすぐに壁にぶち当たった。
Zoomの契約更新が翌年の9月に設定されていて、今ライセンスを追加すると更新日まで削減できない、つまり「余分なコストが確定する」という問題。
「え、じゃあ試験用に新規ライセンスは増やせないの？」
「検証すらできないのでは…？」
ここで諦めるわけにはいかなかった。
結局、USテナント側で既に持っていたライセンスの一部を、一時的に日本ユーザーに振り分けてもらい、最小限の環境で検証を始めることになった。
これがまた泥臭い調整の連続で、「誰のライセンスを一時外すか」といった社内調整まで発生する始末。
24〜25人の選抜メンバー
検証対象に選んだのは、グローバルに散らばる24〜25人のメンバー。
SMSを実際に送受信してもらい、
- 実務で使えるレベルか
- キャリアごとに挙動の違いはないか
- 認証SMSなど業務シナリオに耐えられるか
をチェックした。
テストは順調とは言えず、キャリアによっては配信が遅延したり、特定の国宛てだと不安定になったり…。
Slackには「届いた！」「いや来てない！」という報告が飛び交い、まるでSMS実況スレ状態。
▼学びと突破口
この検証を通じて分かったのは、「机上の設計だけじゃ何も進まない」という当たり前のことだった。
実際にユーザーを巻き込んで試すことで、想定外の挙動も早めに炙り出せる。
そして同時に、現場の人たちが「自分もテストに参加した」という実感を持ってくれることで、導入への抵抗感も薄れていった。
結果的に、このUSテナントでの検証劇は、プロジェクト全体の信頼感を生むターニングポイントになった。
Zoom Phone運用の落とし穴と学び
導入に向けた検証を進めるなかで、机上では気づかなかった「運用の落とし穴」が次々と顔を出した。
ここでは代表的な4つを振り返っておきたい。
1. 日本→海外拠点への転送問題
今回の導入目的の一つが「日本の営業時間外に入った着電を海外拠点に転送する」仕組みだった。
しかし、いざ設定してみると想定以上に複雑だった。
- 転送先に「1を押させる」オプションの意味が理解されず混乱
- タイムゾーンの違いで「結局誰が受けるのか」が不明確に
- 転送後のボイスメールがどこに保存されるかも利用者に伝わっていなかった
結果的に「便利なはずの転送が、かえって不安と混乱を招く」という状況に。
ここで学んだのは、転送そのものよりも“運用ルールと周知”が成功の鍵だということ。
2. 個人番号がいらない組のコールキュー問題
次に浮上したのが「個人番号はいらないけど電話対応は必要」なグループの扱いだ。
バックオフィスやサポート系チームなど、代表番号にかかってきた電話を順番に取れれば十分な人たち。
こういうメンバーにまで個別ライセンスを割り当てるとコストが跳ね上がる。
そこでコールキューを活用したが、最初は以下の問題が噴出：
- 誰がどのキューに入っているかが見えない
- 鳴っても「自分が出るべきか分からない」と迷う
- 結果として「誰も取らない着信」が発生
最終的にはチームごとにキューを設計し、着信ログを管理者が確認できるようにすることで安定運用にこぎつけた。
ここでの学びは、ライセンス設計よりもキュー運用の見える化が重要という点だった。
3. 既存サービスとの共存問題
さらに頭を悩ませたのが、既存サービスとの共存だ。
- 一部拠点はまだ Dialpad を利用
- 開発ベンダー（EPAM）は Teams が中心
- 全社では Slack がメインチャット
つまり「電話はZoom、履歴はDialpad、監査はTeams、日常コミュニケーションはSlack」というカオス状態に陥りがちだった。
完全にZoomに一本化するには時間も工数もかかるため、移行期は**「どこで何を確認するか」をユーザーに周知し続ける地道な運用**が必要だった。
ここは「情シスがどれだけ面倒を見れるか」が試される場面だったと思う。
4. メンバーの保有回線が増えてしまう問題
Zoom Phoneを入れるとき、意外と盲点になるのが 「1人あたりの回線数」。
- 国内番号を持つ人 → 1回線
- さらにSMSも使う人 → 番号が追加で必要になり、2回線
- さらに貸与スマホ（キャリア回線）も使う人 → 合計で3回線持ちになる
こうなると、回線管理は一気に複雑化する。
「誰がどの番号を持っていて、どこまで使っているか」を常に棚卸ししないと、使われていない回線が放置され、無駄なコストが積み上がる。
実際、導入初期にこの線引きをきちんと決めないまま走ると、
「この人は電話だけで良かったのにSMS番号も契約していた」
「貸与スマホの番号とZoomの番号、どっちを使うのか利用者が混乱」
といったケースが続出。
ここでの学びは、最初に“誰がどの利用パターンか”を整理し、回線数を最小化する設計をしておくこと。
さもないと、情シスは“3回線ユーザー”を量産してしまい、管理地獄に突入する。
▼学び
これら4つの落とし穴を通じて実感したのは、ツール選定や機能比較よりも“運用設計”が成否を分けるということ。
転送やコールキュー、共存フェーズのルールが整理されて初めて、ユーザーが安心して電話を使える環境になる。
Zoom Phoneは優秀なツールだが、それを本当に「電話として使えるもの」にするのは、地味な運用デザインと粘り強い周知の積み重ねだった。
情シスの立ち回り術
もちろん技術知識は前提だけど、それだけでは前に進まない。
- 規制や契約の制約をどう受け止めるか
- 利害の異なる拠点をどう巻き込むか
- 利用者が安心できるルールをどう作るか
ここにこそ、情シスの真価が問われる。
「答えはドキュメントにない」「ググっても出てこない」──そういう状況で、どう立ち回れるかが最終的にプロジェクトの成否を分けた。
▼小さな検証から突破口を
今回の成功の裏側には、小さな検証をとにかく回すという泥臭い作業があった。
SMSテストで24人を巻き込み、転送設定を何パターンも試し、コールキューをチームごとに調整する。
その積み重ねが「机上の設計」から「本当に使える仕組み」へと変えていった。
最後に：これから導入する人へ
もしこれからZoom Phoneを導入する人がいたら、僕からのアドバイスはシンプルだ。
- 技術的な正解を探すより、運用ルールを早めに固めること
- 一気に理想を目指さず、小さな検証を積み重ねること
- 拠点や部門を超えた信頼関係づくりに時間を惜しまないこと
電話という古くて新しい仕組みを扱うからこそ、情シスには「橋渡し役」としての立ち回りが求められる。