Case Study / 実践記録

3回しか開催していない事業に、決済基盤を作った
― 解散したヨガ事業の記録

昨年、動きたくても動けない人の意思決定を支援するサービスを立ち上げ、決済も認証もインフラも作りました。実際にヨガを開催できたのは、3回です。うまくいった話ではありません。それでも、同じことをやろうとしている人には、成功談より役に立つと思うので記録しておきます。

山本翔太 Vitality Design LLC 代表 生活者理解の現場〈His Recoveries〉を自ら運営 読了 約10分
結論

PayPay決済・LINE認証・AWS・独自バックエンドまで作り込んだが、実際にヨガを開催できたのは3回だった。顧客は友人が中心で、需要を確かめたことにはならなかった。講師と会場の差分で稼ぐ構造は薄く、手ぶら参加を売りにマットを用意したことでさらに薄くなった。撤退の決め手は数字ではなく「そもそも自分はヨガをやりたかったのか」という問いだった。作る量が、確かめる量を追い越していた。

この記事の要点
  • 決済・認証・インフラを揃えたが、実際の開催は3回。作った量と確かめた量が釣り合っていなかった。
  • 顧客は友人が中心。来てくれたのは事実だが、需要の証明にはならない
  • 「手ぶら参加」を売りにマットを用意したため、差分で稼ぐ構造がさらに薄くなった
  • 台湾とシリコンバレーまで話を聞きに行った。行動量はあったが、聞いたのは作り始めた後だった。
  • Understand → Design → Build という順序は、逆をやって失敗した経験から来ている。

はじめに断っておくと、この記事はうまくいった事例ではありません。事業としては続かず、チームは解散しました。それでも書くのは、失敗の理由が特殊ではなかったからです。順番を間違えただけで、その間違え方は、たぶん多くの人と同じです。

01何を作ったか ― 決済も認証もインフラも

作ろうとしていたのは、動きたくても動けない人の意思決定を支援するサービスでした。体を動かしたほうがいいと分かっている。でも、何を、どこで、誰と始めればいいのかが決められない。その最初の一歩を設計する、という発想です。最初の接点として選んだのがヨガでした。

作ったものを並べます。PayPayでの決済、LINEでの認証、AWS上のインフラ。バックエンドは同期のエンジニアを巻き込んで、かなり凝った作りにしました。当時はいまほどAIが発達していなかったので、フロントエンドは「GitHubとは何か」というところから始めて、npm run dev を覚えながら自分で書きました。

技術的には、たしかに前に進んでいました。決済がつながる。認証が通る。画面が出る。毎日、進んだ実感がありました。いま振り返ると、この実感こそが問題でした。

02実際に開催できたのは、3回だった

ヨガの開催回数は、3回です。決済も認証もインフラも用意した事業の、実績がこれです。

講師はInstagramで探しました。IPキャラクターをフックにした集客が当たり、講師側は集まりました。問題は参加者のほうです。集めた顧客は、友人が中心でした。

友人が来てくれること自体は、ありがたい話です。ただ、事業の検証としては成立していませんでした。友人が来た理由には、サービスへの需要と、自分への好意が混ざっています。この2つは、参加者数を数えても分離できません。分離するには、自分を知らない人が、自分の財布で申し込むかどうかを見る必要がありました。

私たちはそれを確かめないまま、決済の仕組みを作っていました。払う人がいるかを確かめる前に、払う手段を用意していたということです。

03薄利になることは、始める前に計算できた

収益は差分で稼ぐ構造にしていました。講師と会場を手配し、参加費との差額を残す。よくある形です。

ここに「手ぶらで参加できる」というコンセプトを乗せました。動けない人の一歩を軽くするための設計で、考え方としては悪くなかったと思っています。ただ実務としては、ヨガマットをこちら側で用意するということです。原価が増えます。

1回あたりに手元に残る額は、始める前に紙の上で出せました。講師への支払い、会場、マット、決済手数料。参加費を置けば、残る額は決まります。計算しなかったのではありません。作ることに時間を使っていて、計算する順番が後ろに回っていただけです。

薄利だと分かったのは、動かし始めてからでした。順番が逆であれば、コンセプトを変えるか、価格を変えるか、そもそもこの形をやらないかを、開発に入る前に選べたはずです。

04声は聞いていた。ただし、作り始めた後に

誤解のないように書いておくと、外に出なかったわけではありません。むしろ、かなり動いたほうだと思います。

行動量が足りなかったとは思っていません。足りなかったのは順序です。これらはすべて、作り始めた後の行動でした。

作った後に聞くと、質問が「これはどうですか」になります。作る前に聞いていれば、「あなたは何に困っていますか」から始められました。前者では、相手は目の前のものへの感想を返してくれます。後者でしか、作るべきものは決まりません。

もうひとつ、作った後に聞くことには副作用があります。作ったものが、判断を縛ることです。ここまで作ったのだから、という気持ちが、方向転換のたびに重りになります。聞いた話を素直に受け取れなくなる。これは自分では気づきにくい変化でした。

05やめた決め手は、数字ではなかった

撤退の理由を、順番に並べるとこうなります。

やり切れずに解散しました。決め手になったのは、いちばん最後の問いです。

薄利であること自体は、価格や形を変えれば解ける問題です。作り込みが先行したことも、次から順序を変えれば済みます。ですが3つ目は、どちらも当てはまりませんでした。自分が何をやりたいのかを、理解していなかった。

顧客を理解していないまま作ると、要らないものができます。それと同じ構造で、自分を理解していないまま始めると、続けられない事業ができます。私は後者でした。数字が悪かったから畳んだのではなく、悪い数字を前にして、それでも続ける理由が自分の中に見つからなかったのです。

御院で新しい仕組みやメニューを入れる前に、何を確かめておくべきか——現場を見れば具体的に言えます。 診断・取材を受ける

06いま、作る前に確かめていること

失敗の話だけで終わると、読んだ人が明日から何もできません。ここまでの4つのつまずきから、そのまま裏返しただけの確認事項を書いておきます。特別な方法ではなく、当時やらなかったことです。

御院に置き換えるなら、新しいシステムやメニューを入れる前に同じ確認ができます。誰が、自分の財布で、それを選ぶのか。1件あたりに何が残るのか。この2つに答えられないまま導入が決まっている場面を、現場ではよく見ます。

まとめ ― 理解が終わる前に作らない

結論作るほうが、確かめるより手応えがある。だから人は作りたくなる。しかし作ったものは、そのあとの判断を縛る。理解が終わる前に作らない、という順序は、そのためにある。

いま私たちは、Understand(理解する)→ Design(設計する)→ Build(必要なときだけ作る)という順序を仕事の原則にしています。ご相談をいただいたときに、まず作る話をしないのは、このためです。

この順序は、きれいな方法論として思いついたものではありません。逆をやって、事業を一つ畳んだ結果として残ったものです。だから、確かめる前に作りたくなる気持ちも、作ったものに引きずられる感覚も、外から見て言っているわけではありません。

もしいま、何かを作ろうとしていて、まだ確かめていないことがあるなら——それが何かを一緒に洗い出すところからで構いません。

FAQ
なぜプロダクトを先に作ってしまったのですか?
作るほうが、確かめるより手応えがあったからです。決済がつながった、認証が通った、画面が出た——進んでいる実感が毎日あります。一方で需要の検証は、聞いても曖昧な答えしか返ってこず、進んだかどうかが分かりません。手応えのあるほうを選び続けた結果、作る量が確かめる量を追い越しました。
顧客が友人中心だと、なぜ需要の検証にならないのですか?
友人が来てくれた理由には、サービスへの需要と、自分への好意が混ざっているからです。この2つは参加者数を見ても分離できません。分離するには、自分を知らない人が自分の財布で申し込むかどうかを見る必要がありました。私たちはそれを確かめないまま、決済の仕組みを作っていました。
薄利になることは、事前に分からなかったのですか?
分かったはずです。講師と会場を手配して参加費との差分を残す構造なので、1回あたりに残る額は、始める前に紙の上で計算できました。さらに手ぶら参加を売りにマットを用意したため、原価は増えます。計算しなかったのではなく、作ることに時間を使っていて、計算する順番が後ろに回っていました。
この経験は、いまの仕事にどう効いていますか?
理解が終わる前には作らない、という順序を仕事の原則に置いています。Understand(理解する)→ Design(設計する)→ Build(必要なときだけ作る)という進め方は、逆をやって失敗した経験から来ています。ご相談をいただいたときに、まず作る話をしないのはこのためです。

※ 本稿の数字(開催3回、声をかけた7人、VCへの連絡およそ80人)は、当時の記録と記憶にもとづく自社の実数です。第三者による検証は受けていません。サービス名および関係者名は、本人の了解を取っていないため記載していません。

執筆:山本翔太(バイタリティデザイン合同会社 代表)建物の通信・ネットワーク・防犯設備をつくる、職人が動く現場を持つ事業会社に在籍しています。手順が飛ばされる理由や、あとから検証できなくなる工程がどこかを、管理する側ではなく動く側から見てきました。自由診療・美容医療については、自ら複数の施術を受けた当事者でもあります。カウンセリングで何を聞かれ、どこで迷い、何に警戒するかを、患者の側から知っています。男性ウェルネスブランド〈His Recoveries〉を運営。

私たちの失敗は、これで分かります。ただ、御院がいま何を確かめないまま進もうとしているかは、現場を見ないと分かりません。

作る前に、確かめられていますか。

新しい仕組みやメニューを入れる前に、何が確かめられていて、何が確かめられていないか——御院の現状を、継続診断で1枚に整理してお返しします。

伺った内容をもとに、確かめないまま進んでいる箇所がどこかの見立てを1枚にしてお返しします。無償です。売り込みはしません。