Roosta について

この目覚ましが存在する理由

Roosta は、具体的で地味な問題から始まりました。あとで思い出せるほど目が覚めていない人が、アラームを止めてしまう。この事実を真剣に受け取ったところから、製品のすべてが導かれています。

短く言うと

Roosta は iOS and Android 向けのミッション型アラームで、小さな独立したチームが作っています。広告ではなく、使う人が支払うお金で成り立っており、アカウントの仕組みも自前のサーバーもありません。そして、マーケティングで語られるのではなくコードで守られる 5 つのルールを軸にしています。

問題

起床についての助言の多くは、問題は意志の力だと前提しています。たいていはそうではありません。目覚めてからの数分間、脳は行動できる程度には起きていますが、考えたり記憶を残したりできるほどには起きていません。この窓の中では、人は手を伸ばしてアラームを止め、そのことを何ひとつ覚えないまま眠りに戻ることができます。

一度のタップは、この窓に余裕で収まります。設計上の欠陥はそれだけです。音量の問題ではありません。だからこそ、より大きな音の目覚ましを買っても、稼げるのはせいぜい数週間です。人は大きな音にも、小さな音と同じように慣れます。

解決策は、半分眠った脳にはできないことを要求することです。計算、20 歩、物を見つけてカメラを向けること。考え方としてはそれだけで、同じ発想のアプリは以前からいくつもあります。私たちが用意している 17 のミッションも、そのひとつの実装にすぎません。違うのはその周りに何を作るかであり、それは起床までの流れの説明にまとめてあります。

その周りに作っているもの

アラームはインフラです。仕事はひとつ。その仕事を、あなたが意識を失っていて監督できない間にやり遂げる。そして一度の失敗が信頼を永久に壊します。この捉え方から、エンジニアリング指針の冒頭に置かれ、好みではなく譲れないものとして扱われる 5 つのルールが生まれました。

1
アラームの信頼性を JavaScript の背後に置かない
スケジュール、音、起床時の表示は OS が持つ。アプリとシステムの状態が食い違ったときは、システムが勝つ。製品の他のことはすべて交渉可能だが、これは違う。
2
鳴動経路のどこにも通信を必要とするものを置かない
クラウド推論も、リモート設定の取得も、認証の更新もしない。電波のない人でも起きられなければならない。この制約こそが、カメラミッションを端末上で動かしている理由であり、広告がない理由でもある。
3
ユーザーを恒久的に閉じ込めない
すべてのミッションに制限時間と脱出口がある。「このアプリのせいで飛行機に乗り遅れた」は問い合わせであり、星ひとつのレビューだ。摩擦は目的だが、閉じ込めは目的ではない。
4
カメラのフレームは決して保存も送信もしない
推論はすべて端末上で行う。これは実装の詳細ではなくプライバシーの約束であり、しかも検証できる。通信を切ってもミッションが動き続けるからだ。
5
マスコットはユーザーを責めない
成功すれば喜び、スヌーズには肩をすくめる。Roosta はあなたのことを残念がるのであって、あなたに失望するのではない。仕組み自体がすでに手強いのだから、ニワトリはその釣り合いを取る側にいる。

私たちが間違えたこと

アラームのスケジューラは一度ならず書き直しています。最初の版はスケジュールをアプリの中に持っていました。テストでは完璧に動き、そして Android のトラブルシューティング記事が今まさに警告しているとおりの壊れ方をしました。省電力機能がプロセスを止め、アラームは鳴りませんでした。信頼性のルールがあの書き方になっているのも、それが一番目に置かれているのも、この失敗が理由です。

マスコットも作り直しました。以前の方向性は、習慣アプリがおなじみにしてしまった「罪悪感」の調子に寄っていました。それは、まさに肝心な瞬間に不快だと分かりました。今まさに起きられなかった人に必要なのは、自分に失望しているキャラクターではありません。口調についてのルールは、そのために存在しています。