未経験者3名が集まったチーム開発で学んだこと



## はじめに
私を含め、未経験者3名で共同で3週間アプリケーション開発を行いました。
この期間で非常に学ぶことが多く、貴重な体験をしました。
私自身のチーム開発の振り返りを目的としていますが、未経験者だけど共同で開発してみたいという方の参考になれば幸いです。
## 目次
* 参加した理由・経緯
* 開発期間
* プロジェクト開始時の状況
* チームで行ったこと
* チーム開発で学んだこと
* チーム開発で苦労したこと
* まとめ
## 参加した理由・経緯
**理由**
* 他の人のコードを見ることで新たな学びを得たかった
* チームで開発する経験をしてみたかった
* 一緒に学習する仲間が欲しかった

**経緯** 
MENTAという個人間で相談できるメンターを探せるサービスで知り合ったフリーランスのエンジニアの方にチーム開発を進められ、その方が主催するもくもく会のメンバー2人と開発することとなった
## 開発期間
2022年8月13日～2022年9月3日
## プロジェクト開始時の状況
- 大学3年21歳
- ProgateでHTML、CSS、JavaScriptを一周
- その後、学生向けのプログラミングスクールで３カ月間Laravelを用いたオリジナルのアプリケーションの作成
## チームで行ったこと
### 完成の定義・リリース日を定めた
プロジェクトが開始してすぐにチームでアプリケーションの必要機能などの完成の定義の認識合わせを行い、その目標が完了する期限を定めました。
### torelloを使ったタスク管理
タスク管理するうえでチームで意識したこと
- タスクを細分化する。（ex.わからないことを調べることもタスクとして扱う）
    - チームメンバーに自分がやっている内容が伝わりやすくなる
    - 1つずつのハードルが低くなり、達成感を得やすくなる
- タスクを分担するのではなく、チームのタスクを全員で消化していく方法を取った。
    - 特定のメンバーに作業が偏ることを防止
    - チーム間で作業量を把握できる
### 毎週の振り返り会
一週間の振り返りをチーム全体で行う会を設けました。振り返り会ではKPT法という振り返りフォーマットを用いました。


> **KPTとは**アジャイル開発や反復型開発ではイテレーション（繰り返しの単位）ごとに作業の振り返りが推奨されるが、そのためのチーム反省会などでよく用いられるフォーマットである。
> 

KはKeep、PはProblem、TはTryをそれぞれ表します。イテレーションの単位でチームで振り返りを行い、良い点（Keep）、問題点（Problem）、具体的な改善項目（Try）を軸にミーティングをします。基本的な流れは、Problemが具体的なTryになり、Tryが解消したら、消える。またはKeepに昇華します。

引用：[チームでKPTをやってみました - Wantedly Engineer Blog](http://engineer.wantedly.com/2015/04/01/sync-kpt.html)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2823771/00b5946b-2097-96b1-83b7-7bbcd6c27f95.png)
**実際に出たKPT事例**
**P**：不明な点に対して一人で悩みすぎて、分かる人に相談、コミュニケーションを取ることが遅れてしまったことによるタスクの遅延
**T**：作業をするときは基本的にDiscodeのもくもくのボイスチャンネルに入って作業を行い、わからないことがあったらすぐに聞く
**K**：Tryで行ったことにより、Pが改善されたら継続的に行うようにした

### 反省会から新たに行ったこと
**1. 朝会**
毎朝10時に「昨日やったこと」、「今日やること」、「障害となっていること」を共有しました。
チームメンバーの進捗やつまずいている点が明確になり、チームのコミュニケーションがとりやすくなりました。また、タスクの進捗状況を朝に知れることで一日のタスクの管理の見積もりが立てやすくなりました。
**2. モクモク部屋での作業**
Discordのボイスチャンネルに入って作業することを定めたことで、分からないことや疑問点があったらすぐにチームメンバーに質問できる環境を作りました。
**3. 作業できる時間の共有**
エクセルでメンバーの作業できる時間帯を共有しました。結果メンバーに質問できる時間の把握やチーム全体のタスクの見積もりが立てやすくなりました。

## チーム開発で学んだこと
### ①共同開発のフローを知った

**環境構築**

Dockerを使ってチームのメンバーと開発環境をそろえる

**開発**

ブランチを切って、メンバーそれぞれが作業→機能が実装出来たらPRの作成→レビューをもらう→修正作業を行い再度PR作成→レビューで承認が出たらmainブランチへマージ→コンフリクトの解消するといった開発フロー

### ②CUIを意識して作業する習慣がついた

共同開発開始以前は、コマンドを用いた作業していなかったが、チームのメンバーに指摘をいただいたことをきっかけに少しずつコマンドを用いた作業が行えるようになりました。

### ③自分の知らなかった知識を知るきっかけとなった

自分の書いたコードをより短く簡潔にまとめる記述方法をチームメンバーから教えていただいたり、メンバーの書いたコードから新たな学びを得ることできました。

### ④エラーが出たときの対応
エラーが出たときに画面共有をしながらメンバーとエラー対処をすることが多々あったのですが、デバックの仕方や検索のかけ方、問題を切り分けてエラーを対処する考え方など非常に参考になる場面が多かったです。
## チーム開発で苦労したこと
### ①自分の考えを相手に伝えること

チーム開発で自分が最も苦労したことです。開発期間中は実装のイメージの共有、わからないことに対する質問と返答、タスクの見積もりや反省会など様々な場面でチームメンバーとコミュニケーションをとる機会が多かったです。チーム開発以前は個人で作業していたため、開発時に人とコミュニケーションをとる機会がなかったため、非常に難しく感じました。

以下の二点が苦労した主な原因であると感じました。

- **知識不足・あいまいな理解**
    
    APIの設計手順をメンバーに伝える際に、自分の頭の中ではイメージがついてることも言葉が詰まり相手にわかりやすく伝えることが出来ないときがありました。そこで今までの自分の理解があいまいなまま実装に着手してしまっていたことを痛感しました。
    
    相手に自分の意図や説明を明確に伝えられることは一種の理解の基準になるのではないかと感じたので、このことを念頭に置きながら今後の学習を進めていきたいと考えています。また、知識の面に関しても基礎的な概念や専門用語の意味の理解の欠落があると感じ、今後の学習する内容や方法を考え直す良い機会となりました。
    
- **伝え方（あいまい表現）**
    
    コードレビューをいただいたエンジニアの方から伝え方に対して指摘をいただく場面がありました。
    
    - **実際のエピソード**
        
        **{エンジニアの方}**：今日が終わるころには何のタスクが完了していますか？
        **〔私｝**：○○のタスクが大体これくらいに終わると思うので、おそらく何時ころに○○機能が終わっていると思います。
        
         →機能の実装が終わるのか、PRを出した状態なのか、テスト環境で動作確認した状態なのかが伝わらない。なぜ○○の機能が終わるのか根拠もないと指摘を受けた。
        
    
      **〔良い例｝**：○○時に○○さんに○○の機能を実装したPRを出します。なぜなら、○○のタスクが～～な理由で○○時間ぐらいかかるので・・・
    
    <ins>このように相手に伝えるときは**具体的**かつ**根拠**を添えることが重要だと感じました。
    
### ②タスクの見積もり
個人での開発と違いチーム開発は、それぞれスキルの違うメンバーが集まって作業をするので、メンバー個人がタスクをどれくらいの時間で終わらせることが出来るのか見通しが立たない状況でした。そのため、チームとして毎週1週間のタスクの見積もりを考えることは非常に難したかったです。ましてや未経験者3人が集まっているので、初めて触れる技術がほとんどで知識のキャッチアップに想像以上に時間がかかったり、予期せぬエラーが発生しタスクの遅延が生じることが多々ありました。その状況下で、キャッチアップの時間にどれくらい時間がかかるかをあらかじめタスクに加味したり、タスクの遅延が生じた際のその後の対応をメンバー間で話し合うことで、プロジェクトを何とか進めることが出来ました。
### ③環境構築、予期せぬエラーの対応
***環境構築***
今回はチーム開発ではDockerを使った環境構築を行いました。主にチームメンバー一人が環境構築を行い、私はレクチャーを受けるといった形でしたが、レクチャーの理解をするのも一苦労でした。まず、Dockerとは何かということから始まったため、自分一人で実装できる段階まで理解が進まなかったのが現状です。自分の理解力のなさから時間がかかり、メンバーに迷惑をかけてしまうことがありましたが、それでも快くレクチャーいただいたメンバーには感謝です。
**予期せぬエラー**
githubに誤ったファイルをpushしてしまい、PRを消去したのですがcommit履歴が残ってしまったため、commit履歴を改ざんする作業を行いました。インシデントの対応でタスクの遅れが発生し、非常に大変でした。

## まとめ
3週間ではありましたが、非常に有意義な経験を得ることが出来ました。共同開発ではメンバーとのコミュニケーションの中で自分が劣っているスキルや知識などが見えてきます。これは個人で開発していると気づかないことなので、自分の足りないスキルを見つけるという点で共同開発は非常に有効だと感じました。また、毎朝集まって作業することで学習のモチベーションを維持にもなるので非常におすすめです。
エンジニアとして将来活躍できるように共同開発で感じた自分の足りないスキルを重点的に学習し、残りの学生生活の学習をしていきたいと思います！
最後まで読んでいただきありがとうございましたm(__)m