はじめに（自己紹介とこの記事について）
LITALICOのITサービス部に所属している @shuheie です。
この記事は LITALICO Engineers Advent Calendar 2025 の8日目の記事になります。
ITサービス部 ITインフラグループにて主にネットワークや全国拠点に設置しているITシステムに関する仕事をしています。2024年11月に入社しましたので、無事入社1年を迎えられてホッとしている今日この頃です。(昨年の今頃に入社エントリとして投稿した記事は こちら)
さて、今年のはじめごろに、一部の部門が使用している電話（固定電話回線と携帯電話を連携する FMC 的な機能）のサービスがキャリア側で今年末 (2025年12月) にサービス終息されることが発表され、後継サービスの検討から開始して、年内に移行完遂する案件が立ち上がりました。
この記事では、この案件の中で大切にしたことや意識したポイントについてまとめたいと思います。尚、私のバックグラウンドとしては、以前の職場でコールセンターシステムや自社（当時）グループ内線網の運用管理を5年ほど実施していた経験があり、その背景から今回の案件にアサインをしていただきました。
記事のなかでいくつか「用語」のように使っている言葉がありますが、あくまでこれまで私が経験した中で聞いた言葉として書いているので、会社によって＆環境によって言葉自体の有無や使い方として異なることがある点は、予めご留意ください。
情報収集フェーズ
後継ソリューションの検討にあたり、以下の3つの観点で検討を行いました。それぞれの観点で気を付けたポイントについて記載します。
利用者視点で見た、既存の電話システムの機能や使い方
今でこそ IP 電話やクラウド PBX といった形で IT システムの側面が強くなってきた電話の世界ですが、どちらかというとファシリティの要素が強く、メーカーやベンダー、もしくはユーザー企業については暗黙の「これが当たり前」がたくさん存在しているように思います。
例えば、電話機間の転送1つとっても...
- 社外からの通話を保留にすると通話が回線ボタンに保留され、その番号を転送先に伝える。(ラインパーク転送、パーク保留とも)
- 文字にすると分かりづらいですが、昔のオフィスを舞台にしたドラマで出てくる「○○さん！1番に外線入ってます～」っていうアレです。
- その他にも、通話ごとに一時的な保留番号が発行され、それを伝える場合もある。（コールパーク転送）
- 社外からの通話を保留にして、相手の内線番号に架電して転送先と会話した後に (○○さんからの電話です、などの要件を伝える)、自身の電話を切ると、もともとの社外との通話が転送される。(コンサルト転送)
- 大代表などの受付に入った電話を担当部署に取り次ぐようなケースがイメージしやすいかもしれません。
- 社外からの通話を保留にして、相手の内線番号を入力して自分は電話を切る。転送先とは会話をせず、転送先の電話が鳴って応答すると、転送が完了する。(ブラインド転送)
- (そもそも転送機能をつかっていない)
といったように、「電話機間の転送」に類する動作がいくつもあり、ユーザー観点ではどれかが「電話を転送するときの当たり前の操作」になっているといった事例が様々あるように思います。そしてここで括弧内に示した転送方式名は、およそ一般的な言葉ではなく、利用者は意識していない場合がほとんどです。
今回のプロジェクトは電話に関するシチュエーションを「発信」「着信」「保留」「転送」「留守番電話」「電話帳」「キャリアの転送サービス (後述) の利用状況」などなどのシーンに分解して実際の利用者にヒアリングを行うとともに、発着信それぞれの通話相手先や、現状も問題点についても併せて直接教えて頂きました。
現行の通信キャリアとの契約内容の確認
実際の利用者とのヒアリングと並行して行ったのが、現行の通信キャリアからの契約情報の収集です。実は固定電話には様々なオプションサービスがあり、こちらも利用者が知らず知らずのうちに利用しているケースがあります。後継サービスの中では従来のキャリアのオプションサービスを使用できない可能性もあったため、キャリアの営業担当者から情報を提示してもらい、かつその利用状況を利用者にヒアリングしました。
また、拠点に設置している PBX の納入を行っているベンダーからも工事指示書や引き渡し時に提供している簡易操作手順などのドキュメントの提供を受け、突き合わせながら構成と利用状況の理解を進めました。
例）
- 回線種別
- アナログ (加入電話), ISDN (INSネット)など、回線種別により以降のサービスで使えたり使えなかったりということがあります。
- 追加電話番号
- 電話回線に番号を追加するサービス。ダイヤルインサービスやi・ナンバーなどいくつかある。電話回線に紐づいた付与された番号（契約者回線番号）と追加電話番号は設計・構築・移行フェーズで考慮する各ポイントでも取り扱いが違ったりするので、注意が必要です。
- 転送サービス
- 通信事業者の交換機で電話の転送を行うサービス。NTTではボイスワープと呼び、他社でも同様のサービスがありますが、提供サービス内容は事業者により微妙に違う場合があり、注意が必要。また、様々な使い方ができるのでキャリアや回線サービスをまたぐような案件では具体的にどういった利用シーンでどのような設定で利用しているかにも気を付ける必要があります。
NTT東西が提供する各種サービス、オプションサービスについては 技術参考資料 (リンク先はNTT東日本) として詳細な技術仕様が公開されています。私が経験した中ではそこまで深く確認が必要になったケースは多くないですが、ディープめな仕様も記載されているので、好きな方は楽しく読めるかと思います。(インターネット技術の世界でのRFCみたいな感じです。)
候補となる後継サービスに関する情報収集
後継となるサービスは、クラウド PBX 型のサービスを中心にいくつか候補を上げて紹介を受けましたが、前述の通り、「同じような機能でも少し違う部分がある」「機能自体は存在しているが対応していない使い方がある」など、微妙な差異が存在します。このため、 前述の利用者に対してのヒアリング内容 を元にして要件表を作成し、各社に配布し記入をしていただく方式を取りました。これはもう1つ意図があり、各社ごとの紹介資料では読み取りが難しい部分も含め、横並びで比較がしやすいようにする目的もありました。
それから、後継サービスへの移行にあたり、網側 (通信事業者側) でどのような工事が発生するかと、その工事がどういったものか、どの程度のコントロールが可能なものか、という情報の収集を綿密に行いました。特に電話番号の事業者間移行 (いわゆる番号ポータビリティ) を伴う場合には、移行前後の通信事業者の工事都合はなかなかコントロールができない、いつ不通時間が発生するかなどの情報が不明確ではないケースが多々あります。また、何か問題があった時の切り戻しもできないケースがほとんどのため、リスク度合いを見極める目的もありました。
ただし、この部分については今回少し時間をかけすぎたかもしれないと思うところがあります。1つ1つの確認にメールのやり取り・打合せや先方からの情報提供の待ち時間があり、結果としてタイムリミットの旧サービスの提供終息に計画段階の想定より近付いてしまったことは反省点です。
番号ポータビリティについて
携帯電話の事業者間の番号移行 (ドコモ→auへの同番移行など) は今では当たり前のものとして定着していますが、実は固定電話の事業者間移行が自由にできるようになったのは 今年の1月のこと (リンク先は総務省の該当ページ)です。意外と最近ですね。
それまでは、「NTT東西が発行した電話番号」は他通信会社に移行できる、というような制約があり、番号ポータビリティができる固定電話番号を指して「NTT東西由来の番号」のような言葉で表現したりすることもありました。
今回の案件においては、現キャリアのサービス終息までに後継サービスに切り替えることが最優先の課題であったため、この工事や切替/切り戻しのコントロールの観点や、その整理・調整にかかる工数や準備にかける時間が問題となる可能性が高いと考えられる状況でした。
このため、後継サービス候補の中でもキャリアの転送サービスとの組み合わせにより番号ポータビリティ工事を回避できるサービスを選定し、実際の移行に向けたフェーズがスタートしました。
設計・構築フェーズ
設計・構築フェーズでも、前述の「利用者にとっての当たり前」を紐解きながら、事業部門の担当者とコミュニケーションを取りながら進めることとなりました。
一方で、クラウド型電話サービスを採用したため Web ブラウザで柔軟に設定の変更ができることから、あまり最初からかっちりと作りこみを行うわけではなく、
- クラウド型電話サービス側に仮の電話番号 (実際のサービス利用には使わない電話番号) を付与
- 発着信時のフローについて仮実装
- 発着信操作ができる端末側 (今回はスマートフォン) も実装し、実際に電話を使う拠点担当者の手元に送付
- オンライン会議 (このフェーズからは週次で実施) の中で、実際に発着信する操作を試してもらう。
- 場合によってはその場で改修までしてしまってしてあらためて試してもらう。
この繰り返しで徐々に仕様を詰めていきました。情報収集の過程で利用シーンと必要な機能はある程度見えてきていたため、実はこのあたりのフェーズはあまり時間をかけることなく、2～3週間程度のやりとりで概ね最終形態が見えてきました。
尚、上記の過程の中で、拠点担当の方より「なんか面白くなってきましたね。実際にイメージがついてくると。」とコメントを頂きました。ドキュメントやディスカッションの中では見えづらい部分もあるので、実際に見える環境の中でディスカッションできたのは今回の取り組みでよかったんだと思います。
移行フェーズ
移行の流れや、各スタッフへの実際の展開方法について事業部門の担当者との会話を進めたところ「新しい電話環境の使い方については、細かめのドキュメントがあったほうが良いかもしれない」ということになりました。
この懸念についても、やはり電話システムの特性による部分があるのかもしれません。
- 「電話の使い方の当たり前」がすでに固まっているため、それが変更となることへの不安感
- 特に今回の案件ではインターフェースとして「固定電話機」から「スマートフォン上のアプリ」に変わることから、習熟コストへの不安感が大きかったように思います。
- 社外とのコミュニケーションの主要な手段の1つであるため、使えなくなった時の業務インパクトが大きい
今回導入した電話システムの適用部門向けには、「初期設定の手順」「アプリを使用した電話の発着信」「通話履歴の確認や設定変更などの運用管理」といったステップバイステップの操作手順書を作成し、事前に展開しました。できるだけ画面キャプチャを使い、操作の流れを分かりやすくするように意識しました。（こういうことも書いておいた方がよさそうですね、なんていうことを盛り込んでいったら60ページくらいになってしまった...）
 |
| 作成した操作手順書の目次 (一部マスクしています) |
今回の対象は東京～沖縄まで4拠点に渡るため、1拠点ごとにオンライン会議で各拠点の利用者とリアルタイムに会話しながら、従来の電話環境からクラウド型電話サービスへの発着信方法の切替と切替後の発着信テストを実施しました。（この文章を書いている段階だと、まさに"しています"という状態です。）
今回は着信先の変更のためにキャリアの転送サービスの設定変更を各拠点の利用者にて実施いただく必要があるのですが、IVR (○○の方は1を...というのを電話機のピポパで指定していく操作) でかなり複雑な操作を実施していく必要があります。
このため、通信事業者が提供する転送サービスのマニュアルを元に、電話機から流れるアナウンス内容を含めて手順にまとめておくことで、比較的スムーズに操作を実施いただくことができました。また、切替の際に、新しい環境での発着信以外の操作方法についても実際のアプリ画面を見て頂きながらご説明することで、実業務での利用も大きな問題なく入ってもらえている印象です。
もちろん、切替直後は細かい仕様の確認や問い合わせは発生しますので、利用部門とIT担当のグループチャットに連絡を頂き、適宜コミュニケーションを取っています。
おわりに
この段落を書きつつ、記事の仕上げを行っているのは、公開期日ギリギリの12月4日(木)です...記事の進捗とは裏腹に、今回の電話サービスの移行プロジェクトはタイムリミットであった旧サービスの提供終息の1か月前までにすべての本番環境の切替を完了し、無事にサービスインしました。
電話という利用者とのコミュニケーションの前線に立つデバイスのため、移行後のトラブルについては内心ドキドキしながらこのタイミングを迎えましたが、個別の QA やご相談は頂いているものの、概ねスムーズにご活用を頂けており、一安心しています。
今回のように現場と密にコミュニケーションを取りながら要件づくりから関わることができるのは、いわゆる情シス・社内ITの醍醐味かなと改めて感じる案件でした。一方で、今回は社内の中でもユーザー規模の少なめのサービスに関する取り組みだったため、要件の取りまとめ・すり合わせも実施しやすかったため、スムーズに進められた面もあったように思います。会社全体などより広い範囲での再構築や切替を行う場合には、また違ったやり方や工夫が必要になると感じます。いずれにしても、改めて振り返ると、電話特有の考慮ポイントや気を付けないといけないなと思うところも多いな、と思い、この記事を書きました。（タイトル回収）