開発への想い

災害のとき、従業員の安否確認と業務の継続のために、緊急時の連絡手段を確保しておくことが重要だと言われています。しかし、東日本大震災の際には、多くの企業が連絡網を整備していたにも関わらず、電話がつながらなかったり、導入していた安否確認システムが動かないなどの問題が多くの発生しました。
震災後に行われた通信のつながりに関する調査によると、携帯電話では65.4%、固定電話でも55.1%の人が通話できなかったと回答しました。一方、携帯メールや携帯ウェブは3割強、パソコンメールは22.1%、パソコンウェブでは11.3%と、つながらないと回答した人の割合が比較的少なく、インターネットを利用したメールやウェブの方が比較的につながりやすいことがわかりました。

そのため、私たちは「メール」「スマートフォンアプリ」「LINE」といった通知手段に重点を置き、つながりにくい電話の通話機能は省くことで、災害時でも連絡がとりやすく、低価格なサービスを開発することにしました。

東日本大震災の際に、従来からある他社の安否確認システムには、以下の大きな2つの問題が起こりました。
・急激にアクセスが集中したことで、システムの負荷が高まり正常に機能できなかった
・通信トラフィックが急増したことで、メールサーバーが混雑し、安否確認メールの送受信に遅延が起きた

◆正常に機能しない
この問題には、さらに、もうひとつの問題が潜んでいました。
従来の安否確認システムでは、サービスを提供している事業者が自社で構築したサーバーを使用して災害が発生するたびに人が判断して安否確認メールを送信していました。そのため、この事業者が被災した場合、安否確認メールは送れないことになっていました。
この問題を解決するために、私たちは、Amazon Web Services（AWS）のクラウドサーバー上にシステムを開発することにしました。メインデータサーバーも「過去100年間に地震や津波などの被害報告がない」「日本に比較的近い」「電力が安定している」などの理由でシンガポールに設置し、メイン以外のデータサーバーも世界各地に分散させることで、国内の大規模災害にも影響されない環境を整えました。さらに、クラウド上にシステムを開発したことで、アクセスが急増して集中的に高い負荷がシステムにかかったとしても、自動でサーバーを拡張させることができ、システムを安定して稼働させることが可能になりました。

◆通信トラフィックの急増
東日本大震災では、災害発生後30分で通信トラフィックがピークに到達したことがわかっていました。そこで、分間100万通以上のメールを高速に配信できる「SendGrid（センドグリッド）」というメール配信システムを使用することで、通信トラフィックがピークに到達する前に安否確認メールを配信することを可能にしました。

これらシステムに関する課題を検証するため、弊社サービスを契約している全社を対象にした全国一斉訓練を実施しています。
日本全国から一斉にアクセスを集中させることで災害時と同等の高い負荷をシステムにかけ、システムが安定して稼働できるかを検証しています。また、弊社が主催して一斉訓練をすることで、参加企業においては、安否確認に対する従業員の回答訓練だけでなく、災害時に近い条件での運用ができるかを確認する管理者の訓練にもなっています。

従来の安否確認システムには、管理面でも、3つの問題がありました。
・人事情報の管理が重複して二重管理になる
・登録されているメールアドレスの有効性が不明
・個人情報の漏えいの可能性がある

◆二重管理の問題
従来の安否確認システムでは、従業員の入退社や人事異動があるたびに、社内の人事システムやグループウェアの管理とは別に、安否確認システムのユーザー情報もメンテナンスする必要があり、人事情報を二重で管理する必要がありました。
その無駄な作業を解消するため、弊社では、SmartHRやkintone（ユーザーデータを管理するアプリ）、cybozu.com、freee人事労務、Google Workspace、Microsoft Entra IDなどの人事情報管理サービスを利用している場合、1クリックでユーザーや部署の情報を自動的に同期して登録できるようにしました。前出以外のシステムで管理している場合でも、APIを活用することで同様に同期して登録ができます。
これらの人事情報管理システムで、ユーザー情報の追加や編集、削除を行うと、安否確認システムにも即座に反映され、部署情報も自動的に更新されます。部署情報に関連付けて安否確認の通知を自動的に送信する設定にしていれば、管理者はユーザー情報や災害時の自動送信設定を更新する手間がなくなり、無駄な作業を解消できます。

◆メールアドレスの有効性
弊社サービスでは、会社が所有するメールアドレスに加え、個人が所有する複数のメールアドレスを通知先に登録することで、安否確認メールが到達する確率をあげています。しかし、複数のメールアドレスが登録できるということは、無効になったメールアドレスが登録されている可能性も高くなります。そこで、事前に設定した周期で全ユーザーに対してメンテナンスメールを自動送信してエラーの有無を確認する仕組みになっています。その結果は、管理者であれば連絡網から確認でき、「登録してある通知先の数」や「連絡先に対するエラーの有無」などが確認できます。

◆個人情報の漏えい
個人が所有するメールアドレスを複数登録できることは、緊急時に確実に連絡を取るためには重要ですが、個人情報の漏えいに対して注意が必要です。
個人情報の漏えいの主な原因は、外部からの不正アクセスと内部の人的ミスとされています。特に、管理ミスや誤操作による漏えいが全体の約80%を占めています。そのため、プライバシー保護と個人情報の管理負担の観点から、ユーザーが登録した個人所有のメールアドレスなどは、管理者でも閲覧できない仕様にしました。同様の理由で、重要な個人情報になるGPS（位置情報）も意図的に取得しない仕様にしました。
外部からの不正アクセスに対しては、ログイン方式を二段階認証に対応させ、セキュリティを強化すると同時に、弊社サービス内のすべての通信をSSL暗号化することで、第三者による不正アクセス、盗聴、なりすましを極限まで防止しています。
※一部のフィーチャーフォンなどで最新のSSLに対応していない場合は、http通信になります。

災害に備えて、多くの企業でマニュアルや連絡網などを準備していました。しかし、東日本大震災では想定通りにことが進みませんでした。
従来の安否確認システムでは、従業員の安否確認までしか想定しておらず、その後の対策や指示をする機能が備わっていませんでした。その結果、経営陣や主要メンバーが状況を判断して議論しながら対策を立て、それを指示することに非常に多くの時間がかかっていました。

そこで、弊社では、経営陣やマネージャーを中心に「対策を検討や議論ができるメッセージ機能」と、一般社員に対して「現状の報告や方針の伝達、多くの意見や報告を求めるための掲示板機能」の2つのコミュニケーション機能を備えることにしました。これにより、緊急時でも迅速な情報共有と正確な意思決定が可能となります。

さらに、通常時には、ほとんど利用することのなかった従来の安否確認システムから、社内のコミュニケーションツールとして従業員にお知らせや関係者間のメッセージ交換などに活用できるシステムへと進化しました。このシステムは基本設定だけで手軽に運用することも可能ですが、詳細な設定によって多様な組織構造、運用・管理体制にも柔軟に対応できるシステムです。

災害が発生したときでも、多くの企業が災害リスクを最小限に抑えて、早期に事業継続できる事を願って安否確認サービスを開発しています。