https://itunes.apple.com/jp/app/chibadge-shiro-marinzuno-diangabajjide/id687676749?mt=8&uo=4&at=10l16903
昨日リリースした、chibadge shiro - マリーンズの得点がバッジで確認できるアプリ。
本番環境でPUSH通知が来るかどきどきしていましたが、無事に通知が来たのでひと安心です。
（試合は負けてしまいましたが）
あわせて使いたい chibadge kuro - マリーンズの失点がバッジで確認できるアプリ は現在申請中ですが、今週中には審査が終わるのではないかと思っております。
今回はこの chibadge の開発を振り返ってみたいと思います。
ことの発端
千葉ロッテマリーンズ には一球速報機能がついています。
僕は1日になんどもの1球速報ページにアクセスしていましたが、「試合が動いたときに教えてくれたらいいのになぁ」と思ったことがすべてのはじまりです。
協力者あらわる
時を同じくして、社内のイケメン宇宙エンジニアが、
「僕にかかれば、作れないAPIなんて無いですよ。はっはっは。」
とか言っていたので、試しにマリーンズのスコアを返してくれるAPIの作成を依頼してみました。
すると、なんということでしょう。その日のうちにマリーンズの現在の得点がわかるAPIが完成したのです。
プロトタイプ作成
そんなこんなで、速攻でAPIが完成したのでプロトタイプをつくって検証することになりました。
これまで、
とかの書籍から、
クリエイターがつくるものはアプリではなく、ユーザー体験である。
疑似体験が提供できる最速でプロトタイプをつくって検証する。
的な考え方を学んできたので、（主観が混ざってます）
目指すべきユーザー体験と同じような体験ができるプロトタイプを、
最速でつくって検証するということを心がけ、TitaniumをつかってAPIをポーリングしてバッジを表示するアプリをつくりました。
プロトタイプをつくってみてわかったこと
完成したプロトタイプの仕様は、
- 10分にAPIで1回マリーンズの得点を確認
- マリーンズの得点状況をバッジに表示
というとてもシンプルなものでした。
んが。
バッジが届いたらめちゃくちゃテンションがあがりました！
（僕がマリーンズファンだからかもしれませんが）
体験的には申し分ないと確信しました。
しかし同時に、
- 失点がわからないと勝っているかわからない
- バックグラウンドに回すと10分でとまる
という問題点も浮かび上がってきました。
問題点を解決するために
失点がわからないと勝っているかわからない
当初の僕は得点だけがわかれば充分だと考えていました。
APIをつくったイケメン宇宙エンジニアは失点もわかったほうが良いと主張していましたが、
生粋のマリーンズファンの僕は、バッジにただ大きな数字が表示されているだけで幸せな気分になれるんじゃないかと信じていました。
で、プロトタイプをつかって検証したところ、
バッジに18とか表示されていると、無条件でうきうきすることがわかりました。
バッジに5と表示されていて、うきうきしながら公式サイトを開いたときに5-8とかで敗けていると想像以上にショックということもわかりました。
そんなこんなで、提供できるユーザー体験を再考したときに、失点バージョンもわかったほうが良いということがわかりました。
失点の伝え方も、
- バッジに得失点の差を表示する
- 2-3なら23と表示する
とかいろいろかんがえたのですが、わかりやすくアプリをもう1つつくることとなりました。
なので、失点をつたえるアプリの申請がなかなか通らないこの状況に、非常にそわそわしております。
バックグラウンドに回すと10分でとまる
これはプッシュ通知をつかうことで解決できるということはわかりきっていました。
僕はプッシュの実装がはじめてだったので、プロトタイプのときは実装スピードを考慮してポーリングにしましたが、
プッシュをつかったプロトタイプをつくったところ、そちらのほうが全然良いユーザー体験でした。
まとめ
- つくるべきものは新しいユーザー体験（プロダクトは手段）
- プロトタイプを最速でつくって検証する
の2点を再認識できた良い制作だったと思います。
