去年、家に分別用のゴミ箱を4つ買って並べました。プラスチック、缶、びん、紙です。並べた日は、家が片付いた気がしました。
ところが、住んでいる地域では、プラスチックの回収は月に2回しかありません。出す場所も、家の前ではなく150メートル先の集積所でした。分けた袋はゴミ箱から溢れて廊下に置かれ、次の回収日まで積み上がります。半年たって、廊下にはプラスチックゴミの袋が並んでいました。
いま思えば、僕が整えたのは分ける入口だけでした。家から出ていく出口——回収日と集積所——を確かめないまま、入口だけを4つに増やしていたわけです。
新規事業の立ち上げでも、同じことが起きます。やることの中身は、どの手順書を読んでもだいたい同じです。違いが出るのは、どこから手をつけるかという順番です。
先に結論だけ書きます。AI時代に新規事業を立ち上げるときは、ユーザが触る入口ではなく、受けた注文が現場の作業になる出口から作ります。AI時代以前は出口を配備するための開発期間が長く、失う時間が大きすぎたため、ニーズがあるかないかをクイックに検証し、筋が良い入り口に合わせて出口を作るやり方が主流でした。しかしAI時代には、この出口が整備されたシステムの開発期間が極端に短くなります。そのため、AI時代に合わせた新規事業の開発方法を模索する必要が生じています。出口が1本通っていれば、入口はあとから何本でも足すことができ、検証からシームレスにそのまま事業拡大する時代だからからです。
ここでいう入口はユーザが使い始める画面、出口は受け付けた内容を現場の作業に反映する仕組みです。
僕は、旧来の常識通りユーザがいちばん先に触る予約の画面から作り、そこで受けた予約の一部が店の台帳に届いていないことに、検証開始から3日目に気づきました。今日は、その3日間に何が起きていたかを通じて、どこから作り始めるかという話をしていこうと思います。前置きはさておき、本題に入ります。
この話に出てくる事業
大企業と僕の会社の共創事業（両社が共同で作る事業）で、僕の会社が開発を担当したMVP（実用に必要な最低限の機能を備えた試作品）のひとつに、施術者を指名できる整体院の予約アプリがあります。施術1回の枠は90分。PoC（本格展開の前に小さく試す検証）に参画する店舗は5つで、腰痛と肩こりを、担当の施術者が最初から最後まで1人で見る形の店です。
指名があるので、予約は日時だけでは決まりません。誰の、どの90分かまで決まって、はじめて予約になります。店側は、施術者ごとに90分の枠が縦に並んだ台帳（予約管理表）を見ながら動いています。
もともと5店舗は、店のサイトに置いた入力フォーム（画面の項目を埋めて送信する方式）で予約を受けていました。今回のアプリは、そこに新しい入口を足すものです。どちらの入口から入っても、その予約が店の台帳に記録されて、はじめて現場の仕事になります。
① 教科書どおりに、ユーザが触る予約画面から作った
どこから作るかは、素直に教科書どおりに決めました。立ち上げの手順書に載っている順番は、だいたい共通しています。ユーザが触るところから作ること、反応が早く返るところから作ること、動いたものを見せられる形にすること。この3つで絞ると、先に作るのは予約の画面しか残りませんでした。5店舗の店長に聞いても同じで、「まず予約の画面ですよね」と即答されています。
作ったのは、ユーザがアプリに向かって音声やテキストで「土曜の午前に、○○さんで」と話しかけるだけで予約が取れる画面です。フォームの項目を順に埋めなくても、話した中身から必要なものをアプリが聞き取って、予約の処理が進みます。
画面の流れは、症状を選ぶ、施術者を選ぶ、日時を選ぶ、内容を確かめる、の4段です。整体、骨盤矯正、産後ケア、スポーツ向けの4メニューにこの4段を掛けた全予約導線を2時間で作っています。プログラムの行数は1,547行。そのうち、話しかけた内容を予約の処理へ差し込む繋ぎの部分（予約画面と予約処理をつなぐプログラム）は、107行でした。作り込んだのはユーザに見せる画面のほうで、画面と処理の繋ぎはおまけ程度の分量です。
リリース前の通し試験は、音声と従来のWEBフォームの両方の経路でやっています。店長にも触ってもらい、自分の店でよく受ける指名と時間帯の組み合わせを、お客さん役を演じながら3件試してもらいました。3件とも予約の確認画面まで進み、台帳にも枠が記録されました。この時点で、間違った感覚はまったくありませんでした。
② 予約は入っているのに、施術者の90分が埋まらない
PoCの開始後は、アプリ経由の予約件数と、台帳に記録された枠の数を、毎日突き合わせることにしていました。開始から2日間は、両者の差は数件で、入力のタイミングのずれとして説明がつく範囲でした。
3日目に、数字が合わなくなりました。アプリ側の予約は入っているのに、施術者ごとの90分の枠だけ埋まっていません。予約が台帳に立たない条件を特定した結果、話しかけて予約したときの、整体メニューだけが台帳に記録されませんでした。同じ音声の予約でも骨盤矯正は記録されます。フォームからの予約は、メニューを問わず記録されます。
ユーザの画面には、どの経路でも「ご予約を承りました」と出ます。日時も、指名した施術者の名前も出ます。ユーザの側からは、成立しているようにしか見えません。一方、店の側からは、その予約は最初から存在しません。当日、指名された施術者は空き時間のつもりで別の予約を入れ、そこに予約を取ったはずのユーザが来ます。ぶつかるのは当日で、その場では店頭の手違いとして片付いてしまう。だから、不具合が出た瞬間に不具合として報告される道がありません。
③ 気づいたのは、数字の不一致と、店長が持ってきた1件のメールでした
数字の不一致だけなら、まだ「入力遅れが溜まっているのでは」という読み方も残っていました。決め手になったのは、同じ日に店長が持ってきた1件の苦情メールです。ユーザから「予約完了のメールは届いているのに、店に着いたら予約が入っていないと言われた」という内容で、指名した施術者の名前と、90分の開始時刻まで書かれていました。
そこで、予約が入ってくる入口を1本ずつ、台帳まで指でたどる棚卸し（入口と行き先を一つずつ洗い出す点検）をしました。当時、予約の入口は5本です。アプリのテキスト入力、アプリの音声入力、店舗サイトのフォーム、店舗での出張施術の依頼、予約プラットフォーム経由。
台帳に届いていなかったのは、5本のうち音声入力の1本、それも整体メニューの分岐だけでした。そこから入った予約は、台帳ではなく、開発初期に仮置きしていたスタッフ向けカレンダーに書き込まれていました。店の誰も開かない場所です。開いてみると、3日分の整体の予約が3件、そこに溜まっていました。
④ 原因を1つに絞る
思い当たることは、いくつもあります。試験のメニューの組み合わせが偏っていたこと、店長に触ってもらった3件がたまたま整体以外だったこと。ただ、それらは全部、最後の1つの結果です。原因を絞ると、ユーザが触る入口から作り始めたことでした。
順番を数字で並べると、はっきりします。予約の導線を作ったのが最初の日。受けた予約を施術者ごとの90分の枠として台帳に記録する出口を作ったのは、その20日後です。出口ができた時点で、先に作ってあった入口の分岐を新しい出口へ繋ぎ変えたのですが、音声×整体の1分岐だけが、仮置きのカレンダーを向いたまま残りました。
入口が先にあると、出口ができるまでの間、入口は仮の行き先を持ちます。仮の行き先は、あとで必ず繋ぎ替えることになります。繋ぎ替えの数は、入口の数×メニューの数だけ増えていきます。今回はそのうちの1本を落としました。出口から先に作っていれば、仮の行き先も、繋ぎ替えの作業自体も、最初から存在しません。
⑤ 直したのは1箇所だけ
やったことは、入口ごとの専用処理をやめて、予約の通り道を1本にすることだけです。話しかけて予約する経路から専用の処理を外し、話しかけた結果が、フォームと同じ既存の予約処理に流れ込むようにしました。
このとき、予約の入口をひととおり点検しています。アプリの中には残っているのに、ユーザには二度と表示されない画面が3枚見つかりました。最初の日に作った予約導線の一部です。まとめて撤去しました。その日にやったのは、専用処理を消して、1本化のための処理を足すこと。直すというより、作ったものを捨てる作業でした。
⑥ あとで知った ── 最後に回した作業に、名前がついていました
しばらくして、製品づくりの助言をしている Silicon Valley Product Group の Marty Cagan の文章を読み、手が止まりました。新しいプロダクト（製品やサービス）の作り方を、長く書いている人です。作るに値する解決策を見つける段階で、先に潰すべきリスクを4つに分けています。
1つ目は「whether customers will buy it or users will choose to use it」。ユーザが買うか、使ってくれるか。2つ目は使いこなせるか、3つ目は作れるか。そして4つ目が「whether this solution also works for the various aspects of our business」。その解が、事業のほかの面でも成り立つか、というリスクです。
指名された施術者の90分が台帳に立つかどうかは、まさに4つ目です。ユーザが買うかどうかは、5店舗分の過去の実績で分かっていました。分かっていなかったのは、受けた予約が現場の1枠として成立するかのほうです。
同じ文章には「The business value (viability) risks can be substantial」とあり、続けて、それらは「too often under-appreciated and under-estimated (or simply avoided)」だと書かれています。過小評価されるか、単に避けられる、と名指しされていました。書かれたのは2017年です。2023年に整理し直された文章では「Assessing the product risks is the first thing we do」と、順番まで明示されています。僕がやったのは、4つ目のリスクの優先順位を最後に回すことでした。
⑦ 変えてみて、何が良くなって、何を失ったか
通り道を1本にしてから、変わったことがあります。話しかけて取った予約が、メニューを問わず施術者ごとの90分の枠として台帳に記録されるようになりました。毎日の突き合わせも、経路別に数える必要がなくなり、アプリの予約数と台帳の枠数という2つの数字を見るだけになっています。数字が合っているかを誰でも確かめられる状態になったことが、いちばん大きい変化でした。
ただ、代償があります。3件書いておきます。
1件目。話しかけるだけでは完結しなくなりました。既存の予約処理の形式に合わせたので、予約が終わるまでにユーザが画面を触る回数が3回ぶん増えています。
2件目。アプリをアップデートしていないユーザの端末では、撤去したはずの旧経路がまだ動きます。開発側からユーザの端末の中身は消せません。旧経路から予約が入ったときは店長のメールへ転送し、店舗の担当者が確認して手で台帳に記録する手順を1つ足しました。あわせて、仮置きだったスタッフ向けカレンダーは、月に一度、店舗の担当者が開いて空であることを確かめています。
3件目。専用に作った予約処理を、丸ごと捨てました。1,547行のうち、予約の中身に関わる部分で残ったのは予約画面と予約処理の繋ぎの107行だけです。先に出口から作る順番で始めていれば、払わずに済んだ代償でした。
⑧ 現場で決めるなら、この3つの問い
新規事業を立ち上げるときに、どこから作るかを決める問いは3つです。
1. 受けた注文は、現場の誰かの作業になるまで通っているか。通っているなら、入口を足してかまいません。通っていないなら、入口より先にそこを通します。いちばん効くのはこの問いです。出口が1本通っていれば入口はあとから何本でも足せますが、逆にすると、入口の数だけ届いていない経路が増えます。
2. 入口ごとに、別の通り道を作っていないか。作っていないなら、そのまま進めます。作っているなら、1本に寄せてから次へ進みます。繋ぎ忘れは、通り道の数に比例して増えます。
3. 注文が届かなかったとき、ユーザか現場のどちらかが気づけるか。気づけるなら、任せてかまいません。気づけないなら、数字の突き合わせか、人が定期的に見る手順を残します。今回の予約は、ユーザには成立して見え、店には最初から存在しませんでした。落ちた瞬間には誰も困らないので、放っておけば苦情が来るまで見つかりません。毎日の突き合わせを決めていたことが、3日目の発見につながりました。
入口から出口までを1本の道として見る方法は、扱っているものには依存しません。90分の施術でも、修理の受付でも、部品の手配でも同じです。受けたものが、誰かの作業として立つところまでが1本の道です。
⑨ この順番が効き続ける理由
作るのが速くなるほど、出口から作るか入口から作るかの差は開くと考えています。速くなって増えるのは、入口のほうだからです。話しかける入口、地図アプリから入る入口、外部の予約サイトから入る入口。予約導線を2時間で作れる速度は、そのまま入口を量産する速度になります。
一方で、出口は増えません。施術者の90分は1つで、そこに予約が登録されるかされないかの、どちらかしかありません。入口が10本になっても出口が1本のままなら、繋ぎ忘れの起きる場所は10通りに増えます。しかも、繋がっていない経路の不具合は、受けた時点では誰の目にも見えません。ユーザの画面には「ご予約を承りました」と出るからです。速く作れる時代ほど、出口を先に通し、数字を毎日突き合わせる決まりが効いてきます。
そもそも、教科書が入口から作れと言ってきたことには、理由がありました。出口——受けた予約を台帳の枠として登録する側——は基幹の処理で、作り込むには時間と費用がかかる。ニーズが無かったと分かったとき、いちばん大きな損失が出る場所でした。だから、安く作れる画面で先に確かめろ、という順番には、その時代なりの合理性があります。
その前提が、いま崩れています。基幹の処理の変更に、たいした時間がかからなくなったからです。出口を先に1本通しても、ニーズが無ければ捨てられる大きさで作れます。出口から作るという順番は、正しくなったのではなく、作れるようになったのです。
もうひとつ、検証のあり方も変わりました。開発期間が短くなると、ニーズ検証だけを切り出した活動は、役割の幅を狭めていきます。検証で作ったものを捨てて本番を作り直すのではなく、検証を始めたその仕組みのまま、事業を育てていく。そうなると先に要るのは、日々のグロースで増えていく入口の拡大に耐えるインフラです。出口を先に1本通しておくことは、戦略の変更に応じて入口を足し続けられるシステムの、いちばん効率的な立ち上げ方になっています。
新規事業を立ち上げる順番をどう組むかは、新規事業コンサルとMVP・PoCのページに整理しています。PoCは、本格開発の前に小さく試して実現可能性を確かめる検証です。作りかけの入口が何本あるか数えかねている段階であれば、こちらからご相談ください。
撤去した3枚の画面のうち、1枚だけ手元に残してあります。日時を選ぶ画面で、90分の枠を横に並べて描いていたものです。よくできています。ユーザの予約には一度も使われていませんでした。
ゴミ箱のほうは、いまも4つ並んでいます。回収日をカレンダーに入れたので、廊下の袋は、先週2個だけ減りました。
以上です。
