1. そもそも安否確認システムは必要か
「災害時に一斉メールを送るだけなら、自社でもできるのではないか。」
そのように考える方もいるかもしれません。確かに、技術的にはGoogle Workspaceや自社システムなどを組み合わせて実現することは不可能ではありません。しかし、そのためには、
- 気象庁等の災害情報を取得する仕組み
- 災害時でも停止しない発信環境
- メール以外（電話・SMS・LINEなど）の代替連絡手段
- 未回答者への自動再通知
- 回答状況のリアルタイム集計
など、多くの仕組みを自社で構築・維持する必要があります。災害という非常時に確実な運用が求められることを考えると、専用システムを利用することは十分合理的な選択と言えるでしょう。
一方、小規模な企業や単一拠点の企業では、電話やメール、チャットツールなどを組み合わせた運用でも十分対応できる場合があります。逆に、
- 拠点が複数ある
- 夜勤やシフト勤務がある
- 緊急時に迅速な集計が求められる
といった企業では、専用システムを導入する動機は大きくなります。
2. 製品ごとの差はどこにあるのか
安否確認システムには様々な製品がありますが、基本的な業務フローは概ね共通しています。
- 災害情報を取得する
- 登録済みの連絡先へ安否確認を発報する
- 従業員が安否を回答する
- 未回答者へ自動再通知を行う
- 管理者が回答状況を集計する
- 未回答者や要支援者へ個別対応を行う
- 一定の条件を満たした時点で対応を終了する
各製品の違いは、この流れそのものではなく、
- 発報条件の設定
- 通知手段
- 集計画面
- 他システムとの連携
- 管理機能
- サポート体制
などにあります。そのため、
「どの製品が一番優れているか」
ではなく、
「自社にはどの機能が必要なのか」
を整理することが重要です。
3. ベンダーへ問い合わせる前に整理すること
問い合わせを始める前に、最低限次の内容は整理しておきましょう。
- 従業員数
- 拠点数
- 災害時の対象者
- 発報条件（震度・地域など）
- 使用したい通知手段
- 家族の安否確認が必要か
- 平時の訓練で利用するか
- 他システムとの連携要件
これらが整理されていないと、各社から異なる前提で提案が行われ、比較が難しくなります。
要件が整理できたら、ベンダーには次のような事項を確認するとよいでしょう。
- 災害情報はどこから取得しているか
- システム停止に備えた冗長構成になっているか
- 通知手段は何種類利用できるか
- 未回答者への再通知はどこまで自動化できるか
- 回答状況はどの単位で集計できるか
- 年1回程度の訓練を支援しているか
- 緊急連絡先データはどのように更新するのか
- 導入後のサポート体制
比較表だけでは分からない非機能要件も、実際の運用では重要になります。
4. システムは導入して終わりではない
安否確認システムは導入後の運用が重要です。例えば、
- システムオーナーは誰か
- 手動発報できる権限者
- 集計単位
- エスカレーションルール
- 未回答時の対応
- 定期訓練の実施
などを規程として整備しておく必要があります。いざ災害が発生した際に責任の押し付け合いになったり、責任者が重複して立てられたりすることのないよう、しっかりとした規程やルールの取り決めが肝要です。
特に重要なのが集計単位です。集計単位の責任者は、連絡がつかない従業員へのアクションなどを担うことになります。この単位が部門単位のように大きすぎると、中間の集計者が対応しきれません。逆にチーム単位まで細かくすると、中間層がピラミッド構造になり、指示が行き届きにくくなります。組織と集計単位の適正なバランスを見極め、セグメントを設計する必要があります。
また、人事異動や組織変更があっても運用を継続できるよう、引継ぎ体制も整えておかなければなりません。特に、上記した中間責任者の引き継ぎは重要です。
そして、運用面で最も手間がかかるのが定期的な訓練です。訓練の計画、対象範囲、実施後の振り返りまで含めて、総務が中心となって運用を改善していくことになります。平時の訓練については、従業員だけでなく経営幹部が非協力的になるケースもあります。人命に関わることですので、システムオーナーとともに、社内の意識を引き締めていく必要があります。
まとめ
安否確認システムは、どの製品も基本的な業務フローは大きく変わりません。そのため、
「どの製品が一番良いか」
を最初に考えるのではなく、
- 自社に必要な運用
- 必要な機能
- 社内ルール
- 将来を見据えた運用体制
を整理した上でベンダーへ相談することが重要です。
比較する前に比較できる状態を作ること。それが、安否確認システム導入において総務が担う最も重要な役割と言えるでしょう。