ろばーと気まま雑記

気ままに書いてきます

HackU2019 OSAKAでHappy Hacking賞を受賞した話 〜ハッカソン初参加でPM的ポジションをする中で考えてたことや感じたこと〜

実は8/19~9/3で開催されたYahoo!さんが主催するハッカソン、HackU2019OSAKAに出場していまして、ありがたいことにHappy Hacking賞をいただくことができました。
これは会場全体の人気投票で決定される賞であり、つまりは多くの方の支持を得れたからこその受賞で大変嬉しかったです。


今回はハッカソン作品を作りあげるまでの過程や、人生で初めてハッカソンに出場してみて自分が感じた事などについて綴ろうと思います。

作品紹介

まず最初に何作ったかの紹介から。
提出時の紹介文をセルフ引用しておくと

見ず知らずのあなたへ

あなたの言葉や想いが何処かの誰かに届くかもしれないし届かないかもしれない。
SHABOMはそんな新しい形のコミュニケーションツールです。
言葉が時間と空間を超えてあなたや遠くの誰かの心を動かすかもしれない。
次はあなたがAR空間 SHABOM に何かを残しませんか。

チームたこてんより



ということで、我ら「たこ焼きに天かすは欠かせないけどやっぱり今日はてんぷらが食べたい」略して「たこてん」ではAR技術を用いた新感覚のSNSアプリ『SHABOM』（読み：シャボン）を作成しました。

『SHABOM』は特定の誰かを意識せず、自分の想いシャボンに包んでAR空間に飛ばすことができる新しい形のSNSです。
シャボンは現実の風に流されてAR空間を自由に漂流し、いつかどこかの誰かに届くかもしれないし、届かないかもしれない。
そんなボトルメールのような儚さを持ったSNSになっています。

アプリの中でユーザーはAR空間を飛び交うシャボンを投稿したり、誰かが作ったシャボンを取得することができます。
AR空間に放たれたシャボンは誰か1人しか獲得できませんが、獲得したシャボンのメッセージは後から確認することができる、そんな仕様になっています。

興味を持たれた方はデモ動画とプレゼン発表の様子もご覧ください🙌


『SHABOM』デモ動画


Hack U 2019 OSAKA 作品発表会・展示会・表彰式

ハッカソンのチーム構成

チームアップまで

今回のHackUはインターン先兼バイト先のメンバー6人で出場しました。
リーダーを務めてくれた1人が昨年もHackUに出場していて、今年はがっつり取り組んで賞を狙いたいというモチベーションの元、自分を含めた他のメンバーを誘ってくれました。
ちなみにそのリーダー以外の5人は今回がハッカソン初参加でした。笑

インターン先では先輩を中心にしたチームが昨年のHackUで優秀賞を獲られていて、今年もその先輩チームが同じく出場してるのでお互いライバル視しつつ(?)頑張ってましたw
（ちなみに自分たちのチームでは最初から最後まで「絶対勝つ先輩超える」的モチベーションがかなり強い面もあった。気がする。）

チーム内での役割分担

役割分担はお互いのバックグラウンドや技術スタックを考慮して

  • フロントエンド(Unity)：2人
  • バックエンド：1人
  • デザイナー兼プレゼンター：2人
  • プロジェクトマネージャー：1人(自分)

としました。自分はプロジェクトマネージャーとして全体統括的なことをしていました。

タイトルとかかっこつけてPV数増えるかなーとか目論みつつPM（プロジェクトマネージャー）と書いちゃいましたが、実態はふんわりとタスク管理やエンジニア・デザイナー間での調整とかを手伝ってたくらいです。

みんな優秀で各々自走してくれていたので正直大したことはしていません。笑

SHABOMが完成するまで

今回のハッカソン開発を振り返ると、ハッカソンでの開発を完走するには以下の3つのフェーズをくぐる必要があるなと感じました。

  • フェーズ１：作品イメージの確定
  • フェーズ２：MVPの開発を終える
  • フェーズ３：入賞を目指したブラッシュアップ

それぞれ詳しく見ていきます。

フェーズ１：作品イメージの確定

まずはチームMTGやアイデアソンを通してハッカソンで作っていく作品の内容や世界観を決めていきます。 この作品の世界観や内容はハッカソンのテーマなどでも変わってくると思います。
今回のHackUではテーマが「自由」＝「なんでも作っていい」となっていました。聞かされた時はさすがに暴挙がすぎると思った()

たこてんではメインで取り組みたい技術をARとして選定、そこから作品のイメージを膨らませていきました。
実際には下図のようにマインドマップを用いながらアイデアソンを行って作品内容を大まかに決定、後に自分がその内容をまとめたProduct Documentを作成、デザイナーの2人がトンマナなどを作る中で世界観を構築してくれました。

f:id:t_6bar10:20190908061147p:plain

フェーズ２：MVPの開発を終える

ハッカソンで最も大切なことは何か？
そう、発表当日に作品があることです。 いくら素晴らしい作品のイメージがあろうと、その開発が終えられなければそれはただの絵空事。 モノがそこに無ければ意味は無い。ハックしてこそのハッカソンなのです。

ということで、最低限発表できるモノを期間内に作るためにMVP(Minimum Viable Product)を見極め、まずはその完成を目指すべきです。 *1

『SHABOM』におけるMVPは

  1. 投稿文を包んだシャボンを作成、AR空間に投稿できること
  2. AR空間を漂流するシャボンをユーザーが観測できること

この2点でした。

開発においてはこの2つを達成できるかが最優先です。 ここでのポイントとしては2. においてシャボンの獲得・確認という具体的な機能を、現行主流のSNSにおけるお気に入り機能やいいね機能と同等であると抽象的に位置付け、完成物を見れば必須に思える機能であってもMVPにおいてはオミットしたことです。
こうして作品に最低限必要な機能であるかを具体と抽象の行き来によって見極め、MVP達成までの工数を減らしてあげることができます。

また、1.と2.は独立して実装可能な機能であるという工夫もポイントです。（サーバーにある程度のデータが置かれている前提） 機能間でのやり取りがあると、その分だけ考慮事項が増えていきます。 「シャボンを投げる」「シャボンを見る」という互いに干渉しない機能に絞り、まずはそれを完成させることを先決させました。

MVP達成は一つのマイルストーンなので、なるべく近いところに置いてあげることが重要です。 これによって、エンジニアはハッカソンの短い開発期間の中でモチベーションをフルバーストさせながら一つのシンプルな機能に集中して実装に取り組めるようになります。(なっていたと信じている)

フェーズ３：入賞を目指したブラッシュアップ

フェーズ２でMVPが作れたら、あとは作品をひたすらに作り込むのみです。
ここにどれだけ時間を置けるかがハッカソンで賞を獲れるかを左右するでしょう。 『SHABOM』ではこのフェーズ３に置いて

  • シャボンのサイズをタップ継続で膨張＆収縮させる
  • 上スワイプでシャボンを放てるようにする
  • メッセージのフォントをシステムデフォルトからデザイナー陣が選んだものを選択できるように
  • シャボンの獲得機能の実装
  • ユーザーが過去に投稿したシャボンと獲得したシャボンを確認できるプロフィール画面の追加
  • AR表示とアプリケーション背景の表示切り替え機能
    他たくさん

と怒涛の追い込みを展開しました。
エンジニアとデザイナーの必死の追い上げにより冒頭で紹介した『SHABOM』が形になったのです。
この間自分は何をしていたかと言うと、みんなが必死で消し込み続けるタスクをひたすらに追加、細分化し、上昇したタスク達成率を戻し続けていました←

PMとしてやってたこと

自分がハッカソン全体を通してやっていた以下の5つのことをもう少し掘り下げて書こうと思います。

  • Slackワークスペースの準備
  • MTGでの議事録や決定事項のドキュメント作成
  • 開発スケジュールの進行管理
  • チームメンバーへのタスク割り当て
  • エンジニアとデザイナー間での調整役

Slackワークスペースの準備

常にチーム全員が集まって開発に取り組めるわけではないのでコミュニケーションツールを持っておくことは言うまでもなく大事です。
インターン先でもSlackはフル活用されており、メンバー全員使い方は熟知しているので今回は専用のワークスペースを作りました。

チャンネルは
#all(MTGでの決定事項まとめやスケジュールリマインドなどの全体に関わる内容)
#design (デザイナー用)
#eng (エンジニア用)
#eng_back (バックエンドエンジニア用)
#eng_front (フロントエンドエンジニア用)
#github_back (バックエンド書いてるGitHubリポジトリの更新通知用)
#github_front (フロントエンド書いてるGitHubリポジトリの更新通知用)
#random (雑談)

くらいがあれば十分です。
実際はこの他にも作品決めの前の情報共有用に#share、サーバーテストの結果を流す#eng_test、今後のリリースを目指した内容を話す#releaseなんかも作られました。

MTGでの議事録や決定事項のドキュメント作成

チーム内で共有しておくべき内容はしっかり言語化してドキュメントを置いておくことは、認識を揃えたり開発開始後の行き違いを防ぐために鬼重要です。
細かい内容はあとで各自編集してもらってもいいので「ドキュメントを置いておく」ことを心がけました。

全体向けにはGoogle Document 、マークダウン慣れてるエンジニア向けにはHackMDを試したりしてみました。
HackMD好評だったので良かった。

開発スケジュールの進行管理

これが今回の一番の仕事だったと思います。
フェーズ2の部分でも触れましたが、作品発表に向けて消し込んでいくべきタスクを洗い出し、項目を細分化、適切に並び替えてエンジニアやデザイナーに渡してあげることが一番大事です。

ちなむと、自分の中で細分化していてもメンバーが見える形で提示するかどうかにも気を遣いました。
フェーズ２真っ只中の状況でその下にフェーズ３の更に多いタスク項目を見せるのは個人的には得策ではない感があったので。

具体的にはGoogle スプレッドシートのアドオン機能からガントチャートを作成して運用してみました。
本当はGitHubでProject立ててissueとかかっこよく使いこなしてみたかったのですが、初ハッカソン＆GitHub普段触らないメンバーもいてたので見送りました。
結果的にこれは正解だったと思っていて、スプレッドシートだとみんな見慣れているので運用に積極的に参加してくれました。

ガントチャート運用自体の良かった点としては

  • 全体の達成率を計算してくれるのでモチベーション維持になる
  • 各項目に取り組み期間と達成率が書けるので個々人でも見通しが立ちやすい
  • タスクを番号管理できるようになるのでコミュニケーションしやすい（「次X.X.Xやっていく〜？」「おけ！」みたいな感じ）

等がありました。まぁ期間設定の方は最終的にフェーズ３で崩壊を迎えてタスク書き出しシートと化しましたが。笑

↓実物はこんな感じ。 f:id:t_6bar10:20190908075246p:plain

チームメンバーへのタスク割り当て

これは実際のところ割り当てるというよりは相談する形になっていましたが。
全体感を一番把握しているのは自分なので、タスクフリーになったメンバーが出るとスプレッドシートから次のタスクを示して、取り組めるかの相談と確認、決まったら「じゃあお願い！！」ってするだけのお仕事です。

あとタスク振ったら適当に終わりそうな時間を何となく見積もってみて、その次の進行をこれまた何となく考えておくとスムーズにお仕事ができます。

エンジニアとデザイナー間での調整役

デザインが上がらないとエンジニアが動けない部分があればデザイナーに伝えたり、デザイナーの要望が実装可能なのかをエンジニアに先に確認したりと互いの橋渡し役をしてました。

チームメンバーの中でデザイン面の話にも少しは参加できて、エンジニアが実装する中身の話も分かる人間は自分だけだったので、これは結構ユニークネスを発揮して立ち回れた部分ではないかなぁと勝手ながら自負しています。

PMポジションをやってみて

今回初めてのハッカソンかつPM役をすることになり、特に専門知識も無いのでわりと思いつきでいろいろな事に取り組んできましたが、感覚としてはできる事はやれたかなと。
ハッカソンでのPMは初めてですが、これまでにプロジェクトをまとめたりディレクションを執るような役回りは何度かさせてもらってて、そこでの経験とかも活かせたかなと思います。

そして、ハッカソンで入賞を目指そうと思うと、マネジ面からチームの面倒を見る役割ができる人は絶対に必要だなと感じました。
結局作品そのものの形を作っていくのはデザイナーとエンジニアです。
なので、全体を見るような役回りは切り離すことで、その役に入る人たちがフルパフォーマンスを発揮できる状態を作っておくことが、結果的に作品のクオリティを上げていくことにも繋がるのかなと。

ただ、自分のバックグラウンドにはiOSアプリ開発もあるのでエンジニアとして取り組みたかった気持ちもあるのが正直なところです。

今回マネジメントに専念したのには、チーム構成の面で最適と判断した面もあれば、開発期間がもろにインターンと被っていて時間を多く取れないなど事情が様々あったのですが、自分がもっとつよつよだったら確実にコードでのコントリビュートもできたなと思うので技術力もっと上げます。

最後に

『SHABOM』はスマホアプリとして正式にリリースするために今も開発を続けています！
リリースの際にはまたブログで告知的なものをすると思うのでダウンロードしてもらえると嬉しいです🙌

ハッカソンやりきるの、とても楽しいし絶対良い経験になるので興味のある人は気軽にトライしてみると良いと思います！
確実に何かしらの成長を得ることができます。
長くなりましたが読んでいただきありがとうございました！

*1:ビジネスの世界ではMVPは「実用最小限の製品」と訳されています。本記事での使用方法では多少意味合いが異なっている可能性がありますがご了承ください。