人には譲れない一線というものがある。大人としての尊厳を守るために----トイレには余裕を持って向かうべきだ。そう、誰だってわかっている。しかし現実は残酷だ。タイムリミットが迫る、そんなときほど、個室の戸は固く閉ざされていたりする。落胆もタイムロスも大きく、仕事効率に響く大きな問題だ。解決しなければならない、ITの力で!
身近な課題解決にこそ活きるIoTの機能をまずはおさらい
なんだかわからないテンションでリードを書いてしまってやや後悔気味の筆者だが、思わずリキんでしまうほど詳細で充実したセッションがJAWS Festa東海道 2016にあったのだ。サーバーワークスの中村 悟大さんの、「トイレで学ぶ、IoTの仕組み」だ。
「AWS IoTもリリースから1年が経ち、いろいろな活用法が見えてきました。IoTの楽しさは、テクノロジーで身近な課題を解決できるところにあります」(中村さん)
中村さんはまず、AWS IoTの説明から始めた。IoTではHTTPよりも軽量なMQTTプロトコルが使われることが多く、AWS IoTも双方に対応している。MQTTはパブリッシュ/サブスクライブモデルを採用しており、デバイスがデータをパブリッシュし、それを仲介するサーバーがあり、データを目的の形に処理してパブリッシュするという流れになっている。AWS IoTはこの仲介サーバーに当たり、ブローカーと呼ばれる機能を提供する。特長としては、X.509証明書やIAM、Cognitoなどの認証機能を備えており、セキュリティポリシーを詳細に設定できる点が挙げられる。
「またAWS IoTではルールエンジンやクエリーを使って、特定の条件時にあらかじめ設定したアクションを起こすよう設定できます。クエリーでは四則演算やタイムスタンプを発行でき、結構細かい条件を指定できます」(中村さん)
AWSの他のサービスをアクションとして設定しておけば、デバイスから送られてきた信号に基づいて判断を行ない、条件に合致した場合に特定の処理ができるという仕組みだ。1つのルールエンジンに複数のアクションを設定でき、連携可能なサービスも多い。通知機能としてはSNS、DBはDynamoDBやRedshift、データ分析ならMachine LearningやKinesis、CloudWatch、Elasticsearch Serviceといった具合だ。SNSやLambdaと連携できるので、それらを通じてさらに他のサービスと広く連携することも可能だ。
「たとえば、IoTのデータをRedshiftに溜めておき、Machine Learningで異常を検知したらSNS機能を使ってメールを送信し、Kinesis Streamにデータを投げてLambdaで加工するといったことができます」(中村さん)
解決すべき身近な問題が中村さんの職場環境に潜んでいた
中村さんには、IoTを使って解決したい課題があった。それは軽視されがちでありながら、業務効率の低下にもつながる重大な問題。そう、トイレの個室問題だ。中村さんが働くフロアの男子トイレには、個室が2つしかない。それに対して男性社員は40人。20人に1つという圧倒的不足である。
ちなみに事務所衛生基準規則第17条第2項によれば「男性用大便所の便房の数は、同時に就業する男性労働者六十人以内ごとに一個以上とすること。」とあるので、中村さんの職場では基準の2倍を軽く超えた数の個室が用意されていることになる。しかし、法律さえクリアしていればいいという問題ではない。もよおしたときに空いていなければ意味がないのだ。空室があるか否か、それが問題だ。むしろ、それだけが問題だ。
「しかも、私の席からはトイレが遠いのです。トイレまで行ってみたら満室だった、しかたがないから席に戻ってタイミングを待つ。この往復時間は非常に無駄です。じゃあ近くでトイレが空くのを待てばいいじゃないかと思うかもしれませんが、そこにも落とし穴があります。トイレから執務室に戻ってくるルートは1つではないので、扉ひとつを見つめて出待ちすることはできないのです」(中村さん)
詳細なフロアマップとともに、中村さんの職場におけるトイレ事情が語られる。IoTは現場の課題に密着した技術だけに、背景事情を具体的に説明することが対策や効果を理解するために役に立つ。
解決策その1:Raspberry Piでトイレ個室の状態を可視化
IoTのハンズオンなどでもよく使われる、みんな大好きRaspberry Pi。中村さんが最初の武器として選んだのも、そのRaspberry Piだった。それぞれの個室ドアに、開閉を検知するセンサーを設置。30秒ごとにパブリッシャー側のRaspberry Piに送信する。ドアの開閉信号を受け取ったRaspberry PiはAWS IoTにトイレの使用状況データを送信、AWS IoTはそのデータをサブスクライバー側のRaspberry Piに送信し、LEDで個室使用状況を可視化する仕組みだ。
「これにより、トイレまで行かなくても個室の使用状況がわかるようになり、席を立つ必要はなくなるはずでした。しかし、多くの人から見える場所にサブスクライバー側のRaspberry Piを設置したところ、LED表示が小さすぎて見えないという問題が浮上しました」(中村さん)
トイレが空いているかどうかを確認するためにRaspberry Piが見える場所まで行かなければならないため、一度席を立つという行為までは省けなかった。しかしトイレまで行くよりは移動距離が短くなり、ロスタイムの削減に成功。業務モチベーションが途切れる恐れも減った。課題解決にはトライ&エラーが付き物だが、中村さんの第1打は十分な効果を示し、1塁に選手を送り出せたと評価していいだろう。
解決策その2:slackにトイレ個室予約システムを導入
個室の満空情報収集まではできているので、次なる課題はその情報を席にいながらにして見えるようにすること。中村さんが選んだプラットフォームは、業務時間中は立ち上げっぱなしにしてあるslackだ。
解決策1で作った満空情報表示LEDはそのままに、個室の状況に変化があったときだけIoT Shadowを更新する。Slackで「/toilet status」とタイプするとAPI Gatewayを通じてLambdaが呼び出され、Shadowを参照して満空情報を返答する仕組みが作られた。
「これでトイレまで行かなくても、席にいながらにして個室の使用状況がわかるようになりました。しかし、使用中だった場合になんどもステータス確認をするのは効率的ではありません。そこで個室を予約しておき、空いたらslackで呼んでもらえるようにしました」(中村さん)
トイレに呼んでもらう。トイレに呼んでもらう。2回書いてみたが、なかなかシュールな響きだ。多忙な時や寒くてこたつから出たくない時、思わず「トイレが来い」と言ってしまうことはあるが、トイレの側から「お前が来い」と呼ばれるわけである。
システム的な構成としては、slackで個室を予約すると、予約キューとしてDynamo DBに保存。個室の状況に変化があり、空室の状態になったらキューの先頭にいる人をslackで呼び出す仕組みだ。ご丁寧に、呼び出し後10分経過しても個室状況に変化がない場合にはキャンセルとみなし、次の人を呼び出す機能まで備わっている。
「新たに用意したコマンドは /toilet reserve と /toilet cancel です。reserveコマンドを受け取ると、Dynamo DBのトイレ予約キューの最後に名前が追加されます。cancelコマンドを受け取ると、その人の名前がキューから削除されます。これで、何度もステータスを確認しなくてもよくなりました」(中村さん)
次に個室が空いたらトイレに行こう。そう予約しておけば、呼び出されるまでは業務に専念できるようになった。無駄な離席を最小限に抑えつつ、数少ない個室を最大効率で活用する。これはもう働き方改革の一環と位置付けていいと筆者は感銘を受けた。
しかしまだ戦いは始まったばかり、中村先生の次回作にご期待ください
さて、画期的なトイレ個室予約システムを作り上げた中村さんだが、課題がすべて解決されたわけではない。次なる壁は、オンラインとオフラインのすれ違い。2次元嫁が決して画面を超えてあなたのベッドに来ないのと同じように、slack画面内でトイレが呼んでくれたとしても、それが必ずしも現実の個室の状況と一致しているとは限らないのだ。
「slackで個室が空いたと連絡を受けて、トイレに向かいます。その間に、slackを見ていない人が先に個室に入っていたりするんですよね。でもこっちは個室が空いたと思って、そこにターゲットを定めてしまっていますから……」(中村さん)
大人としての尊厳を守るために、トイレには余裕を持って向かうべきだ。そのために予約システムまで作ったが、なお残る高い壁。中村さんはテクノロジーの力でこの壁を越えることができるのか。
「ドアの開閉センサーだけではなく、予約がある場合にはロックしておくようにするなど、物理的な対策との連携が必要かもしれません」(中村さん)
slack世界と現実世界のトイレを結ぶ、そのために中村さんは戦い続ける。快適な職場環境を得るために、そして人間の尊厳を守るために。
この連載の記事
-
第17回
デジタル
年末のJAWS-UG名古屋はre:Inventの振り返りLT(ただしLong Talk) -
第15回
デジタル
CMSをフレームワークとして活用し、クイックスタートを実現しよう -
第14回
デジタル
クラウドはアジャイル開発本来の力を引き出し、エンジニアの在り方も変える -
第13回
デジタル
ライター重森が体験したJAWS Festa 東海道 2016熱狂の1日 -
第12回
デジタル
「マイル手帳」のバックエンドをServerless Frameworkで構築 -
第11回
デジタル
しずおかオンラインの榊原さん、VPC内のLambdaの苦労を語る -
第10回
デジタル
しずおかランチ開発で得たLambdaとElasticsearch連携時の認証テク -
第9回
デジタル
サーバーレス事例たっぷりのJAWS-UG東海道 in 浜松 -
第8回
デジタル
8月27日、JAWS-UG東海道 in 浜松に行きまーす! -
第7回
デジタル
10月22日は名古屋へ!JAWS Festa 東海道 2016の申し込み開始 - この連載の一覧へ