経緯はシンプルだ。メモパチのAndroid版をGoogle Playに出したい。そのためには12人・14日間のクローズドテストが必要。テスターが集まらない。じゃあ集まる仕組みを作ればいい。
テスター募集の方法は他にもある。Xで呼びかける、個人開発者向けのDiscordサーバーを探す、知人を片っ端から当たる。実際にそれも試した。問題は、集まっても管理が大変になることだ。誰が参加したか、誰が14日間達成したか、リマインドをどうするか——スプレッドシートで管理するのも手だが、それ自体が手間になる。
どうせ自分が必要なら、同じ問題を抱えている人間は他にもいる。仕組みとして作った方が、自分にも他の個人開発者にも使えるものになる。そうして生まれたのが TestersBoard だ。開発にかかった時間は約2週間。Firebase、Google認証、自動メール送信の仕組みをゼロから組んだ。
仕組み
どう動くか。
ポイント
Google Playのテスト要件（12人・14日間・毎日使用）に合わせて設計している。必要人数と期間は自由に設定できるので、要件が変わっても対応できる。セキュリティ
情報は抜かれない。
個人情報（メールアドレス）を扱うサービスなので、そこはちゃんとやった。テスター同士がメールアドレスを共有するような仕組みではないが、サービスが参加者のアドレスを持つことになる。それが漏れたら最悪だ。
認証はGoogleに丸投げする方針にした。自前でパスワードを管理すると、ハッシュ化、ソルト、ストレージの保護と気にする点が増える。その全部を正しく実装できる自信はあっても、やらなくて済むなら絶対にやらない方がいい。Google認証を使えば、パスワード漏洩のリスクはほぼGoogleの責任になる。
「抜かれることはないはず」と言い切れる根拠はここにある。自前でパスワードを持たず、アクセス制御をFirebaseのセキュリティルールに委ねているので、実装ミスでデータが漏れるリスクが最小化されている。
Firebaseのセキュリティルールは、「認証済みのユーザーが自分のデータにだけアクセスできる」という制御をデータベース側で強制する。アプリ側のコードにバグがあっても、ルール側で弾ける。防衛ラインが二重になっているので、片方が崩れても即座に問題にはならない。個人開発でセキュリティ実装に使える時間は限られているが、この設計ならそのコストを最小限に抑えながら、まともな水準を維持できる。
オチ
そして気づいた。
メモパチのAndroid版をリリースするために、テスター募集サービスをゼロから作った。Google Login、スレ管理、自動メール、リマインダー、進捗チェック。全部作った。
結末
よく考えたら、Android端末を持っていなかった。
fin.
テスターを集める前に、自分がテストできない。作ったサービスは本物だし、誰かの役には立つと思う。ただ自分の問題は何も解決していない。
振り返ると、TestersBoard自体の開発は想定より早く終わった。Firebase周りの設計で詰まる場面もあったが、2週間ほどで動くものができた。それ自体は悪くない。問題は、完成してから「そういえばAndroid持ってないな」と気づいたことだ。開発中は完全に頭から抜けていた。
自分が必要だから作る、というのは良い動機だ。ただ、自分が本当に必要かどうかを最後まで確認しないまま作り切ることもある。教訓というほどのものでもないが、次から先に確認する癖はついた。
Android端末は買うかどうかまだ検討中です。もしTestersBoard使ってみたい方、またはメモパチのAndroidテスターになってもいいという方は TestersBoard からどうぞ。