無料と有料を混ぜない — 二層に分けた設計判断
なぜ地域コミュニティを無料の運営アプリ(ClubHouse)と有料のマーケットプレイス(ClubLink)に分けたのか。マネタイズと利用者層のバランスをどう取ったかの設計判断を書きます。
地域コミュニティのプロダクトを、私たちは無料の運営アプリと有料のマーケットプレイスに、あえて二つに割りました。
なぜ混ぜなかったのか。理由は一つです。
「お金が絡む瞬間」を、無料の入口から切り離したかったから。ひとつに混ぜたほうが実装は楽なのに、そうしなかった――その設計判断の話をします。
私たちは社長1名とAI COO だけの、小さな会社です。
地域のクラブやチームを支える仕組みを、二つ開発しています。ひとつはクラブ運営そのものを助ける ClubHouse。もうひとつは応援者とクラブをつなぐマーケットプレイスの ClubLink です。
この二つを最初から別プロダクトにしたのは、機能の都合ではありません。「お金が動く場所をどこに置くか」――それだけを軸に、境界を引きました。
🧩最初に迷ったのは「一つにまとめるか」でした
一つに混ぜれば実装は楽。でも無料の軽さと有料の重さは、同居させると必ずどちらかが犠牲になる。
開発を始めた頃、正直に言えば一つのアプリに全部入れたい誘惑がありました。
運営機能があって、その中に投げ銭やスポンサー募集の有料機能も乗っている。ユーザーはアプリを一つ入れれば済むし、こちらも認証やデータ基盤を一本化できる。素朴に考えれば、混ぜたほうが得に見えました。
でも、手を動かすほど気づきました。無料で広く使ってほしいものと、お金を扱うものとでは、求められる「重さ」がまるで違う。
運営アプリは、日々の連絡や出欠管理のように軽くて摩擦がないことが命です。一方でお金が動く機能は、規約も本人確認も決済の責任も重い。
この二つを同じ画面に同居させると――軽いはずの運営機能まで「なんだか重そうなアプリ」に見えてしまうのです。
🚪無料の運営基盤は、間口をとにかく広くしたかった
ClubHouse は誰でも無料で使える運営基盤。お金の匂いを消して、入口の心理的ハードルを下げた。
ClubHouse は、地域のあらゆるクラブのための運営基盤にしたいと考えました。スポーツに限らず、文化系のサークルや子ども会のような集まりまで。誰でも無料で使える場所です。
ここに料金の話や「応援して稼ぐ」という空気を持ち込むと、ただ連絡を回したいだけの人が身構えてしまう。
地域コミュニティの担い手は、多くがボランティアに近い立場の人たちです。その人たちにとって、最初の一歩で「お金の匂い」がすることは、想像以上の心理的ハードルになります。
だから運営アプリは、徹底して無料・汎用に振り切りました。マネタイズの気配を消す。広く薄く入ってもらう入口を、まず確保したかったのです。
🎯収益はスポーツに専化した応援マーケットで取る
収益はもう一つの ClubLink で取る。対象をスポーツの応援に絞り、支払う理由のある濃い場所へ寄せた。
では、収益はどこで取るのか。
それが ClubLink です。こちらは対象をスポーツクラブと、その応援者に絞り込みました。
応援というお金が動きやすい文脈があり、スポンサーや支援者という「支払う理由のある人」がいる領域だからです。
あえて対象を狭めたのは、収益機能は「広さ」より「濃さ」で成り立つと考えたから。
誰でも使える運営基盤とは逆に、応援マーケットは熱量の高い場所に絞ったほうが、支払う側にも受け取る側にも意味が通る。無料側で広く母集団を作り、有料側で濃い部分から収益を取る。役割をはっきり分けたわけです。
🪜二層ファネルという設計判断
無料で広く入口を開け、次の課題を持ったクラブが有料へ進む。段階を分けたのが、この設計の肝です。
この構造を、社内では二層ファネルと呼んでいます。
無料の運営アプリで広く入口を開ける。そこで日々の運営に馴染んでもらったクラブのうち、応援やスポンサーという次の課題を持ったところが、有料のマーケットへ進む。
無理に一つのアプリで両方をこなさせない。段階を分けたのが、この設計の肝です。
分けたことで、実装上の割り切りもしやすくなりました。運営アプリは決済や本人確認の重い仕組みを持たなくてよく、身軽に機能を足せる。逆にマーケット側は、最初から金銭を扱う前提で規約や責任の設計に集中できる。
関心事が混ざらないので、それぞれのアプリのあるべき姿がぶれにくいのです。
私たちは、こうした「なぜそう分けたか」をADR（設計判断の記録）として必ず書き残しています。COO実務の多くをAIが担う一人会社では、判断の理由を言葉にして残さないと、AIも数週間後の自分も、平気で別の前提で動き出すからです。設計の意図を会話のように書き残していく考え方は、Martin Fowler の論考にも通じると感じています。
⚖️分けたことの代償と、それでも分けた理由
分割は認証連携も説明も増えるコスト。それでも無料の軽さと有料の重さは、同じ器に入れないと決めた。
もちろん、分割にはコストがあります。
アプリが二つあれば、認証やデータの連携を自前で設計しなければならない。ユーザーに二つのアプリの関係を説明する手間も増えます。開発リソースの限られた小さな会社にとって、これは軽い負担ではありません。
それでも分けたのは――無料の摩擦のなさと、有料の責任の重さは、同じ器に入れると必ずどちらかが犠牲になると判断したからです。
混ぜて中途半端になるより、それぞれが自分の役割に集中できる形を選びました。今のところこの割り切りは、開発の判断を速くしてくれていると感じています。
📝まとめ — お金の置き場所で境界を引く
境界を引いた基準は、機能でも技術でもない。「お金が絡む瞬間をどこに置くか」だけでした。
もし同じように「無料で広げたいもの」と「お金を取るもの」を一つのプロダクトに抱えているなら、一度、分けて考えてみてほしいのです。境界は機能でも技術でもなく、お金が動く瞬間で引く。
無料で広く入ってもらう入口と、収益を取る濃い場所を分離する。
この二層の設計は、まだ運用の途中で、答え合わせの最中です。それでも、一人会社が迷わず手を動かすための確かな軸になっています。
あなたのプロダクトで「お金が絡む瞬間」は、どこに置きますか。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する