災害発生時に従業員へ通知し、回答状況を管理する安否確認システム。
利用者から見るとシンプルな仕組みに見えますが、内部では「災害情報の取得」「発令判定」「対象者の抽出」「通知」「回答」「集計」といった複数の処理が連携しています。
重要なのは、これらを一つの大きな処理として作るのではなく、役割ごとに分けて設計することです。
災害情報を取得する
自動発令を行う場合、まず外部から地震や気象などの災害情報を取得します。
取得した情報は、そのまま利用するのではなく、発生日時、災害種別、対象地域、規模、イベントを識別する情報など、システム内部で扱いやすい形に整理します。
外部データと内部データを分けておくことで、情報提供元の仕様が変更された場合にも対応しやすくなります。
発令するかを判定する
次に、取得した災害情報から安否確認を発令するかを判定します。
例えば地震であれば、一定以上の震度を発令条件とすることができます。
ただし実際には、対象地域かどうか、どの企業や拠点が対象になるのか、同じ災害ですでに発令していないかといった判定も必要です。
特に重要なのが、同じ災害情報の更新による重複発令を防ぐことです。
通知処理を分離する
災害発生時には、多数の通知が短時間に集中する可能性があります。
そのため、発令を決定する処理と、実際に通知を送る処理は分けて設計した方が管理しやすくなります。
処理を分けることで、送信件数の制御、送信失敗時の再処理、二重送信の防止などにも対応しやすくなります。
回答状況を状態として管理する
通知後は、従業員からの回答だけでなく、通知や回答の状態も管理します。
例えば、まだ通知していない、通知済みだが未回答、回答済みといった状態です。
状態を明確に管理することで、未回答者だけを抽出したり、再通知したり、回答率を集計したりする処理が容易になります。
安否確認システムは、単に回答を保存するシステムではなく、こうした状態の変化を管理するシステムでもあります。
まとめ
安否確認システムは、単にメールを送信するだけの仕組みではありません。
災害情報を取得し、発令条件を判定し、対象者へ通知し、その回答状況を管理するまで、複数の処理が連携して動作します。
特に自動発令では、「災害情報を受信したこと」と「安否確認を発令すること」を分けて考え、必要な条件を満たした場合だけ発令する設計が重要です。
jkabu安否では、こうした考え方をもとに、気象庁の防災情報と連動した自動発令や、未回答者の把握・催促ができる仕組みを構成しています。
jkabu安否の詳しい機能については、以下をご覧ください。
