見出し画像

42Tokyoで本格的なチーム開発した感想

取り組んだ課題

今回のチーム開発で取り組んだ課題は、レイキャスティング技法を使って3D空間で遊べるゲームを作るcub3Dというものです。

ただし、こちらの課題は複数人で取り組むチーム課題ではなく、生徒一人で取り組むことが推奨されているソロ課題です。

参考:レイキャステイングとは?

課題の詳細な概要については、他の生徒が書いた記事を参照してください。

参考:[Lv3] cub3d


チーム開発で組んだ生徒

画像2

今回の課題でチーム開発を一緒に行った生徒(以下、Nさん)には、僕からDMを送って、一緒にやりませんか?と声をかけました。

振られるかもという不安な気持ちがあったものの、Nさんは快く僕の打診をすぐに了承してくれました。

なぜNさんに声をかけたのか。

以前にNさんとはオフライン勉強会で一度だけ面識はあったものの、たくさん話したことはなかったです。

けれども、オンライン上でのNさんのアクティビティや企画したイベントなどを見ていて、自己管理能力が高く、自ら企画したり取りまとめたりと能動的でとても魅力的な生徒だと思っていました。

また、今回の課題でこれまでに取り組んできた進捗内容が異なるため、チーム作業する上でうまく分業できると思ったことも理由として挙げられます。


チーム開発しようと思った契機

そもそも、以前からチーム開発に強い関心がありました。

これまでエンジニアとしての業務経験がなかったものの(現在はエンジニア職でアルバイト)、エンジニア業務は一人ではなく、チームで開発していくことが通常と聞いていました。

なので、42Tokyo内で積極的にチーム開発をして経験を積むことは、将来的に大きな財産になると思っていました。


また、今回の課題は恐ろしいほどにやるべきことがたくさんあり、そして細かい&大量のエラーパターン処理も実装する必要があります。

そのため、一人でやるよりも複数でやったほうが完成度の高いプログラムが作れると思いました。


開発環境

画像3

チーム開発として選択したプラットフォームは、Githubです。

これまでにも何度か似非チーム開発でGithubを使ったことがありましたが、本格的なチーム開発をしたことがありませんでした。

今回のチーム開発を通じて、Githubのたくさんの素晴らしい機能を知り、実際に使うことができました。


チーム結成から完成までの時系列

11月08日:チームを結成&リポジトリ作成
11月11日:本格的にチーム開発の始動
12月09日:プログラム完成&レビュー
12月10日:課題のクリア

このようにして時系列にしてまとめてみると、チーム開発期間は1ヶ月ほどだけだったんだと知りました。

チーム開発の内容の濃さから2ヶ月位に感じていました。


Github上から見える数字

チーム開発で使っていたリポジトリページに残る数字です。

Pull Request数:71
commit数:451
issue数:39


チーム開発を開始する前の取り決め

画像4

チーム開発を本格的に始める前に、ボイスチャットでミーティングを行いました。

このミーティングでは、以下のような内容をREADMEでまとめて意見や方向性を共有しました。

1. 課題を完成させる期限的目標

2. チーム開発手法

3. 課題全体で残っているパート

4. パートを大まかに2つに分けて、タスクを割り振る


チーム開発手法として決めた項目は、以下のような感じです。

1. Mainブランチはmain

2. 開発はmainから各自のdevelopブランチを切って行う

3. ブランチ名は作業内容を分かりやすくしよう。(例:kkamashi/add_function_to_read_texture, N/add_function_to_set_texture etc)

4. 細かくcommit、タスクが終わったらpush

5. 最低1日1push

6. Discord上で細かく毎日連絡を取り合う


チーム開発が少しづつ進むに連れて、以下の項目も追加認識として互いに共有しました。

1. 1週間の稼働日が分かるスケジュール表を通知する

2. 始動する前に、1日のスケジュールやToDoリストなどを共有し、開始することを通知する

3. PR作成時/コメント時/mainにマージ時に通知する

4. 終了時に、1日の振り返りと明日の予定を書いて報告する


チーム開発を通じて感じたメリット

画像1

1. 互いにコミュニケーションを毎日取るので、ダレたりすることなく、常に高いモチベーションを維持しながら開発ができる

2. 自分が詰まったら、すぐに助けを求めて一緒に考えてくれる人が身近にいる安心感

3. 毎日のPRコードレビューを通じて、日々違うコーディングスタイルや課題解決方法を学ぶことができる

4. メンバーが理解しやすいように、常に可読性を意識しながら書く習慣がつく(例:変数や関数の命名、役割に応じたファイル/ディレクトリ分け)

5. 得意/苦手分野を互いに補いながら、開発ができる

6. 一人で開発するよりも、誰かとやったほうが絶対に楽しい!


チーム開発を通じて感じたデメリット

画像5

デメリットは特に見つけれられませんでした。

それは、今回のチーム開発で一緒に組んだ人がNさんだったからだと思います。

Nさんと組んで良かったことを以下に挙げてみます。

1. 生活時間が僕とそれほど変わらないため、時間調整にストレスを感じない

2. 自己管理能力が高いから自分で能動的にどんどん進められる

3. 何事にも柔軟に対応できる人で、僕からの細かいフィードバックにも耳を貸してくれる

4. 僕の書いたコードに対して、どんどんフィードバックをくれたり、分からない点に対して質問してくれる

5. 「より良いプログラムにしよう」という意識を持って、品質を高めようと努力してくれる

反対に、生活時間が異なる人だったり、目指している目標や方向性が違っていたり、チームとして一緒にゴールを目指す努力ができない人と一緒にチームを組むと苦しかっただろうなと思います。


改善点(こうしたら良かったかも)

画像6

・Norminette + αとなる独自のコーディング規約(スタイル)を作って良かったかも

・相手が書いた箇所のコードをリファクタリングしても良かったかも(互いのパートの理解度&品質の向上)

・各自が担当したパートをもっと細分化したタスクにして、遅れが生じているパートのタスクを余裕があるメンバーが手助けできる形にすべきだった

・一日の振り返り報告を"To Do"ではなく、"To Feel"にしてみると良かったかも(チームビルディングの一つ)

参考:“To Do”ではなく“To Feel”が大事な理由。


最後に

みんな、チーム開発楽しいよ!みんなもやってみないかい?


この記事が気に入ったらサポートをしてみませんか?