『混雑予報』在宅勤務で新サービスを検討~リリースした話
こんにちは。ナビタイムジャパン エンジニアの「ねこにうもれたい」と｢ねこはすべてを解決する｣です。
5/26(火) 緊急事態宣言が全面的に解除された翌日に Slack / Amazon Alexa / Googleアシスタント で簡単に混雑度を確認できる『混雑予報』アプリを同時リリースしました。
(Slackは既存のSlack向け乗換検索アプリ 『NAVITIME for Slack』 の機能拡張です)
「NAVITIME for Slack」「Amazon Alexa」「Google アシスタント」向けに駅の混雑予報を提供開始
こちらは在宅勤務期間中に検討･開発･検証を行いました。
今回は在宅環境勤務におけるサービス検討･分担開発の様子についてお伝えします。
『混雑予報』サービス概要
ナビタイムジャパンのサービス内での駅の検索数を集計し、過去の一定期間と比べて際立って検索数が上昇している日時、時間帯を確認できるサービスです。
1時間ごとに「通常通り」「通常の約2倍」「通常の3倍以上」の3段階で混雑度を予報します。
開発背景
なぜこの3サービスなのか?
混雑予報をお知らせするサービスを検討したとき、｢日常使いできる｣｢すぐに呼び出せる｣ことが重要だと考えました。
そのため、在宅勤務で利用の増えているSlackと、朝の支度をしながら毎朝簡単に呼び出せるAmazon Alexa / Googleアシスタントを選びました。
3サービス同時リリースにしたのはニュースインパクトを狙ったのもあります (じつはSlackは先行して開発完了していましたが、リリースのタイミングを揃えました)。
緊急事態宣言が全面的に解除された翌日というタイミングにリリースできたこともあり、各種ニュースサイトにも取り上げていただきました。
開発のポイント
とにかくシンプルに
｢時間も指定して調べられたほうが便利では?｣
｢いつも使う駅を登録できたほうが便利では?｣
仕様検討の段階でいろいろやりたいことやアイディアが出てきます。
ただ、とくにVUI(Voice User Interface)では複数の機能があることがユーザに伝わりづらく、何回も会話が発生するとユーザが離脱しがちです。
ユーザが求めているのは多機能ではなく、必要な情報にすぐたどり着けるシンプルな動作です。
そのため最初に出たアイディアも削り、駅の当日の混雑予報を返すというシンプルな仕様にまとめました。
対応するケースを絞り込む
｢上手く聞き取れない駅名はどうする?｣
｢同じ名前の駅名は?｣
｢通称はカバーする?｣
SlackのようなフリーフォームもAmazon Alexa / GoogleアシスタントのようなVUIも、ユーザ入力の自由度が高くいろいろなケースが考えられます。
開発者としては思いつくケースにはなるべく対応したくなりますが、すべてのケースに対応するのは不可能でコードも複雑になります。
そのため今回は、できることを少なくしかつ正常フローに注力しました。
リモートワークですべて完了
バックエンドにはAWSやAzureを利用しており、フルリモートで開発完了しています。
相談はSlackで。共有はConfluenceで
仕様検討や相談はすべてSlackで。決定事項の共有はConfluenceで行いました。ビデオ通話はじつは一度も使っていません。
Slackに関係者が全員joinしているパブリックチャンネルを用意し、そこで全てのやり取りを行って情報をオープンにしました。気づいた人が問題点と解決案をSlackで提示し、気になった人がツッコミという流れで、各自のレスポンスが早かったこともありチャットで不自由なく進められました。
一度仕様検討が難航し、｢話したほうが早そう｣という雰囲気になりましたが、体調が万全でないメンバーと夕方以降MtgがNGなメンバーが居たため翌日に持ち越し、翌朝すんなりチャット相談で決まったことがありました。
在宅勤務だと｢切りの良いところまで｣と作業を続けがちですが、途中でも業務を切り上げ気分転換することも大事だと学ぶ出来事でした。
工夫したこと
常に最新の仕様を参照できるようにドキュメントを整備した
今回、エンジニア3人がそれぞれのサービスを並行して開発したので、情報の鮮度保持は最優先で行いました。 そこで、早い段階で仕様をConfluenceにまとめて都度更新を行い、常に関係者が最新の仕様を参照できる環境にしました。
QAの負担をなるべく軽減する
特に今回は短期間での開発ということもあり、QAのスケジュール・リソースに厳しい制約がありました。
そのため、QAの負担を軽減するためにサービス間で不要な機能差分を作らないように心がけました。仕様作成前に各プラットフォームでできることとできないことを調査し、差異がある部分の機能は使用を避けました。
この取り組みに関して今回担当してくださったQAさんに所感をお伺いしました。
仕様が揃っていたのはやりやすかったです。
発生した事象がデバイスの仕様によるものなのか、不具合なのかの切り分けが楽でした。
テスターさんも初めて触るデバイス、かつ自宅からの作業だったので助かりました。
逆に、テスターさんのデバイスの初期設定を補助できる人がおらず、準備に時間がかかってしまったそうです。サポートの仕方は今後の課題です。
また、仕様を揃えたこと以外にも貢献できた点がありました。
・ゴールが明確で仕様をシンプルにできた
・仕様が資料として残っていた
・QAからの質問に対する関係者の反応が早かった
Alexaスキルの開発には実機を使わない
今回のAlexaスキル開発はシミュレーターのみで完了しました。シミュレーターは開発時の強力な助けとなります。
(参考: 公式ドキュメント )
できること(一部)
・Webブラウザ上で動作する
・Amazon Alexaとの対話に音声・テキストが使用できる
・送受信したJSONの内容の確認ができる
なにより、検証用のAlexa端末を家に持ち帰る必要がなくなります！
まとめ
・Slack / Amazon Alexa / Googleアシスタント で『混雑予報』アプリを同時リリースした
・仕様検討からリリースまでの全行程がリモートで行われた
・成功の秘訣はこまめな連絡と最新の情報共有
今後の展望
機能のアップデート検討アイテム
・Alexaスキル『混雑予報』:
・画面付きデバイスでの混雑度表示
・NAVITIME for Slack:
・混雑の共有機能
・時間指定で定期実行してお知らせ
新情報の提供
まだまだ人混みを避ける必要性がありそうなので、電車ごとの混雑度などの有益な情報を案内することを検討をしています。