ハコヅミを作る #44：フリーと有料の違いを、どこに置くかを決める
前回（#43）の最後に、GitHub Actions の障害でデプロイが止まりました。待っているあいだに、コードを書かない相談を進めています。
今回は、その1つ目です。
- フリーと有料の違いを、どう考えるか（#184）
- フリーの上限の数を、決め直す
- ベータ版のあいだは、どうするか
仮の数のままだった
登録数の上限は、#29 で作りました。そのときの目的は、1人が大量に登録して、データベースや画像の置き場を使い切るのを防ぐことです。数は「仮」として、ギア 300・消耗品 100・画像 300 などと入れていました。
ベータ版では、テスタがこの上限の中で使います。仮のままでは、何を確かめているのか分かりません。始める前に、考え方から決め直すことにしました。
2つの考え方
最初に頭にあったのは、次の2つです。
- 試せる程度の上限にする。使い勝手が分かるくらいは登録できる。ちゃんと使うと決めた人に、有料会員になってもらう
- ふつうに使う分には、フリーで足りる上限にする。道具が多い人、キャンプの回数が多い人が、有料会員になる
どちらがよいか、Claude Code に意見を聞きました。
1つ目が、合わない理由
返ってきた答えは、2つ目に近いものでした。1つ目が合わない理由は、こうです。
ハコヅミの価値は、持ち物を全部入れて、はじめて出ます。
ギアを 30 個までしか入れられないと、残りは頭で覚えることになります。半分だけのチェックリストは、信じてよいか分かりません。ないより悪い、とも言えます。
つまり、上限を低くすると、「使い勝手が分かる」前に、「これでは忘れ物がなくならない」と分かってしまいます。お金を払う前に、いちばんの売りを体験できません。
自分のデータを見ると、ギアは 56 件です。ファミリーなら、100 件を超える人もふつうにいるはずです。
費用の面でも、絞る理由がありませんでした。ギアやプランの行は、いくら増えても、ほとんど費用がかかりません。費用に効くのは、画像だけです。
2つ目にも、弱点がある
では、2つ目でよいかというと、こちらにも弱点がありました。数の上限だけだと、ほとんど誰も当たらないのです。
- キャンプ 100 回は、月に1回行く人でも、8 年かかる
- ギア 300 件に届く人は、かなり少ない
「たくさん持っている人が、いつか払う」は、起きるとしても何年も先で、人数も少ない。数の上限は、有料にする理由としては弱い、という指摘でした。
言われてみれば、そのとおりです。どちらの案も、「数」で分けようとしていたのが、合っていませんでした。
「積み込み」と「楽しみ」で分ける
落ち着いたのは、数ではなく、ものの種類で分ける考え方です。
| 分け方 | 中身 | フリー |
|---|---|---|
| 積み込みに要るもの | ギア、消耗品、コンテナ、プラン、持ち物チェックそのもの | ふつうの人が困らない数。絞らない |
| 楽しみ・記録のもの | 画像、料理 | 一通り試せる数 |
| これから作る機能 | 共有、コミュニティ | 差を置く（具体的には、あとで決める） |
守る線は、1つです。忘れ物をなくす、という中心は、フリーで全部使える。
差を置くのは、「もっと楽しむ」側です。ギアの写真を全部に付けて、カード表示で眺める。料理をたくさん持つ。こういうところは、好きな人ほど欲しくなります。
なかでも、画像を、いちばんの差にすることにしました。増えると費用がかかる、ただ1つのものです。ここに差を付けるのは、筋が通ります。
これから作る共有の機能についても、1つだけ先に決めました。「見ること」は、有料にしない。見る人が減ると、共有そのものが育ちません。差を付けるなら、出す側の上乗せに置きます。
数を決める
考え方が決まると、数はすぐに決まりました。
| 対象 | 今まで（仮） | 決めた数 | 考え方 |
|---|---|---|---|
| ギア | 300 | 300 | ファミリーでも足りる。絞らない |
| 消耗品 | 100 | 200 | 料理の食材が、消耗品として増える |
| コンテナ | 50 | 50 | ふつうは 5〜15 |
| プラン | 20 | 20 | ふつうは 2〜6 |
| キャンプ | 100 | 100 | 何年分も入る。記録が消える心配をさせない |
| 料理 | 30 | 20 | 一通り試せる数 |
| 画像 | 300 | 50 | いちばんの差 |
消耗品の 100 は、#42 で料理を入れたことで、ふつうの人でも当たる数になっていました。料理 20 品に、食材が5つずつあれば、それだけで 100 です。ここは、考え方がどちらでも、直す必要がありました。
画像の 50 は、ギアとキャンプの画像の合計です。確かめたのは、この数え方でした。合計なら、「主なギアと、行ったキャンプの写真には付けられる」くらいの数になります。
アカウントの画面の「使っている数」。この例では、画像だけが上限に近い
上限に達したときの扱いは、今までどおりです。新しい登録だけを止めます。超えている分は消しません。画像の差し替えも、できます。
ベータ版も、この数で
テスタには、上限をゆるめて使ってもらう手もありました。選んだのは、フリーの数のまま使ってもらうほうです。
ベータ版は、数が合っているかを確かめる場でもあります。ゆるめてしまうと、確かめられません。テスタへの案内には、「数の上限は、ちょうどよいかを確かめているところです。足りないと感じたら、教えてください」と入れます。
テスタには、有料のプランを始めた日から1年間は無料、と約束しています（#37）。上限に当たっても、損はさせません。
数は、コードに書いていない
決めた数を入れるのは、すぐでした。上限の数は、コードには書かず、データベースのテーブルに持っています。変えるのは、マイグレーションの SQL が1行です。
UPDATE `plan_limits`
SET `max_supplies` = 200, `max_dishes` = 20, `max_images` = 50
WHERE `plan` = 'free';
アプリのコードは、1行も変えていません。紹介のページや利用規約にも、数は書いていなかったので、直すところはありませんでした。
「数は、あとで変わる」と考えて、#29 で外に出しておいたのが、ここで効きました。
正直なところ
相談の最後に、Claude Code はこう書いていました。
1人で運営する、趣味の強いサービスなので、有料会員の数は、多くは見込めない。「元を取る」より、「続けるための足し」と「応援してくれる人への上乗せ」くらいに置くのが合っている。その前提なら、フリーを広くして、使う人を増やすほうが、長い目で見て得になる。
耳の痛い話ですが、そのとおりだと思います。この前提を、料金を決めるときにも持っておきます。
おわりに
- 「どこまで無料か」を決める前に、「このサービスの価値は、どこで出るか」を考える。全部入れてはじめて役に立つものは、入り口を絞ると価値が見えない
- 数の上限は、有料にする理由としては弱い。ほとんどの人は、何年も届かない
- 差は、費用がかかるところに置くと、説明がつく
- 変わりそうな数は、コードの外に持つ。決め直したときに、SQL が1行で済む
次回は、同じく止まっているあいだに決めた、公開のあとの道のりです。