スクラム実践入門
スクラムについてしっかり学んでおきたく、技術評論社から出ている『スクラム実践入門』を読むことにしたのでその記録です。
この本の
- 6章ではGMOペパボの
- 7章ではmixiの
- 8章ではDeNAの
事例が書いてあるので、その事例について気になるところを要約して書きます。
GMOペパボの事例
- まずはとにかくプロダクトバックログを洗い出した
- 大量のバックログが出た
- 量も問題だが、優先順位がぜんぜんわからん
- やばいということがわかっただけでも良かった
- スプリント
- スプリントは1週間（5営業日）だが、スプリントレビューとスプリントプランニングで1日潰れるので実質4日
- デイリースクラム
- 「昨日したこと」「今日やること」「困っていること」を一人1分で
スクラム導入でわかったこと
- 見えるか化は偉大
- コミュニケーションツールとしてのスクラム
- 不具合対応を交代制にして、日誌にまとめた
- 割り込みタスクはある程度許容する
- スプリントプランニング時には無いが仕方がない
- 仕事の仕方を全社で共有する
mixi の事例
もともと
企画と開発が別れていて、詳細なドキュメントを通じてやり取りしていた。このドキュメントには「なぜ」の議論はなく、「なぜ」の部分は企画チームの間でのみやりとりされていた。
開発は5人程度、企画は3人。スクラムガイドを斜め読みした程度の知識でスタート。
始めた時の課題
- スプリントは1ヶ月
- スプリントプランニングが難航
- 「1ヶ月でこれをやります。これ以外のことはやりません」というと企画に納得してもらえない
- スプリントが終わると大量の問題点が上がり、レトロスペクティブに無限の時間が
- ギリギリ終わらないタスクが有るとスプリントが伸びてしまう
- スプリントは基本的にタスクに依存してはならず、伸ばすのはNG
- スプリントを導入した目的がよくわからず、マンネリ化
スクラムの本質を学ぶ
他のチームもスクラムが気になっていた。現状に漠然とした問題意識はあったようだ。
本格的にスクラムを学ぶべく、スクラムマスター研修へ参加した。「スクラムとはソフトウェア開発をチームスポーツのように進めていくもの」であると学ぶ。ルールの中でどう勝つかを考えるゲーム。
改めて始めるスクラム
- スクラムの目的の設定
- 属人化の排除
- 正しくプロダクトバックログを作る
- 企画チームは、仕様書ではなくプロダクトバックログをしっかり作る
- 結果的に企画と開発の対話の機会が増えた
- 今何が必要なのか、ということだけを考えて優先順位を決める。開発チームの状況は考えなくて良い
- 開発チームは様々なタスクをこなす必要性が出てきて、属人化が減った
- 企画チームは、仕様書ではなくプロダクトバックログをしっかり作る
結果モチベーションの向上につながった
現状
スクラムマスター不在のチームが多いらしい
- スクラムの進め方が浸透しているため
- スプリントレトロスペクティブの際など、必要になることもある
- スクラムチーム同士のコミュニケーションが行われている
DeNAの事例
- DeNAでも始めはうまく行かず、認定スクラムマスター研修を受けた
- 開発のリードエンジニアがスクラムマスターを兼任するのをやめ、別にスクラムマスターを立てた
- スクラムマスターは複数のチームを掛け持ちさせた
- 技術的負債返済スクラムチームと、テスト環境や開発環境の改善スクラムチームを立てた
大規模スクラム
30名を超える規模のスクラム
「スクラム・オブ・スクラムズ」という、スクラムを大規模チームに応用する考え方のもと行った。
- スクラムチームの階層化
- プロダクトバックログの分割
- スクラムチームの分割
業務委託スクラム
1週間に1回、完成したインクリメントのレビューと、スプリントバックログの合意。
まとめ
スクラム導入のモチベーションとして、ほとんどが「属人性の排除」を上げていたので、この点を問題として抱えている場合はスクラムを検討してもよいのかもしれない。
