この記事はWano Group Advent Calendar2022 18日目の記事です。
https://qiita.com/advent-calendar/2022/wano-group
はじめに
私は現在、バックエンドエンジニア兼プロジェクトエンジニアリーダーとして、半年ほどの規模のPJをチーム開発で行なっています。
現状、今回のPJが過去のPJに比べ開発がスムーズで、進捗的にもうまくいっている部分が多いです。
そこで、この記事では開発面やマネジメント面から、過去のPJでの課題を元に今回のPJで取り組んだこと・その結果を振り返ってみようと思います。
前提
チーム構成
- PJチーム: 5名（うち開発者4名）
- PdM(兼テスター) × 1
- BE × 2（うち1人PJリード兼任）
- FE × 2
開発手法
- アジャイル・スクラム開発をベースにしつつ、適宜アレンジ
- 1スプリント = 1week
【PJ開始前】
1. プロダクトのリリース後をイメージ・理解する
このプロダクトは 誰のために・何のために作るのか を具体的にチーム内で擦り合わせました。
課題
・稀にPdMの意図とずれた実装をしてしまうことがあった
・開発のモチベーションが維持しづらく、特にリリースが近づくと辛いことも
結果
・チームのモチベーションが底上げされた
・目線を合わせることにより、設計レビュー時や開発中にも 的を得た改善案が出る ことが増えた
【設計フェーズ】
2. API定義を十分に行う
APIの定義時に、異常系の場合のレスポンスなどまで詳細に定義するようにしました。
課題
・定義されていない部分の擦り合わせが不十分で、FE/BEのつなぎ込み時に手戻りなどの余計な時間がかかっていた
結果
・つなぎ込みや手戻りの時間が削減された
・エラーケースの考慮漏れや不適切なフィールド名などに設計段階で気づけた
3. 状態遷移図を書く・整理し続ける
ステータスの遷移がある場合、ライフサイクルを図に起こしてチームですり合わせをするようにしました。
課題
・初期状態の考慮はできているが、途中状態での仕様やUIなどの検討が漏れるケースがあった
結果
・各状態の時の正しい挙動の認識がメンバー間でずれにくく なった
・PJを運用していく際のドキュメントにもなり、後から見返すことができる
4. タスクを細分化する
タスクを極力分割し、2day以上の見積もりのタスクは作らないようにしました。
課題
・大きいタスクの見積もり誤差が大きかった
・タスクがスプリントを跨いでしまうことが常態化していた
結果
・見積もりの精度向上
・タスクのステータス移動がスムーズになり、進捗がより可視化されたことで遅れそうな雰囲気を事前に察知・対処できることが増えた
・プルリクエストのサイズが比較的小さくなった
5. 詳細設計を実装直前にするタスクをなくす
調査が必要なタスクなど、実装直前ではなくPJ初期に調査を終わらせ見積もりを出すようにしました。
課題
・PJ初期にざっくりと工数をとっておいて、実装時に詳細設計を詰めるようなタスクが見積もりとずれることが多々あった
結果
・PJ初期に第一感と実際のずれを認識できたことで、スケジュールに反映できた
・実装イメージがフワッとしたタスクが頭の片隅にあるといったことがなくなり精神的にも○
6. 開発に使える時間を余計に見積もらない
チーム内のコミュニケーションやコードレビューなどの非定常な時間も、ある程度想定作業量に加味するようにしました。
課題
・コミュニケーションなどの時間を開発時間に加味しておらず、実作業時間以上のタスクを積んでしまう
結果
・スプリント内にタスクが消化できることが増え、PJの進捗が安定した
7. レビュー/テストFB修正用スプリントを用意する
Week1: 開発
Week2: 開発
Week3: レビュー/テストFB修正
Week4: 開発
...
といった具合に、2:1 の割合で レビュー/テストFB修正用スプリント を組み込むようにしました。
課題
・タスクの完了タイミングが、レビューのタイミングなどの第三者要因に依存していた
・レビュー/テストFB修正 の時間を甘く見積もることが多く、PJ遅延の大きな原因になっていた
結果
・レビュー/テストFB修正を予定通り消化できることが増え、これが原因でPJが遅延することが減った
一般的なスクラム開発には反していると思うが、チームの事情もあり導入する判断に
【開発フェーズ】
8. KPTを綿密に行う
週1回1時間、チームで以下を常に行うようにしました。
- 成果報告
- 遅れた/早まった要因の深堀り
- チームとして次のスプリントからどうするかの議論
課題
・遅れの原因が不明瞭なことにより振り返りが疎かになり、再発予防ができていなかった
結果
・同じ原因で遅れを繰り返すことが減った
・各個人レベルでの振り返り・反省が習慣化した
・個人のタスクの遅れをチーム全体でカバーすることで、全体の進捗への影響を最小化しやすくなった
9. 追加タスクは可能な限り後ろのスプリントに積む
追加タスクがでた場合、すぐ対応する必要性がないものはなるべく後ろのスプリントに積むようにしました。
課題
・軽い割り込みタスクなどを先にやってしまいがちで、後に積んであるタスクに使える時間にじわじわ影響していた
結果
・進捗遅延の際に、後ろに回した優先度の低いタスクを削ってスコープ調整をするという選択肢を持つことができた
・開発スピードは良いはずなのに、スプリント単位で見ると予定のタスクが消化できていないといった状況を防げた
10. 相談には即対応
相談をする基準をチーム内で擦り合わせた
相談があれば即座にSlackのhaddle等で対応するようにした
課題
・リモートワークということもあり、軽い相談のハードルが上がっていた？（筆者の感覚）
・特にジュニアメンバーが悩む時間が、自身のタスク遅延の原因になっていた
結果
・悩まなくていい箇所に費やしていた時間が徐々に減ることで進捗の良化に繋がった
まとめ
振り返ってみると、一般的に言われていることを一つ一つ丁寧に実践していくことが大事なのだと感じました。
スクラムの理論に従うことができていない部分もまだまだあるのですが、そこはまだ伸び代があると考えて、今後は原則に従いつつチーム状況に合わせてアジャストしていくことで、より高いレベルでPJを進めていくことを目指したいと思います。
最後に、チームメンバーが皆前向きに業務に当たってくれたというのがうまくワークした一番大きな要因で、チーム含め開発チーム全体に感謝した1年でした！
1年間お疲れ様でした！
TuneCore Japan では 一緒に働くメンバーを募集しています。
エンジニアだけでなく、Director等の各種ポジションをオープンしているので興味のある方はぜひご覧ください！
https://www.tunecore.co.jp/jobs