【渋温泉ハッカソン: チーム9】アプリで渋温泉巡りをより楽しくしたい

こんにちは、 Mobile - iOSコースのKaitoです。今回、渋温泉ハッカソンで "またいきたい渋温泉を形に残すスマホアプリ"をコンセプトに、チームでiOSアプリを開発しました。チームで作ったAPIを使用するなど、とても勉強になるチーム開発を体験できたので、使用技術を含め、その流れを紹介していきたいと思います。

事前準備期間

　-テーマ決め

キックオフ直後、メンバー全員が同時に集まることが中々難しかったため、アイデア出しにFigJamを使用しました。夏のハッカソンで先輩が使用していて、アイデア出しがかなりスムーズにいっていたの思い出して使ってみました。

FigJam

チーム9は "混雑度を見える化し、町巡りを楽しくせよ" というテーマを選択しました。このテーマを選択しているチームが多かったので、ミーティングで他班と差別化できる部分を考えました。

テーマを改めて捉え直した時に "混雑度を可視化するだけでは街巡りは楽しくならない" という意見があがり、班として "街巡りを楽しくせよ" という部分にも取り組んでいく方針を固めました。　　　　　　　　　

　テーマ決めの時点で決まったことは主に以下の通りです。

　・若年層に使ってもらえるために、iOSアプリを作成すること
　・"街巡りを楽しくする"という部分にもアプローチすること
　・一目で混雑度がわかるUIを実現すること

アプリ内UI

　-事前開発

現地開発は3日間に限られているということで、事前開発期間での開発を急ぎました。モバイル側で使用した技術は難易度自体は高い訳ではありませんが、実装項目が期間に対して多かったです。APIが実際にAWSにデプロイされるのは、ハッカソンが始まってからになるということだったので、公開されたらすぐにアクセスできるように関数を用意しておくなど、現地開発までに終わらせられる部分をなるべく実装していくようにモバイルチームで開発していきました。この期間でのミーティングの回数は少なかったですが、方向性をすり合わせて各個人で開発を進めていくことができたことが、事前開発期間で間に合わせる上での大きな要素だったと感じています。

成果物について

　-使用技術、デバイス

センサー:
　・マイコン: M5StickC
　・センサー: TOF方式距離センサ
バックエンド:
　・フレームワーク: Django, Django REST Framework
　・インフラ: Docker, AWS-EC2
　・DB: PostgreSQL
　・リバースプロキシ: NginX
　・アプリケーションサーバ: Gunicorn
モバイル:
　・ライブラリ: MapKit, iOS Chart, MercariQRScanner

バックエンド側の使用技術の選定について(Shunsukeさんより) 処理本体としては、Django+Django REST frameworkを用いた。Djangoを選んだ理由としては、単に使った経験があるからで、REST frameworkを用いた理由としては、JSONでのリクエストとレスポンスの、バリデーションやシリアライズの実装を簡単に行うためである。インフラ構成としては、まず開発環境をDocker Composeで整備し、デプロイ時にはそれをAWSでEC2上にそのまま展開してポートを公開する形を取った。次に個々のDockerコンテナを説明していく。まずアプリケーションサーバとして、Djangoビルトインの開発サーバはあるが公式ドキュメントでは非推奨であるため、パフォーマンス向上のためにも、設定が簡単なGunicornを用いた。しかし、今回使用したEC2インスタンスの仮想CPUコア数は1であったため、そこまでのパフォーマンス向上はなかったのではないかと思う。また、その前段にはリバースプロキシとしてNginxを置いた。その理由としては、リバースプロキシを用いることも推奨されており、当初Let's EncryptでHTTPS通信を行う予定だったためでもある。ただ、実際にはプロトタイプとしての開発を意識していたこともあり、機能の充実に時間を使うことにした。また、HTTPのほうが今回用いたIoTデバイスであるM5StickCからのアクセスが行いやすかったという背景もある。　データベースとしては、PostgreSQLを用いた。これは単に、あるサイトでおすすめされていたからというところが大きい。

簡潔な技術フロー(主要技術のみ)

　-成果物

制作したアプリの主な機能は以下の通りです。

　・渋温泉中に設置されたQRコードスタンプラリー
　・各外湯のリアルタイムと過去1週間の目安混雑度が把握できる渋温泉マップ
　・各外湯の混雑度を修正できる管理者ログイン機能

「現在、過去の外湯の混雑度の取得・混雑度の修正・管理者ログイン」について、REST Frameworkを用いて作成したAPIを叩いて値を取得しています。qiitaなど、パブリックなAPIしか使用したことがなかったので、自分達のチームで作成したAPIを使用して実際に値を取得するという体験は非常に新鮮でした。

QRコードの読み取り・目安混雑度のグラフ描画は、それぞれMercariQRScanner, iOS Chart を使用しています。

情報の取得にAPIを使用したページ

サーバ側から各外湯の混雑度を修正することも可能です。値の変更をセンサーのみならず、サーバ・iPhoneからも可能にすることで外湯の混雑度の把握についての精度を担保するようにしました。各個人のiOS端末からも混雑度の修正が可能な仕様は "外湯の清掃業務などのついでに従業員の方が混雑度を修正する事ができる" という具体的な業務を想定した結果、実装したものです。

管理者画面・上記は大湯の混雑度を表示

"街巡りを楽しくする"為の機能としては、スタンプラリーを設けました。スタンプラリーの項目には、なるべく「混雑の解消の為に、渋温泉の中で観光客を分散させる・各外湯の近く」の場所を設けました。他機能の実装に時間を取られてしまい、この部分を拡充させる事ができなかったですが、アイデア次第ではより魅力的にすることも可能だったと思います。事前開発を終わらせて、この機能についてより議論、検討できなかったことが少し心残りです。

以上が、9班が開発したアプリの概要になります。何とかメンバーの中で納得のいく形に出来ました。センサーからサーバの値を更新できたり、それらをAPIとして取得することができたり、また、それらをグラフに表す事ができたりと…段階的に一つのアプリが完成していく過程を開発者として見届けることができたのは貴重な体験でした。

振り返ってみて　

Kaito (著者: mobile) モバイル開発に関しては、コースでの取り組みが非常に役に立ちました。定例会で行っているUITraceのおかげで、実現したいUIの選択肢が大きく増えたと同時に実装スピードの部分でも成長を実感できました。これから、より実践的な開発経験を積んでいきたいです。また今回、チーム内でリーダーをやらせてもらいました。とは言っても、技術的な知識が足りず、チームのメンバーに引っ張ってもらう事の方が多かったように感じます。振り返ってみると、特にチームのマネジメントの部分での心残りが多かったです。具体的には「もっと上手く分担できていたら、あの部分に時間を割けていたな」などと反省する部分が多く、「何か人にタスクを振る」という行為が非常に難しいことを実感しました。勉強になる部分も多かった反面、個人としては力量不足で、とても悔しい経験でした。技術的な部分だけでなく、マネジメントの部分についても勉強していきたいと強く思いました。普段オンライン上でしか話したことのなかった方と実際にお会いして、刺激をもらえた濃い3日間でした。とにかく楽しかったです。これからも勉強あるのみです。 Sota (data) マイコン・センサーを用いて人の入退出検知・サーバーへ情報送信の部分を担当したが、 M5StickCもTOF距離センサーも開発環境であるArduino IDEも今まで触ったことはなくて開発期間の目途が立てられなかった。その上、自分がやっている所が出来ないとその先をいくら作った所で机上の空論になってしまうというプレッシャーもあった。しかし、最終的にはチームで一つのアプリとして完成させることが出来たし、最後の2日間リアルで集まって行う開発経験も新鮮で楽しかった。他のコースの人たちに比べて実際の現場で使える技術・知識が足らない、応用出来てないということもこの温泉ハッカソンで感じたので、今後はもっと開発に時間を割くことで戦力となる人材を目指したい。 Nanami (mobile) このハッカソンは私にとって初のチーム開発で、最初は自分がチームのために何が出来るのか全くわかりませんでした。チームメンバーがセンサー技術のことやサーバー側の仕組みについて話し合っているのに全くついていけず自分の知識の狭さを思い知らされましたが、テーマの問題の分析・アプリの案出しから、モバイルの課題で普段取り組んでいるような実装まで、自分にも出来ることが沢山あってやり甲斐を感じました。最終的にはモバイル的に新しい知識を結構得られたこと、チーム開発を通してコース間の繋がりが見えたこと、またチームメンバーと仲良くなれたということがあり、本当に参加して良かったと思えるハッカソンでした。 Shunsuke (Backend) 今回は初のオフラインイベントであり、ハッカソンの参加自体も初めてだったが、普段関わることの少ない他のコースの人々と集まって、しっかりと動くものをつくることができ、とても楽しかった。技術的には、AWSのインフラの構築をはじめて自分で行い、リバースプロキシやアプリケーションサーバなども利用したため、かなり調べることも多く、その部分に関しては大変だった。反省点としては、まず、もっとしっかり仕事の分担ができていれば良かったということである。第二には、プレゼンテーションでの技術面のアピールも、もう少し行うべきだったということである。また参加する機会があれば、これらの反省点を生かし、また良いものを作りたい。 Izumi(Backend) 私は主に発表資料の作成に携わりました。資料を作るにあたり、いかに渋温泉の人にわかりやすく順序立てて組み立てるか、ということを意識して作成しました。結果、寄り添って考えられているとの評価を貰えた一方、技術面が多く伝えられず、必要な箇所が練りこめていないという評価に終わりました。限られた時間の中で、様々な職種の聞き手にわかりやすく説明するということは難しいなと感じました。