ハコヅミを作る #34：公開までの道のりを引き直す（ベータ版、テスタ、お問い合わせの窓口）
前回（#33）までで、使い勝手の改善が一通り済みました。今回は、コードを書かない回です。
一般に公開するまでに、あと何が要るか。それを全部洗い出して、Issue にしました。途中で、公開のしかたそのものも、考え直しています。
公開までに要るもの
#27で、ステップ2 を「一般に公開するための準備」と決めました。ログイン、管理者、上限、アカウントの画面、エクスポート、退会は、もう本番に出ています。残りを、順に Issue にしていきました。
| Issue | 中身 |
|---|---|
| セキュリティの見直し | 外から悪用されうるところを点検して、直す |
| 利用規約・プライバシーポリシー | 何を預かり、どう扱うかを、書いて示す |
| ログインしていない人向けのトップページ | 何ができるサービスかを、伝える |
| 初めての人への案内 | データが空のときに、何から始めるかを出す |
| 公開 | 守りを外して、誰でも使えるようにする |
どれも、「自分1人で使っているうちは、要らなかったもの」です。
セキュリティの見直しで、気づいたこと
Issue の下書きを作るとき、Claude Code は、今のコードを読んで、気になる点を挙げてくれます。今回、いちばん驚いたのは、これでした。
今は、セキュリティのためのヘッダーを1つも付けていません。
ほかのサイトの枠の中に表示させない、読み込めるものを自分のサイトに絞る、といった指定です。今は、Cloudflare Access（ログインした人だけが開ける仕組み）の後ろにあるので、問題になっていません。公開の前には、必ず要ります。
ほかにも、次のような点が挙がりました。
- URL から画像を取り込む機能（#12）：サーバーが、利用者の貼った URL を読みに行く。回数の制限がないので、踏み台にされうる
- 送信の回数の制限：上限（#29）で件数は止まるが、「登録して消す」をくり返すことはできる
- 他人のデータを読めないことの、総点検：どの入口でも、ほかの人の id を指定して読めないことを、もう一度確かめる
作ったときは、それぞれ守りを入れています。ただ、「自分と、招いた人しか使わない」前提での守りです。前提が変わるので、見直します。
お問い合わせの窓口は、自分のサイトのフォームを使う
利用規約とプライバシーポリシーには、連絡先が要ります。ハコヅミの中に、お問い合わせのフォームを作るつもりでいました。
下書きを見ながら、ふと思いました。このブログ（じるラボのサイト）には、もうお問い合わせのフォームがあります。そこに、サービスの選択欄を足して、使えばよいのでは。
Claude Code に相談すると、フォームの作りを確かめたうえで、勧めてくれました。よい点が、思っていたより多くありました。
- 窓口が1つで済む。2つ目のサービスを作っても、選択欄に1つ足すだけ
- ハコヅミに、メールを送る仕組みを作らなくて済む
- 利用を止められた人も、使える。#29で作った「凍結」は、ハコヅミのどの画面も開けなくなります。問い合わせ先がハコヅミの外にあるのは、むしろ都合がよい
- 個人のメールアドレスを、規約に書かなくて済む
気をつける点も、挙げてもらいました。
- フォームは別のサイトなので、誰がログインしているかは分からない。「ログインに使っている Google アカウントのメールアドレスを入れてください」と、案内を出す
- リンクから開いたときに、ハコヅミが選ばれた状態にする。メールアドレスなどは、URL には付けない
- フォームで預かる情報は、じるラボのサイトのプライバシーポリシーの範囲になる。ハコヅミのポリシーから、そちらへリンクする
「サービスの中に、全部そろえる」と考えがちですが、サービスの外に置いたほうがよいものもあります。
公開は、10 人のベータ版から
公開の Issue を作ったあとで、前に考えていた案を思い出しました。最初は 10 人ほどのテスタに使ってもらい、直してから、一般に公開する、という案です。
実は、#27のとき、「招待した人だけのベータは、挟まない」と決めていました。当時の理由は、Cloudflare Access で招待しても、利用者ごとにデータを分けられないことでした。今は、ログインの仕組みがあります。理由が、なくなっています。
Claude Code の答えは、「やる価値がある。しかも、ほとんど手間を足さずにできる」でした。
1人では、確かめられないところがある
勧める理由の1つ目が、これです。
「初めての人が、何から始めればよいか分かるか」は、自分では確かめられません。自分は、もう使い方を知っています。紹介の文が伝わるかどうかも、同じです。10 人に触ってもらえば、つまずく場所がはっきりします。
Google の「テスト中」を、そのまま招待制に使う
今の本番は、2つの関門で守られています。
- Cloudflare Access：自分と、招いた人しか、URL を開けない
- Google のログイン：設定が「テスト中」で、登録したメールアドレスの人しか、ログインできない
ベータでは、1だけを外します。2 の「テスト中」が、そのまま招待制の関門になります。
| 今 | ベータ | 一般公開 | |
|---|---|---|---|
| Cloudflare Access | あり | 外す | 外したまま |
| Google のログイン | テスト中 | テスト中のまま | 本番にする |
アプリの中に、招待の仕組みを作る必要がありません。公開の Issue を、「ベータを始める」と「一般に公開する」の2つに分けました。
テスタを募る順番
もう1つ、相談して気づいたことがあります。テスタに声をかけるとき、「どんなサービスか」を見せる必要があります。紹介のトップページを、そのまま見せればよい、と考えていました。
ところが、紹介のページは、Access を外すまで、ほかの人には見えません。順番が逆でした。
- Access を外す（紹介のページは誰でも開ける。ログインは、まだ自分しかできない）
- 紹介のページを見せて、テスタを募る
- 応募してきた人を、登録する
紹介のページには、画面の絵を入れること、「今はベータ版で、テスタを募っています」と書くことも、決めました。作り手の話（なぜ作ったか）は、紹介のページには書かず、このブログに書きます。
テスタの人数と、お礼
人数は、10 人ほどを目安にしました。ただし、声をかけるのは 15 人ほどです。応募しても、ギアを登録して、プランを作って、キャンプに行く、までたどり着かない人が、半分くらいは出る見込みだからです。
人数より、顔ぶれが大事だ、という話もありました。ソロの人とファミリーの人、iPhone の人と Android の人、今は別の道具でリストを作っている人。そして、冬もキャンプに行く人。持ち物チェックは、実際にキャンプに行かないと試せません。
お礼は、次の2つにしました。
- 有料プランを始めるとき、テスタは1年間無料にする
- 意見を、優先して取り入れる
ギフト券などは、渡しません。お礼を目当てに、キャンプをしない人が応募するのを、避けるためです。「有料プランが無料」は、使い続けたい人にとってだけ、価値があります。
約束のしかたにも、気をつけます。
- 「ずっと無料」とは、約束しない。長く続けるサービスなので、あとで重荷になる。期間を、はっきり書く
- 有料プランを始めない場合もある。「始めるときは」という約束にする
- 誰に約束したかを、控えておく
引き直した道のり
公開までの順番は、こうなりました。
- セキュリティの見直し
- 利用規約・プライバシーポリシー（お問い合わせは、じるラボのサイトのフォームへ）
- ログインしていない人向けのトップページ（テスタ募集の紹介にもなる）
- 初めての人への案内
- ベータ版を始める（Access を外して、テスタを募る）
- ベータで届いた意見を直す
- 一般に公開する
相手が 10 人でも、人のデータを預かります。1 と 2 は、ベータの前に済ませます。3 と 4 は、まさに試してもらいたいものなので、これも先です。
おわりに
- 「自分しか使わない」前提で作った守りは、公開の前に見直す
- サービスの外に置いたほうがよいものもある。お問い合わせの窓口は、その1つだった
- 一度「やらない」と決めたことも、理由がなくなれば、やってよい
- 招待制は、今ある仕組み（Google の「テスト中」）で足りないかを、先に考える
- 1人では確かめられないことは、人に頼む。初めての人の目は、自分にはもう無い
- お礼は、「使い続けたい人」にだけ価値があるものにする
次回からは、公開に向けた実装に戻ります。まずは、セキュリティの見直しです。