問題と仮説 日常で見つけた問題を、試して確かめる

「予約できるたこ焼き屋」を考えていて、予約より先に必要なものに気づいた

小さなたこ焼き屋の仕組みを考えていました。最初に浮かんだのは「予約できるようにする」です。スマホで注文しておけば、着いたときには焼き上がっている。並ばずに済む。悪くない話に思えました。

ところが、自分が客だったらどうかと考え直したところで手が止まりました。予約する前に、確かめたいことがあります。

予約より先に、知りたいことがある

  • 今日はやっているのか
  • いま注文を受けてくれるのか
  • どれくらい待つのか
  • もう売り切れていないか

考えてみれば当たり前で、予約というのは「その店が今日やっている」と分かって初めて意味を持ちます。開いているかどうか分からない店を、予約しようとは思いません。

順番が逆だったわけです。

人の行動には順番がある

並べてみると、こうなっている気がします。

  1. いま使える状態なのかを知る
  2. 利用するか判断する
  3. 行動する(店に向かう)
  4. 予約する、買う

サービスを作る側は、たいてい下から考えます。予約、決済、会員登録、アプリ。機能として立派に見えるのは下のほうだからです。私も下から考えていました。

でも利用者は上から順に通ります。そして一番上でつまずいたら、下にどれだけ立派な機能が並んでいても、そこまで辿り着きません。

「ステータス戦略」と呼んでみる

名前がないと考えにくいので、仮にこう呼んでみます。

ステータス戦略:時間によって変化する状態を、利用者が自分で確認できるようにすることで価値を生む戦略。

肝心なのは「自分で確認できる」というところだと思っています。店に聞けば分かることを、聞かなくても分かるようにする。やっていることはそれだけです。新しい機能を足すというより、すでにある情報を外から見えるようにする、という感じに近い。

たこ焼き屋だけの話ではなさそうだ

同じ形の話が、まったく違う場所にもある気がしてきました。思いつくまま挙げてみます。

  • 飲食店:営業中/準備中/売切れ/あと何分待ち
  • ショートステイ:空室あり/満床/相談だけなら可
  • 美容院:本日の空き
  • 病院:診療中かどうか、いまの混み具合
  • 駐車場:空車/満車
  • 漁業:今日の漁があったか、何が入ったか
  • 農産物直売所:本日の入荷
  • 小売店:在庫あり/売切れ

並べてみて気づいたのは、どれも調べても出てこない情報だということです。いまその場にいる人しか知らない。だから利用者は、その場にいる人に聞くしかない。

ホームページは「変わらないこと」には強い

住所、電話番号、営業時間、メニュー、サービス内容。こういう情報は、一度書けば当分変わりません。ホームページも検索も地図アプリも、こうした固定情報を届けるのはとても得意です。

一方で「いまどうなっているか」には、あまり強くありません。営業時間に「11時から19時」と書いてあっても、今日開いているかは分かりません。定休日でなくても閉まっていることはあるし、売り切れて早じまいすることもある。材料が足りずに開けなかった日もあるかもしれません。

検索して出てくるのは、たいていその店のいつもの姿です。今の姿ではない。

固定情報の時代から、状態情報の時代へ

大げさな言い方かもしれませんが、いま考えていることをそのまま書くと、こうなります。

「どこにあるか」「何をしているか」は、もうだいたい調べればわかります。そこはある程度満たされてしまった。残っているのは「いま、どうなっているか」のほうで、こちらはほとんど手つかずに見えます。

もっとも、これは私がいま見ている範囲での話です。業種によっては、とっくに解決しているところもあるはずです。

課題の見つけ方:人が電話して確認していることを探す

この考え方が使えそうだと思ったのは、課題を見つける手がかりになるところです。

やることは単純で、人がわざわざ電話して確認していることを探す。それだけです。

  • 今日やっていますか?
  • 空いていますか?
  • 在庫はありますか?
  • 今から受け入れできますか?
  • 何時なら大丈夫ですか?

こういう電話が繰り返しかかってくる場所には、たぶん「状態が見えていない」という課題があります。

電話のいいところは、証拠として残ることです。アンケートを取らなくても、想像しなくてもいい。同じ質問が何度もかかってくるなら、それは情報が届いていないという事実そのものです。

しかも電話は、両方の手を止めます。かける側は電話をかけるまで動けないし、受ける側は作業を中断して出ることになる。一番忙しい時間帯に、一番多くかかってくるのもたちが悪いところです。

結局、予約システムの話ではなかった

最初は予約システムを作る話だと思っていました。ここまで書いてきて、そうではなかったと思うようになりました。

これは「確認という無駄」をなくす話でした。

予約はその先にあるもので、確認の手間が消えて初めて必要になる機能かもしれません。順番を間違えると、誰も辿り着かない場所に立派なものを建ててしまう。

次に試すこと

いまのところ、これは机の上で考えただけの仮説です。実際にやってみないと、本当かどうかは分かりません。次はこのあたりを確かめてみようと思っています。

  • 状態がひとつ見えるだけの、ごく単純な仕組みを作って実際に置いてもらう
  • 置いたあと、確認の電話が本当に減るのかを数えてみる
  • 「更新する手間」がどこまでなら続くのかを見る。ここが一番あやしいと思っています

最後にひとつだけ。もしあなたの周りで、同じ質問の電話が何度もかかってくる場所があるなら、そこにも同じ課題があるかもしれません。それが何の電話なのか、よかったら教えてください。

この記事が扱っている問題

問題名を辿ると、同じ問題について考えた記事が時系列で並びます。

考えたことがあれば