STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

安否確認サービスをコーポレートエンジニアが導入するとどのような運用設計をするのか

こんにちは、STORES のPX部門IT本部でマネージャー兼コーポレートエンジニアをしている中野(@howdy39)です。

STORES では今年に入ってトヨクモ社の安否確認サービス2をエンタープライズプランで導入しました。

もともと安否確認用途としては別のクラウドサービスを使っていたのですが、下記のような理由でシステム切り替えを行いました。

  • メールを見ない人もおおいのでLINE連携ができるようにしたい(安否確認の回答スピードと回答率をあげたい)
  • 災害発生時に安否確認通知を自動送信したい(初期対応に時間がかかる)
  • アカウント発行・削除を自動化したい(運用コストをなるべくかけたくない)

本記事では、コーポレートエンジニアがセキュリティやAPIを考慮しつつ安否確認システムの導入を行うとどのような運用設計をするのか?という内容で書いていこうかと思います。

想定読者

  • 安否確認サービスの導入をしようとしている
  • セキュリティも重視したい
  • APIを使ってアカウント管理運用をラクにしたい

通知の運用設計

まずは機能要件の中でも最重要機能となる通知機能をみていきます。 今回導入した安否確認サービス2の通知機能はとても優れていて

  • 災害発生時の自動連動送信
  • 未回答者への自動再送信
  • LINE連携

など通知にまつわる機能はすべて用意されています。

上記以外にも、個人ごとに所属地域(自宅と会社の間の都道府県など)を設定し、当該地域に災害が起きたら通知する機能があるのですが、この機能は使いませんでした。つまり日本のどこで大きな災害が起きても従業員全員に安否確認通知が飛ぶ運用にしました。

これは下記のような理由で通知されないケースを嫌ったためです。

  • 住所登録してないユーザーには送られないため登録率を100%にする必要がある
  • 住所変更した際に設定変更忘れが起きる可能性がある
  • 出張, 旅行, 帰省時などに被災した際に通知されない可能性がある
  • 人によっては設定が大変になる
    • 例えば、京都在住の方が東京への新幹線出社を考慮すると、経路上の京都、滋賀、愛知、静岡、神奈川、東京を設定する必要がある

これらの理由と大きな災害の発生頻度を考えると全員に送られる運用で十分、と判断し所属地域を使った通知機能は使わないことにしました。

アカウント登録・削除方法の運用設計

安否確認サービスを使う上で一番運用コストがかかるのはアカウントの登録と削除であり、特に登録部分はどのような情報を入れたいか(=入れたくないか)も関わってくるのでセキュリティの観点でもとても重要となります。

www.anpikakunin.com

管理画面から1アカウントずつ登録するのは現実的ではないので、CSV 連携機能は最低限必要でもちろん用意されています。

安否確認サービス2ではSmartHR, freee人事労務, Google Workspace などと連携し、管理者が管理画面で連携ボタンを押すことでアカウント情報の登録と削除をまとめて行う便利な機能があります。 当初はSmartHRと連携してアカウント情報を取り込もうとしていましたが、これは運用コストとセキュリティ面を理由に使うのをやめました。

主に3つのデメリットがありました。

1つめが運用コストで、SmartHR連携時には管理画面を開いてボタンを押さないといけません。 アカウント登録タイミング(=入社タイミング)はある程度まとまっています。そのため入社のタイミングで押すだけなのでそこまで苦ではないのですが、問題は削除タイミング(=退職タイミング)です。退職タイミングは人によってバラバラなので退職日になったら管理画面にいって画面操作して…を行うのは大変です。 また退職日前に削除を忘れて退職済みの方に安否確認通知が飛んでしまう、なんてことにもなりかねないので人間の手をなるべく入れずに自動でやりたいです。

2つめがセキュリティ面で、弊社の利用方法の場合に不必要な情報も安否確認サービス側に連携されてしまう点です。 下記画像がSmartHRとの連携時に連携される情報なのですが、個人の電話番号が含まれてしまっています。

【安否確認サービス2】SmartHRとの連携マニュアル.pdf

万が一、安否確認サービス2から情報が漏洩してしまった場合に従業員個人の電話番号が漏れてしまいますし、安否確認サービス2のシステム管理者に個人の電話番号が見えてしまうのも懸念点です。セキュリティの基本は情報を拡げないことなので、使わないのにも関わらず個人の電話番号が連携されてしまうのは避けたいです。

3つめもセキュリティ面で、パスワード関連です。 管理画面からSmartHR連携する際に初期パスワードを設定するのですが、同タイミングで作られるアカウントは同じパスワードになってしまいます。 2つめに出てきたように個人の電話番号が連携されてしまうので初期パスワードのままですと、なりすまして他人の電話番号がわかってしまいます。もちろんそんな悪いことをする人はいないと思いますが、セキュリティは性悪説で考えたいので初期パスワードはユニークであることが好ましいです。 そのためSmartHR連携を使う場合、連携直後にCSVアップロードを行いパスワードを上書きするのが安全です。その場合はCSVアップロードが結局必要になるのでSmartHR連携をする利点がだいぶ小さくなってしまいます。

そのためSmartHR連携する際には初期パスワードをユーザーに教えない、という運用がおすすめです。 初回ログイン時に自身のメールアドレスを入れてもらい、パスワードリセットメールから初回ログインを行うという手順です。 これであれば全ユーザーをユニークなパスワードにすることが出来ます。

API でこれらのデメリットを解決する

こういうときに便利なのがAPIです。 SmartHR連携ですと上記にあげたような3つのデメリットがあったのですが、これはエンタープライズプランに用意されたAPIを使うことですべて解決できます。

anpi-guide.toyokumo.co.jp

APIの場合、下記のような実装が出来ます。

  • 登録する項目を絞れる(ログインID, パスワード, メールアドレスだけでOK)
  • 初期パスワードを秘匿できる
    • APIを実行するプログラム内でランダムパスワードを生成すれば、システム管理者でもユーザーの初期パスワードを知らない状態にできます
    • ※ 初期パスワードはユーザーにも伝えずパスワードリセットメールからログインする手順にしています
  • アカウント発行削除にかかる追加運用コストがゼロ
    • Google Workspaceを始めとした既存のアカウント発行・削除処理はSmarHRの情報をもとに自動発行する仕組みを構築していました。そのため新しいシステムを導入しても、アカウント発行削除にかかる運用コストがいままでと何一つ変わらないで実装できました

アカウント発行につかっているGoogle Apps Scriptのコード

APIと聞くと身構えてしまう方も多そうですが、Google Apps Scriptの場合ですと下記のようなシンプルなコードでアカウント登録ができます。 ポイントとしては、アカウント作成した直後は部署情報が未所属になってしまうことです。 未所属だと安否確認の通知対象にできないので、部署情報を更新する別APIも同時に叩く必要があります。

departmentCodes: ['top'] で更新することで最上位部署にいれています

const ANPIKAKUNIN_API_TOKEN = PropertiesService.getScriptProperties().getProperty(
  'ANPIKAKUNIN_API_TOKEN'
);

class AnpikakuninService {
  static createUser({ fullname, email, password }) {

    const url = `https://api.cloud.anpikakunin.com/v1/member`;

    const payload = {
      fullname,
      username: email,
      email,
      password,
    };

    const options = {
      method: 'POST',
      headers: {
        Authorization: `Token ${ANPIKAKUNIN_API_TOKEN}`,
      },
      contentType: 'application/json',
      payload: JSON.stringify(payload),
    };

    const response = UrlFetchApp.fetch(url, options);
    const content = JSON.parse(response.getContentText('UTF-8'));

    return content;
  }

  static updateDepartment({ email }) {
    const url = `https://api.cloud.anpikakunin.com/v1/member/${email}/department`;

    const payload = {
      departmentCodes: ['top'],
    };

    const options = {
      method: 'PUT',
      headers: {
        Authorization: `Token ${ANPIKAKUNIN_API_TOKEN}`,
      },
      contentType: 'application/json',
      payload: JSON.stringify(payload),
    };

    const response = UrlFetchApp.fetch(url, options);
    const content = JSON.parse(response.getContentText('UTF-8'));

    return content;
  }
}

ロールの運用設計

安否確認サービス2はロールが柔軟に設定できます。 マネージャー権限は使わずに、危機管理責任者とシステム管理者のみを使い、下記のように割り当てました。

  • 危機管理責任者(ロール)
    • 安否確認の管理組織メンバー
  • システム管理者(ロール)
    • アカウント発行削除にAPIを用いているためコーポレートエンジニア

anpi-guide.toyokumo.co.jp

データセンターの場所やSLAの有無をチェックする

安否確認システムでは災害発生時にちゃんと動くのかがとても重要です。 安否確認サービス2ではシンガポールをデータセンターとしてつかっていたり、SLAが明記されていることも安心材料でした。

www.anpikakunin.com www.anpikakunin.com

おわりに

今回、安否確認サービスを比較検討した結果、トヨクモ社の安否確認サービス2をエンタープライズプランで導入したのですが、APIが提供されているサービスはやっぱり良い。というのを再確認できました。

標準機能で実現できないことを自社にあわせてAPIで実現できるのはやはり強いです。

また、公式ドキュメントがとても丁寧に書かれているのでシステム導入者目線でもわかりやすいですし、ユーザーに対してのアナウンスも「公式ドキュメントのこの手順見てやってくださいー」とリンク貼るだけでOKなのも良かった点かなと思います。

anpi-guide.toyokumo.co.jp

もちろん、どのような安否確認サービスが自社にむいているかは各社違うと思います。 セキュリティや可用性を重視し、APIを活用した一例として本記事が参考になれば幸いです。