COVID-19と共に変化する社内システム対応事例
寺田崇寿氏：「COVID-19と共に変化する社内システム対応事例」をテーマに、事例の1つして、出社自動判定システムの開発に関するお話をしたいと思います。LINE Growth Technologyの寺田と申します。よろしくお願いします。
まず簡単にですが、自己紹介です。私はLINE Growth Technologyの所属で、2020年の2月にプロジェクトマネージャーとして入社しました。もともとはSIの仕事をしていて、銀行のシステム開発やSAPのパッケージ導入など、比較的堅い分野のシステム開発に携わってきたという経歴です。
LINEでは、社内システム開発や出前館のサービスに関連するシステム開発など、比較的幅広い領域を担当しています。また、組織のマネージャーも兼任しています。
コロナへの対応として開発したもの
最初に、コロナへの対応として我々が何を開発したかを紹介したいと思います。出社に関連して、私たちは2つのシステムを開発しました。
1つ目が、「Office Attendance Count」というシステムです。こちらは、オフィスごとの社員の出社人数を集計・取得できます。1日の中でも、定期的に出社人数をカウントしていて、朝昼夕時点の延べ出社人数を確認可能です。LINEには、国内外のオフィスがあるので、海外を含めたオフィスの出社人数をこのシステムから確認できます。
次に、「Office Attendance」というシステムです。システムの名前が非常に似ていますが、こちらは主に、個別の社員とPayrollの担当者向けの仕組みになっています。
日本のLINE本社だけでなく、LINE FukuokaやLINE Growth Technologyなどのグループ会社でも共通して利用するシステムです。オフィスに出社すると、翌日自動的に各社員の出社状況がシステムに反映されます。
通勤費の実費精算の制度に対応するための仕組みで、これまでの勤怠システム上の勤務日とは別に、出社したのかという情報を記録する必要が出てきたことから、このシステムを開発しました。
Payrollの担当者は、月締めの際に従業員の出社日数のサマリファイルを取得し、この日数をベースに、通勤費の計算、支給を行っています。また、LINEの社員には外国籍の方も非常に多いので、社員全体で使うものに関連しては、日英の言語対応もしています。
せっかくですので、開発体制についても紹介したいと思います。リモートワークに関するシステムを今回開発したのですが、開発体制としてもリモートで行ってきました。
プロダクトオーナーは、東京および福岡にいる人事関連部門のメンバー、プロジェクトマネージャーとテックリードは福岡のメンバー、開発部隊は札幌のエンジニアと、リモートワークに関する取り組みを進めていく中で、自分たちでも、リモートでどこまでできるのかを実践しながら、このシステム開発プロジェクトを進めていきました。
なぜこのシステムを開発したのか
次に、なぜこのシステムを開発する必要があったのかについて、その背景をお話ししていきたいと思います。
まず、1つ目の理由は、既存のオフィスサービスを適切なかたちで維持していくためになります。LINEでは、朝食の無償提供や昼食のお弁当の販売などのオフィスサービスがあります。コロナ禍においてリモートワークが主流にはなりましたが、一方で、どうしても業務上出社する必要がある社員もいます。
より適切なかたちでサービスを提供するため、日々どのくらいの出社がありそうか。つまり、どのぐらいの需要がありそうかという情報が非常に重要でした。
2つ目は、オフィスファシリティの準備のためになります。感染予防のための席の配置の変更や、これまで会議室で行っていた会議がオンライン化することで、スタディルームのような個人スペースがこれまで以上に必要になるなど、オフィスの使い方にも変化が出てきました。
こちらも、出社の実績に基づいて、十分な設備を用意する必要があり、そのための基礎情報として出社状況に関する情報が必要となりました。
3つ目は、会社としての方針決定のためです。なかば社会全体が強制的にリモートに切り替わっていった中で、今後その傾向は続いていくのか、あるいは働き方が何かのタイミングで戻るのかを見極めながら、制度などの検討を進めていく必要がありました。
直近では「LINE Hybrid Working Style」を発表していますが、こちらも、出社実績の数字や、従業員からのフィードバックを受けながら検討が進められてきました。
そしてまず、オフィスの出社人数を把握するために、「Office Attendance Count」を先行してリリースしました。継続的に出社率を見ていく中で、平均としては、おおむね25パーセントくらいの出社率だね、というのが結果的にわかってきました。
リモートワークにかなり推移しているね、という状況を受けて、制度的な対応というのも検討が始められてきました。
その1つが通勤費の実費化で、日常的な通勤が実態に合わなくなってきたことにより、変更が検討されていました。これを受けて開発が始まったのが、「Office Attendance」です。このシステムに関しては、「とにかく機能もワークフローもシンプルに作ろう」というのがスローガンでした。
これは、制度が変わったから「日常的にやることが増えた」「面倒になった」というのを社員に感じさせないためには、どうしたらよいかに重点を置いて考えたためです。
出社すると自動的にそれが記録される。月末に内容を確認して、その数字に基づいた支払いが自動的に行われる。そのくらいのやり方がいいよね、と私たちは考えました。
その上で、なんらかの要素で出社を判定する必要がありますから、100パーセントの精度というのは難しいとしても、9割くらいの社員は、何もしなくても、このフローにのっとって、判定できるということを目標に掲げていきました。
その中で、出社状況の変更などは、上長の承認があったほうがよいのでは、などの観点もありましたが、基本的には社員を信用しようと、それでみんなの手間が削減できるのであれば、それがベストであろうと考えました。このへんの天秤の掛け方が、非常にLINEらしい、よい会社だなと思います。
ただ、社員を信用して、なにも不正対策をしないというわけではなく、事後チェックはできるように、出社の自動判定結果からの変更は記録としてとるようにしました。このへんは、社員に任せるところと、システムでちゃんと確認できる体制を作るという、非常によいバランスで意思決定をしていけたかなと思っています。
何をもって出社と判定するのか
その上で、最も重要な「何をもって出社と判定したか」について、具体的な話をしたいと思います。「何をインプットにしたの？」「どういう情報の組み合わせで精度を高めていったの？」という部分になります。
何が使えるかはいくつか検討しましたが、まずはオフィスに来たら確実に通る、オフィスのセキュリティゲートを候補に考えました。精度という観点では、これが一番高く出せるだろうという見込みでした。社員側が出社を登録するために、特に新たな作業が発生せずに済む。これまでどおり、ただゲートを通るだけでよいという点が非常に大きなポイントとなりました。
一方で課題もありました。LINEはオフィスが複数あります。ビルのセキュリティゲートはビルの持ち物ですので、オフィスによって機器が違い、データのフォーマットも変わってきます。システムで一元的に扱うには、これがアンコントローラブルな部分で難しいと考えました。
それに加え、人事の方が物理的な端末にアクセスして、この入館データを取得する必要があるなど、制約も多く、僕らの目指す自動化の実現に対しては少し違うね、ということでこの案はNGとしました。
このほかにも、オフィスに出退勤システム登録用のカードリーダーがあり、そちらはLINEの資産なので活用できるのではないか、という案も検討しました。
こちらについては、Webで勤怠登録する手段も取れる中で、出社した時にみんながカードリーダーにタッチしないと出社として扱われない、といった制約を作るのも少し違うよね、ということで、こちらの案も取り下げにしました。
LINE社員の持つPCに注目
こういった中で、できるだけ自然に、業務を始めるとみんなが利用するものは何であろうかと考えた末、LINE社員は基本的にPCを保持している点に注目しました。
そこから、オフィスのファシリティである社内ネットワークへのアクセス情報を使ってみようと考えました。LINEのネットワーク設備は、選任の部署が一括で管理しており、判定精度さえ担保できるのであれば、これが有効に使えるだろうと考えたためです。
一方で、ネットワーク情報単独では、誰が出社したか判別がつかないので、社内のさまざまなシステム、情報を統合してアーキテクチャを検討しました。
ネットワークに接続するのはPC資産ですので、まずはPCの資産情報になります。ネットワークへのアクセス情報とアクセスした資産の持ち主の情報を「Elasticsearch」上に統合して集めました。
そして、やりたいことはあくまでも通勤費に関連する出社判断ですので、どこでもオフィスに出ていればいい、というわけでもありません。
そのため、LINE内の別システムで保持している社員情報やオフィス情報も取得し、Office Attendanceのバッチで解析して出社判定に使うことにしました。これにより、社員が事前に登録している勤務地あるいは通勤先のオフィスに出社したかどうかまで、判別可能になっています。
これらの各システムは、LINE社内で独自に開発しているものです。ただシステムへのデータ連携が考慮されており、用意されているAPIなどを用いて、各システムからデータを収集することで、短期間で効率的に全体の仕組みを構築できました。
Office Attendance Countが約2週間、Office Attendanceが約2ヶ月と、要件定義から考えるとかなり短い期間のプロジェクトではありましたが、それを可能にしたのは、このあたりのアセットが事前にそろっていたことが非常に大きかったなと思います。
精度向上のための課題
一方で、精度向上のためにいくつかの課題も出てきました。
1つ目は、LINE内のテスト端末の問題です。テスト端末は、オフィスで保管されていて、資産の管理者としては特定の社員に紐づいています。一方で、テスト端末はシステムテストに利用するため、開発部隊のみんなが利用する資産でもあります。
このテスト端末がネットワークにつないだ状態になっていることで、その端末の管理者が出社していると判定されてしまい、誤検知の割合が高くなっていました。このため、テスト端末については全般的に判定から除いていく必要がありました。
2つ目が、VDI端末の問題です。VDI端末は、オフィスにある共有のデスクトップPCであるケースが多く、一部のロールの社員は個人のPCを保有しておらず、代わりにこの共有端末をVDI経由で利用していることが、あとになってわかってきました。
このため、VDI端末については、ネットワークに接続したPCの管理者というのが実際の利用者には当たらず、正しく出社している社員を判定できていない点が課題となりました。
この結果、特定のロールのメンバーだけが極端に出社の判定精度が低くなる状況に陥りました。これを解消するため、共有のPCそのものは出社の判定から除外し、一方で、VDIにログインしている社員を適切に判定して、出社判定していく必要がありました。
これを解決するため、また社内の別システムであるテスト端末管理、VDIアクセス管理システムからの情報取得をアーキテクチャに組み込んでいきました。このVDIアクセスなどの情報は、セキュリティ的に機微な情報でもあるので、このあたりの情報に関連しては、Elasticsearch上にいったん保管するという方式を取りました。
ここに保管するタイミングで、出社判定に必要な項目だけを絞り込んで連携し、適切なアクセスコントロールをするなど、このあたりは、セキュリティ部門とも適切に相談しながら進めていきました。
最終的な出社判定の精度
次に、最終的な出社判定の精度についてお話ししたいと思います。
こちらは直近の3ヶ月での実績の結果になります。この左側のグラフは、3ヶ月間、約90日間に対して、社員が訂正を行った割合になります。出社と自動判定したものを未出社に訂正した誤判定のケース、あるいは未出社だったものを出社に訂正した検出漏れを集計した結果になります。
結果として、修正された割合が1.35パーセントとなり、判定の精度としては、98.65パーセントという高い数値を出せました。
右側のグラフについては、出社とシステムが判定したものに対する訂正率になります。出社の検出漏れを除いた、純粋に出社の判定は正しかったかという割合になります。こちらについても、訂正率が1.77パーセントなので、精度としては98.23パーセントということで、9割は担保していきたいよね、という目標をクリアできる精度となりました。
やりたいことに対して非常に柔軟に対応できる環境
最後に、まとめになります。LINEの中には、たくさんの社内システムがあります。多くが自社開発しているシステムなので、やりたいことに対して非常に柔軟に対応できる環境がLINEの中で整っていると考えています。
そして私たちは、その中でなにか1つのシステムを開発するだけではなく、これらの組み合わせやこれらをつなぐことで、新たな価値を創り出す取り組みを進めています。
最後に、これはEnterprise IT部門のスローガンでもありますが、「LINERのために、LINEが一番働きやすいと感じられるような環境」を提供し続けるために、私たちは活動しています。
今回の出社自動判定システムのほかにも、社内の課題を見つけて改善していくためのさまざまな活動を行っているので、もしLINEの社内システムに興味を持っていただけたのであれば、非常に幸いです。
以上、私の発表は終わりとなります。ご清聴ありがとうございました。
