人生で2回目のチーム開発経験
1. はじめに
こんにちは。アプレンティス2期生のsakanaです。
アプレンティスでは、計2回チーム開発を行うのですが、先日その2回目を経験しました。
このチーム開発では、学生からの投票が最も多いチームにBest Student Award, メンターからの投票が最も多いチームにBest Awardが贈られます。
そして、私たちのチームはBest Awardを受賞することができました！めっちゃ嬉しい！
という訳で、1回目のときから変化した部分はあるのか、良かったと思う点はどこかなどをまとめていきたいと思います。1回目の記事はこちらです。
また、私たちが作成した「List It Bro! for twitch」については、後ほど記事で紹介するので、良ければそちらもご覧ください。
2. チーム開発の背景
そもそもどういう経緯でチーム開発をしているんだろうと思われる方もいると思うので、簡単に自己紹介とチーム開発の経緯について説明しておきます。
私は理系大学院出身の27歳で、現在は無職です。今年の9月にアプレンティスというエンジニアを目指すサービスがあることを知って、そこに参加しています。
アプレンティスでは、2, 3週間ごとに与えられた課題をこなしていき、運営側で割り振られたメンバーによるチーム開発も経験しながら、最終的にはオリジナルプロダクト製作を経験します。
それを通じて、企業の方々にドラフトで採用されれば、晴れてアプレンティスシップに参加でき、問題がなければそのまま就職できるというサービスです。
チーム開発は計2回行われるのですが、その内2回目が今回の記事で紹介するものになります。
3. チーム開発の流れ
今回の開発のテーマは「ワクワクするもの」。Webアプリとして作成して、3分のプレゼンでデモを交えながら発表するというものでした。
チーム開発期間は12/11～2/4で2/4にプロダクトの発表。
しかし、チーム開発専念期間は1/29～2/4の1週間のみで、それ以外の期間はまた別で課題があります。
そのため、チーム開発専念期間までに実装の準備を終わらせておいて、期間に入ったら実装を進めていくという形式でした。
12月上旬にチーム分けが発表され、私たちのチームは4人チームとなりました。
3.1. プロダクト決定
アイデア出しまではそれなりに順調だったのですが、アイデアを1つに決定するのに相当時間を使いました。
最初はオンラインプレゼント交換アプリを作ろうと決まりかけていたのですが、自分たちが作れるシステム的に、ユーザー自身が贈られてきたプレゼントの購入を明示的に行う必要があって、プレゼント交換感が薄いというところを懸念して、今回は没となりました。
そこからまた新しいアイデアを探して…となったので、かなり時間がかかってしまいました。
幸い私たちのチームは、全員時間に融通が利いたので、チーム会の日数を増やすことでどうにかなりましたが、もう少しコンパクトにアイデア決定までを行いたかったなと思います。(週2予定だったチーム会を週4でやったときもありました)
3.2. 環境構築
私は環境構築担当になったので、Dockerでの環境構築を行いました。
もともと、Apprenticeの課題も全部Dockerで環境構築してやっていたので、大きな違いはありませんでした。
ただ、1回目のチーム開発では、Dockerを使わずに環境構築をしていたので、チーム開発でDockerを使うのは今回が初めてでした。
Mac環境の人だけ特定のRubyのバージョンに謎のエラーがでたり、1人だけ使おうとしていたポート番号が使えなかったりといったことはありましたが、バージョンの指定やポート番号の指定をすることでなんとかなりました。
3.3. 開発専念期間
私はフロントエンドのクリップ視聴ページ、プレイリストページ、Topページを担当しました。
元々プレイリストページのドラッグアンドドロップ機能や、クリップ視聴ページの自動再生などを試作していたので、それなりにスムーズに進みました。
私の担当分野に限らず、全員しっかりと優先度を決めて、デモに必要なことから順番にやっていったので、デモで使う機能が前日にはちゃんと出来上がって、全員でデザインの微調整を行うことができました。
4. DEV 1の課題の振り返り
DEV1では、次回のチーム開発で対処したい課題を4つ挙げていたので、まずは今回のチーム開発でそれらがどうだったかを振り返っていきます。
4.1. こまめな情報共有
チーム開発専念期間中は、作業中は基本的にdiscordにつないでいたので、何か合ったらすぐに連絡を取り合える環境を作れていました。
メンバーの1人は起床から睡眠までの時間がかなりずれていたのですが、21:00-23:00までをコアタイムとして設けることで、その時間は必ず全員通話にいて、必要なコミュニケーションがかなり取りやすかったです。
(チーム内日報、コミュニケーションのハードル下げとかは別で書こうかな)
4.2. フォーマッタの準備不足
フォーマッタの設定担当を事前に決めていました。そのため、担当の方が決めてくれた設定を全員導入することで、インデントの深さが違ってコードが読みづらいなどの問題は全く起こりませんでした。
それもこれも、フォーマッタの担当の方がしっかりドキュメントも用意して設定を準備してくれたからです。感謝！
4.3. Github運用ルール共有不足
Githubの運用ルールとして、Branchの切り方、Branch名、Commitメッセージのルールを設定しました。
そのおかげで、Commitメッセージは見やすくなったのですが、プルリクのタイトルについては何も決めていなかったので、後から少し後悔しました。
次に開発するときは、プルリクタイトルの先頭にもissue番号を振るなど、管理しやすくなる方法を導入したいです。
4.4. ディレクトリ構成の考察不足
事前にディレクトリ構成を考えてから開発を始めることで、ディレクトリの見直しは少なくて済みました。
とはいえ、多少は変更は起きたのですが、あまり準備に時間をかけすぎるわけにもいかないので、今回は丁度良い塩梅だったのではないかと思います。
5. やって良かったもの
次に、今回のチーム開発で特にやって良かったことを紹介します。
朝会
コミュニケーションのハードルを下げる目的もあり、毎朝10:00-12:00に朝会を実施しました。
およそ2か月前に初顔合わせしましたが、毎日誰かしらは朝会にいるので、どんどんコミュニケーションの抵抗感がなくなり、かなりカジュアルにやり取りができる仲になりました。
気軽に聞いて答えることのできる関係は、特に開発専念期間中に自分がやりたいことや困っていること、相手にやってほしいことなどを伝えるのに非常に役立ったと思います。
Notionの導入
自分以外の3人は、前回のチーム開発ではNotionを使用していないようでした。
そこで、自分がざっくりとしたNotionのテンプレートを用意して、ミーティングの議事録やドキュメント、ガントチャートなど、すべてそこにまとめるようにしました。
今回のチーム開発では、週ごとにPMを交代する形をとっていたのですが、みんな自分がPMのときは、議事録のページにその日の大まかな流れを書いておいてくれたりして、話し合いが進めやすかったです。Notion最高！
コンフリクト対策
コンフリクト対策として以下のことを行いました。
細かいタスク切り出し
細かくタスクを切り出すことで、できる限り担当範囲が被らないようにすることができました
長くブランチを切って手元に置かない
長い時間手元に置いてしまっている場合は、一部未完成でもプルリクを行うというルールを設けました。
Dockerの導入
微妙なファイルの違い等がなく、push時に余計なファイルが変更されるということがありませんでした。
フォーマッタの導入
全員同じ設定のフォーマッタを導入したので、インデントや改行が異なっているせいでファイルの変更が起こるということはありませんでした。
同時編集しそうなファイルを変更する際は、discordで事前連絡
これはルールとして定めてはいませんでしたが、自然とみんな行っていました。
6. 生じた課題とどのように対処したか
次は生じた課題と、どのように対処したかです。
話の脱線
課題
ミーティング中、話が脱線することが時々あった。
対処
タイムキーパーを設けて、各話題について制限時間を設けた。
また話し合いに入る前に、発表時に見せる部分の機能かどうかという部分の意識を強めた。
アイデアがなかなか決定しない
課題
アイデアの決定までに時間がかかった。
対処
1回目のアイデア決定では1つの案に絞った後で、没になってしまい、手戻りがかなり発生した。そのため、2回目はいくつか候補を挙げて同時に深掘りをして、その中から決定する方式に変更した。
7. 次回以降に対処予定の課題
最後に、振り返りで気づいた課題を紹介しておきます。
タスク切り出しの改善
課題
タスクの切り出しがフロント基準になってしまった。そのため、バック側はタスクの切り出しがほぼ最初からになってしまった。
対処
次回はフロントとバックでそれぞれタスクの切り出しを行い、それを機能ごとにつきあわせて確認する形をとってみる。
より情報共有を細かく
課題
自分の中で共有すべきでないと無意識に思っていたが、共有した方が良いことがあった。
対処
情報共有のハードルはもっと下げて良い。具体的には、チーム日報にぼやき欄を作ったり、discordに独り言用のチャンネルを設けるなどを行って、一応書いておくか、くらいのものも共有する。
8. まとめ
1回目のチーム開発の反省もしっかり活かし、コミュニケーションを密に取りながら開発を進めることで、結果的にBest Awardを受賞することができました。
引き続きこのプロダクトをブラッシュアップして、世に出せる形までもっていきたいと思います。
9. 最後に
本当にチームメンバー全員で勝ち取った賞でした。この経験をこの後の開発にも活かしていきたいです。
そして、この記事が少しでも、これからチーム開発を行う方の参考になれば幸いです。
Discussion