3月に「なぜ自分でアプリを作るのか」を書いた。あれから3ヶ月が経つ。
機能を考えるより先に、やるべきことがあると気づいた。設計の軸を決めることだ。
軸のないまま機能を積み上げると、どこかで必ずブレる。「この機能を入れるべきか？」に迷うたびに時間を使う。開発が止まる。
今回は、Taxi Meterを作るうえで自分が決めた「9つの設計原則」を公開する。
原則 1. 最初に画面を開いたとき、そこには指示がある
分析アプリを作っているつもりはない。
グラフを眺めて「ふむふむ」と満足するツールではなく、「今、銀座へ向かってください」という指示を出すツールにする。
数字はその理由として見せる。あくまで主役は「次の行動」だ。
これをAction Firstと呼ぶ。Taxi Meterの設計全体を貫く考え方。
原則 2. 入力が1秒でも面倒なら、続かない
どれだけ優秀な分析機能を作っても、入力が面倒ならデータが溜まらない。データが溜まらなければ何も分析できない。
理想は**「考えずに記録できる」**こと。
- GPS自動判定でエリアを取得
- ワンタップ入力
- 自動時刻取得
乗務中は手が空く時間が少ない。入力のコストを極限まで下げる設計にする。
原則 3. ネットが繋がらなくても動く
タクシーで移動しながら使うアプリだ。地下駐車場、トンネル、通信が不安定な場所はいくらでもある。
そのためオフラインファーストを守る。
- 売上分析
- 過去の乗務履歴
- エリア提案
これらはすべてスマホ単体で動作する。通信が必要なのは天気・鉄道情報・イベントデータなど「外部情報の取得」だけだ。
「ネットが繋がってなくて使えなかった」が起きないようにする。
原則 4. AIより先にルールベースを完成させる
「AIが提案する営業アプリ」と言うと聞こえは良い。だが最初からAIを使う必要はない。
金曜22時なら銀座
これはAIではなく、ただの集計結果だ。過去データを見れば出てくる。
まず統計とルールベースで動く提案を完成させる。それが正確に動くようになってから、リアルタイムの外部情報と組み合わせるフェーズに進む。
AIを使う順番を誤ると、精度が出ない提案をユーザーに出し続けることになる。信頼を失ったら終わりだ。
原則 5. 一度でも「外れた」と思われたら使われなくなる
営業支援アプリの命は信頼だ。
「この提案、全然当たらないじゃないか」と思われた瞬間、アプリを閉じる習慣ができる。
そのため初期は確信度が高いときだけ提案する。自信がない場面では、提案ではなく「判断材料」として数字を見せる。
毎回提案するより、当たる提案をする方が長く使われる。
原則 6. 「実験モード」を中核に据える
これがTaxi Meterの最大の差別化ポイントだと思っている。
例えば、
「ホテル前付けを5乗務試してみる」
を設定する。5乗務後に「平均円/時 +12%」と結果が出る。「採用」か「却下」かを判断する。
こういう営業のPDCAを回せる仕組みは、他のアプリにほぼ存在しない。
感覚でやっていたことをデータで検証できるようになる。
原則 7. 最初の提案データは私自身の経験則を使う
新規ユーザーが登録した初日、当然データはゼロだ。
だがそれでは何も提案できない。いきなり「データが少なすぎます」では使い物にならない。
最初は私自身の約3年・274乗務のデータから導いた経験則を標準搭載する。
- 羽田空港の狙い時
- 銀座・六本木の回転が良い時間帯
- 品川・高輪の需要パターン
データが蓄積されるにつれ、「標準」から「あなた専用」へ徐々に切り替わる設計にする。
原則 8. 「円/時」の精度にこだわる
売上の多い日が必ずしも良い乗務ではない。12時間営業して9万円より、9時間で9万円の方が効率は良い。
だから指標は**「円/時（時間あたり売上）」**を中心に置く。
ただし休憩時間を含めると指標がブレる。
- 休憩開始・終了をワンタップで記録
- 実稼働時間だけで計算
これをやらないと、「休憩を我慢して数字を上げる」方向に誘導してしまう。そうではなく、効率の良い営業時間を見つける指標にする。
原則 9. MVPのスコープを守る
最初から天気・羽田・イベント・AIを全部入れない。
最初に完成させるものはこれだけだ。
- 円/時の計算
- 勝ちパターンの抽出
- 空車ロスの見える化
- 実験モード
小さく作って、小さく改善する。完璧を待っていたらリリースできない。
まとめると、Taxi Meterは「営業OS」だ
9つの原則を並べて気づいたことがある。
このアプリが目指しているのは「分析ツール」ではない。
- 記録する
- 分析する
- 提案する
- 振り返る
- 改善する
この営業のサイクル全体を支える基盤だ。タクシードライバーの営業OSという表現が一番近い。
どんな機能を入れるか迷ったとき、「それは営業OSとして必要か？」で判断する。この9原則が、そのための基準になる。
次回（#3）は「設計哲学 — なぜこのアプリを作るのか」。 機能や数字ではなく、このアプリの根っこにある考え方を書く。
Taxi Lab — 現役タクシードライバーによるデータ営業研究所