日本大学OB主催のハッカソンで優勝した話
はじめに
NU CAMP 2020(日本大学OB主催のハッカソン)に参加し、優勝した。
前回は最下位で悔しかったので、全力を尽くした。
担当したこと
チームリーダーを担当していた。具体的には、
- メンバーへのタスクの割り振り
- メンバーからの質問対応（アドバイスなど）
- スケジュール管理
- 進捗管理
を行った。これに加え、自分にもタスクを割り振って仕事をこなしていた。
使用した技術、ツール等
連絡用ツール
- LINE
通話用のツールで、身近なものであったので採用。 - slack
全員が使っていたため学習コストがない。メンターへの質問やコード共有などに適していた。また、全チームのチャンネルを全員が見れるようになっていたため、他チームへの情報共有も同時に行えるため。
ワイヤーフレーム作成
- Figma
インターンで触ったことがあった。- コンポーネントやグルーピングなどの機能
- 実際に自分のスマホで触って確かめれる点
- メンバーで共同編集ができる点
- Figma以外のツールを使ったことがなかった
を踏まえ、紙と比較したうえでメンバーの学習コスト等考えても採用しても問題ないと決断した。
進捗管理
- Trello
こちらも別のインターンで触ったことがあり、便利であると感じていた。また人の進捗管理をしたり、Todoリストのような感覚で使える点に魅力を感じた。
フレームワーク、言語等
Ionicについてはハッカソンで指定があった。React,Vue,Angularの選択肢があったがメンバー全員Reactしかかけないため、Reactを採用した。
- Ionic
- React
- JavaSctript
学んだこと
仕事の振り方
今回、かなり仕事の振り方を重要視していた。メンバーでプログラムを一番かけるのは自分であるのは事前から分かっていたし、熱意も初めの段階では自分が一番高かったであろうと今も思う。しかし、全てのコードを自分で書けるか、全ての作業を自分でするのが正しいかといわれると絶対にそうではない。自分がそこまでの実力がないこともまた理解していた。そこで重要になるのは、「人を使う」ということである。
私は今回のハッカソンで「自分でも他の人でも出来る作業は必ず他の人に振る。」を最後まで徹底していた。もちろん、自分に仕事がないときは自分でやるし、自分はできず、その人にしか出来ない仕事（プレゼンやデザイン等）は振っている。それによって自分が高い次元のこと、具体的には、全体のデータの持ち方であったり、プレゼンの内容、コンセプトのブラッシュアップや、メンバーのエラー対応（メンバーが解決できないという時点で、自分の仕事になる）等、アプリに関する包括的全ての仕事に時間を多く割くことが出来た。このような高い次元を考える必要のある人間が、CSSのピクセルを少しずつずらすような作業はするべきではない。
伝えたいこととしては、「自分の（リーダーの）時間を確保する」という点で仕事の振り方はとても重要であると感じた。
Reactの流儀
ReactってのはviewライブラリなのでコンポーネントはデータからJSXを組み立てる関数だと意識してください。データの初期化とか更新処理は関数に切り出すとシンプルになります。
これは私のお師匠様からの金言。ハッカソンを通してこれを痛感した。コンポーネントの切り分けが重要と言葉では聞くが、どうも簡単なTodoアプリなどを作っていてもいまいち重要性がつかめていなかった。今回のハッカソンでも良く考えずにコードを色々書いていった結果、最終的なコードが美しさとは程遠いゴミコードである。ゴミコードを書いている意識はなかったのだが、いろいろ修正を加えて突貫工事のようなコードを書いていくにつれ、チリが積もっていったのだろう。MVCのVの部分という意識が頭の中に一つもなく、一つのコンポーネントでデータの登録や更新、データを取ってきて、さらに表示までさせている。出来上がったコードは人には見せられないコードだった。これは私の認識不足で、チームのメンバーには申し訳ないと感じている。Reactの流儀をより理解する良い機会となった。
進捗管理
進捗報告は面倒だ。と私は思っていた。今日自分がやったことを文字に起こしてリーダーに報告しなければいけないのはすごく頭を使うし、大体でいいじゃないか。しかし、リーダーをやってみてそのような考えは180度変わった。ゴールから逆算して考えていくと、今メンバーが抱えてるタスクは何なのか？それはどの程度時間がかかるのか？優先度と見合っているのか？いまどれだけ遅れているのか？遅れを取り戻すためにどれだけのやるべきタスクを捨てるべきなのか？を考えなければいけないからである。今回のようなスケジュールの決まっているプロジェクトであるとそれの重要性が顕著に出たなと感じる。今の状況が分れば、それの対処法を考えることが出来る。メンバーが実装に詰まってるのであれば、それを自分が実装して、他のタスクをメンバーに振ったほうが効率が良い状況など容易に想像がつくであろう。
メンバーは進捗報告をリーダーにする義務があり、リーダーはそれをスケジュール管理に活かす義務、進捗報告の重要性をメンバーに気付かせる義務が発生すると感じた。進捗報告にはコストがかかり、そのコストに見合っただけの価値がある。それを理解していないリーダーが進捗管理をするべきでないし、リーダーが有能だと感じているのであれば、ぜひ進捗報告をきっちりしてほしいと考える。
勝った理由
自分なりに、なぜ勝てたのかをプロセスベースで話していこうと思う。
毎日12時間程度、通話をつなげながら開発した
タイトルの通りで、通話をつなげながら開発していた。これによりチームの雰囲気がとても良くなった。また、雑談しながらなにかエラーに詰まればすぐに質問出来たり、仕事がなくなればメンバーがすぐ私に仕事を聞いて来たりなど、質問してから回答までのラグがないことがとても時間効率が良かったのではないかと感じる。
一つ一つに対して理由を考えた
その理由が正しいかどうかはともかく、例えば、こういうUIにするとなったときにそのUIを選択した理由を持っていた。アプリ案のコンセプトなどもブラッシュアップに非常に時間を割いた。ユーザテストを行ったりアンケートをとったりというのも、根拠や理由を得るためであった。
アプリが早く完成した
開催期間が9日間だったのだが、私のスケジュール管理能力とメンバーの協力により、6日の時点でアプリが完成していた。これにより、ユーザテストを行いPDCAサイクルを一回回せたのがアプリの改善に大きく役立った。
さいごに
メンバーにはとても感謝したいし、メンバーに恵まれたと強く思う。私の仕事の割り振りや、スケジュールに文句ひとつ言わずついてきてくれたし、私の熱意に応えてくれ、最終的にみんなの熱量が同じレベルに達していた。これは本当にすごいことで、チームで何かをするときに、モチベーションのレベルが同じになることは滅多にない（少なくとも筆者の人生の中では一度もなかった）。
正直なことを言うとこのアプリを保守する気はなかったのだが、とても良い経験になりそうなので、保守しようと考えを改めた。アプリはデプロイ済みで、まだまだ改善点があるがぜひ触ってみてほしい。モバイル版への対応しか考えていなかったので、Webでの挙動は確認していない。
アプリ「就活ノート」【https://jobhuntingnote.app】
Discussion