読者です 読者をやめる 読者になる 読者になる

zenhack 2016 fallで僕らはどのように開発を進めたかその2

こういうのは続きを早く書くのが大切ということで、第二回目の記事を書かせていただきます。
2回目は、振り返りを書かせて頂きます。

良かったこと・良くなかったこと・次はこうしたいの3部構成でお届けします。

良かったこと

機能の役割分担できたよ

f:id:takahiro-f:20161004195805p:plain
前回のarchitectureにある通り、
FrontEnd/API/Engine(写真集めと解析)という3つのアプリに分けたことと、
最初にAPIが何をどこまでやるかということを明確しました。
具体的にやったことは、

  • likeを付けた写真の(登録、参照、更新)
  • 現在地の近くにある写真のリストの取得

とそれぞれのインタフェースを定義だけではありますが。
これは、短時間の開発でもやはり有効だということを再認識しました。
このおかげで、FrontEndをやっていた僕らがそんなにAPIがやってることに口を出さずに(笑)、

  • それぞれの間でどういったデータのやりとりをするか

ということだけを気にして、黙々と開発出来ました。
「ここ、どうする?」みたいな数が極力減ったことは
今回のhackathonのような短時間の開発でもスピードアップに繋がるとおもいました。

人の役割分担できたよ

元々は、僕の役割はそこまではブレてないんですが、こんな感じのイメージで、
そうとう野望ある役割分担をしようとしていました笑

  • taka66 - Design + Front-end
  • sideroad - API + Front-End
  • nab - Front-End
  • kojiro - スマホアプリ
  • okame - IoT

ありとあらゆるデバイスで何か作ろうと、、笑
でも始まってすぐ時間が足りないってことに気づかされ、あっさり諦めて役割を考え直したことは良かったと思います。
今回のhackathonでどうであったかはさておき、

  • taka66(僕) / Design,HTML,CSS,JS(モックアップ) + プレゼン資料作成
  • sideroad / FrontEnd(SinglePageApplication(React.js)) + interaction animation(js) + Infra(Heroku)
  • nab / API
  • kojiro / API + Infra(AWS)
  • okame / Photo search Engine

短い時間の中でプロダクトをどのように完成こと
ということはものすごく大切だと思っていて。
時間の中で動くものを作る為にこの役割分担に行き着いたのは良かったと思っています。
Done is better than perfect..

機能を削ること

実装を初めて比較的早期に、いくつかの機能を最初の実装から外すことを決めました。
例えば、現在地の近く意外の場所から検索する機能と、カテゴリに分けてそこから検索する機能などです。
最小限でコンセプトを伝えられる機能を実装して、残り時間があれば拡張しよう。
というポリシーでいきました。分かってはいるものの、考えているとあれやりたくない?
みたいなことによくなるので、hackathonではお互いにいい案配で指摘しあえることも大切だと思います。
ただ、削っている間にコンセプトを見失って、実装しやすい機能だけ実装する
ということはもちろん望ましいことではありません。
ので、機能を削る時は、自分たちが作るもののコンセプトに必要最小限であるかどうかで
優先度を考えるのがいいと思います。

自分たちが作ったものを気に入ること

これは結果論も半分です。
感覚的な話ですが、これはおよそ上手く行っているバロメーターとしては比較的正確だと考えています。
時間が無い中で、作るプロダクトは不完全なところもあります。
それでも、作っているサービスを好きでいられることは、みんながそのアプリに可能性を感じて入れていて、
コンセプトにある程度納得がいってるということにもなると思います。
個人的にはロゴとかアプリ名とかがあると愛着がますので、合間の時間を使ってなんとかロゴを作りました笑

良くなかったこと・考えること

目的・テーマへの理解と先入観

こちらは特に個人的な振り返りになりますが、
正直、
お題:「観光」
ここだけ見てたなーってのはあると思います。禅ハックのサイトをみて、申し込んでた時に考えたことは、
観光に役立つアプリを作るってこと。
そこだけ見ていて、
・協賛の鎌倉市さんの観光に関連した資料のデータの使い方、理解が不十分だった。
・後は、禅をより深く絡める、禅の考えを活かすこと。
やっぱりhackathonにはテーマがあって、そこには主催者が解決したい課題があります。
そこへの解決の道筋を見せられることは、大切なことだったなと。

誰の為のものか

ここもお題に付随するところなんですが、

  • > 観光に役立つアプリを作ること。

を考えると、まず最初に浮かぶのは観光客にとって役に立つもの
っていう発想になると思うんです。これ自体は間違っていないと思います。
ただし、もちろん観光を受け入れている側の方々もいて。
今回のhackathonは、受け入れることに携わっている方も多くいました。
基本的にはユーザはやっぱり観光客ですし(もちろん作るアプリによりますが)、
その場合、彼らに使ってもらえないことには、何もないというのはあります。
ただ、彼らに使ってもらうことで、受け入れる側の課題がどのように解決されていくか。
そこはもっとしっかりプレゼンなどで伝えるべきでした。

申請が必要なAPI

ってまぁまぁあるじゃないですか。事前に申請しとけって話でうね。
使う可能性を感じるものは。

自分の武器を探す

良くなかったってより考えてることですが。
hackathonとかに行くと思うことが多いです。
自分が一番輝けるのはどの領域なのかと。
これは役割分担を明確にすればするほど出てきますが。
今回のメンバーだったら自分はフロントとかデザインだし、
逆にそういう人がたくさんさんいればバックエンドのapi開発やったとも思う。
流動的に動けることはいいことももちろん多いけど。。
間を繋ぐことも大事だけど、やっぱり役割分けるとスペシャリティ大事になってくる。
技術を生かしたデザインみたいなのをもっとできるようになりたい。

SPAの為のマークアップ作成

SPAを実装していると、コンポーネント毎にcss閉じ込めたくなる時はよくあると思います。
その時に、マークアップcssが一つのファイルだと、そこから当て込むのが面倒なんですよね。
段々更新があった時に取り込むのが大変になる。
デザインのモック作った後に、コンポーネントの切り方をFrontEndの人と決めて、cssは全体のものは一個のcssにして、
コンポーネント依存のcssは割り切って一個のファイルで最初からcss作ったほうが、
連携しやすかったなっておもいました。
これはすぐ実践できそうなので、次にこういった機会があるときはそうしようと思いました。

次はこうしたい

  • テーマの理解と、その上で何を作るかっていうのを先入観なしで、考えられているかどうか見つめ直す時間をブレストの完了前に作る・自分がその視点を持つ
  • 事前に関連するAPIは使えるようにしておく(特に申請が必要なもの)
  • もっと、オレオレテンプレートを作り込んで、デザインでも、アプリでもwebでも、最初の一歩を踏み出せる時間を早くする。
  • SPAの為のマークアップを勉強する(次も同じ役割やるかどうかは分からないけど
  • このhackathonはチームで参加してるところは結構少なくて、1人で参加してその場でチーム作ってる方がかなり多かったので、そういう参加の仕方をすると、また違った感想を持つ気もしますし、そういう参加の仕方をしてみたいなって。

って感じかなー。時間かけて振り返ればもっと出てくることはありそうだけど。

おまけ(オリジナルシャツ作り)

今回、hackathonの開催にあたって、
チームの気合をいれる為にTシャツ、ポロシャツ、シャツを突貫で作ってきました。
急にオリジナルグッズを小ロットで作りたい時は、毎回渋谷の
ARTON.CO.LTD
さんにで作ってきました。
ロフトの隣です。プロントの上です。
個人的には何度もお世話になっています。
f:id:takahiro-f:20161008200235j:plain
f:id:takahiro-f:20161008200249j:plain

Illustratorでデザイン作って持って行って、artonでdesignちょっと調整して印刷。
っていうことをちょこちょこやっています。
その場で出来るってのがなんとも素敵ですし、1枚1枚違うデザインで作れたりもしますし。
小ロットで作るには安いし、その場で素材色々選べるし。
印刷の位置スタッフさんと相談できるし。
シャツ1枚、ポロシャツ2枚、tシャツ3枚+みんなそれぞれアイコン入りなんて、ここでやらなかったらかなり面倒
大変おすすめです!

f:id:takahiro-f:20160927211431j:plain
f:id:takahiro-f:20160927211243j:plain
f:id:takahiro-f:20160927212139j:plain