はじめに
有事を加味した通信設備選択の重要性は、このほどのパンデミックで世界が理解したところだろうと思います。
実際、多くの企業がオフィスに行かなくては事業を維持できないことを悟り、設備の増強や出社担当を決めることをしたり、経営者や上司が出社を強制するなどの状況になったりと、各種のゆがみが発生することもありました。
今後、有事の際にオフィスに行かなくても、もしくはオフィスに行く機会を減らしても、事業に影響が少ないシフトをとれる状態にしておく必要があると考えます。
BCP（事業継続計画）は昨今、銀行の融資項目にも上がるほど当たり前の言葉となりましたが、BCPが特に言われるようになったのは東日本大震災発生後です。
自社のビジネスをどのように継続するのかは重要な課題です。
ここでは災害時の電話にフォーカスし、電話設備において何ができるかを記載します。
東日本大震災と通話・通信
筆者は東日本大震災発生時、某電気通信業のコールセンタ―のインフラ構築に携わておりました。
某社は東北地方にコールセンタを配し、日々約1000名のオペレータの方々が日々稼働していました。サービスのカバーエリアは東北・関東で、多くのユーザーに利用されています。
地震発生と同時に日々行われている業務が「ピタリ」と止まるのが震災の怖さです。また当時システムはオンプレが主流で、設備に対しても普段では考えられない状況が発生します。
2011年3月11日14時46分、東日本大震災は発生し、その後津波の影響は甚大な被害を及ぼしました。
当時私は札幌に出張中で、東北における正しい状況の把握は難しい状況に陥りました。
固定電話、携帯電話は東北・関東エリアではかかりにくい状態になり、メールは相手の状況次第となりました。
被災地とは当然連絡がとれなくなりました。東京の本社との通信も緊急優先通話へ切り替わり、一般通話の制限が行われました。
この制限中は一般電話での通話が制限されるため、同僚・顧客・家族への通話が難しくなります。私も地震の当日と翌日までは連絡が取れなくなりました。
また、停電も発生しました。当時、東北・東京電力エリア内は数1000万戸で停電し、完全な復電は3月18日だったそうです。
複電は場所によりさまざまで、市街地の雑居ビルでの復電は地震発生後の4時間後でした。郊外のコールセンターは電源消失後、非常電源設備を稼働させ復電しています。
複電したとはいえ、震災後の混沌の中では業務できませんでした。社内ネットワークも復電と同時に復旧し大量の安否確認メールを処理し始めたそうです。
震災発生後、一番最初に行うことが、家族や社内の安否確認となりますが、固定電話や携帯電話が使えない状態での安比確認は目視以外できない状態になります。
実際、携帯電話でSMS等通信が復旧したのが、被災から1週間後でしたので、被災地では各自での安否確認を実施し、報告をまとめていました。
様々な努力をしていましたが、社内ネットワークの復旧に伴いIP電話が利用可能になったそうです。これにより、本社支店間の通話が可能になったのが幸いし、支援要請が行えたとのことでした。
震災後のリソースの復旧順序は以下の通りでした。
- インターネット
- スマートフォンのバッテリー稼働でインターネットへ接続
- 電源
- 社内のネットワーク経由でインターネットへ接続
- 電話
- 固定・携帯ともにキャリアで決まるため、復旧順序は不規則
この地震は設備自体にも影響を出していました。
電話交換機や通信用設備を収めたラックは床面にアンカー固定されていましたが、床面のひび割れによる固定アンカーの脱落や、多くのアンカーナットの『合いマーク』がズレており、床固定が緩んでいる状態が見受けられました。
もし震源に近かったり、強い揺れに再度襲われれば、倒壊の危険性を察することは難しくありませんでいた。また、ラックの中に収められたほとんどの通信用パッチパネルは緩み・脱落・抜線の危険もありました。
被災を受けた現地の方々は、社員のこと・家族のことなど、多くの心配がある状態でさらに社内設備の平常化を目指す必要があり、これはかなり難しいことだと感じました。
有事の際に利用可能な環境・リソース
まず安否確認を実施するとして、迅速に対応するために何が必要でしょうか。
どのような企業であっても準備が必要と考えています。
有事発生後すぐに使えるリソースは以下の通りです。
- 有事に関わらず稼働
- インターネット
- クラウド
- サービス復旧次第
- 停電
- 復旧は断線等の確認のため電力会社次第
- 電話での通話
- 制限解除のタイミング通信会社次第で読めない
- 停電
よって、インターネットリソースの活用が効果的なようです。
スマートフォンの活用
災害時の安否確認で一番情報量が多のは、相手との通話になると考えます。
通話を行える機器を考えると、インターネットへ到達するのに一番早いのがスマートフォンです。
スマートフォンといえど、フォン機能（通話機能）は使えないため、LTE・4G・5Gの通信端末として使用します。（前項でいくつか記載しましたが、固定と携帯電話は通信制限が掛かりつながりにくい状況です。）
充電されているバッテリー容量の限りとなりますが、有効です。
クラウドPBXの活用
設備としてはクラウドPBXが有効です。
オンプレミス電話交換機は有事において回線、機器ともにその機能を停止してしまい、復旧がいつなのかは、行政と電話工事会社のスケジュール次第となってしまします。
ですが、有事といえど、災害を受けていない地域からの受電をうけ、業務を遂行できるのであれば、行いたいと考えると思います。
また、業務遂行が難しい場合でも、今の状況を自動的に発信者へ伝えることができれば、ビジネスチャンスを逃すことなくの業務遂行継続につなげたいと考えるでしょう。
クラウドPBXの場合であれば、システムへの接続が出来さえすればPBXの着信設定の変更で、非災害地への自動転送を可能にした入り、自動応答で状況の伝達を自動的に行うことが可能です。
またスマートフォンのアプリケーションの活用で、パケット通信による内線外線通話が可能になります。災害の度合いに応じて、その対応を自社で行えるのは大きなアドバンテージになると思います。
電話システムと災害対策
クラウドPBXの導入
電話システムの入れ替えを検討している場合、BCP対応に備え、クラウドPBXの導入の検討は有効であると考えます。スマートフォンの通話機能が利用できない状態では、スマートフォンアプリでの通話は有効な手立てとなると思います。
これらクラウドPBXの仕組みは、2015年ころからサービス開始しておりますが、電話業界の変貌と競争の中でかなり苦戦を強いられており、主流とはなっていません。
ただパンデミック発生の際のは多くの方々から問い合わせをいただき、導入されています。
スマートフォンの利活用を検討し、固定電話数の見直しでコスト削減を行うことも有効なBCP対策とできそうです。
オンプレミス型の電話交換機における災害対策
現在のオンプレミス型の電話交換機の災害対策はどうなっているのでしょう。
企業における電話システムは交換機と電話回線の2部門が結合されてサービス提供されていますので、それぞれ分けて考えてみましょう。
電話交換機
交換機の災害対策のうち、転倒防止のための耐震架台への設置は大型交換機では当たり前の装備です。
また、さらに大型の場合は蓄電池設備を用いて、電力停止後しばらく電話を使えるようにしている企業もあります。
それでもやはり電源消失が起これば、電話の交換機能も回線接続機能も失われてしまいます。電源消失に対する対策は蓄電設備が最良の延命策となりますが、蓄電設備にも限りがあり、それ以上の対策は難しいと考えます。
電話回線
種別により災害対応が異なります。
INS1500相当の回線に関してはONUを利用するため、電源の消失ともに回線は不通となり、通話不能となります。
INS64では電話交換機の種類によってDSUの外付けと内臓の2種類の収容方法を選択できますが、いずれも電源を必要とするため、電源消失ともに通話ができなくなってしまいます。
このように、比較的新しいINS1500 とINS64は災害に対しては脆弱が認められますが、反してアナログはとても有用な回線です。
アナログ回線は電話局から直接配線されている回線であるため、停電時でも通話可能な回線です。停電時用に電話交換機を通さず、確保しておくことは有効な通話可能策となります。
ただし、大規模災害の際には緊急優先通話に切り替わってしまうため、希望の通話先への接続は難しくなります。
オンプレミス型の電話交換機も電話回線も有事の際には通話ができなくなるため、活用は難しいと判断できるでしょう。
まとめ
災害時にも利用できるシステムを選択するのはとても大事なことですが、自身の環境を鑑みると、とても難しいことと思います。
オンプレミスのシステムでは物理的な制限が発生しますし、クラウドなら自社運用のタスクが追加されたり、使い勝手が変わることに懸念があります。
どちらも震災やパンデミック発生まではあまり検討していなかったかもしれません。ただ、有事はどこでどのように発生するかもわかりませんし、検討のスタート地点もはっきりしないと思います。
平常時の時にできうる想定を環境に合わせて行い、ふさわしい仕組みの選択を行えるよう取り組む必要があります。
企業においては、今後の働き方を左右する大事な選択ともなりうるため、本記事が検討時の参考になれば幸いです。
高山 智行（日本ビジネスシステムズ株式会社）
入社24年目、パケット音声にまつわる技術をJBSにため込みたいと考えています。 そのため、レガシーPBXからクラウドPBXまた通信端末として電話機やスマホに詳しいです。 WindowsよりLinuxやAsteriskに精通しています。 音声パケット通信のためのネットワーク構成もここに残します。
担当記事一覧