はじめに
こんにちは！
ここでは私がチーム開発から学んだこと、教訓についての話をします。
至らぬ点もあるかと存じますが、何卒ご容赦願います。
意見・アドバイス等々、お気軽にコメントください！
私のチーム開発経験
今まで3チーム、回数は4回、年数にして1年ほど経験してきました。
この機会をいただけたこと、またそのご縁にとても感謝しています。
教訓
- 作業や課題を公開しよう
- 対人スキルは技術スキルと同等・それ以上に大切
- 縦割りはやめよう
- 「コードが書ける=偉い」ではない
- 問題解決は質問する勇気による問題の理解から始まる
サークル（１）
2022年水無月の頃、大学入学当初からサービスの開発に興味があった私はサークルに入ることにしました。サークルには様々なチームがありました。どれも魅力的でしたが、当時少し勉強していたWeb分野のサービスを開発するチームに入ることにしました。
以前からユーザーが触れる部分（UI/UX）に興味があったため、見た目に関する序盤の開発は順調に進んでいました。しかし、その先の内部処理が全く分からず、開発は停滞してしまったのです。そこで、自身の技術スキルを高める必要があると考え、個人開発を行うことにしました。
振り返ると、わからないことをオープンにすべきだったと反省しています。
サークル（２）
2023年、私が技術スキルを最も重視して個人開発に努めてから1年が経とうとしていた頃、ある案の開発にお誘いをいただきました。その案はとても魅力的で、今まで磨き上げてきた技術スキルを試す良い機会だと思ったため、参加することにしました。
開発メンバーは、高度な技術スキル1名・ビギナー4名・私でした。
ビギナー4名の内、1名はUIデザインに精通していたため、デザイナーをお願いしました。
残り3名のビギナーは、まず技術のキャッチアップを行う必要があると判断したため、勉強会を実施することにしました。（この取り組みはとても良かったと思います）
1か月弱の勉強会を終えて、本開発に進むことにしました。本開発では完成の期日を決めました。
初めは順調に和気あいあいとペアプログラミングを行っていました。タスクを作り、時間をかけてレビューを行い、教育と開発を同時に進めていました。しかし、中盤から雲行きが怪しくなりました。このままでは期日に間に合わないと判断したためです。
そこで、最低限のレビュー体制は維持しつつ、気になる部分の修正は私が行うことにしました。
結果、開発のスピードは大幅に向上しました。
これが正しいと信じていたため、この方法を継続しました。しかし、1週間も経たないうちに違和感を抱くことになります。気付けばコミットログは私で埋め尽くされており、開発のスピードと引き換えに、チームの士気を下げていたのです。メンバーは自信を無くし、開発の意欲がなくなっていました。
当時の私は「プロダクト第一」であったため、この問題を致命的だとは思わず、そのまま開発を進めました。その後、とんでもない量のタスクをこなすことになります。同時に、メンバーから学びを得る機会を失いました。
振り返ると、優先すべきはプロダクトではなく人間関係だったと反省しています。
その後、同じメンバーで新たなサービスの開発を試みました。
今度は期限を設けず、代わりに縦割りを行いました。縦割りにより、適切にタスクの分配が行えると判断したためです。
結果、メンバーの関係は悪化しました。
縦割りはメンバーを役割に縛ることと同義です。役割に縛ることで、それを全うする責任が生じます。これは精神的負担がとても大きいです。さらに、役割の特化は視野を狭めます。（属人化）
振り返ると、縦割りではなく横割の組織を目指すべきであったと反省しています。
ベンチャー企業
サークル（２）の傍ら、同時期にベンチャー企業に参画する機会をいただきました。お給料を貰いながらの開発は初めてで、とても新鮮な気持ちでした。プロジェクトへの貢献に意気込んでいました。
しかし、開発を進めるうちに、意気阻喪することとなります。Bizの要求が正しくDevに共有されておらず、仕様と実装のズレが頻繁に生じていました。手戻りと修正を繰り返し、次第にプロダクトビジョンが見えなくなっていたのです。これでは、開発が続きません。
そうした中、メンバーの1名が問題提起しました。メンバー全員が問題であることに同意し、改善に向けて意見を出し合っていました。その後、Bizも重大な問題であることを認識し、程なくして改善がなされたのです。
振り返ると、問題解決は問題の理解から始まり、質問する勇気が必要だったと反省しています。
まとめ
私がチーム開発から学んだ教訓の一覧です。
- 作業や課題を公開しよう
（スクラムの価値基準・公開） - 対人スキルは技術スキルと同等・それ以上に大切
（スクラムの価値基準・尊敬） - 縦割りはやめよう
- ❌ Component Teams
- ✅ Feature Teams
- 「コードが書ける=偉い」ではない
自分も含めメンバーには強み・弱みがある - 問題解決は質問する勇気による問題の理解から始まる
（スクラムの価値基準・勇気）
さいごに
この記事が皆さんのお役に立てれば幸いです！
今後もチーム開発のベストを模索していきます🐋
様々な失敗をしましたが、最後にチーム開発は楽しいと思えるメンバーに出会えて感謝です！
🐧
Discussion