
# チーム開発のすゝめ

この記事は[共同開発鯖 Advent Calender 2021](https://qiita.com/advent-calendar/2021/growthers)の12日目の記事です

## 書いてる人

こんにちは。鈴鹿高専２年生の@Re-taroです。
テストの前後どちらも大会という地獄のデスマーチの合間を縫って執筆してます。

## はじめに

みなさんは**チーム開発**というものをしたことがありますか？
私は今年に入って初めて同級生とアプリを制作して大会に出ました。
そこで学んだことなどを踏まえてこの記事を書かせていただきます。
思想強めです。ご了承ください。

## 個人開発の場合

### 利点

- コミュニケーションコストがかからない
    - 趣味での開発の際、コミュニケーションを交わすことがありますか？私はありません。

- 自分のペースで開発ができる
    - 個人的な感想ですが、私が個人開発が好きな理由はこれにあります。判断や調整が自己完結するのは素晴らしいと思います。

### 問題点

- 一定規模の開発までしかできない
    - 三人寄ればなんとやらというように、スキルや物理的に可能な作業量が限定されるのでスケジュール上の問題が次第に発生してくると思います。

## チーム開発の場合

### 利点

- 新しい技術の導入も期待することができる
    - あなたの周りを見渡してみましょう。あなたとは違うことができる人がうじゃうじゃいますね？そういう人と組んで開発をしてみましょう。

- 楽しい
    - 正直な話、これに尽きます。一つのプロダクトを協力して開発するというのはとても楽しい体験だと感じます。

### 問題点

- コミュニケーションをスムーズに取るのが難しい
    - 開発のメンバーとのコミュニケーションが疎かになってしまうと、課題の共有、進捗、スケジュールの管理などに支障が出てしまいます。

- 差分や品質の管理が大変
    - 個人で開発しかしたことがない友人に尋ねると、ブランチを切ったこともマージしたこともないとのこと。私も意識して差分管理を行ったことがなかったため大量に競合を発生させました。また、今どのコードが正常に動作するかわからなくなるという自体も発生しかねます。

**コミュニケーション・差分管理・品質管理**。この３つの課題を解決するためにはどうすればいいかを書いていきます。

## 理想的なチーム開発

### コミュニケーション(MTG)が多い

- 最低でも週に2回はMTGをするべきだと私は思います。例を挙げると進捗の集まる日曜日と水曜日に進捗報告や課題、タスクを共有する。という感じです。

### VCSが適切に使用されている

- ソースコードが適切に管理されている。またドキュメントなどの設計書も整理されている。ブランチ、タグが適切に利用されていることで、バグ対応版、最新リリース版等がすばやく検索できる。などです。

### CIが導入されている

- 自動的にビルド、単体テストを実行し、チェックをすることで、コミット漏れや修正ミスにすぐに気付くことが可能で、コードの品質を保証できます。

## コミュニケーション

### プラットフォーム

正直色々なものがありますが、私はDiscordを推しています。理由としては、

- Webhookを用いて(後述する)GitHubと紐付けることが可能。

- 基本的にすべてのサービスを無料で使える。
    - Slackなどもいいと聞きますが、音声通話が有料プラン限定なので今回は見送りました。

などです。

### MTG

グループチャット機能を用いて積極的にMTGをしましょう。議事録などは取っておくと後で見返せて鬼のように便利です。
全体でのMTGの他にフロント同士などで頻繁に進捗は共有しておきましょう。
余談ですが、テキストちゃんねるにtimesを作っておくと、開発が終わったあとに見返せてとてもいいです。

[timesとは](https://note.com/vaaaaanquish/n/ncc512cf0e263)

実際の様子
![preview](https://i.imgur.com/E9U6YHz.png)


### チケット管理システム

タスク管理をするためにはかかせません
導入には以下のメリットがあります。

- 「何をしなければならないのか」が定義できる

- 「誰がするのか」という担当者のアサイン

- 「いつまでにするのか」という期限を決められる

- 「今どうなってるのか」というステータスを管理できる

- 情報の一元管理と共有が可能

### プラットフォーム

こちらもたくさんのシステムがありますが、私はGitHubを推しています。GitHubでチームのOrganizationは建ってますか？建っていなかったら、[こちら](https://docs.github.com/ja/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch)から建てましょう。
このOrganizationの中でProjects↓
![preview](https://i.imgur.com/svkODpP.png)
を押してチケット管理を始めましょう。詳しくは[こちらの記事](https://qiita.com/itkr/items/0d4c0015da28827b2bb7)が詳しく解説しています。

## 差分管理

### How to 差分管理

いろいろ意見はあると思いますが、私はGitとGitHubを用いてます。
以下が開発の流れです。

- まずはmainブランチからはじめる
    - ローカルリポジトリでmainブランチに入る
    - リモートリポジトリでmainブランチの更新があるか確認する
- featureブランチで開発
    - featureブランチを切る
    - 開発する
    - 変更点をローカルリポジトリでcommitする
    - リモートリポジトリへpushする
- Pull Requestを出す
    - PRでレビューをしてもらう
- 最後にmainブランチへmerge
    - PRのレビューが終了したら、mainブランチへmergeする

です。

### ポイント

- 単純ですが、ちゃんとしたPRを出す・コンフリクトを防ぐためには必須です。
    - とにかく、コードを変更したくなったら、必ず一度mainに戻ってからブランチを切り直す癖をつけてください。
    - この一行を忘れて変なブランチから開発することで、コミット履歴がめちゃくちゃになります。git pullもgit diffも使い物にならなくなります。
    - コンフリクトを退治してたら日が暮れたとか悲惨なことになります。忘れないでください。

- mainブランチをルールで保護することをおすすめします。
    - (後述する)CIが通るまで。や、開発メンバーからレビューをもらうまで。などすることでコードの品質を保つことができ、また進捗の確認共有にも繋がります。

## CI

### CIとは

CIとは継続的インテグレーションの略でコードの変更をリポジトリにマージし、定期的・自動的にビルド・テストする手法のことを指します。詳しくは[こちらを](https://zenn.dev/t_kitamura/articles/8e32d83e24a76d)ご覧ください。

### 導入するメリット

CIを導入するメリットはコードの品質を保証するところにあります。
PRにあるそのコードを、私達は常々目視でレビューしますが、それが実際にビルドできるか、また正確に動作するかを保証するすべはありませんよね？CIを回すと、私達の手間とならずにテストやビルドを自動でできるようになります。

### How to CI

まず**ブルジョワ**のみなさん！[Jenkins](https://www.jenkins.io)や[Circle CI](https://circleci.com)などを使い倒しましょう。私は使い切れないので使ってませんが、、、。私のオススメはGitHub Actionsを使うことです。詳しくは[こちら](https://qiita.com/vZke/items/868eb9fd5289d2a25660)の記事で分かりやすく解説されています。

### ユニットテスト

ユニットテストとは，クラスや関数といった単位のプログラムのテストになります。
主に設計通りにこれらが動くかをテストし，論理構造が適切かを確認します。

- 機能確認テスト
    - 1つのモジュールが設計書や仕様書通りに動作することを確認するテスト
- 制御フローテスト
    - プログラムの論理構造に沿って，「命令」や「分岐」などが実行されるかを確認するテスト

などがあります。

### 結合テスト

結合テストとは，単体テストで検証したプログラムを組みわせて行うテストになります。

- 状態遷移テスト
    - 状態遷移図や状態遷移表に基づいて動作を確認するテスト

## おわりに

見返すといろんなリンクへ飛ばすだけのものとなってしまっていた、、、文章書くのって難しいですね。
