ハッカソン型インターンでどん底から這い上がって3位に選ばれた話
こんにちは。2ヶ月に及んだ夏休みが間もなく終わろうとしていることに焦る気持ちを抑えきれないいとゆうです。
夏休みに入る前、休暇中にやりたいことをあれやこれやとピックアップしておいたのですが、実際にはその半分くらいしかできませんでした。以前記事にしたサービスも、リリースするのにまだ時間がかかりそうです。自分の能力を過信してたなぁ…
さて、今回は私が9月下旬に参加した楽天株式会社様のインターンについて書こうと思います。楽天といえば楽天市場を筆頭に他のEC企業を圧倒するサービス数が売りのメガベンチャー企業です。今回参加したのは完全リモートのハッカソン形式インターンで、各チームに専属のメンターさんがつき、アイデア出しから開発、プレゼン資料作成までサポートしてくださいました。また、開発の合間に社員との談話会や職場紹介、個人単位でのキャリア面談などが設けられ、職場理解や進路相談にも手厚い態勢でした。何より嬉しいのがお給りょ…コホンコホン。
この記事の対象読者
- チーム開発の流れについてざっくりと知りたい方
- テーマに沿ったプロダクト開発のtipsを知りたい方
- オンラインの講義や会議に話者や聴衆として参加経験のある方
- 丸っこいものが好きな方
まずはアイデアソン
今回のインターンはハッカソン形式なので、まずはテーマが与えられました。テーマは今の時代らしく「オンラインで人と人をつなぐサービス」。このテーマに沿ってアイデアを出すところからスタートしました。
私たちのチームは全員M1の情報工学系で、なかには機械学習ニキもいたため、技術先行で考えようという話が出ました。また、他のチームが6人構成のところ、どういうわけかこのチームだけ4人構成であったので、アイデアで勝負しよう、という話も出ました。この2つの観点からアイデアをしぼっていきました。実現性やテーマとの親和性なども加味し、なんとかアイデアを2つまで絞ったのですが、そこから先が一向に絞れず…
絞れなかった理由としては、どちらに決まっても役割分担の際に一人余ってしまいそうだったからです。これがチーム開発の難しいところ。メンバー一人ひとりのスキルや経験をもとに適切にタスクをアサインしなければならないのですが、パズルピースのようにぴったりはまる配分方法が常にあるとは限りません。
結局、最後には実現性の部分を突き詰めて、アイデアを絞ることにしました。具体的な使用技術の検討をつけていく中で、片方のアイデアで使用を想定していたzoom APIの機能がzoomのpro版でしか使用できないことが分かり、こちらを切り捨てることにしました。
最終的に決まったシステムのコンセプトは、次のようなものです。
- ユースケース
- 多人数のオンライン会議や講義
- 問題点
- 上記のようなケースでは、映像が小さい、ビデオをoffにしている人が多いなどの理由により、話者が聴衆の反応を読み取りづらい
- 聴衆からすると、大人数になるほど自分の顔を晒すことに抵抗があり、ビデオをoffにしたい
- 解決策（2段階）
聴衆の映像をシンプルなアバターの動きに置き換えることで、zoomのギャラリービューなどで見た時にも一目で聴衆の反応が分かるというところが推しポイントです。その点で、既存のスナップカメラやLINEビデオ通話の機能などとの差別化をしています。
プロダクトデザイン
アイデアが決まったら、解決したい問題やターゲットなどを整理し、プロダクトの機能や画面遷移などを定義するプロダクトデザインのフェーズに入りました。アイデアソンの段階で細かい部分まである程度議論しておいたので、このフェーズはスムーズに進みました。と、思ったのも束の間。プロダクトデザインのプレゼンで、プロダクトマネージャの方からあからさまな不評をいただいてしまいました。
他のチームがそれなりにいい評価をもらっている中での不評だったので、なかなかに刺さりました。いただいたレビューのうち主要なものを抜粋すると、
- 話者が聴衆の反応を知りたいというニーズがそもそもあるのか分からない（利用シーンが狭いのではないか）
- 聴衆にとっての機能が何もないので、人と人をつないでいるとはいえない（テーマとの親和性が悪い）
というものでした。
1番目のレビューは完全に伝え方の問題でしょう。しかし、テーマとの親和性の部分は重視して議論を進めてきたはずであったので、2番目のレビューは正直驚きでした。私たちのチーム内では、人と人をつなぐという部分を通信的な意味で捉えていたのですが、どうやら社員の方が重視しているのは「インタラクション」だったようです。テーマの意味について、事前に社員の方とすり合わせをしておくべきでした…。かくして、私たちのチームはいきなりどん底に立たされてしまいました。
プロダクトデザインのレビューを受けて、いろいろと考え直さなければならないことが出てきました。一からアイデアを練り直している時間はないので、ベースは変えずに何か聴衆にとって役立つ機能を追加してインタラクティブ性を確保することを考えました。
オンライン会議や講義で聴衆が抱える問題を考えたところ、（主にオンライン講義で）聴衆からのアクションに話者が気付きづらいという点がが挙がりました。例えば、チャットなどで質問や指摘をしても、話者がすぐに気づいてくれるとは限りません。既存のビデオ通話ツールにはスタンプでのリアクションや挙手ができるものもありますが、スタンプは分かりづらい&一時的にしか表示されない、挙手は感覚的にできない&話者に気づかれにくいという欠点があります。
そこで、聴衆がリアルで手を挙げたことを検知し、映像に反映できれば利便性が上がるのではないかと考えました。後付け的になってしまいましたが、なんとかインタラクティブ性の問題は解決しました。
システムデザイン
システムデザインのフェーズでは、使用言語や技術、フレームワーク、開発環境などの詳細を決めるほか、メンバー毎の役割分担とラフスケジュールを決め、開発への備えを万全にしておきました。アイデア出しの時点で懸念されていた役割分担の問題ですが、私が他の所用で中抜けしている間に意外にもすんなりと決まっていました。大雑把な分担はこんな感じです。
| GUI | 感情推定・挙手検出 | アニメーション制作 | 仮想カメラ |
|---|---|---|---|
| Me | 機械学習ニキのDさん | 動画編集に強いHさん | 万能なKさん |
私は知らぬ間に、アプリの基幹部分であるGUIを任されておりました。
仮想カメラというのは、アバターのアニメーションをソースとした仮想的なカメラのことで、これをユーザの端末に認識させることで、zoomなどのビデオ通話ツールから利用できるようになります。
仮想カメラの作成にはOBS studioというネイティブアプリを使用し、このアプリを遠隔操作することで、ソースとなるアニメーションを私たちのアプリから動的に設定することにしました。正直、この連携部分は完全にKさん任せだったので詳細な説明はできかねます…参考までに使用したOBSのプラグインの情報を載せておきます。
ネイティブアプリと連携するという仕様上、開発するアプリもネイティブアプリ（ユーザの端末上で動作するアプリ）にする必要があります。ネイティブアプリなぞ私を含めてメンバーの誰も作った経験はなかったのですが、Kさんの情報によればnodejsのフレームワークであるElectronを使用することでWebアプリケーションと同じように作成できるのだそうです。チームメンバーの中で最もjavascriptの経験があるらしかった私は、その経験が活かせるのならとGUIの担当を承諾しました。
ここまで述べてきたシステムの概要をまとめると、次のようになります。
プロダクトデザイン同様、システムデザインもメンターさんの前でプレゼンし、フィードバッグをいただきました。主要なものを一部抜粋すると、
- 既存のものと自分たちで作るものの区別をはっきり示すこと
- スケジュールには遅れをカバーするためのbufferを設けておく
- ソフトウェアのバージョンやライセンスを明記すること
というものでした。
私たちのシステムはOBSや表情検出APIなど、既成品の力を借りる部分も大きいので、1番目のレビューは確かにその通りです。上記の概要図は、このレビューを受けて作り直したものになります。
2番目についても、納期に間に合わせるうえで大切なことであると納得しました。3番目は、当たり前と思う方もいらっしゃるかもしれませんが、私の中では新しい発見でした。チームで開発するうえで、他のメンバーが書いたコードを引っ張ってきて自分の環境で実行することはよくあります。この際、使用するソフトウェアのバージョンを揃えておくことで、バージョン違いによる動作不良などを防ぐことができます。そのため、ソフトウェアのバージョンについて明記しておくことは非常に重要です。
今回の開発ではnodejsとnpmのバージョンを予めそろえておきました。私の開発環境はWindowsだったので、Windows向けのnodistというバージョン管理ツールを用いてバージョンを揃えました。
開発
開発の下準備が整い、いよいよ開発がスタートです。
Kさんの提案により、githubを使ったissueドリブン開発をすることになりましたが、githubの使用経験が浅い私はどうすればよいのかさっぱりでした。周囲のメンバーもあまり分かっていなかったようで、Kさんのgithub講座が始まりそうな勢いでした。githubを用いたチーム開発の流れについては、それ単独で記事を書きたいくらい学ぶ必要性を感じたので今回は割愛します。
基本的には、各自黙々と開発を進めていきました。不慣れな技術を扱う場面も出てくるので、そのへんはお互いに聞き合いながら。自分では分からなくても、他3人いれば誰かは知っているというケースが多かったです。単独の開発では何時間も悩むような問題がものの数分で解決できてしまったりするのが、チーム開発のいいところですね。
しかし、OBSと私たちのアプリを連携させる段階で想像以上に時間がかかり、スケジュールにbufferを設けていたにも関わらずサービス残業に突入してしまいました。開発期間が限られている中で、チームメンバーの誰も触れたことのない技術を使ったことが災いしました。
開発最終日の夜に至っては、もはやインターンではなくハッカソンの徹夜開発を彷彿とさせる雰囲気でした（知らんけど）。奮闘の末、ようやくアプリが期待した動作をしてくれた時には、深夜にも関わらず大声を出してはしゃいでしまいました。
プレゼンテーション
英語力を重視する楽天らしく、プレゼンと質疑応答はAll Englishで行いました。プロダクトデザインでの反省を踏まえ、利用シーンが容易に想像できるような寸劇動画を導入に用いました。導入の流れは、
- 通常のオンライン会議や講義の様子を動画で見せる
- 開発物の紹介
- 開発物を使ったオンライン会議や講義の様子を動画で見せる
といった具合です。1の動画は肖像権の関係でお見せすることが難しいので、3の動画をお見せします。
あ、今更ですが開発物の名前は「emoTamaCamera（エモたまカメラ）」です。「感情（emotion）+玉（Tama）+カメラ（Camera）」からきています。語感がいいのでお気に入り。
online meeting with emoTamaCamera
online lecture with emoTamaCamera
エモたまカメラがある場合とない場合の対比で見せたことでユースケースを明確化し、lecutureの動画には生徒と教師がインタラクションをとる場面を盛り込むことでテーマとの親和性をアピールしました。
少々悩んだのがデモンストレーションです。上に掲載した動画が一種のデモンストレーションの役目を果たしているとも考えられますが、他の多くのチームはWebサービスを開発しており、リアルタイムで実際に動かしながらデモを行うことが想定されます。私たちとしても実際に動くものを作ったという証明のため、リアルタイムにデモを行いたい、という思いがありました。
しかしプレゼンの際に使用することになっているzoomウェビナーは話者の映像以外が表示されないため、感情推定や挙手検出のデモをリアルタイムで行うことは諦めざるをえませんでした。
代わりに、予め録画した以下の動画をデモとして流しました。GUI、ユーザの表情、アバターのアニメーションを一画面に表示したものです。が、肝心の表情は肖像権の関係で見せられずすみません…！
それでもやはり、実際に動くことを伝えたかったため、私たち自身がエモたまカメラを使ってアバターと化した状態でプレゼンを行いました。デモにこそなりませんが、聴衆に対するインパクトは大きかったと思います。
質疑応答は基本的に英語が得意なKさんにお任せしました。発表および質疑のクオリティも最終的な評価に関わってくるので、得意な人に一任するのは逃げではなく戦略です。
結果発表
総合評価3.5/5の、7チーム中3位でした。
機械学習やネイティブアプリなどの点が評価され、技術点では全チーム中最高の点数をいただきました。また、プロダクトデザインから一転して、テーマとの親和性の部分が評価されていることを何より嬉しく感じました。しっかりと議論し直して本当によかった！
一方で、パワーポイントや発表に対する評価が低いのは反省点です。動画や発表者のアバター化など工夫をしてはいたものの、開発に時間をとられてスライドの作成と発表準備がやっつけ仕事になっていた点は否めません。他のチームのプレゼンを聴いていると、スライドに発表に十分に時間をかけて準備してきたことが伺えました。成果を他人に理解してもらうためのものとして、やはりプレゼンの準備は疎かにしてはいけない部分であると痛感しました。
まとめ
今回の記事の中で、再現性がありそうな知見をまとめると
- 定められた期限の中で開発を行う際は、開発者がもつスキルとの相性や実現性をもとにアイデアを選ぶ
- テーマに沿った開発を行う際は、その意味について出題者側とすり合わせしておく
- 開発スケジュールをたてる際は、遅れが生じた際に備えてbufferを設けておく
- チーム開発では、使用するソフトウェアのバージョンは統一しておく
- チーム開発では、一人で悩んで解決しなかった問題はすぐに共有
- 言葉や文章で説明してもうまく伝わらないことはメディアにしする
- 開発と同じくらい、プレゼンも重要視する
ぐらいでしょうか。技術的なところに関する言及はほとんどできませんでしたが、もし要望があれば考えます。
また、開発に使用したgithubのリポジトリ情報も掲載しようか検討中です。ただ、私の一存で載せていいものでもないと思うので、載せるとしてもメンターさんの許可をいただいてからになると思います。
今回の記事は以上です。最後まで読んでいただきありがとうございました！
