みなさんこんにちは。
午睡チェックのディレクター/スクラムマスターをしている保坂です。
この記事は、UniFaアドベントカレンダー 18日目の記事となっております。
先日AWS Startup Architecture of the Year Japan 2020 Live Finaleで、ルクミー午睡チェックのアーキテクチャが評価され、ユニファが優勝することができました。
当日の生中継を見ていて優勝とった瞬間、とても興奮してslackに画面キャプチャを貼りまくっていたことを思い出します。 Well-Architected な仕組みに関してブログを見てください。
さて、今回のブログでは、午睡チェックの仕組みの補足と、施策を実装してからの失敗談を書きたいと思います。
■センサーとタブレットの間
午睡チェックの構成は大きく分けると、
センサー
アプリ(タブレット)
ネットワーク
サーバ
に分けられます。
実は、センサーとアプリの間でも、フォールトアボイダンスを考慮した作りをしています。
センサーとアプリはBluetoothで接続されており、接続が切れてしまうとセンサーの値を取得できなくなってしまいます。センサーと接続が切れてしまった場合、アプリ上でアラートを表示するようにしています。しかし、接続が切れてしまう前にアラートをあげることで、失敗を回避することができます。
As is: センサー ー ×接続切れ× → アプリ(接続切れアラート)
To be:センサー ーーー→ アプリ(接続切れそうアラート)
センサー接続切れ前にアラートを出し、その際に出した文言は次のアクションに繋がるようにしました。
ところが、この施策を回した際に失敗が起きたのです。
■その時失敗は起きた
接続切れそうな時に、アプリ上の文言は「デバイスと近づいてください」と表示させ、文言をタップすれば消える状態、バツボタンを表示している状態でした。このアラートを表示した時の先生の行動は、デバイスとセンサーを近づけていました。ですが、消せることが伝わらず「近づけたものの表示が消えない」状態を産み出してしまいました。
▼変更前
▼変更後
■暗黙のルールが失敗の原因
ある体験に対して、きちんとコミュニケーションが取れる状態を作り出せているのか?我々にとっての当たり前は、相手にとっての当たり前では無いかもしれないと、立ち止まって状況を考える必要があるなと、考えさせられる出来事でありました。
■最後に
午睡チェックのWell-Architected な仕組みの補足と、施策を実装の失敗を書きました。創造プロセスの積極的な参加は、具体的な成果へ結びつけ、その成功は影響力で測ることができます。引き続き、創造プロセスにダイブしていきたいと思います。
ユニファでは保育現場の課題解決のため家族コミュニケーションを豊かにするために一緒に働いてくれる仲間を募集中です!!