LINE各オフィスの ”来客受付” を支えるシステム

はじめに

こんにちは、LINEのIT戦略室で社内システムの開発と運用をしている上田 進太郎です。

LINEはここ数年、社員が増加傾向にあり、直近3年間は年2回のペースで拠点の増床を行っています。増床時の設計に必ず関わってくるのが、来客と受付の運用設計です。
来客と受付は、他社との会議や採用面接など、お客様との対面でのコミュニケーションで必ず発生し、「受付は会社の顔」とかよく言われたりしますよね。

その「会社の顔」を担っている、LINEの来客受付の運用とそれを支えるシステムを紹介します。

社内ポータルの予約システムについて

LINEでは社内ポータルサイトが存在し、そこではカレンダーやメールの管理、掲示板でのアナウンスなどが行われており、社員はだれでも利用できるようになっています。
社内ポータルのひとつの機能として、来客や会議室の予約画面も存在し、社内の予約関連は基本的にここで一元管理されています。APIも提供されており、このAPIを使用して以下で紹介する各種予約システムに連携させて運用を行っています。連携部分のシステムは基本的にスクラッチで作っています。(言語等は後述)

▼予約画面の一部 (来客予約と会議室の予約を一緒にすることもできる)

各拠点システム紹介 – 新宿ミライナタワー

本拠地であるミライナタワーでは、ビルに元々備わっている来客予約システムと有人受付で運用を行っています。ビルの来客予約システムはAPIが存在せず、WEB上のUIからCSVのアップロードでしか予約ができないため、上記で紹介した社内ポータルAPIとSeleniumを利用し、社内ポータルで行った予約情報を自動でビルの来客予約システムに連携するよう、スクラッチで連携システムを組んでいます。
連携システムはSeleniumと親和性が高いということと、開発者にPythonのノウハウがあったことによりPythonで開発されています。Repositoryの中身はこんな感じです。

LINEでは使用する言語や技術に縛りはなく、基本的には開発者の裁量やシステムの用途によって自由に選択することが出来ます。IT戦略室では新しい技術を取り入れた際に、このようにブログでの共有や社内での共有会で活発に情報共有がされています。
システム内部の仕組みとしては以下の図のようになっています。
workerで社内ポータルAPIに新規予約がないかを毎分(1分おき)に問い合わせます。
予約があった場合は予約情報をuploaderに渡し、該当の担当社員の社員情報(メールアドレスなど)を取得し予約と組み合わせてビル来客予約システムに登録できるCSVへ整形します。その後Seleniumで整形したCSVをアップロードという流れです。

来客受付フローとしては

①担当社員が社内ポータルで来客予約する。
②連携システムが社内ポータルの予約情報を取得し、ビルの来客予約システムに連携。社員と来客者にQRコードが添付されたメールが届く。
③ビル入場時、来客者の方に届いたQRコードを利用して入館証を発行していただき、受付フロアまで来ていただく。
④受付スタッフがアテンド&担当社員を電話などで呼び出し。

となります。

受付スタッフの業務負荷がちょっと高いのが課題として上がっていますので、なんとかシステム化できないか検討中です。(アテンド、担当者呼び出し以外に、会議室管理、お客様へのお水出し etc…)

各拠点システム紹介 – ACALL

ビル備え付けのフラッパーゲートが存在しない拠点にはACALLを導入しています。(ACALLのホームページ)

ACALLは設置に場所を取りませんし、無人で受付と担当者呼び出しまでできるので助かっています。ACALLと社内ポータルの連携には、APIがコンパクトに開発でき、dockerと親和性の高いGolangを使用してスクラッチで開発されています。
さらに、拠点の増減にも対応できるように、環境変数を変更しKubernetes上へ簡単にDeployができる仕組みになっています。Repositoryはこんな感じです。とてもシンプル。アプリとKubernetesへのDeploy用スクリプトやconfig用のRepositoryが分かれています。

また、担当社員は社内ポータルを使って予約するわけですから、ACALLのユーザー登録などを意識しなくてもいいよう、予約時に自動でACALLにユーザー登録をする工夫もしてあります。
システム構成は以下のようになっていて、社内ポータルAPIから毎分予約情報を取得するところは同じですが、Kubernetesを使用し、拠点毎にnamespaceを区切りpodを立ち上げています。
社内ポータルAPIへ問い合わせ時に各拠点のIDが必要になるのですが、namespaceで区切ってそれぞれの環境変数へ設定することにより、拠点が増減したときの対応をできる限りしやすくしています。
ACALLでは、予約と担当者への通知にユーザー登録が必要なので、その部分も自動で処理してくれるような連携システムになっています。
ACALLのAPIは近日中に公開予定だそうです。

来客受付フローとしては

①担当社員が社内ポータルで来客予約する。
②連携システムが社内ポータルの予約情報を取得し、ACALLへ連携。社員と来客者にQRコードが添付されたメールが届く。
③受付フロアまで来ていただき、届いたQRコードをACALLの端末にかざす。
④ACALLが担当社員をメールで呼び出し。
⑤担当社員が迎えに行く。

となります。導入スピードが速いのと、運用に手間がかからないのが特徴です。

今後増える予定の新しいオフィスでは、フラッパーゲートも弊社で用意できる状態なので、フラッパーゲート通過用のバーコードとACALLの端末にかざすバーコードを統合し、よりスムーズに来客ができる環境を準備中…らしいです!

各拠点システム紹介 – 大崎ガーデンタワー

オフィスの様子はLINE HR ブログ「大崎オフィス紹介」をどうぞ!

こちらも新宿ミライナタワー同様、ビルに元々備わっている来客予約システムを使用しています。ただし、こちらはビルの来客予約システムにAPIが用意されていたので、ミライナタワーよりは連携部分はシンプルです。連携部分のシステムはGolangでスクラッチ開発されています。ここまではミライナタワー同様なのですが、受付の業務負荷が高いことが課題として上がっていたので、独自の受付システムを導入しています。
つまり、大崎ガーデンタワーでは連携システムと受付システム、それぞれ別のシステムを導入しています。

まず、連携システムから見ていきましょう。Repositoryはこんな感じです。

連携システムに関しては、上記ミライナタワーで紹介したものとほぼ同じです。ただし、ミライナタワーと違いビル来客予約システムでAPIが提供されており、Seleniumを使う必要がなかったのでシンプルになっています。

続いて受付システムです。

▼受付の人がさわる、受付システムの画面(2件しか入ってませんが実際はもっと来客予約でぎっしりです)

この受付システムを受付スタッフに使っていただいています。「来ました」を押して、必要な情報を入力すると、担当社員のSlack,LINE WORKSチャット,メールに通知が飛ぶ仕組みです。

Repositoryはこのような感じです。ここにきてカラフル。Repositoryを分ける必要性も特に感じなかったのでAPIとフロントを1Repositoryで管理しています。

開発期間があまり長くとれなかったのでスピード重視で、APIはGolang、フロントはvue.jsで実装し、フロントのデザインについては社内で独自で開発したkoromoというcssフレームワークを使用しています。

koromoについて詳しく知りたい方はこちらもご覧ください。

予約情報取得など社内ポータルAPIの負荷を抑えるため、また、各種情報を迅速に取得するために、データはredisにcacheしています。以下は画面で担当者を呼び出す際のシステム概念図です。

来客受付フローとしては

①担当社員が社内ポータルで来客予約する。
②連携システムが社内ポータルの予約情報を取得し、ビルの来客予約システムに連携。社員と来客者にQRコードが添付されたメールが届く。
③ビル入場時、来客者の方に届いたQRコードを利用して入館証を発行していただき、受付フロアまで来ていただく。
④受付スタッフがアテンド&受付システム(Slack,LINE WORKSチャット,メール)で担当社員を呼び出し。

となります。

こちらの受付システムは新宿ミライナタワーには入っていないので、ミライナタワーの運用も更に改善できるよう修正してから、ミライナタワーにも導入しようと検討しています。

まとめ

来客受付を設計するときは

  • ビル固有のフラッパーゲートや受付システムは存在するか。
  • そもそも受付を有人にするか、無人にするか(コストやUXと相談)
  • 来客する人が迷わず、迎える人が大変にならないよう設計されているか

が鍵になると思います。
また、LINEのように増床が度々行われる場合、システム的に対応しやすい設計になっていると良いですね。

以上、「LINE各オフィスの ”来客受付” を支えるシステム」でした。