チーム開発を経て
チーム開発に参加しました！
6月は、知り合いのエンジニアの方とのご縁で、チームで簡易的なECサイトの開発に参加しました。
実際の開発フローに触れることができ、自分にとって非常に貴重な学びとなりました。
以下は、今回の経験を通じて気づいた点や、今後の学習でも意識したいことをまとめたものです。
そもそもスクラムの用語はかなり難しい
今回のチーム開発では、スクラム開発の手法を取り入れて進めました。
ただし、最初は「プランニング」「リファインメント」「レビュー」「レトロスペクティブ」など、
スクラム特有の用語や、それぞれのミーティングで何をするのかを理解するのに時間がかかりました。
今回やったスクラムの流れ
スケジュール
毎週、なるべく曜日と時間を固定して行いました。
以下は私が今回やったスクラムのスケジュールです。
- 月曜：プランニング
- 火・水曜：リファイメント
- 日曜：レビュー・レトロスペクティブ
プランニング
スプリントゴールとPBIを決める
- 前スプリントでやり残したタスクの確認
- ロードマップ・マイルストーンの確認
- 何をやるか、次は何が必要になるかを考える
- 今スプリントのタイムボックスを入力
- 前回は何時間で何ポイント終了したか
- 今スプリントでは全員で何時間取れそうか
- ベロシティを踏まえ、対応可能ポイント数を見積もる
- 前回の数字を参考に今回はどのくらい終わりそうかを計算する
- 対応するPBIの選択
- スプリントゴールの設定
- 今回やるタスクが全て終わったらどんなことができるようになるか？
- 例：「管理者が書籍を登録・編集・削除ができるようになる」
タスク設計
- PBIごとにタスクを分解する
- タスク切りをする
- 初心者でも見ればできるように、定義をIssue内に書きこむ
- これはやらない、これはこれの後にやる…などもあれば、今のうちに明確にして書いておく
リファイメント（PBIの明確化）
- PBIの内容を全員ですり合わせる
- 見て作業ができそうか？疑問点はないか？
- 受け入れ基準を明確にする
- 技術的な要件や制約を洗い出し、着手できる状態にする
- 作業工数を見積もり、作業を分割・調整する
- 優先順位を明確にする
レビュー・レトロスペクティブ
- 今スプリントで完成したもののデモ、レビューを行う
- 完成（マージ）したものだけに行う
- よかった点・改善すべき点を明確化する
- KPTの発表（Keep・Problem・Try・感謝）
- 具体的な改善策を立てて、課題の克服をする
- 同じ間違いを繰り返さない体制を作る
プランニングでのベロシティの計算
ベロシティの計算が特に難しくきつかった。
計算が苦手なので、毎回時間がかかってしまいました💦
AIを使って問題を作成したので、よかったら解いてみてください！
⚠️今回の計算方法
ポイントは基本的にフィボナッチ数列（1, 2, 3, 5, 8, 13...）を使いますが、実績を元に計算をするため、小数等他の数字を使用しています。
ベロシティ
ベロシティとは
1スプリントで完了したストーリーポイントの合計
平均ベロシティ ＝ 過去数スプリントの完了ポイントの平均
| スプリント | 完了ポイント |
|---|---|
| Sprint 1 | 10pt |
| Sprint 2 | 12pt |
| Sprint 3 | 8pt |
→ 平均ベロシティ = (10 + 12 + 8) ÷ 3 = 10pt
スプリント見積もり問題1
📝 問題
| スプリント | 作業時間合計 | 完了したタスク数 | 完了ポイント合計 |
|---|---|---|---|
| Sprint 1 | 24時間 | 5タスク | 2pt |
| Sprint 2 | 30時間 | 6タスク | 3pt |
| Sprint 3 | 18時間 | 4タスク | 1.5pt |
次のスプリントでは、27時間の作業時間が使える見込みです。
🧮 計算問題
- 平均ポイント数（1スプリントあたり）を求めてください
- 1pt あたりの平均作業時間を求めてください
- 次のスプリントで完了できそうなポイント数を予測してください
- タスク1つあたりの平均ポイントを出してください
- 次スプリントで何タスク終えられそうかを予測してください
| 作業時間合計 | 完了したタスク数 | 完了ポイント合計 |
|---|---|---|
| 72時間 | 15タスク | 6.5pt |
1時間では 0.2タスク 0.09pt
✅ 1. 平均ポイント数（1スプリントあたり）
6.5 ÷ 3splint = 2.16pt
答え：2.16pt
✅ 2. 1pt あたりの平均作業時間
合計作業時間：
24 + 30 + 18 = 72時間
合計ポイント：
2 + 3 + 1.5 = 6.5pt
計算式：72 ÷ 6.5 = 約11.08時間/pt
答え：1pt あたり約11.08時間
✅ 3. 次スプリントで完了できそうなポイント数（27h使える）
27 ÷ 11.08 ≒ 2.43pt
または、27*0.09=2.43pt
答え：2.43pt
✅ 4. タスク1つあたりの平均ポイント
合計タスク数：5 + 6 + 4 = 15タスク
合計ポイント：6.5pt
6.5 ÷ 15 = 約0.433pt/タスク
答え：約0.433pt/タスク
✅ 5. 次スプリントで完了できそうなタスク数
使えるポイント：2.43pt
タスクあたりのポイント：0.433pt
2.43 ÷ 0.433 ≒ 約5.6タスク
答え：5〜6タスク
| 質問 | 答え（概算） |
|---|---|
| 平均ポイント（1スプリント） | 2.16pt |
| 1ptあたりの作業時間 | 約11.08時間 |
| 今回見込めるポイント | 約2.43pt |
| 1タスクあたりの平均pt | 約0.433pt |
| 完了できそうなタスク数 | 約5〜6タスク |
スプリント見積もり問題2
📝 問題：メンバー別作業時間を考慮したスプリント予測
あなたのチームは4人で構成されています。
以下は、直近のスプリント実績です：
🔙 前回スプリントのデータ
| メンバー | 作業時間 |
|---|---|
| Aさん | 12時間 |
| Bさん | 10時間 |
| Cさん | 8時間 |
| Dさん | 10時間 |
- 完了したタスク数：10タスク
- 完了したポイント：5pt
💡 次のスプリントでは：
| メンバー | 予定作業時間 |
|---|---|
| Aさん | 14時間 |
| Bさん | 12時間 |
| Cさん | 10時間 |
| Dさん | 12時間 |
🧮 問題
- チーム全体の作業時間（前回）と、1ptあたりの作業時間を求めてください
- 1タスクあたりの平均ポイントを求めてください
- 次のスプリントの合計作業時間を求めてください
- 次のスプリントで完了できそうなポイント数を予測してください
- 次スプリントで完了できそうなタスク数を予測してください
✅ 答え合わせ
1. チーム全体の作業時間（前回）と、1ptあたりの作業時間
12+10+8+10 = 40時間
40 ÷ 5pt = 8時間/pt
2. 1タスクあたりの平均ポイント
5pt ÷ 10タスク = 0.5pt/タスク
3. 次のスプリントの合計作業時間
14+12+10+12 = 48時間
4. 次のスプリントで完了できそうなポイント数
48 ÷ 8 = 6pt
5. 次スプリントで完了できそうなタスク数
6pt ÷ 0.5pt = 12タスク
まとめ
| 項目 | 値 |
|---|---|
| 前回の1ptあたり作業時間 | 8時間/pt |
| 1タスクあたりの平均ポイント | 0.5pt |
| 次回スプリントの作業時間合計 | 48時間 |
| 次回の完了見込みポイント | 6pt |
| 完了見込みタスク数 | 12タスク |
セルフレビューをしてからPRを作成しているか？
今回がほぼ初めてのPR操作だったため、最初はかなり戸惑いました。
他のPRのマージ忘れなどから、意図しないファイルがFiles changed に紛れてしまうことが何度かありました。
この経験から、PRを出す前に「自分が本当に修正したものかどうか」を確認し、不要な差分は取り除く必要があることを学びました。
セルフチェック・レビュー前に確認すること📝
- タイトルは適切か
- レビュワーが見やすいように変更点を説明できているか
- いらないファイルが紛れてないか
- 動作確認ができているか
- コードが正しく修正されてるか
- テストが通っているか、CIのエラーが出てないか
- コンフリクトがないか
- 不要なコメントや文字列が入ってないか
- 課題が解決しているか
- セキュリティ的に問題がないか
- ベストプラクティスはないか？もっと簡単な書き方はないか？
PRをOpen後、コメントの返信する際も再度セルフレビューすること！
ただ、最初のレビュー前に確認できていても、レビュー対応のやり取りの中でこれらが崩れてしまうことがあるため、修正を加えたら再度このチェックを繰り返すことが大事だと感じました。
参考
セルフレビューに30分使うこともある。
早くやることがいいのではない。
言葉を正確に使う
自分では伝わっているつもりでも、他の人には何を指しているか分からないことが多くあります。
そのため、画面に表示されている文言をそのまま使ったり、スクリーンショットに直接書き込んだりして、誰が見ても「どこを指しているのか」が明確に伝わるよう意識しました。
参考
早くやるより時間をかけてでも丁寧にやる
開発では「早く出す」よりも「丁寧に確認して仕上げる」ことが大切だと実感しました。
PR（プルリクエスト）が main にマージされるまでには、意外と時間がかかるもので、
実際に「1つのPRに対して1〜2週間かかることもある」とアドバイスを受けました。
そのため、急いでPRを出すよりも、自分の中でしっかりレビューしてから提出することが、結果的にスムーズな進行につながると感じました。
また、意外とエンジニアはコードを書くよりも「調べる時間」の方が長いことも多いと実感しました。
何かエラーが出たときや、実装方法に迷ったときなど、「すぐに書く」のではなく、「どう書くのが最適か」を考えながら情報を探す力が求められると感じました。
参考
最後に・参加してくださった皆さんへ
皆さん業務やプライベートでお忙しい中、お付き合いいただき本当にありがとうございました。
私自身、知識不足でご迷惑をおかけした場面も多かったかと思いますが、温かくサポートしていただき、とても感謝しています。🙇
これまでは主に個人で学習していたため、チームで開発することや、GitHub上で他人にレビューされる前提でコードを書くという経験が少なく、「自分の書いたコードは他人から見てわかりやすいか？」といった視点もありませんでした。
今回のチーム開発を通じて、「人に見せるコードを書く意識」や、「自分の調べ方を見直すこと」の大切さに気づくことができました。
学びの多い、貴重な機会をくださり、本当にありがとうございました！
余談
今までは毎日更新していたZennですが、これからは毎月更新を目標にしていこうと思います！🍀😌
Discussion