ハッカソンを通じた学び ~チーム開発の面から~

Transcript

1. ハッカソンを通じた学び ~チーム開発の面から~
2. 伝えたいこと 本LTでお伝えしたい事は以下の2つです ・初めてのハッカソンで対面した問題点 ・次に向けて自分が行うべきこと
3. 目次 1. ハッカソンとは 2. なぜハッカソンの参加したのか 3. チーム概要 4. 反省点 1. GitHub ( issue / PR ) 運用の混乱 2. タスク見積もりの曖昧性 5. 得られた学び 6. 次に向けて自分が行うべきこと
4. 1. ハッカソンとは • 短期間でプロダクト（Webアプリ等）を作る開発イベント。 • 異なるバックグラウンドのメンバーがチームを組み、集中して開発。 • チーム決定から発表までを1～3日間で行うのがベーシック。 → 今回、私は初学者向けハッカソンに参加（期間：約1か月）。
5. 2. なぜハッカソンに参加したのか 目的： • 開発において他人の考え方・進め方を学びたかった。 • チーム開発の全体像を掴みたかった。 背景： • プログラミングを始めてから日が浅く（当時3か月）、自分の学習法に不安 • 仕事で開発することが目標のため、チーム開発の経験を積みたかった
6. 3. チーム概要 • リーダー1名、フロント1名、バックエンド2名の4人構成。 • バックエンドは、1年目の方と自分（プログラミング経験3か月）が担当。 • 大枠のタスクはリーダーから割り振られ、都度レビューを受けながら開発。 • バックエンド側の2人は、初ハッカソンかつプログラミング歴も浅い。 → 全体を通じて、特に目立った反省点を共有したい。
7. 4.1. GitHub ( issue / PR ) 運用の混乱 問題： • 進捗内容が追いづらく、リーダーによるフォローが困難だった。 原因： • 1PRに対し過剰な実装を行っており、変更範囲の確認にも時間が必要だった。 • issueにおいて、「タスク」と「タスク遂行中の問題」を両方管理していたため、 計画外か計画内のissueか判断が難しかった。
8. 4.2 タスク見積もりの曖昧性 問題： • 各タスクの作業日数が伸びてしまった結果、発表準備が逼迫。 原因： • 実装のタスクで処理単位の分解や、依存関係の考慮を行わず。 • その上で実装が詰まった際、大枠の見積もりで相談するか判断。 → 実装と見積もり日数で乖離が発生（1~3日）。
9. 5. 得られた学び 曖昧性がチーム開発において、大きな足枷になってしまう。 そのため、チームで最初に規約（共通言語）を作る必要性がある。 例： • issue管理方法の規定（例：タスクはJiraやNotionで管理） • PRの粒度を揃える • 相談基準の明確化（相談しやすくする目的で） • 他にもコード規約等も挙げられる...
10. 6. 次に向けて自分が行うべきこと 「個人の認識」と「チームの理解」を近付けられるようにする。 1. タスクの分解 • タスクで実装する処理内容(例：関数単位)を明確にし、依存関係を整理。 1. issue / PR の粒度統一 • 1PRに対して、1処理単位で行うこと。 • issue＝状態記述であり、タスクと区別できるように記載すること。
11. ご清聴ありがとうございました