LASSIC Media らしくメディア
安否確認システムの開発を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守運用を受託
地震や風水害の直後に、まず経営が知りたいのは「従業員は無事か、事業は動かせるか」という一点です。安否確認システムは、この初動の安否把握を自動で担う仕組みです。本稿では、総務・人事・BCP担当や情報システム部門の方に向けて、安否確認システムを新規開発あるいは刷新する際の外注の進め方を整理します。パッケージ（安否確認SaaS）とスクラッチの判断軸、そして外注先に確認すべき点を、内閣府や気象庁の公式情報をもとに解説していきましょう。
この記事のポイント
- 安否確認システムは、災害・緊急時に多チャネルで一斉配信し、回答集計と未回答者への再送までを自動化する初動対応のツールです。
- 内閣府の事業継続ガイドラインは、平時から安否確認の手順を定めて定期的に訓練しておくことを求めています。
- 外注時は災害時の可用性・自動起動の信頼性・連絡先データのメンテ運用という3点が、機能一覧より重い確認事項になります。
目次
安否確認システムとは——災害時に従業員の安否を自動収集する仕組み
安否確認システムとは、地震・風水害・大規模障害などの緊急時に、従業員へ一斉に連絡を配信し、その回答を集計して被災状況を素早く把握するための仕組みです。単なる連絡網の電子版ではありません。多くのサービスは、気象庁が発表する地震情報の震度としきい値を照合し、設定した震度を超えると管理者の操作を待たずに配信を自動で開始します。担当者自身が被災していても初動が止まらないよう、この自動起動が中核となる機能です。
自動起動が想定する場面の一つが、地震の初動です。気象庁の緊急地震速報（警報）は、地震波が2点以上の観測点で観測され、震度5弱以上または長周期地震動階級3以上と予想された場合に発表されます*1。この速報は、震源付近でP波を検知した地震計のデータから震源や規模、予測される揺れの強さを計算し、揺れの強いS波が伝わる前に知らせる仕組みです*2。安否確認システムの多くは、こうした気象庁の地震情報を監視し、自社の基準を超えた地域の従業員へ配信をかけます。
配信後の流れも見ておきましょう。連絡はメール・専用アプリのプッシュ通知・SMS・チャットツールなど複数チャネルへ同時に送られ、どれか一つが不通でも届く確率を高める設計です。従業員は「無事」「軽傷」「要支援」といった選択肢で回答し、家族の安否や出社可否を添えるケースもあります。回答はリアルタイムで集計され、拠点別・部門別のダッシュボードに反映されるのが一般的です。未回答者には自動で再送がかかり、一定時間が過ぎると上長へエスカレーションされます。平時には訓練用の配信を流し、連絡先の不備や回答率を点検できる製品も多く見られます。
導入が広がる背景——BCPと大規模災害リスク
安否確認システムが担うのは、BCP（事業継続計画）の初動フェーズです。内閣府の事業継続ガイドライン（令和5年3月）は、災害発生直後には役員および従業員の安否確認を速やかに行う必要があるとし、平時から安否確認の実施手順を定めて定期的に訓練しておくことが有事に役立つと述べています*3。同ガイドラインでは、従業員等の身体・生命を守ることが最優先に位置づけられており、安否の把握はその出発点にあたります*3。
もっとも、計画があっても運用が追いつかない企業は少なくありません。帝国データバンクが2024年5月に実施した「事業継続計画（BCP）に対する企業の意識調査」（有効回答1万1,410社）では、BCPを策定済みの企業は全体で19.8%にとどまりました*4。規模別では大企業37.1%に対し中小企業は16.5%と、両者の開きは依然として大きい状況です*4。策定率は前年から伸びたものの、多くの企業でBCPの実効性を担保する初動の仕組みづくりが道半ばであることがうかがえます。
誰が無事で誰と連絡が取れないのかを短時間で把握できなければ、BCPの発動判断も、代替要員の手配も進みません。安否確認システムは、この最初のボトルネックを解消する道具として広がってきた仕組みです。近年は地震だけでなく、大雨特別警報や感染症の拡大といった多様な事象への対応も求められています。
BCP・防災、グループウェア、勤怠管理との違いと連携
「グループウェアや勤怠管理システムがあれば足りるのでは」という声もあります。しかし各システムは役割が異なり、緊急時の初動という観点では代替が効きにくいのが実情です。違いを整理しておきましょう。
| 仕組み | 主な役割 | 安否確認との関係 |
|---|---|---|
| 安否確認システム | 緊急時の一斉配信・安否回答の集計・未回答者対応 | 初動の安否把握そのものを担う |
| BCP・防災計画 | 被災時の事業継続方針・体制・手順の文書化 | 安否確認は計画の初動フェーズに位置づく |
| グループウェア | 平時の情報共有・スケジュール・掲示板 | 自動起動や多チャネル到達は専用設計ではない |
| 勤怠管理システム | 出退勤・労務データの記録と集計 | 在席者の把握で連携でき、初動連絡は別機能 |
グループウェアは平時の情報共有に強みがあります。ただし、担当者の操作を前提とする配信が多く、震度連動の自動起動や不達時の多チャネル切り替えまでは備えていないのが通例です。勤怠管理システムは誰が在席していたかという記録には役立ちますが、緊急連絡を発火させる用途とは設計思想が違います。安否確認システムはこれらと競合するものではなく、連携先として組み合わせる対象と捉えるのが適切でしょう。たとえば勤怠や人事マスタと従業員データを同期すれば、連絡先の鮮度を保ちやすくなります。
パッケージ（安否確認SaaS）とスクラッチ開発の判断軸
開発方針は、大きくパッケージ（安否確認SaaS）の採用とスクラッチ開発に分かれます。まず検討したいのはSaaSです。災害時の一斉配信・自動起動・集計といった基本機能はすでに作り込まれており、災害時に負荷が集中しても配信し切れるインフラを提供事業者が運用します。導入も短期間で済むため、標準的な要件であればSaaSが第一候補になります。
一方で、SaaSの標準機能に収まらない要件があるときは、スクラッチや、SaaSを土台にした個別開発が選択肢に入ります。判断の分かれ目を挙げてみましょう。
- 既存の基幹システムや入退館・IoTセンサーと安否データを深く連携させたい
- 拠点や職種ごとに異なる複雑なエスカレーション経路を設計したい
- 海外拠点や協力会社、来訪者まで対象を広げ、細かな集計軸を持たせたい
- 官公庁や重要インフラ向けに、厳格なセキュリティ要件や閉域網対応が求められる
こうした要件が中心なら、外注先と相談しながら個別開発を検討する価値があります。ただし作り込むほど災害時の可用性を自社側で担保する責任も重くなる点は見落とせません。全部を作らず、SaaSを基盤に不足分だけを外注で拡張するハイブリッドも現実的な着地点です。要件の8割が標準機能で満たせるなら、残りのためだけにフルスクラッチへ踏み込む必要はないでしょう。
外注時に確認すべき点——可用性・自動起動・連絡先メンテ
安否確認システムの外注では、機能一覧の網羅性よりも「いざというときに本当に動くか」が問われます。平時にしか検証されない仕組みは、災害時にこそ真価が試されるためです。発注前に確認したい観点を3つに絞って挙げます。
災害時の可用性と冗長性
安否確認システムは、大規模災害でアクセスが集中する局面でこそ稼働しなければ意味がありません。サーバーやデータセンターが地理的に分散して冗長化されているか、被災地と同じ電力・通信網に依存していないかを確認します。想定される同時アクセス数に耐える設計か、配信の遅延がどの程度に収まるかも、契約前にすり合わせておきたいところです。目標復旧時間や過去の稼働実績を数値で示せる委託先かどうかが、一つの見極めになります。
自動起動トリガーの信頼性
震度連動の自動起動は、気象庁の地震情報を取り込んで動きます。ここで問いたいのは、情報の取得元と遅延、そして取りこぼしへの備えです。どの震度・どの地域を配信条件にするか柔軟に設定できるか、情報源が一時的に途絶したときのフォールバックがあるか、誤起動を防ぐ仕組みがあるかを確認しましょう。自動起動に加え、管理者が手動で任意の対象へ即時配信できる経路も必須の要件です。訓練配信で起動から到達までを定期的に検証できると、取りこぼしを防ぎやすくなります。
従業員の連絡先メンテナンス運用
見落とされがちなのが、連絡先データの鮮度です。入社・退職・異動が起きるたびに連絡先が古くなり、いざ配信しても届かない事態が起こり得ます。人事システムや勤怠システムと自動連携して従業員データを同期できるか、本人が自分で連絡先を更新できる仕組みがあるかが確認ポイントです。運用負荷を下げる設計になっているほど、実効性は長続きします。導入後の運用設計まで一緒に描いてくれる委託先を選ぶことが、形だけで終わらせないための近道です。
内製と外注の分かれ目——運用を担う体制で判断する
ここまでの観点を踏まえると、内製か外注かの判断軸が見えてきます。標準的な要件で、かつ災害時の可用性を自前で保証する負担を避けたいなら、SaaSの採用が合理的です。反対に、独自要件が多く既存システムとの連携が複雑な場合は、要件定義から運用設計までを一貫して任せられる外注先の力が要ります。
専門パートナーへ委託する際は、依頼できる範囲の広さが選定の分かれ目になります。要件定義・製品選定・個別開発・既存システム連携・訓練を含む運用設計までを一気通貫で相談できるかを確かめましょう。安否確認は、作って終わりではなく、連絡先の更新や訓練を続けてこそ機能する仕組みです。開発だけでなく、その後の保守運用まで見据えた体制があるかどうかが問われます。
自社に情報システム部門があっても、通常業務と並行して災害時の可用性設計や継続的な訓練運用まで担うのは負荷が大きいものです。現状のBCPと拠点構成を棚卸ししたうえで、どこを内製し、どこを外注するかを切り分けるのが実務的な進め方といえます。
まとめ：安否確認システムの外注で押さえる3つの判断軸
本稿では、安否確認システムを外注で開発・刷新する進め方を、公式情報をもとに整理しました。要点は3つです。第一に、安否確認システムはBCPの初動を担うツールであり、内閣府ガイドラインが求める平時からの手順整備と訓練の受け皿になります*3。第二に、標準要件ならSaaSが第一候補で、自社固有の連携やエスカレーションが必要なときにスクラッチや個別開発を検討するのが基本線です。第三に、外注時は災害時の可用性・自動起動の信頼性・連絡先メンテ運用という、平時には見えにくい3点を機能一覧より重く確認する必要があります。自社の災害リスクと拠点構成に照らし、内製と外注の切り分けから検討を始めることをおすすめします。
よくある質問
安否確認はグループウェアや勤怠システムで代用できませんか。
平時の情報共有や勤怠記録はそれぞれのシステムが得意とする領域です。ただし震度連動の自動起動や、不達時に複数チャネルへ切り替える配信は、安否確認に特化した設計を前提とします。代用ではなく、人事・勤怠マスタと従業員データを同期する連携先として組み合わせるのが現実的です。
パッケージ（安否確認SaaS）とスクラッチ開発はどう選べばよいですか。
一斉配信・自動起動・集計といった標準機能で要件が満たせるなら、短期間で導入でき災害時の可用性も提供事業者が担うSaaSが第一候補になります。既存基幹との深い連携や自社固有のエスカレーション経路など標準に収まらない要件が中心のときに、スクラッチや個別開発を検討してください。SaaSを土台に不足分だけを拡張するハイブリッドも有効です。
気象庁の情報と連動した自動配信はどこまで信頼できますか。
緊急地震速報（警報）は震度5弱以上などの基準で発表され、P波の検知データから揺れの強さを計算してS波の到達前に知らせる仕組みです*1*2。多くのシステムはこの地震情報を監視して自動配信します。外注時は、情報源が途絶したときのフォールバックや誤起動を防ぐ仕組み、手動配信の経路まで確認しておきましょう。
従業員の連絡先はどう最新に保てばよいですか。
入社・退職・異動のたびに、連絡先は古くなりがちです。人事・勤怠システムと自動連携して従業員データを同期する仕組みと、本人がメールアドレスや家族の連絡先を自分で更新できる仕組みを組み合わせると、鮮度を保ちやすくなります。運用負荷を下げる設計かどうかを、導入前に委託先へ確認しましょう。
開発を外注する際、最初に何を準備すればよいですか。
まず自社のBCPと拠点構成、対象とする従業員や協力会社の範囲を棚卸しします。次に想定する災害事象と、震度などの配信条件を整理してください。これらがそろうと、SaaSで足りるか個別開発が要るかの判断や、外注先との要件すり合わせがスムーズに進みます。運用・訓練まで含めた体制を誰が担うかも、早い段階で決めておくとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：気象庁「緊急地震速報（警報）及び（予報）について」（https://www.jma.go.jp/jma/kishou/know/jishin/eew/shikumi/shousai.html）
- *2 出典：気象庁「緊急地震速報のしくみ」（https://www.jma.go.jp/jma/kishou/know/jishin/eew/shikumi/shikumi.html）
- *3 出典：内閣府（防災担当）「事業継続ガイドライン －あらゆる危機的事象を乗り越えるための戦略と対応－」（令和5年3月）（https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf）
- *4 出典：帝国データバンク「事業継続計画（BCP）に対する企業の意識調査（2024年）」（2024年5月調査・有効回答1万1,410社）（https://www.tdb.co.jp/report/economic/7llbf4-_jo/）
