メンバー目線から見たスクラム開発の本音
みなさん、スクラム開発してますか？
今回は、約2年間スクラム開発に携わって感じたことを、チームメンバー視点で率直にまとめてみました。
どんなスクラムをやっていたか
スクラムとひとくちに言っても、チームごとに運用方法はさまざまです。
参考までに、私たちのチームでどのようなスケジュールで開発していたかをご紹介します。
| 項目 | 内容 |
|---|---|
| チームメンバー | 5〜6人 |
| 拠点 | リモート＋オフィスのハイブリッド体制 |
| スプリント | 1週間 |
イベントの一覧
- デイリースクラム（15~30分/日）
- 相談会（30~90分/日）
- スプリントレビュー（1回/週）
- レトロスペクティブ（1回/週）
- スプリントプランニング（1回/週）
- リファインメント（1回/週）
1週間の流れ
イベントを1週間にマッピングすると、こんな感じです。
※相談会は必要に応じて開催しています
最初に感じたのは、「1日中ミーティング？」「開発に使える時間少なすぎない？」ということでした。
さらに、これに加えてスクラムイベント以外の打ち合わせも発生するため、実際に開発できる時間はかなり限られています。
開発に充てられる時間短いな・・ が最初に感じた率直な意見でした。
スクラムの「よかった」ところ
内容に入る前に、スクラムを離れてみてあらためて感じた良さを挙げていきます。
スキルギャップを埋めやすい
開発チームには、経験豊富なベテランと駆け出しの新人が混在しているのが普通です。
当然、ベテランの方がスピードも生産性も高いわけですが、新人がそこに追いつくにはどうすればいいのでしょう？
- 手が止まりそうな時に的確に相談できる
- ベテランが気づいてフォローする
といった動きが求められますが、これは高いコミュニケーション能力が必要です。
特にリモート環境下では、より難易度が上がります。
その点、スクラム開発では相談しやすい環境が自然とできあがるため、仕組みの力でコミュニケーションの壁を乗り越えることができます。
しっかりと受け入れ体制の整ったスクラムはメンバーの入れ替わりがあっても機能すると感じました。
開発効率が高い
しっかり見積もりを行うことで、無駄の少ない開発ができます。
言い方を変えると「隠し事ができない」とも言えますが、それによって進捗の遅れにすぐ気づけて、フォローしやすいというメリットがあります。
もちろん、見積もりの粒度が粗いとこの効果は得られません。
よくある失敗として、「バッファ」という謎の時間が生まれるケースがあります。
見積もりが甘い＝やることが曖昧、という可能性が高いため、チームで認識を合わせてタスクの明確化が必要だと思います。
スプリントレビューでの品質向上
スプリントレビューでは、実装した機能を実際にチーム全員で触ってみることで、リリース可否を判断します。書面のレビューではなく、「動くものを見る」のがポイントです。
実際に触ってみることで、
- 要件に落としきれていなかった点
- テストで漏れていた不具合
などが浮き彫りになり、短時間でプロダクトの品質をグッと上げることができました。
内容は地味ですが、毎回多くの改善点が見つかるため、非常に重要なイベントだと感じています。
どのようなスクラムイベントをしていたか
ここからは、各イベントの目的と、チームで実践していた工夫をご紹介します。
デイリースクラム
何をするか
- 昨日の作業・今日やることの共有
- 進捗状況の把握（早め／予定通り／遅れ）
- 相談事項の共有（あれば）
コツ
相談事項がある場合は、デイリースクラム後の相談会で問題を解決します
もし、相談会で解決できなければ、
- 余裕のあるメンバーにタスクをお願いする
- 難しければ、タスクの一部を次スプリントに回す
（例：テスト実施まで完了する予定だったが、テスト実施は次スプリントとする）
タスクを減らすことになった原因はそのままにせずにレトロスペクティブの課題として扱いましょう。
ここで大事なことは進捗が遅れたまま、ずるずると時間を消費しないことです。
相談会
何をするか
- 相談事項があればチームで集まって解決する
リモートでは「ちょっと聞く」が難しいですよね。
昔のように、席を立って声をかけることはできません。
相談会という時間が確保されていることで、「聞きたいけど、わざわざ時間取るほどではない」といった心理的な障壁が解消されます。
これによって「ちょっと確認したいこと」が聞きやすくなり開発効率が向上します。
コツ
- 相談会は開催必須ではない
- 誰も相談事項がなければなしでOK
- 運用方法は多々あるが、チャットツールに定期的にポストする仕組みを実装し、それにスタンプやスレッドで反応する形式が簡単
スプリントレビュー
何をするか
- 1週間の成果物をみんなで確認する
自分の成果物ができたら、開発環境や検証環境にデプロイしておき、みんなが確認できるように準備しておく
コツ
- 「触る時間（3分）」と「話す時間（10分）」を明確に分けると◎
- チームで触って「もっとこうしたほうがいいね」となれば、さらによいものができあがる（やったね！）
- チームで触って「これバグじゃね？」みたいな挙動が見つかれば、障害が減る（危なかったね！😮💨）
レトロスペクティブ
何をするか
- 1週間のスプリントの中で課題だったポイントをあげて、今後「どうすればもっと楽しく開発できるか」をみんなで話し合う
- レトロスペクティブの手法はいろいろあるので、調べてみるとよい
参考：レトロスペクティブの手法まとめ
コツ
ぶっちゃけ、一番むずかしいイベントだと思います。
意見が出ず、シーン…となることもしばしば。
これが原因でスクラム嫌だとなっている人も多いんじゃないでしょうか。
-
話しやすい環境づくりが超大切！
- 最初の時間にアイスブレイクの時間を設ける（序盤に全員ちょっとずつでも発言する）
- オフィスでひとつの部屋に集まって開催する
- ファシリテーターが話しすぎない（ファシリ＋もう1人くらいだけがずっと会話している状態は避ける）
- リモート環境ではうまくいかないこともある（リモートだと他の人の会話に入りづらくて「まあ話さなくてもいいか」になりがち）
- エンジニアは話すのが得意な人ばかりではないけど、お互いに興味を持つように努力すれば、意外と楽しいイベントになるかも
- なにも課題がなかったのに無理やり捻り出した議題は空気が凍りがちなので気をつけましょう
スプリントプランニング
何をするか
- 各々の今週の作業可能時間を算出する（例：20時間など）
- プロダクトバックログの上から順に、メンバーに作業を割り振る（例：機能Aのフロントエンド実装）
- 各々でタスクを細かく分解して、作業時間を見積もる（例：デザイン実装6h、ロジック実装6h、計測実装3h、テスト実施3h など）
- 分解したタスクをメンバー間で共有し、タスクの抜け漏れがないか確認する
- 最初に算出した作業時間から溢れてしまった場合は、タスク量を調整する（例：テスト実施は次のスプリントに回すなど）
コツ
- 全員が全員のタスクを完全に把握するのは、時間的にも精神的にも不可能
- 領域ごとに分かれて見積もりを行う
- BE領域／FE領域／インフラ領域など
- 各領域（例：3人）で集まる
- 割り振られたプロダクトバックログアイテムを各個人でタスクに分解する(10分)
- タスク分解結果を一人ずつ共有していく
- 共有結果で抜け漏れがあれば、タスクに追加していく
- 精緻で細かい見積もりが完成
- BE領域／FE領域／インフラ領域など
- 各タスクの見積もりは長くても2hにする（長すぎる場合はタスクを細かくする）
（例：NG 実装10h → OK デザイン実装4h ロジック実装4h 計測実装2h）
さいごに
スクラムのやり方は、チームの数だけ存在すると思っています。
大切なのは、そのやり方が「チームに合っているかどうか」。
合っていなければ、どこかで誰かがつらくなってしまいます。
最初は苦しいですがチームが成長して自走できるようになれば、開発者体験もよく、品質も上がり、変化にも強いチームが出来上がります。
自分たちに合ったやり方を模索しながら、楽しく開発していきましょう☺️
参考
Discussion