※ この記事はLuup Advent Calendarの20日目の記事です。
こんにちは、Luupの小笠原です。
今日は、Luupのサービス運営を裏で支えているオペレーション用アプリ開発の紹介をします。インナーアプリは当然ユーザーの皆様の目に触れる機会はなく、インナーアプリ開発について公開されている情報も少ないと思いますので、ご参考になれば幸いです。
自己紹介
Product部とService Operation部の2つの部に兼務で所属して、以下のような業務を行なっています。
- 需給最適化
- ユーザーがどこで車両に乗ってどこで降りたいと思っているのかという需要に対して、必要な場所にポートはあるのか、ポートに車両はあるのか、車両が故障したり電池切れで使えない状態になっていないか、ポートが埋まって車両が返却できなくなっていないか、などの分析及び施策実施
- オペレーション構築
- 効果的かつ効率的なオペレーションの検討と、それを実現するためのオペレーション自動化の仕組み設計や各種インナーツールのPM業務
Luupの需給最適化も非常に難しく且つ面白い領域ですが、今回はオペレーション用のインナーアプリ開発について紹介します。
Luupのオペレーション概要
Luupの提供している電動アシスト自転車と電動キックボードは車両に搭載しているバッテリーで駆動しているため、時間経過による自然放電やライドによってバッテリーが減っていきます。そのため、車両が電池切れにならないように適切なタイミングでバッテリー交換をする必要があり、担当者がLuupのポートを日々巡回してバッテリー交換をしています。この現場で実務を担うチームのことをFieldチームとLuup社内で呼んでいます。
Fieldチームは、主に以下のような業務を行っています。
- 車両のバッテリー交換
- 故障した車両の回収
- 修理した車両や新規で購入した車両のポートへの投下
- 車両が余っているポートから、車両が足りていないポートへの車両の移動
- ポートに置いてある看板の修理やポートテープの張り替えなどの非定常業務
Fieldとは別にRepairチームも存在しており、
- 車両の故障を事前に防ぐための定期メンテナンス
- 故障した車両の修理
などを行っています。
今回紹介するオペレーション用アプリの主なユーザーは、上記のFieldチームとRepairチームです。 Fieldチームがバッテリー交換をする際のバッテリーの施錠/解錠や、車両を移動する際の車両の施錠/解錠や紐づくポートの変更、Repairチームが定期メンテナンスや修理を行なった際のログ管理、などをオペレーション用アプリから実行しています。
FieldとRepair以外にも多数のチームがLuupのサービス運営に携わっています。CS(カスタマーサポート)チームが車両の不具合情報を連携して、Repairチームが車両の安全性を担保して、その車両をFieldチームが適切な場所に配置したりバッテリー交換をすることで、Luupのサービス運営は成り立っています。また、ユーザーの皆様からのご意見や故障データの傾向を見てHardwareチームがより使いやすく壊れにくい車両の開発にも取り組んでいます。これらの各チームからの情報の記録や共有面でも、オペレーション用アプリは中心的な役割を果たしています。
ソフトウェア・IoT・ハードウェアが絡み合うLuupのサービスは、オペレーションも複雑になりがちです。現場のオペレーションに寄り添いながら、複雑なオペレーションをなるべく簡単で正確に行えるような業務フローに落とし込み、効率化することがオペレーション用アプリの目的です。
開発体制
Luupのオペレーション用アプリ開発は週1の定例で、現場で起きている課題の共有、ソリューション方向性の検討、自動化の具体的な条件やオペレーション用アプリに実装する仕様の検討、開発の優先順位付けやスケジュール管理、などを少人数（4名）、短時間（30分）で行っています。
実装時には、定例参加メンバー以外のAndroidエンジニアやServerエンジニアが実装を行なったり、車両の施錠や解錠の機能が関わってくる場合にはIoTエンジニアと連携して開発することもありますが、基本的にはオペレーション用アプリは少人数で開発を行なっています。
Luupがオペレーション用アプリ開発で意識している3つのこと
Luupがトライ&エラーを繰り返して辿り着いた、オペレーション用アプリ開発で意識しているポイントを3つ紹介します。
1. 現場主義であること
開発の大原則としています。オペレーション用アプリは、エンドユーザーの本音を日々密に受け取ることができるプロダクトです。オペレーションの現場で困っていることはないか、もっと効率化できることはないか、常にフィードバックをもらっています。現場からもらった要望をPMやエンジニアが機能に落とし込みますが、その機能が現場の課題を本当に解決するのかどうかも再度入念に確認します。また、オペレーション用アプリ開発に携わるエンジニアにFieldオペレーションに体験参加してもらうことで現場理解を深めています。逆に、オペレーションがルーティーン化すると現場の立場からは改善の可能性に気づきづらい場合もあるのでPMやエンジニアから改善案を出すこともありますが、いずれにせよ、最終的に現場のオペレーションの簡易化や高精度化や高速化に貢献するかどうかで、実装の要不要や優先順位を判断しています。
2. スピードを重視すること
簡易的なQAや現場経験の長い一部メンバーへの先行アプリ配信などで一定の品質の担保はしますが、基本的には早くリリースして、現場からのフィードバックをもらい改善することを重視しています。不具合が起きるリスクは上がりますが、リリースとフィードバックのサイクルの数を重ねることで中長期的にはアプリの質が高まると考えています。オペレーション用アプリだからこそ取れる方針だと思います。
3. 簡易検証で現場からフィードバックを早く得ること
上記の2つの方針とも関連しますが、オペレーション用アプリを開発する前にRedashを使って実装予定の機能の簡易的な検証をすることも多々あります。RedashでSQLを使ってデータを地図上に可視化することで、非エンジニアがオペレーション用アプリを再現できます。例えば、車両が余っているポートから、車両が足りていないポートへの車両の移動（Luup社内では再配置と呼んでいます）をFieldで行いたい時に、オペレーション用アプリに実装するためには当然アプリやサーバーの実装でかなりの工数を使います。アプリ実装する前に、Redashで擬似オペレーション用アプリを作ってFieldで実際に再配置を行なってもらうことで、本当にオペレーション用アプリに実装するほど効果のあるものなのか判断できたり、オペレーション用アプリ開発前にUI/UX面などのフィードバックを得ることができます。Redashを使った簡易検証は、限られた人数でスピーディな開発をする助けになっています。このやり方も、オペレーション用アプリだからこそ選択しやすいやり方だと思います。
実際の開発例
最後に、Luupの実際の開発例を1つ紹介します。Luupの運用している車両は徐々に増えており、現在は合計で5,000台以上の車両を提供しています。Fieldは以前より多くのバッテリー交換や車両の運搬をするようになりました。Repairチームもより多くの車両の定期メンテナンスや修理をするようになりました。そのようなオペレーションの大規模化を背景にして、FieldやRepair業務の現場をより効率良くしたいという想いから生まれた「車両の一括操作機能」の紹介です。
今までLuupで複数台の車両を操作（例えば施錠/解錠）する際は、①アプリのQR/ID入力で車両を読み込む②車両を操作する というように1台1台車両の操作を台数の数だけ実行していました。
そのため、例えばポートAからポートBに10台の車両を移動する際は、
-
ポートAで車両10台を解錠する
（①車両を読み込む+②車両を解錠する）× 10台 = 操作20回
-
ポートBで車両10台を施錠して、紐づくポートをAからBに更新する
（①車両を読み込む+②車両を施錠する+③紐づくポートを更新する）× 10台 = 操作30回
と合計50回ものオペレーション用アプリ操作が必要でした。
車両の一括操作機能により、①まとめて車両を読み込む②読み込んだ複数車両を一括で操作する というようにやり方を変えたことで、
-
ポートAで車両10台を読み込む
操作10回
-
読み込んだ車両10台を、ポートAで一括解錠する
操作1回
-
読み込んだ車両10台を、ポートBで一括施錠する
操作1回
-
読み込んだ車両10台を、ポートBで紐づくポートをAからBに一括更新する
操作1回
と合計13回（実装前比で-74%の操作回数削減！）のアプリ操作回数で同じことができるようになりました。バッテリー交換でも、同じようにオペレーション用アプリからバッテリーの電子鍵を解錠したり施錠したりする操作が必要ですから、この機能によりFieldチームのあらゆる活動が大幅に効率化されました。
例えばLuupのバッテリー交換回数は、この1年半くらいでなんと10倍以上に増えています。車両の台数が増えて、車両のライド頻度も高まっているためです。急成長するサービスを支えるためにこのような改善を積み重ねて、最高の効率で最高のサービスを提供することを目指してオペレーション用アプリの開発に取り組んでいます。
最後に
今まで紹介していなかったLuupのオペレーション用アプリについて初めて紹介させていただきました。
Luupは「街じゅうを駅前化するインフラをつくる」というミッションを掲げています。インフラという高い目標に辿り着くためには「ユーザーの皆様が乗りたい場所に車両がある」ことや「車両が電池切れや故障しておらず乗れる」など、他の交通インフラが多大な努力で実現している高い条件をLuupも満たす必要があります。また、オペレーションで最高の効率を実現することは、ユーザーの皆様に適切な価格で持続可能なサービスを提供できることに繋がりますので、これもインフラにとっては重要です。
Luupのオペレーションはまだまだ道半ばで、例えばユーザーの皆様が乗りたい場所に車両がないことや、逆にポートが埋まっていて車両が返せないことも多々生じていることを認識しています。そのような課題を解決して、私たちが他の交通インフラを利用する時と同じように、「乗りたい場所に車両がある」ことや「車両が電池切れや故障しておらず乗れる」などをユーザーの皆様が意識する必要もないほど安定したサービスを運営することがインフラとなるために必須だと考えています。
今回は、インフラを目指すLuupを裏で支えているオペレーション用アプリ開発の紹介でした。お読みいただきありがとうございました！
※ オペレーション用アプリ開発を含めて、一緒にLuupのサービスを作り上げる仲間を募集中です！
Discussion