みなさんこんにちは！
サーバーワークスのIoT担当の中村です。

今回の記事もIoT関連の記事です。タイトルがちょっとアレですが、オフィスでの働き方についてのお話です。サーバーワークスの東京オフィスは仕事の効率を上げるために、様々な工夫が凝らされています。そこで、「実際の所どうなのか」と思った私が社員の動向をトラッキングした結果、効率に繋がる何かが見えてきた、という話です。

話は遡り、2015年の東京オフィス移転の話から始まります。少々前置きが長く恐縮ですが、しばしお付き合いください。

※前置きを飛ばして本題から読む方はコチラ

オフィス移転プロジェクト

サーバーワークスの東京オフィスは、2015年3月末に江戸川橋から飯田橋に移転しました。引っ越しの際には新しいオフィスのデザインやレイアウトに関わりたい人たちがタスクフォース(特定の課題に取り組むためのチーム)を組み、結果的に素晴らしいオフィスが出来上がりました。今の飯田橋のオフィスには、代表である大石の意思や、タスクフォースのメンバーの思いが詰まっています。

オフィスを移転した当時は、特に以下のキーワードが強調されていました。

BYOD
フリーアドレス
3つのC

この3つのキーワードについて、ひとつずつ紹介していきましょう。

1. BYOD
BYODとは、 Bring Your Own Deviceの略で、社員が自分のデバイスを持ち込んで仕事をすることです。会社が指定するOSや、会社の指定するセキュリティソフト等がインストールされていることが前提ですが社員は自分の使い慣れたデバイスを業務で利用することができます。(※BYODに関しては東京オフィスに限らず、全社的に行われています)

2. フリーアドレス
フリーアドレスとは、社員が固定席を持たずに空いている席にて自由に仕事をすることです。サーバーワークスの東京オフィスには一部の数名を除き、基本的にはフリーアドレスとなっています。オフィスには一般的なデスクの他に、ソファー席や円卓、小上がり(畳)などのスペースが用意されているため、社員は好きな場所で好きなように仕事をすることができます。

例えば、小上がりスペースはこんな感じです。彼らは談笑しながらネットサーフィンしているようにも見えますが、これでも仕事をしています。

3. 3つのC
サーバーワークスの東京オフィスは4つのエリアで区切られています。コラボレーションエリア(Collaboration Area)、コミュニケーションエリア(Communication Area)、コンセントレーションエリア(Concentration Area)、そしてリフレッシュルームです。リフレッシュルームは休憩や食事をする所、他のエリアについては、仕事を行うスペースになっていて、それぞれ特徴があります。

コラボレーションエリアは、ガヤガヤしながら仕事をするスペースで、プロジェクターが2機設置してあり、勉強会などもこの広いスペースで行われます。コミュニケーションエリアは、人と話しながら仕事を行うスペースとなっていて、固定電話はこのスペースにのみ設置してあります。最後にコンセントレーションエリアは、その名の通り集中して仕事を行うスペースです。このスペースのみそれぞれの机はパーティションで区切られ、イヤホン、ヘッドフォンの着用が許可されています。

オフィスの見取り図を大まかに色分けると、以下のような形になっています。

サーバーワークスの東京オフィスを特徴づけているのは上記で紹介した「BYOD」「フリーアドレス」「3つのC」の3つのキーワードです。社員は自分の使い慣れたPCをもって出社し、その日の気分に応じて、仕事を行うエリアを選択します。もし、その日の午後に気が変わって、人と話したくなったり、集中したくなったら、席を移動すれば良いのです。

このオフィスの目的

上記で3つのキーワード「BYOD」「フリーアドレス」「3つのC」を紹介しましたが、なぜこのような取り組みを行っているのでしょうか。それは、「仕事の効率を上げるため」…と代表は言っています。

自分に当てられた8時間の中で、集中しなければいけないのだったら集中の方に行こう、コラボレーションしなきゃいけないのだったらコラボレーションの場所に行こうよというかたちで、いまやらなければいけない作業や業務、それに合わせて場所を移動して仕事の効率を上げていこうと、こういうチャレンジをやっているわけなのです。

引用: 社内サーバゼロ、フリーアドレス、メールをやめてSlack。クラウド専業SIerが模索するクラウド時代の働き方夏サミ2015
http://www.publickey1.jp/blog/15/slacksier_2015.html

それでは、効率とは何でしょうか？weblio辞書には、以下のように書いてあります。

こうりつ【効率】
> ①機械作業などをする際に，その仕事量とそれを行うのに要したエネルギー量との比。「熱－」
> ②（費やした労力に対する）仕事のはかどりぐあい。仕事の能率。「－のよい作業方法」

引用: weblio辞書
http://www.weblio.jp/content/%E5%8A%B9%E7%8E%87

今回の話では②の定義が近いと思います。

さて、仮に効率を「費やした労力に対する、仕事のはかどりぐあい」と定義とすると、「費やした労力」というのは何でしょうか？また、「仕事のはかどりぐあい」とは何でしょうか？オフィスを3つのエリアにわけて、フリーアドレスとしたことで何か良いことはあったのでしょうか？

というわけで、疑問に思った私はとりあえず社員のストーキングを始めることにしました。

本題

前置きがかなり長かったですが、ここからが本題です。

社員のストーキングと書きましたが、具体的には「社員がどこで、どんな仕事をしているか」というデータを集めてみた、という話です。詳細は後ほど紹介しますが、結果的に以下のようなレポートが出来上がり、この中で色々分析することができるようになりました。

これを行うには、元となる社員の行動のデータを用意して、収集・集計して、分析する必要があります。順に追っていきましょう。

まずは、元データの集め方を紹介します。

元データとなる行動データを用意する

場所(どこにいるか？どんなところにいるか？)

社員がどこにいるか、という情報はCisco社のMeraki MR32を使って取得しています。MR32はCisco社のアクセスポイントで、今回はこのアクセスポイントに実装されている「CMXロケーションアナリティクス」機能を使って場所を取得しています。CMXロケーションアナリティクス機能とは、アクセスポイントに接続しているデバイスがどこにあるのか、等を取得できる機能です。MR32のコンソールから以下のようにデバイスの位置を表示することもできますし、位置情報を特定のURLに位置情報等を含んだJSONをPostさせることもできます。

今回はこの機能を使って、リアルタイムにデバイスの位置情報をデータ収集用のAPIサーバーにPostさせることで、社員(のデバイス)がどこにいるか、という情報を集めています。

参考: Meraki MR32 https://meraki.cisco.com/products/wireless/mr32
参考: Location Analytics API https://meraki.cisco.com/technologies/location-analytics-api

また、サーバーワークス東京オフィスでは温湿度センサーをエリア毎に設置しているため、デバイスの場所がわかれば、そのデバイス周辺の温湿度もわかります(目安程度ですが)。せっかくなので、このデータも活用します。

なお、温湿度センサーについての話は以下の記事を御覧ください。

SensorTagとEdisonで室温計を作ったった - サーバーワークスエンジニアブログ -
http://blog.serverworks.co.jp/tech/2016/02/26/play-with-sensortag-and-edison/

行動(何をしているか？)

社員が何をしているか、という情報は各種SaaSから集めることにしました。サーバーワークスでは業務毎に色々なSaaSを使い分けてしています。例えば、プロジェクトの管理にはBacklog、ファイルの共有にはBox、コミュニケーションにはSlack、といった具合です。そして、これらのツールにはログをリアルタイムに特定のURLにPostする(Outgoing Webhook)機能が備わっていることが多いです。もちろん、業務の中には、これらのツールを使わないものもあります。例えば、考え事をしたり、会議に参加するような業務です。そのため、今回の手法で取得できるデータが社員の行動を全て網羅しているわけではないですが、とりあえず今回はこれで良しとします。

データの収集方法は、前述したMerakiのCMXロケーションアナリティクスでデータを集めた手法のように、データ収集用のAPIサーバーに向けて各種SaaSのログが流れるようにすれば、社員が何をしているかを収集することができるようになります。

収集・集計する

データの収集・集計はAWS上で行います。というわけで、まずは構成図です。

この構成図の赤枠が「社員がどんな所にいるか？」を収集する構成で、黄枠が「社員が何をしているか？」を収集する構成です。そしてそれぞれが、Kinesis Firehoseを経由して、Redshiftの各テーブルへと溜まっていきます。

赤枠については、まずMR32のLocation Analytics APIによるPostを受けるためのAPIサーバーを用意しておきます。APIサーバーはELBとEC2のごく普通の構成です。そして、受け取ったデータはDynamoDBに格納しておきます。なお、Location Analytics APIから送られてくるデータは1回のPostにつき、アクセスポイントに接続しているデバイス分の位置情報等が送られてくるので結構な量になります。以下がサンプルです。緯度や経度、計測時間、OS、等が送られてきます。

{
    "version": "2.0",
    "secret": "xxxxxxxx",
    "type": "DevicesSeen",
    "data": {
      "apMac": "0a:0a:0a:0a:0a:0a",
      "apFloors": [
        "xxxx"
      ],
      "apTags": [],
      "observations": [
        {
          "ipv4": "/xxx.xxx.xxx.xx",
          "location": {
            "lat": 35.701790580442186,
            "lng": 139.7432836668546,
            "unc": 0.06893999402757973,
            "x": [
              17.589247823629563
            ],
            "y": [
              5.467205516882092
            ]
          },
          "seenTime": "2017-02-28T02:58:25Z",
          "ssid": "xxxxxx",
          "os": "Windows",
          "clientMac": "0b:0b:0b:0b:0b:0b",
          "seenEpoch": 1488250705,
          "rssi": 54,
          "ipv6": null,
          "manufacturer": "Intel"
        },
        {
          // 以下デバイスのリストが延々と続く
        }
      ]
    }
  }

「この情報だと誰のデバイスかわからないじゃないか」と気づいた方は鋭いですね。この情報で持ち主を特定できそうなものは、せいぜいIPアドレスかMACアドレスくらいです。そのため、デバイスに振られるIPを固定したり、全デバイスのMACアドレスとその持ち主を把握したりしないと、デバイスと人を紐付けることができません。

というわけで今回は、Slackのコマンドから自分のデバイスのMACアドレスをDynamoDBに登録する仕組みを作りました(構成図右上)。この仕組みで自分のデバイスのMACアドレスを自己申告してもらうことで、このログからでも「誰のデバイスなのか」がわかるようになります。

黄枠の部分は、各種Webhookを受けるためのAPIサーバーを用意しておきます。APIサーバーはこちらもELBとEC2の構成です。また、Slackに関してはWebhookではなく、Real Time Messaging APIを使ってWebsocketで接続してデータを収集します。ここで収集できるデータは各種SaaS上で、「誰が、いつ、どんな事をしたか」というデータです。

そして、収集したデータはそのままKinesis Firehoseに流して、Redshiftに蓄積していきます。そして、Kinesis FirehoseからRedshiftにデータを流す時に、LambdaによるData Transformationの機能を利用して、「誰が、いつ、どんな事をしたか」というデータに「どこで(どんなところで)」という情報をDynamoDBから取ってきて足します。これにより、「誰が、いつ、どこで(どんなところで)、どんな事をしたか」というデータになり、それがRedshiftのSummary Tableに蓄積されていきます。

赤枠のDynamoDBからRedshiftのLocation Tableに伸びている線があります。これは何をしているかというと、DynamoDBに入っているデバイスの位置情報を継続的にRedshiftに溜めています。DynamoDBには最新の情報のみ保管し、Redshiftには継続的な情報を蓄積しています。つまり、DynamoDBには「今だれがどこにいるのか」というデータが入っていて、Redshiftには、「誰が、どの辺りにどのくらいの時間いたのか」というデータが入っています。

分析する

データが集まったら、分析です。一番ワクワクするところですね。今回はPowerBIで行います。PowerBIのRedshiftコネクタかPostgreSQLコネクタを利用すれば、Redshiftに接続してデータを取得することができます。

それでは、早速ですが分析の結果です。今回は、PowerBIで以下のようなレポートを作成しました。

このレポートでは、東京オフィスの中で、誰がどんなところで、どのくらい業務を行っているのか、を分析することができます。他にも、どんなSaaSを良く利用しているのか、各SaaSで具体的に何をしているのか等も確認することができます。

画面左上のオフィス見取り図にオーバーレイされている棒グラフは、棒グラフが生えている位置(X軸)における効率です。今回は効率は、「その場所で行動した量(回数)/そこにいた時間(分)」としました。例えば、1時間同じ場所にいて、Slackで30メッセージ、Boxでファイルを4回アップロード、Backlogのチケットを2回返したとします。その場合、今回の効率の計算方法に当てはめると、効率は「(30 + 4 + 2) / 60 = 0.6」となります。

それでは、このレポートについて、もう少し掘り下げてみましょう。今回は、私の同期である高橋(taisei)の仕事ぶりをこのレポートで見てみます。人で絞り込むには右上のリストにチェックを入れます。絞り込むと、棒グラフや円グラフなど、全てのビジュアルも同様に絞り込まれます。例えば以下のレポートを見ると、taiseiのSaaSの利用割合は、Slack 58%, Box 24.7%, Backlog 16.6% ということがわかります。

次は、さらにBoxでどんな事をしているのかを掘り下げてみてみましょう。左側の円グラフのBoxをポチっとすると、さらに情報を絞り込めます。

すると、Boxでどんなディレクトリを利用しているか、そしてどんな行動(アップロード、プレビュー、ダウンロード等)をしているかも見ることができます。そして、棒グラフでは、全体のうち、Boxの利用が占める割合がどの程度なのか、というのを確認することができます。taiseiはCommunication AreaでBoxを利用することが多いみたいですね。

また、左下には日時で絞り込むためのボタンを用意しています。例えば、時間で絞り込んだり、曜日で絞り込んだりすることができます。以下は10時で絞り込んだ場合と水曜日で絞り込んだ場合のデータです。このレポートを見る限りだと、10時は比較的効率が高く、色々なエリアに座っていることが多いようで、逆に水曜日は限られたエリアに座っていて、しかも効率があまり良くない、ということがわかります。

(10時に絞り込んだ図)

(水曜日に絞り込んだ図)

…というわけで、PowerBIを用いたデータの分析の紹介でした。なお、このレポートは予め用意されているわけではなく、白紙のキャンバス上に各種コンポーネント(棒グラフや円グラフ等)を配置していくような感じで作成します。また、集めたデータも裏で関連付けておく必要があります。

まとめ

大分記事が長くなりましたが、今回はサーバーワークスの東京オフィスの話と、IoTを絡めた社員の動向のトラッキングと、その分析についてのお話でした。

行動の節でも書いた通り、今回の手法で取得できるデータが社員の行動を全て網羅しているわけではないので、本当の業務効率を表しているものではありません。もっと言えば、そもそもの効率の計算方法についても、正しいかどうかはわかりません。

ですが、まずは集められる所からデータを集めて、自分のデータを客観的に見ることで、業務効率の向上に繋がる何かのヒントになるのではないかと考えています。また、個人に絞らずにデータを総合的に見ることで、次のオフィスのデザインや、現在のオフィスの改善に繋がるかもしれません。この活動が、将来的に意味のあるモノになるかどうかは今のところわかりませんが、とりあえずもう少し様子を見ていきたいと思います。

また、今回の記事で紹介したデータ収集の構成、PowerBIによるレポートは2017年7月5日に開催される「SORACOM Discovery 2017」に展示します！！
私も展示員としてブースに立ちますので、詳細を知りたい方は是非7月5日に ANAインターコンチネンタルホテル東京までお越しください。

SORACOM Discovery 2017
https://discovery2017.soracom.jp/