おやすみのシャワーを浴びて寝るために僕らがしてきたこと


クックパッド社主催「第3回開発コンテスト24」にて「おやすみシャワー」をチームで開発し、2度目の特別賞を受賞しました

応募した作品については、以下のビデオをご覧ください:

あなたは一日の終わりを誰と過ごしますか。
ときには見知らぬ誰かと「おやすみ」の言葉を交わすのはどうでしょう。
「おやすみ」はあなたに降り注ぐ、流星のシャワーのように。
素晴らしい一日の終わりを分かちあう、最高のおやすみ体験をお届けします。

そして次は、あなたから。

@darashi から見たその軌跡を記録し、共有します。 もう少し掘り下げた “想い” のようなものは、少し時間を置いてうまく整理ができたらアウトプットしていきたいです。

他のメンバーの記録

他メンバーからの目線で書かれたエントリもあわせてごらんください!

去年のこと、今年のこと

去年のことは、特別賞の受賞が決まった直後に書いたエントリ 「できればいいのに」が現実になる場所: 1/2 Real-time Tab Sync の開発に混ぜてもらいました に(かなりテンションが高い感じで)まとめてあります。

去年のコンテストは「@kei_s がプロダクトの骨格をつくり上げたところに、途中から参加させてもらって、楽しくワイワイ開発した」というのが僕からの景色でした。

今回はそれとはちょっと違っていて、開始時には既に @kei_s@june29 の間で「今年も参加しよう」という合意がされている状態でした。

私たちについて

私たちのチーム Team OyasumiSupport#end_of_day は

の総勢4名でした。

@darashi@kei_s@june29 は 2007年に Ruby札幌 の勉強会で会ってからの仲です。一緒に同じチームでお仕事したり、悪ノリしたり、いくつかのカンファレンスを一緒に運営したり、いくつかの作品を一緒に作ったりする間柄です。当初開発は3人で進めていたのですが、途中から @ZoAmichi が画を作るのに協力してくれるということになり、急遽 join してくれました。素敵アートワークをありがとう!

@darashiは札幌に住んでいて、@kei_sは大森、@june29@ZoAmichiは蒲田に住んでいます。最終的には札幌、大森、蒲田の3拠点4名をPS3のビデオチャットで結んでの開発となりました。

Team OyasumiSupport#end_of_day

左から大森、札幌、蒲田。下の iPad に映っているのは UTC と JST を表示するように 設定された World Clock Pro

何が起こったか

開発がどういう風に進んだのかを共有します。

何をどういう順序で行って、どのくらい時間を使ったかを書いてみます。 もちろん、実際には重なりながら進行しているので、大体の目安だと考えてください。

前夜

@darashi@kei_s がいる facebook グループに @june29 が種になるキーワードを投稿してくれました。抜粋すると・・・

このときポストされていた「伏線」のうちいくつかは回収され、最終的なプロダクトの中に息づいています。

08:00-09:00 起床〜テーマ発表直前

朝起きてから、@kei_s がセットアップしてくれた さくらのVPS(V3)1GB が使えるように準備しました。 テーマに依らず必要になるであろう共同作業用のインフラは準備しておこう、というところです。

公開鍵やドットファイル類を送り、手に馴染んだ道具ということで、 Ruby と node.js を予めビルドしておきました。

09:00-11:00 テーマ発表から手を動かし始めるまで

今回、@june29 は土曜日に仕事があったので、午前9時過ぎに家をでなければいけない状況でした。 そこで、テーマが発表されてすぐ、 Skype の音声チャットをつないで打ち合わせを始めることにしました。

「前回の実績からすると最初の2時間くらいはアイディア出しに使っても大丈夫」という @kei_s の心強いアドバイスがあったので、それなりにだらだらと話し始めました。

札幌、大森、蒲田、雑踏

あっという間に @june29 が出発する時間になったので、iPhone の Skype に切り替えてもらい、そのまま打ち合わせを続けました。 彼の移動する道すがらの音がリアルタイムで流れて、なかなか味わい深い体験でした。 電車に乗っている間も、イヤホンで聞いてもらってチャットに発言する、という感じで進みました。

これが想像以上に新鮮で刺激的でした。雑踏、そして時には隣の人の立ち話まで聞こえて来て、まるで自分が東京で電車に乗っているかのような感覚でした。特に、馴染みのある電車を利用していたときは、懐かしさすら感じるレベルでした。それから、イヤホンをしたままトイレに行った@kei_sが、駅の真ん中で用を足しているかのような背徳感があったと発言していたことをここに記録しておきます。面白いことを言って電車に乗っている @june29 をニヤニヤさせる遊びも楽しかったです。

そんなこんなで、チームの間に「音は楽しい」という共通認識が育ちました。

ネタ帳を少し

で、その中でどういう話をしていたかというと、記録に残っている分をなんとなく箇条書きにすると、

という感じです。アイディア出しをしながら facebook のグループのウォールに適宜スレッドを分けてポストしていきました。

やっぱり「音」は楽しい

そして次第に「音」に興味が移っていく… このへんで 10:00 くらい。

ここで 10:40 くらい。

期限内に形にできそうなものは何か

そろそろ11時なので、「24時間以内に何らかのプロダクトとしてまとめられそう」という観点で見直すことにしました。

このへんが残りました。この中でテンションが上がるのはやはり「音」だったので、プロダクトの詳細な形は置いておいても、まずどうやれば音を録音したり、再生したりできるかを考えることにしました。

プラットフォームの選定

プロダクトとチームのスキルセットを考え、どういう技術を採用するかを検討しました。

スマートフォンかPCか

寝る前に何らかの音を録音するとすると、スマートフォンをターゲットにするのが順当に思えました。タブレットやPCをベッドで使う人はそこまで多くは無さそうです。

PC 用のアプリケーションとしてつくると、機種によってマイクやスピーカーが無いかもしれません。また、メンバーが得意な技術のなかで、PCで手軽に録音/再生できる、というようなものはありませんでした。Flash なら実現できそうでしたが、誰もほとんど経験がありませんでした(たぶん。実際には知らない)。

開発経験と見積もり

経験という意味では、自分はスマートフォンアプリの開発はほとんど経験はありませんでした。

それでも、自分には iPhone ネイティブアプリや、Android ネイティブアプリ、Titanium MobilePhoneGap をつかって Hello World に毛の生えたものくらいは作った経験があったので、なんとなくどれを使うべきかという感覚はあって、

という印象でした。

お互いをよく知っているということ

ちなみに、他のメンバーも、お互いにスマートフォン開発の経験が豊富ではないことを知っていました。それだけではなくて、 @kei_s が JavaScript を得意としていること、 Titanium Mobile の経験があることも知っていました。フロントエンドの得意な @june29 がスマートフォン向けWebサイトの開発経験がある、ということも知っていました。

皆 Web アプリケーションはそれなりに経験がある、ということも知っていました。 一番得意な分野をバックエンド寄りなほうからフロントエンド寄りのほうに並べると、@darashi@kei_s@june29 になると思います。今回のプロジェクトでも、結果的にちょうどそのくらいの部分を中心に担当しました。

このこと——誰が何をどのくらいできて、何ができないかをお互いが包み隠さずよく知っていること——はチームで開発する上でとても大事なことです。この共通認識があって、共通認識があるということを認識しているだけで、話し合うまでもなくタスクが適切な人に届けられることになります。気がついたらその時点で最も適切な人がやっているのです。

相手の腹を探っている暇はないのです。

iPhone w/PhoneGap を選択

僕らは全員が iPhone ユーザであるということも知っていました。 なので、対象プラットフォームは自然に iPhone に決まりました。 (@kei_s@darashi は Android も持っていることも知っていました。ただ、この状況で敢えて Android を選ぶメリットは大きくないだろうとすぐに判断できました)。

フロントエンドを得意とする @june29 が戻ってくるまでの間に、必要な要素技術を JavaScript からすぐに呼び出せるように揃えてさえおければ、その後はなんとかなるだろうという気がしました。PhoneGap はスマートフォン Web 開発の知識の多くがそのまま使えるフレームワークだからです。

そういうわけで、チームとして考えても iPhone アプリケーションを PhoneGap でつくるのが最善手であるように思われました。 逆に、PhoneGap で録音再生がうまく出来ないと、他のフレームワークを選択せざるを得ず、スマートフォンをターゲットにするのは難しくなると思われました。

技術的リスクにそなえて

PhoneGap でうまく音声を録音/再生出来なかった場合に備えて、他の方法で代替できないかというアイディア出しも簡単にしておきました。

@june29 から、ビデオをメールに添付して送ってもらえばスマートフォンでの録音したものを取得できる、というアイディアが出ました。これならば、再生も http で送ればよいので、現時点で自分たちが持っている技術で全て賄えそうです。

もちろんクールではないのだけれど、何もアイディアが無いよりはマシです。

次に進む方向

このへんで @june29 がお仕事へ旅立って行きました。ちょうど 11:00 くらいでしょうか。

この時点で、僕の中で MVP として考えていたのは、誰かの「おやすみ」を聞いたり、自分の「おやすみ」を録音したりできる、というプロダクトです。これだけでも実現出来れば、まずは出せるものにはなるだろう、という感触がありました。

ざっくり調査

調べてみると、 リファレンス にも それらしいAPI が載っていて、 PhoneGap で音声の録音再生をしている記事 なども見つかったので、なんとかなりそうだなあという気持ちになってきました。

ということで、まずは PhoneGap で必要なことが “本当に” “全て” できるのか、向こう3時間くらいをタイムボックスにして技術調査を行うことにしました。

作業しつつ、進む方向を固定してしまう前に、すこしアイディアを揺さぶってみたりもしました。「おやすみ」以外に何があるだろう。「おつかれ」でも楽しいかもしれない。単にリレーするだけでなく、新着n件を重ねて同時に再生するとかでも面白いかも。

11:00-15:00 技術調査, スパイクコード

まずは世界に挨拶を

@kei_s が少しの間離れることになったので、“Hello World” を PhoneGap で動かすところを目的にしてスタートしました。

PhoneGap はかなり前に試していたのですが、すっかり忘れていて、ドキュメントをみながらセットアップしました。エミュレータで “Hello World” 的なものが動き、実機でも動いたところで @kei_s が戻ってきました。

同期

ここから PS3 を使ったビデオチャットができるようになったので、つなぎながら作業の続きにとりかかりました。

まず @kei_s に現状までの進捗を報告し、環境構築やプロジェクトの新規作成でハマったポイント、リファレンスを読んでいてわかったことを共有しました。ほどなくして @kei_s の手元でも同じところまで動くようになりました。

次の目標を iPhone で「録音できること」に置きました。

分岐

最初は二人で調査していたのですが、二人の目が必要な作業ではないと判断して、途中から調査と実装を @kei_s に引き継ぎ、@darashi はバックエンドの作成に移りました。

というのも、iPhone で録音ができたとして、それが本当に録音できているのかを確認するためには、iPhone で実際に再生するか、データを外部に転送する必要があるからです。 iPhone 上で再生して確認する方法だと、もしうまく再生出来なかった場合に、再生が失敗しているのか、録音を失敗しているのかを切り分けるのが困難になりそうだと考えました。

そこで、先に仮実装でもよいからサーバを用意しておき、ネットワークで転送してもらうことにしました(サーバの実装が間に合わなかったら、ローカルファイルの再生に進んでもらおうと考えつつ)。

そのほうが「音が鳴る/ならない」の二択ではなく、「データのここがおかしい」という判断ができる可能性があります。さらに言うと、iPhone からサーバに転送する部分は、いずれ必ず必要になる部分なのです (iPhone 上で音声データを再生する部分も一見必要になりそうですが、このとき想定していたプロダクトであれば、ネットワークから音声データを受信して再生出来れば十分で、iPhone のローカルファイルを再生する必要はないかもしれません)。

バックエンドの仮実装

というわけでバックエンドをつくります。Sinatra でサクっと作りました。ここは慣れているので、時間をかけずにすぐに・・・と言いたいところでしたが、ちょっとハマりつつ、@kei_s がサーバに送る部分を書き上げるくらいのタイミングでちょうどバックエンドの準備もできました。

録音→サーバに送るところまで

早速テスト。まず、クライアントからデータをサーバに送ります。次に、scp でローカルマシンに転送します。きちんと音声が録音されていたことが確認できました。 サーバからデータを取り出す部分はまだ書いていなかったので、とりあえずの確認方法です。

これで勝つる。最悪再生は Web でもできるはずなので、なんとかいけるなーと思いました。ここまででだいたい 15:00 です。

サーバ→再生も

@darashi がサーバ側から音声データを送り出す部分を書いている間に、 @kei_s がサーバからのデータを受信するところを書いてくれました。録音してサーバに送った音声データを、クライアントで再生することができるようになりました。ここまでで 15:30 くらい。

次は、実機で触って遊んでみたいということで、リリースの準備作業をすることにしました。前回はリリース前にバタバタしたので、まず先にいつでもリリース出来る状態をつくろうという意識がありました。

15:30-18:30 コードの整理, デプロイメント, 配布の用意

「最初のリリース」を次の目標にしました。そこに向けて進むために、まずは足場を固めることにしました。

コードの置き場

この時点では、バックエンドは VPS に ssh でログインしたターミナルで vi で編集したり、rackup で起動したりしていました。フロントエンドのコードは Dropbox を使ってやり取りしていました。このままでは後々きつくなってくることが明らかでした。 そこで、 github にリポジトリを二つ作成し、それぞれフロントエンドとバックエンドを置くようにしました。

バックエンドの自動デプロイ

また、@kei_s がフロントエンドのコードを整理している間に、バックエンドを自動デプロイ可能にすることにしました。Passenger をセットアップし、 capistrano でデプロイできるように準備しました (“一昨日やった問題”だったので15分くらいでできました。素振り重要)。

TestFlight での配布の練習

バックエンドは慣れているので良かったのですが、問題はフロントエンドのプロダクションの準備でした。何しろ TestFlight はテスターとして使ったことがあるだけ、というレベルなので、Xcode でのビルドの仕方も含めて調べる必要がありました。

それでも、この作業をこなしておかないとリリース可能な状態にはならないので、必ず今やるべきだという確信がありました。

試行錯誤の末、TestFlight をつかってテスト版を配布できる状態になりました。以降、@darashi はビルド職人(オフショアのビルド担当者!)として、その時間の多くを過ごすことになります。チームの変更を受け取ってビルドし、テスト版を TestFlight にリリースする。このサイクルを何度も回しながら開発を進めていきました(本当はもっと自動化できるとよかった)。

18:30-22:00 プロダクトデザイン, ユーザストーリー

技術的に不安だった部分が全て片付いて一段落したところで、今手元に揃った材料をどうパッケージしていくかを改めて考え始めることにしました。課題「一日の終わりを楽しくするもの」との整合性も改めて確認することにしました。

何ができるとよいのか

ユーザにとって、どういう風に見えるプロダクトであるべきか。またしてもちょっと悪ノリした感じのアイディア出し:

この大きく二つのアイディアがありました。僕は、おやすみリレーのほうがシンプルで、パッケージとしてうまくまとめやすそうだと感じていました。今手元にあるプロダクトからの差分も小さそうだという印象もありました。

このとき手元にあったもの

この時点で僕らの手元にあったのは、「録音する」「送信する」「音声を再生する」のボタンが並んでいるだけのアプリケーションでした。これを順番に操作することで、録音したり、それを聞いたりできます。

逆に言うと、適切な順番に操作しないと、期待されるような体験は得られません。作りかけのボイスレコーダーです。

プロダクトの形として、何通りもの可能性を考えることはできました。しかし、まだこの時点では、どういう順序に何がおこるのか、というストーリーを一本に絞ることができませんでした。一度「おやすみ」を投稿すると、それ以降に来た「おやすみ」が聞けるようにする、というアイディアもありました(ただし「これではいつ寝ればいいのかわからない」「(ユーザ数が十分でないと)実際にはそんなにタイミングよく来ない」という理由で採用されませんでした)。

決断を先送りしたい

この判断はコンテストの中で一番大事な判断になるところだと感じていたので、だいぶ悩みました。 なによりストーリーが大事です。でも、まだ「これでいこう」という決断までは出来ない状態でした。

そうこうしているうちに、 @june29 が仕事を終えて戻ってくる時間が近づいてきました。@june29 はこういうストーリーを組み立てるのがとても上手なので、彼もいるところで一緒に話をしたいという気持ちが強くありました。 それから、手元にあるものを誰かに見せてフィードバックを得たい、という気持ちもかなり強くなってきました。

送信前の確認機能はほしい

煮詰ってしまったので、ひとまず手を動かす作業に戻ることにしました。どう転んでも必要になるであろう、無駄にならないと思われるものを選んで実装することにしました。

プロダクトから録音機能が無くなることはないだろうから、録音をする上での不便を潰すのは無駄にならない作業だろうと考えました。

まず、 @kei_s が録音した音声を送信する前に確認できるようにしてくれました。

同時に再生するとほどよい悪戯っぽさが生まれる

それから、複数のデータを保存できるようにしたほうが良いだろうということで @darashi がバックエンドを変更し、@kei_s がフロントエンドを変更しました。

最初のバージョンは複数の音声が同時に再生されるものでした。順番にではなく同時に再生するようにしたのは、第一には実装の手数が少なかったからです。ただ、実際やってみると、複数の「おやすみー」が同時に再生されるのはかなり面白い体験で、これは何とかなりそう、という気持ちになってきました。

「おやすみを共有するサービス」という括りでみると、レッドオーシャン感があって怖いなあと思ったのでした。なのですが、「複数の人の声が同時に再生される」という、ちょっと悪戯っぽいところが気に入りました。この「ほどよい悪戯っぽさ」は武器になるだろうと感じたので、大事にしたいと思いました。

ここまでで 20:30 くらいです。

無駄にならない改良をもう一つ

いじっていて、録音開始のタイミングと、終了のタイミングがわかりづらいというのが気になりました。これも @kei_s がカウントダウンするようにしてくれて、対応しました。

この間、@darashi はプロダクションビルド、署名と TestFlight への送信の練習などをしていました。

ここまで 21:50 くらいです。

22:00-23:00 状況の同期, チーム拡大

このへんで @june29@ZoAmichi がガローア(蒲田サテライト; @june29邸)に到着しました。 PS3 で3拠点接続を開始します。

状況の同期

まず最初に、何をしてきて、何が今僕らの手元にあるのかを共有しました。

@june29 がフロントエンドをいじる体制ですすめるのが最適だと考えていたので、 とるべき次のアクションは大きく以下の3つだと認識していました:

これらを並行して進めながら、チームが再編成されていきました。

現状のプロダクトで遊んでみたところ、ガローア会場も好感触でした。安心感が増しました。

ガローア会場からの初コミットは 23:11 でした。

コードの引き継ぎ, 教えて kei さん

このへんでフロントエンドのコードが @kei_s から @june29 に引き継がれることになりました。

手が空いた @kei_s は、皆の色々な調べ物を一手に引き受けてくれました。 とても心強く、安心して作業を進められました。 今思うと、他のメンバーと三組のペアプロを同時にこなすナビゲーターのようでした。

加速するため、あるいはペア間の情報共有を有効に行うため、複数のドライバーでナビゲータ共有するようなペアプロのやり方も、状況に依っては有効かもしれません。

23:00-00:30 プロダクト名決定ミーティング

作業を続けるうち、そろそろプロダクト名を確定していたほうがよいという場面が増えてきました。 プロダクト名決定会議が始まります。 ここまでの開発コードネームは Koe でした。

出てきた命名(部品)の一部を紹介すると:

・・・と実際にはこれの数倍はあったのですが、

“おやすみのシャワーを浴びて寝る” というフレーズが出てきました。 交差点よりシャワーのほうがアイコンもやりやすいという @ZoAmichi の声もあり、おやすみシャワーに決定しました。

00:17 ごろの出来事です。

決定したプロジェクト名でリポジトリを作りなおす

命名類を直すのが面倒だったので (Xcode のどこをいじれば十分なのかよくわからなかったし)、 フロントエンドはリポジトリから作りなおしました (00:22)。

00:30-01:00 プロダクト再設計, 応募の準備

応募用のメモを Google Docs で作成開始

プロダクト名も決まったので、応募フォームに書く内容の検討を始めました。01:20 頃です。 Google Docs をメンバーで共有して、書けるところから書いて行きました。

プロダクトの設計 reloaded

「おもしろくて眠れなくなる」のでは本末転倒なので、何度も聞けないようになりました。 録音したあと、一度聞いたらそれで終わりで、そのアプリはもう何もできなくなる。 あとはちゃんと寝てください!という設計です。

それから、いきなり「おやすみを言ってください」と言ってもどうしていいかわからないので、先に例示としての再生が必要、という @kei_s のアイディアもありました。

起動直後に、いきなりおやすみが再生されるとまずい (多くの人はサイレントにしている) ので、 再生ボタンは必要だよね、というのもありました。

結局、最初に直近5人ぶんの「おやすみ」再生され、録音、確認、送信すると、自分を含む「おやすみ」が再生される、という仕様に落ち着きました。

@june29 が画面設計の初案を Keynote で作ってくれました。 画面設計について資料を見ながら話し合い、気になっていることを共有し、実装に着手することになりました。

01:00-03:00 アクションフローの実現, パーツの改善

サーバサイドで音声をミキシングするように

@ZoAmichi が画像をつくり、 @june29 がフローの実装をしている間、@kei_s@darashi で取れそうなフィーチャーを片付けることにしました。

複数の音声を同時に再生する際、iPhone からサーバ上の5つの音声ファイルに対してリクエストが発行されるような作りになっていました。しかし、これがややもたつくので、サーバサイドでストリームを一個にミキシングして渡すことにしました。

クライアントサイドは @kei_s が、サーバサイドは @darashi が担当しました。02:40 頃に完了しました。

エミュレータから送られてくる wav ファイルの形式が実機のそれと違っており (ステレオになっていた)、ややハマりました。

フローができる

03:12 に @june29 から push されてきた変更で、音声の再生、録音、確認、送信、自分の声を含む音声を再生する、という一連の流れがページを順に進んで行くインターフェイスで実現されました。

一箇所、動作に不具合があったので(録音したデータを送信するところが動いてなかった)、@kei_s@june29 でそれを直しつつ、という感じだったと思います。 記憶の残存具合から、この頃から自分の意識がだんだん薄くなってきているのがわかります。

03:00-05:30 ビジュアルデザイン, 全体のブラッシュアップ, 応募関連作業

紹介文

自分の担当範囲は大体落ち着いたので、紹介文の原案を作成することにしました。 だらだらーっと書いて、だいぶ良い感じのポエムができました。

アプリアイコン, スプラッシュ画面

そうこうしているうちに、 @ZoAmichi によるアプリアイコンがリポジトリに push されました。 キラキラっと星がシャワーになっていて、とっても素敵な感じになりました。03:30 頃の出来事です。 続いてスプラッシュ画面の画像が 04:45 頃に push され、フロントエンド側の大枠が固まりました。

(@ZoAmichi が居なかったらアイコンとかどうしていたんだろうと思うとおそろしい… 完全に考えから漏れていました)

TestFlight の invitation をコンテストのアカウントへ送信

そろそろ提出に向けての準備が必要だという状況だったので、TestFlight からコンテストのアカウントに向けて invitation を送信しておきました。 5:14 に Accept してもらいました。ご担当者様、おつかれさまです><

紹介文 2nd

紹介文を皆でみてもらって、最終稿ができました。これで作品を投稿できる状態になりました。

iPhone 3GS で検証

TestFlight でみると、コンテストの検証機に iPhone 3GS も含まれているようだったので、手元の iPhone 3GS を引っ張りだしてきて(充電して)検証しておきました。動作には特に問題がなさそうだったので安心しました。

05:30-06:00 「おかわり」の実装, 小さな改良

この時点でいつでもリリース可能な状態になったのですが、締切りまでに時間がまだあったので、小さめのフィーチャを一つだけ選んで実装することにしました。

おかわり

ここで選ばれたのは「おかわり」と呼ばれるフィーチャです。 自分のおやすみを送信したあとに流れる音声を、もう一度だけ聞くことができるものです。

自分が「おやすみ」を送信すると、直後に皆の「おやすみ」が返ってくるので、何が起きたかわからないユーザがいるかも知れない。あるいは、自分の声が本当に入っていたのかわからなかったユーザがいるかもしれない。それを解決するために「おかわり」が作られました。

@june29 が何度でも聞けるようしないほうがよい、と主張しました。「一回だけだよ」と言われて大事に聞いてほしい、という意図からです。それで、泣きの一回「おかわり」をすると、もうアプリケーションは何も出来なくなるように作られました。

(課金でもう一度聞けるようにしよう、などというジョークもありましたが…)

厳密な実装ではなくてもよいという判断

これは実は厳密な実装にはなっていません。自分が録音した後に5人以上の人が録音すると、おかわりしても自分の声が入らない音声が返ってくるのです。しかし、今回のコンテストを主眼に置くとそれでも十分 work するだろうと判断しました。まずはその状態を体験したい、という気持ちもありました。

この作業のためにリポジトリに用意されたブランチが「おかわりブランチ (okawari branch)」です。@kei_s が(朝食もまだだというのに)おかわりのブランチを作りました。

次のおやすみに備える

この時点では、アプリケーションは「おかわり」を終えて最終状態まで来ると本当に何もできなくなってしまう仕様でした。 最後の画面でアプリがバックグラウンドに回されると、次の日に備えて最初の状態に戻るように @kei_s が改良しました。画面の遷移を作成した @june29 とコミュニケーションをとりながら作業が進められました。

06:00-07:30 リリース

最終のビルド

コンテスト検証機を対象に入れて最終のビルドをしました。また、アップデートを通知しました。

ビデオ撮影

時間がまだあるので、ビデオを作ろうということになりました。 ガローア会場で @june29 が出演し、@ZoAmichi が iPhone で撮影しました。 監督は大森会場の @kei_s です。

この頃には「おやすみ」どころかすっかり空が明るくなってしまっていたので、ガローアの2人は仲良く布団を被りながら夜を演出しつつ撮影しました。札幌から遠く離れた地で、男性2名が仲良く布団を被って iPhone を弄るビデオを撮影している様を、生中継で見ていました。人生に一度あるかどうかわからないレベルの経験です。声が出ないように我慢しました (ミュートすればよかった)。

ビデオ編集

ガローア会場で撮られた動画は大森会場に転送され、 @kei_s がそれを編集しました。 @darashi はその様子を観ながら半分ねてました…

ビデオ完成

いい感じにできあがったところで、たまたま vimeo の Pro アカウントを持っていた @darashi がアップロードすることになりました。結果、蒲田→大森→札幌と動画が移動して世界に公開されることになりました。

投稿

vimeo の動画が投稿され、フォームを埋めるのに必要なものが全て揃ったので、投稿しました。7:35 提出完了です。 お疲れ様でした。その時の写真がこちらです。

Team OyasumiSupport#end_of_day

特別賞

昼過ぎまで泥のように眠り、私用から帰ってきて仕事をしていたら、審査結果が発表されました。

また特別賞をいただくことができました。

うれしい!!!やりましたね!!!!!!!!!!!!!

使っていた主なツール、インフラ

だいたい、こんなものを使っていました。色々なジャンルが混ざっていますが、参考まで。

まとめ

クックパッド社主催の「第3回開発コンテスト24」にチームで参戦し、二回目の特別賞を受賞しました。

チームが過ごした24時間を @darashi の目線からまとめました。

今回は、早い段階からリリース可能な状態を保ち、それを改善していくというやり方で比較的うまく回せたように思います。プロセスが自分たちの手でコントロールできている、という感覚がありました。今回に関していうと、与えられた制約や時間のなかで、だいぶ上手に進めていけたのではないかと思います。

「おやすみシャワー」を使ってくれる方を募集します

おやすみシャワーを使ってくださる方を若干名募集してみたいと思います!

iPhone をお持ちで「一緒におやすみしてみたい」という方は、 TestFlight にご登録の上、 @darashi までご連絡ください! 希望者が多いとご希望に添えない可能性もあるのですが、ひとまずご連絡いただければと思います。

あわせて読みたい

御礼

このような機会を与えてくださった、クックパッドさまに感謝いたします。素敵な審査員からのコメントをつけていただいたり、作品の説明を素敵な英語に訳していただいたりと、色々なところからコンテストをよりよいものにしようという気持ちを強く感じました。

感謝の気持ちとともに、月曜日の夜はお祝いということで大好物のしめ鯖とアボカドを さっぱりアボカドしめ鯖 でいただき、つくれぽも送ってみました!!

チームの皆に、心からの「ありがとう」を。おかげさまで楽しい時間を過ごすことができました。

コンテストに関わる全ての皆様に、深く感謝いたします。