既製品を導入するか、内製するか

　ジュニア層プログラマーを多く抱える企業は時折、機能的にシンプルに見えるため安否確認サービスを内製することがあります。ジュニア層の勉強がてら社内システムを内製することで開発実績を積んでもらいつつ、あわよくばそれを社外に向けて売りたいと思う企業が数年前はよく見られました。

　また、システムの構造がシンプルであることから「Google Apps Script」（GAS）で内製する選択肢ももあります。これについての問題点は後述します。

　しかし、安否確認サービスが求められるシチュエーションは社会的な異常事態です。システムの冗長性や予想外のシチュエーション、本番で動かない場合のリカバリーが必要です。個社で対応するよりは、運用も含めて他社に任せられるようなSaaSを選択することをお勧めします。

安否確認サービス自体のBCP

　東日本大震災の発生後、特に上場を目指すような企業にはBCP（事業継続計画）の策定が求められるようになりました。私も策定に関わったことがあるので、その際の災害時レベル別対応方法を紹介します。段階を追うごとに厳しいシチュエーションになります。

　1～3についてはデータセンターへの社内重要サーバの移管が想定されます。4についてはAmazon Web Services（AWS）の「マルチ AZ」のような方法で複数拠点にデータやサーバを配置して冗長性を確保する、クラウドリフトが視野に入ります。

　5や6になるとAWSのマルチリージョンのような方法で、国を跨いでデータ管理やサーバ管理をすることが想定されます。技術的には可能ですが、現実的には大多数の従業員の安否も危うくなるラインのため、経営層と話をしながら「備えを諦めるライン」を設けるようにしました。

　安否確認サービスについてもこうしたBCPの考え方が必要です。オフィス内のサーバで動いているようなものであれば、1もクリアできないため、「いざと言うときに真っ先に応答しなくなるのが安否確認サービス」となる可能性があります。SaaSを使うにしても、1カ所のサーバで運用されているようであれば類似のリスクがあります。安否確認サービスの足回りについてもよく確認しましょう。

何の経路を使って送付するか

　多くの安否確認サービスでは、電子メール送付による安否確認が一般的です。しかし神奈川県の公立高校入試のインターネット出願システムで業者のサーバ設定ミスにより「@gmail.com」宛てのメールが届かないことが話題になりました。迷惑メールフォルダに振り分けられる可能性や、従業員のメールボックスがあふれていないかどうかなどを踏まえるとメール配送は不確実性が高いと言えます。定期的に不通となったメールアドレスをクリーニングする機能が備わっている必要があります。

　SMSや「LINE」アカウントに送付するサービスも存在しています。幾つかの安否確認サービスでこれらはオプションの場合もあることから、予算を鑑みながら選定しましょう。

人事情報システムとの連携

　「SmartHR」や「freee人事労務」などの人事情報システムを導入している企業も多いかと思います。これらとの連携も製品選定をする上で視野に入れることをお勧めしています。連携しないシステムの場合、いざ本番送信というときに送信先が最新でないために送れないといったことが想定されます。特にこうした安否確認サービスは個人の携帯電話宛に送付されることも多いことから、電話番号やメールアドレスが変わることを想定し、人事情報システムを正として送信する形にすることが望ましいです。

運用上のポイント

　安否確認サービスを導入しただけでは不十分です。運用上、決定しなければならない項目についてもお話ししていきます。

送信範囲を絞るべきか

　支社が多いような組織は安否確認サービスの運用で「状況に応じて支社ごとに安否確認を出しわける」という要件をつけたくなります。私もこの議論に参加したことがありますが、緊急時に従業員が出張や帰省、レジャーなどでどこに居るか分からないため、全社送信しても問題はないでしょう。

どういった雇用形態の人に送るか

　雇用形態別の送信対象者についても議論しておく必要があるでしょう。企業では正社員や契約社員、派遣社員、パート、業務委託、副業業務委託、学生アルバイト、選考中のインターンなどさまざまな雇用形態の人が働いています。

　SES（システムエンジニアリングサービス契約）やフリーランスエージェント経由で入場している業務委託は、指揮命令系統の観点から管理するかどうかは所属企業も交えて調整する必要があります。特に近年は、直接契約するフリーランスや副業人材も存在し、そうした人材は連絡対象にすることを考慮してもよいでしょう。

　選考中インターンについても、入社の意向を上げるという観点から「心配していますよ」というメッセージを込めて連絡対象とすることをお勧めしたいところです。事前に人事や労務、経営層なども交えて議論しましょう。

予行演習していますか？

　実際に安否確認の通知を送信し、対象者が問題なく受信できるかどうかを確認しましょう。従業員の中には頻繁に実施される予行演習を通して企業を「オオカミ少年」のように感じる人もいます。部署やチームごとの返信率を示しながら、しっかり返信するように伝えましょう。

誰が送信・受信管理をするのか

　安否確認の送付先として、個人の携帯電話やメールアドレスを登録することになるでしょう。これらの情報は個人情報であるため、誰が閲覧するのかが問題になります。かつて送信者の議論に参加した際は、個人情報の観点から人事や労務が担当するようにしました。

　また、この送信ボタンの押下や受信管理をする人のBCPも考えなければなりません。任意の一人や、行動を共にしやすいグループであれば冗長性が低いと言えます。幅を持たせた権限設定をお勧めします。

一番のポイントは「大型災害の本番できちんと送る」こと

　安否確認サービスの目的は有事の際に従業員の安否がきちんと確認できることにあります。今回の震災でもXでは「普段は予行演習で口酸っぱく返信を求められるが、地震後に全くこない」という苦情がありました。こうした行為を通して従業員は、「返信しなくてもよいのでは」と考えるようになります。

　震災に限らず台風や豪雨、洪水、豪雪などさまざまな災害が想定されます。しっかりとこれらの事態でも運用できるように意識していきましょう。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito