ありえない！アナログな安否確認運用のお話

こんばんは、ばーふぃんです。

今日は、驚くべき安否確認の運用についてお話しします。

いざという時に非常に危険な運用なので、これから安否確認を導入しようとしているそこのあなた、決して真似しないようにしてくださいね。

アナログな災害発生時のオペレーション

さて、安否確認と聞いて、サイボウズとかその辺のサービスを想像していたんですが、これがビックリ。そもそも安否確認システムでも何でもない、違うツールだったのです。

これが何のツールかは公言しませんが、とりあえず安否確認システムではありません。なので、後述する安否確認システムに備わっている基本機能は揃っていません。

では何がアナログなのか。災害発生時にはなんと手動でメール送信を行うというのです！

後ほど取り上げますが、ちゃんとした安否確認システムでは、災害（震度5弱以上の地震等）が発生した時には自動的にメールが送信されるようになっています。

このオペレーションを手動でやると言っているのです。

災害発生時のパニック状態で、手動でメール送信なんてすぐに出来るかも分からないし、こんなアナログ運用していたら初動対応が遅れるのは目に見えていますよね。あー恐ろし。

ということで、本来の安否確認システムってどんなものなのか逆に気になってしまったので、簡単に安否確認システムの基本機能について取り上げてみたいと思います。

安否確認システムの基本機能

災害発生時の自動メール送信

これが一番重要なのではないでしょうか。上述の通り、災害発生のパニック状態で、システム管理者がすぐにメール送信出来るかなんて分かりません。

そのため、災害発生状況に合わせてメールが自動で送信される機能が備わっています。例えば、都内で震度5弱以上の地震があった、とか。

この機能があることで、災害発生時の初動対応が遅れることを防ぐことが出来ます。

安否登録状況の確認

安否確認の基本フローは、本当にザックリで書くと

こんな感じかと思います（素人ながらに書いているので、実際にはもっと細かいオペレーションがあるかと思いますが）。

災害が発生してメールを自動で一斉送信したところで、それが一方通行になっては意味がありません。送信されたメールを確認した後、従業員一人一人が自身の安否状況を登録することで報告する必要があります。

この報告も一方通行では当然意味がなく、システム管理者は従業員全員の安否状況を把握しなくてはなりません。

従業員の安否状況を確認することで、管理者はいち早く次の対応に移ることが出来るようになります。

未登録者への再アプローチ

安否状況の登録が完了してない従業員に対して、自動でメールを再送信することが出来ます。こうすることで、安否登録漏れを減らすことが出来ます。

ちなみに、私がいる会社ではこのオペレーションも手動でやる想定らしいです。実に恐ろしいですね。

ユーザーによる緊急連絡先の登録

ユーザーが災害時の安否確認メール送信先となるメールアドレスをシステムに登録しておくことで、災害時にメールを受信出来るよう事前準備をすることが出来ます。

一般的には、個人のメールアドレスを入れることが多いかと思います。もちろん、その登録したメールアドレスにメールがきちんと届くかのテストも行うことが出来ます。

これまたちなみにですが、私がいる会社ではユーザーが個別に連絡先をシステムに登録することは出来ないため、個人メールアドレスの変更等があったら都度管理者へ連絡を入れ、管理者はその連絡を元に従業員一人一人の緊急連絡先を管理しています。うーん、とっても非効率。

 

ここまでが、最低限の基本機能かと思います。では、安否確認システムを選定するポイントについて、簡単に触れてみたいと思います。

安否確認システム選定のポイント

1.システムの堅牢性、会社の信頼性

安否確認は、従業員の生命にも関わる仕組みです。災害発生という一大事にシステムがダウンしていては全てがパーです。

そのため、安否確認システムがどのような環境で動いているかは、確認出来る範囲で確認するようにしておきましょう。

おそらく、大半はデータセンターやクラウドで運用されているかと思います。

また、会社の信頼性も確認をしておきましょう。あまりにも企業体力がないようなところだと、いざという時に会社が無くなっていました、なんてことになってしまったら終わりです。

2.最低限の基本機能を備えている

安否確認システムも、突き詰めるとかなり多機能なサービスもあるようですが、最低限上述したような基本機能は備えているサービスを導入することが望ましいでしょう。

これらの機能を網羅していないと、初動対応が遅れる、安否登録や確認に漏れが発生する、いざという時にメール受信が出来ない、等といったリスクが発生します。

3.シンプルな操作感で使用出来る。

これも実は非常に大事です。3.11のような本当にやばい災害が発生した時は、基本的にパニックになっているはずです。

そんな時に、「ここをクリックして・・・次にここをあーして・・・」なんてやっている余裕はありません。

ユーザーが簡単に操作出来るUIであるサービスがいいでしょう。

4.普段使い出来る

これはマストではありませんが、あるとプラスアルファにはなるでしょう。

例えば、普段から日常的に使用しているグループウェアに安否確認の機能が搭載されていることもあります。

グループウェアは、メールやスケジュール、ワークフロー等、日常的にログインをして使用しているので、その中の機能としての使用であれば、従業員が災害発生時の登録漏れをすることも少なくなるのではないでしょうか。

まとめ

さて、安否確認システムについて調べてみると、最低限でもここは必要だよね、ということがなんとなく分かってきました。

私がいる会社で運用しようとしているツールは冒頭でも述べた通り、安否確認システムではないため、上述の必要な部分がほとんど欠けているということを、再認識しました。

• 安否確認フローの中のメールは全て手動
• 安否確認システムほどの堅牢性を求められないため、定期的にメンテナンス等してサービス断している
• 普段使いするようなものでもない

上司に、何故このツールで安否確認を運用するか聞いたところ、

「金掛けて新しくサービス導入するよりも、今あるツールの使用を模索して普段使いするように持っていきたい」

と。正直、そんな使用場面が多いツールでもないし、これ解約してちゃんとした安否確認システム入れた方がいいんじゃないかと思う。

日に日に上司に対する不信感が強まっていく。

後日、会議でこのツールはグループウェアでもないので、普段使いは無理だろうとバッサリ言われていましたが、安否確認は当面これで運用することになりました。

笑えないけど、いざ災害が発生した時に果たしてどうなるのか、ちょっと楽しみではあります。

ということで、安否確認システムを検討される際は、管理者にあまり負荷が掛からないような運用にしましょうね。今は何事も自動化の時代です。