📖

初めてのチーム開発経験

2023/12/08に公開

CSS

1. はじめに

こんにちは。アプレンティス2期生のsakanaです。

先日、人生で初めてチーム開発を経験したので、その内容を記事にしたいと思います。

チーム開発未経験者がチーム開発を始めてみたら、どういう課題が生じて、どう対処していったのかを書くことで、少し前の自分と同じようにチーム開発未経験の方の参考になれば嬉しいです。

今回のチーム開発で私たちが作成したオフラインWebページマネージャについては、また別の記事で紹介するので、良ければ合わせてご覧ください。

2. チーム開発の背景

そもそもどういう経緯でチーム開発をしているんだろうと思われる方もいると思うので、簡単に自己紹介とチーム開発の経緯について説明しておきます。

私は理系大学院出身の27歳で、現在は無職です。今年の9月にアプレンティスというエンジニアを目指すサービスがあることを知って、そこに参加しています。

アプレンティスでは、2, 3週間ごとに与えられた課題をこなしていき、運営側で割り振られたメンバーによるチーム開発も経験しながら、最終的にはオリジナルプロダクト製作を経験します。

それを通じて、企業の方々にドラフトで採用されれば、晴れてアプレンティスシップに参加でき、問題がなければそのまま就職できるというサービスです。

チーム開発は計2回行われるのですが、その内1回目が今回の記事で紹介するものになります。

3. チーム開発の流れ

今回のチーム開発期間は10/16(月)～12/3(日)で12/3(日)にプロダクトの発表でした。

ですが、チーム開発専念期間は11/27(月)～12/3(日)の1週間のみで、それ以外の期間はまた別で課題があります。

そのため、チーム開発専念期間までに実装の準備を終わらせておいて、期間に入ったら実装を進めていくという形式でした。

初日にチーム分けが発表され、私たちのチームは私、Mさん、Hさんの3人チームとなりました。

3.1. チーム開発専念期間前まで

プロダクト決定

開発というからには、プロダクトのテーマを決めなければなりません。

今回のチーム開発の要件は、Railsのようななんでもできるフレームワークは使わずに、Ruby/MySQL/HTML/CSS/JavaScriptを使用して「自分たちの役に立つプロダクトを作成する」というものでした。

他の細かい要件も聞いた感じ、Web上で動作して役に立つものというより、手元で動かして役に立つものという印象だったので本当に悩みました。真っ先に思いつくものは、だいたいインターネットにつながることで価値を発揮できるものが多いと思います。

だからこそ、オフライン環境でこそ価値が存在するプロダクトってなんだろうと考えました。その結果、オフラインでWebページを閲覧できるアプリ、オフラインWebページマネージャが候補として浮かび上がってきました。

私たちが課題を確認するときに使用しているGithubのプライベートリポジトリを閲覧できるようにすることで、既存のオフラインWebページマネージャとの差別化を図ることができるというポイントもあり、プロダクトが決定しました。

具体的なスケジュール

私は大学自体に受講したシステム工学演習の経験から、チームで何かをする際は、細かいチェックポイントを設けて、そこに向かって進めていくことが大事だという考えがありました。

そのため、早いうちに定期的にチームで集まる週2回のチーム会をチェックポイントとして設定し、各チーム会までに何をやらなければならないかをまとめる作業を行いました。

最初に作成したスケジュールがこちらです。各チーム会でやること、その間でやることが書いてあります。

11/03(土)：アイデア決定【全員】、ざっくり担当者決め【全員】

スライド作成(デモストーリーを意識、大枠でOK、アピールポイントまとめ、この段階では最悪絵がなくてもok)【M】
Githubリモートリポジトリの用意【sakana】

11/08(水)：スライド確認【全員】、要件定義【全員】、画面遷移図作成【全員→H】

Githubリモートリポジトリへの接続確認【全員】
画面遷移図作成の続き【H】

11/11(土)：画面遷移図確認【全員】、タスク切り出し【全員】、担当者単位でタスク時間見積もり【全員】、担当者割り振り【全員】

ガントチャート作成【sakana】(早めに)

11/15(水)：ガントチャートの確認【全員】

ワイヤーフレーム作成【誰か】

11/18(土)：設計と環境の確認【全員】

11/22(水)：予備日

11/25(土)：

プログラミング【全員】
プレゼン資料作成【M】

実際にはここから修正しながら進めていきましたが、概ねスケジュール通りに進んでいきました。

3.2. チーム開発専念期間中

直前の課題を終わらせて、11/25(土)からチーム開発の実装に取り掛かりたかったのですが、実際には自分が11/26(日), チームメンバーの2人は11/27(月)から開発開始となりました。

そして、我々は全員チーム開発未経験の身。結果的には遅れなく発表日を迎えられたものの、当然の如く問題は発生しました。大きく2つあったので、それらを紹介しておきます。

プルリクが来ない問題

他の2人より1日早くコーディングを開始して自分の担当範囲のプルリクを送り、次の日もプルリクを送り…と繰り返していると、ふと他の2人からプルリクが来ていないことに気が付きます。

日曜に発表なので、月から土の6日間が実質的なチーム開発専念期間ですが、その半ばに差し掛かった水曜まで、プルリクが来ていないのでした。

水曜の夜のチーム会でそのことをチームメンバーに尋ねると、プルリクの手順が合っているか不安に思っていることを知りました。

画面共有で手順を見せることで解決しましたが、もっと早く解決できたなという後悔が残りました。

デザインイメージが全然違う問題

Githubや技術ブログ記事を閲覧するアプリを作成するということで、自分はなんとなくシンプルなデザインのイメージをしていたのですが、メンバーのMさんが作ってくれたCSSを確認したら、カラフルな色使いになっていました。

よく考えたら、各ページの構成や機能の話は先に詰めていましたが、デザインの話は一切と言っていいほどしていませんでした。なので、当然と言えば当然です。

話し合った結果、シンプルなデザインに統一することになりましたが、何日かかけて作っていただいたCSSをそのまま捨てることになってしまい、とても申し訳なかったです。

そんなこんなでいくつか事件はありましたが、最終的には作ろうと思っていたものはちゃんとでき、余裕を持って発表当日を迎えることができました。

4. やって良かった点

開発の流れについては紹介できたので、あとはポイントを絞って、今回得た知見を共有したいと思います。まずはやって良かった点から。

4.1. スケジュール管理

早いうちに、大まかなタスクを各チェックポイント(今回の場合は週2回のチーム会)毎に設定しました。

これにより、大きな遅れがなく最後まで進めることができました。

4.2. 早めのツール選定

ドキュメントやスライド、ガントチャートなどを集約する場所として、チームでNotionを使用することを決定しました。

これを決定するのが早かったので、データがなかったり、どこにあるのかわからなかったりで無駄に時間を使うことはありませんでした。

4.3. 気になったことをシンプルな構成で試してみる

私はRuby on Railsを触った経験から、Rubyの変数の値をHTMLで表示するためには、漠然とERBファイルをブラウザで開けば良いだろうと思っていました。

しかし、Railsを使わずにやるとどうなるんだろうと試してみた結果、フロントエンドとバックエンドのデータ受け渡しにはサーバを立てる必要があることを知り、3日かけてなんとかデータ受け渡しができる状態には持って行けました。

タスクの切り出しからこれが漏れていたということになりましたが、気になった時点で試してみたことで、早いうちに気づくことができて、致命傷にならずに済みました。

今回は自分で解決できたので良かったですが、そうでなくても、試してみてダメだったら今後のタスクとして追加しておくことで、スケジュールの把握がより正確になり、どちらにせよ気づかないよりは良い状況に持っていけたと思います。

4.4. MustタスクとWantタスクに分ける

ガントチャートに記述するのはあくまでMustでやらなければならないタスクのみにして、Wantのタスクは余った時間で行うように設定しました。

このおかげで、ちゃんと動くアプリは存在する状態で、発表時間の少し前まで細かいアップデートを続けることができました。

5. 生じた課題とどのように対処したか

次は生じた課題と、どのように対処したのかです。

5.1. フロントエンド、バックエンド間のデータ受け渡し方法

課題

Rubyの変数の中身をJavaScriptで表示するような、フロントエンドとバックエンドのデータ受け渡しが簡単にできると思っていた。しかし、実際はサーバーを立ててフロントエンドからHTTPリクエストを送る必要があった。

対処

サーバー周りのことについて知らな過ぎて、時間の見積もりすらできなかったため、これに気づいた時点でデータの受け渡しができる状態まで学習と作業を進めた。

5.2. 開発準備の不足

課題

Githubでのチーム開発が初めてだったので、プルリクの流れをチームメンバーがわかっていなかった。

対処

画面共有でプルリクを自分がどのように行っているのかの流れを実際に見せて、その後にメンバーがプルリクを送っている様子を確認した。

5.3. プルリクに対する認識の相違

課題

プルリクに対してチームメンバーの2人は担当したファイルが完成しきったらプルリクを出すという認識をしていた。

対して、自分は一部の機能が実装できていなくても、下書き状態で良いからプルリクを出すことを重視していて、認識の相違があった。

対処

プルリクがこないことには開発は進まないし、手元に長くデータを置くとコンフリクトの可能性も上がるので、通話をしてその旨を伝えた。

5.4. デザインイメージの共有不足

課題

プロダクトのデザインイメージが自分とチームメンバーで大きく異なっていた。

対処

気づいたタイミングで通話を行い、片方のデザインに統一した。

6. 次回以降の課題と対処予定

最後に、途中で気づきながらも対処することが難しかったものや、他を優先して後回しにしてしまった課題を紹介しておきます。

6.1. こまめな情報共有

課題

プルリクがしばらくこなかった問題やデザインイメージの共有不足など、こまめな情報共有ができていなかったことで、いくつも課題が生じてしまった。

対処

週2のチーム会で通話する以外はあまり連絡を取っていなかったので、もっと気軽に連絡を取れる手段を事前に設定しておく。

特に今回はDiscordのチーム用チャンネルを報告などの堅い話を書くものとして使ってしまったので、それとは別でチャンネルを用意するなどが考えられる。

6.2. フォーマッタの準備不足

課題

HTML/CSSのフォーマッタを事前に設定していなかった。

対処

フォーマッタを通すことを開発ルールとして共有し、使用する設定を事前に決定しておく

6.3. Github運用ルール共有不足

課題

branch名、commitメッセージ、プルリクの書き方などの共有ができていなかった

対処

Gitの運用ルールなどを参考に、事前にどういうルールにするかを話し合っておく。

6.4. ディレクトリ構成の考察不足

課題

プロダクト作成中に一度ディレクトリ構成が変わったことで少し工数を使ったのと、ディレクトリ構成にいびつな部分ができてしまった。

対処

類似したアプリがどのようなディレクトリ構成になっているかを調べ、実際に作成したディレクトリ構成でもう少しテストをしてみる。そして、この期間をスケジュールに組み込んでおく。

7. まとめ

前々から予定を立てていたこと、小規模で軽くテストをしておいたこともあって、想定より予定が多少後ろ倒しとなっても、気持ちに余裕をもって開発を進めることができました。その結果、最終的には概ね予定通りとなりました。

しかし、進めていく中でこうしておくべきだったという点がいくつも見えてきました。特に、情報共有をもっとこまめに行っていれば防げた問題がいくつもあるというのが印象深いです。

まだアプレンティスでのチーム開発の機会はもう一度あるので、今度はその反省点を活かしていきたいと思います。

8. 最後に

初めてのチーム開発ということで、至らない点は色々とありましたが、なんとか乗り越えることができました。

この記事が少しでも、これからチーム開発を行う方の参考となれば幸いです。