スーパーハッカソン2012準備編

投稿日:2012-09-12

実はスーパーハッカソンの開催期間中である9/2・3は第2子が産まれる前の旅行、ということで和歌山に行く事になってました。さらに4日は子どもの誕生日+夕方から打ち合わせ。
こんな状況だったけど、メンバーからは「最初に頑張るのは自分たちだから大丈夫!」と送り出してくれたのでした。

今回ツールとして使用したのは、ChatWork・Dropbox・Cacooの3つ。

ChatWorkは今まで使ったことが無かったので、せっかくの機会だから使ってみよう、という流れ。
Dropboxはやはりみんな使ってますね。便利です。
CacooはiPhoneのワイヤー部品も揃ってるし、共有編集できるので提案してみました。他のチームでも使ってるところがありましたね。

で、今の世の中の怖いところ。イーモバとiPhoneがあれば外出先からもチャットに参加できてしまうんですね〜
ちょこちょこ意見を出しながら、「旅行中なんだから自粛しろ」と 優しいお言葉を頂く。

テーマにあるコーズマーケティングの実例を調べたりUIのベースを作ってもらってる間、白良浜で子どもとキャッキャウフフアプリやデータの仕様を考えていたのでした。

そこで決めた大まかな仕様は、
・サーバークライアント型
・クライアント側はWebアプリではなくネイティブアプリ
・サーバー側はPHP+MySQL
というまぁオーソドックスなものになりました。

サーバークライアント型

そもそも見せるのはクライアント側だけなので、クライアント内部でデータを持たせたりすることも十分可能でした。工数で言えば倍では効かないですしね。結果から言えば、まずこの仕様を排除してクライアントアプリの精度を上げても良かったのかもしれません。しかしこの段階ではプレゼンの内容も(当然)決まっていなかったので広く対応できるようサーバー側も構成することにしました。

ネイティブアプリ

iPhoneの画面に最適化したWebアプリとすれば、システム側を自分が作ってフロントの部分はナックルにお任せ→あとでシステムに組み込み、とか出来たので1つの手段として考えていたのですが、画面遷移や操作感の気持ちよさ・使いやすさをどこまで追い込めるか不安があったのでネイティブとしました。折衷として1つの画面をWebViewで作り、その部分のコーディングをお願いする、という形を取りました。

サーバー側構成

データベースを組まずダミーデータを返すだけでも対応できる内容だったので、クライアント側の進捗によってはダミーデータを直接出力する方法を採用しようと考えていました。が、先にサーバー側を組んでしまったのできっちりデータベースも組んでしまったわけですが…
今回PHPで組むのにFuelPHPというフレームワークを使用しました。結果としてサーバー側の工数が大幅に減ることになりました。このフレームワークを使うのは2例目になるのですが、欲しい機能がシンプルに纏められていて、とても使いやすいフレームワークだと思います。

 

スーパーハッカソンのルールとして、「最低限コアな機能は動作すること」という決まりがあり1週間(自分にとっては4日ちょっと)の間でどこまで機能を絞るか、ダミー的なデータで凌ぐか、という算段は当初から考えていました。

開発者としての立場で参加している自分が評価されるのは、仕様やプロダクトの完成度だと考えていました。自分の実力を計るための場だと考えていました。結局、自分の性格もあってほぼ妥協無く、当初想定していた仕様通りの内容を4日間で組むことになってしまったのでした。


PAGE TOP