【2022/07/04追記】
この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。
はじめに
これは何?
- スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事
- WIP制限
- タスクサイズの制限
- 死亡前死因分析
誰向けの記事?
- スクラム最初の壁であるベロシティの安定化を突破できず苦しんでいるエンジニア・スクラムマスターの方
自己紹介
こんにちは、コミューン株式会社で専任スクラムマスターを担っているヤマシタ(@yama_sitter)です。
以前エンジニアとして「自分史上過去最高の会社、コミューンに入社しました」という入社エントリーを書きましたが、入社から半年程度経ってからスクラムマスターに転身しました。 この辺りの背景はnoteの記事に記載していますので、興味のある方は是非読んでいただければと思います。
前提:「ベロシティの安定」とは
端的に「毎スプリントでベロシティが大きくブレることがない状態」を指します。 「安定化はスクラム最初の壁」といった記事を目にしますが、私も同じような印象を持っています。
※ ベロシティが少し上下する程度なら問題ありませんし、徐々に上がっていくのであればむしろ良い傾向だと思います
取り組み導入の背景
自分の所属するスクラムチームにおいて、属人性がもたらす問題が多く、それを解消したかったのが導入の理由です。実際には以下のような問題が発生していました。
- 1ストーリーに1人がアサインされるフローだったため、自分の担当ストーリー以外に深く関与せず、他のメンバーが何をやっているかがイマイチ分からない
- リソース効率は最大化されているもののフロー効率が低く、伴ってバーンダウンチャートも機能しないので、スプリントの進捗が分からない
- 進捗不明なままスプリントを終え、積み残しのストーリーが散見される
- 大味なタスク分解が行われるためサイズ感がまちまちで、ものによっては「1日の予定でしたが、3日も同じタスクをやっています」状態に
- 進捗が分からないため、デイリースクラムでは本人の言ったことを信じる他無く、「困っていないか」と質問しても「困ったことはありません」という発言に終止する
- 積み上げ式、且つ精神論的な計画
- 「とりあえずやることをタスク分解して積み上げる」という観点でプランニングが進み、リスクについてはあまり憂慮されていない
- 「何とかなるだろう」が先行し、解像度の低いスプリント後半の状況についてはあまり考えられていない
- リスクを感じていても、それが細かいものであればシェアされにくい
- 総じて、計画に対する自信の度合いがメンバーによってまちまち
「ベロシティの安定化」は課題として認識していましたが、前述の課題解決を優先していたため、正直深くは考えていなかったです。
属人性を減らす取り組みの一覧
各種取り組みの詳細と、その成果を紹介します。
① WIP制限
どうやったか
- 仕掛中にしていいストーリーを3つまでに限定
- Jira上でWIP制限ルールを適用し、守らないとアラート表示が出るようにする
得られた成果
- 1つのストーリーに対して複数人で取り組むようになり、お互いに何をやっているかがより分かるようになった
- 自分のタスクが終わったからといって別のストーリーに着手するのではなく、仕掛中のストーリーを終わらせるようサポートし合うようになった
- 1つのストーリーを集中して終わらせるようになり、バーンダウンチャートがバーンダウンするようになった
- 結果、デイリースクラムなどの場でスプリントの進捗を明確に把握できるようになる
- デイリースクラムでは「理想線から外れているからリスクがある」「理想線に近いから順調」といった話が挙がるようになり、伴って計画を見直しやすくなった
- 副次的な効果としてペアプロやモブプロが導入され、よりフロー効率が上がった
補足
WIP制限はいわゆる「スウォーミング」の考えが元になっています。 ただ仕掛中を1件にはしていないので「WIP制限」と称している次第です。
② タスクサイズの制限
どうやったか
- 1つのタスクを「6h以内」に制限するルールを導入
- 厳密に6hかどうかでなく、メンバー間で合意を取ることが重要
- Jira上で「仕掛中から1日以上ステータスが変わらないタスク」を見れるようにフィルターを作成し、デイリースクラムなどで適宜利用
得られた成果
- デイリースクラムの時に滞留しているタスクを検知できるようになった
- 伴って、順調か否かが誰の目にも分かるようになった
③ 死亡前死因分析(プレモーテム)
死亡前死因分析とは?
「スプリントプランニングで作成した計画がうまくいかなかった」という仮定を置き、その要因を洗い出すアクティビティです。 そして洗い出した要因を元に計画を見直すことで、より洗練された計画を作成することが可能です。
言ってしまえばスプリントプランニングの延長ではありますが、以下の観点で有効だと思います。
- 視点が変わることでリスクが洗い出される
- アクティビティそのものが楽しい
ちなみに私は以下の記事からこの取り組みを知りました。 私の記事ではないですが、非常に参考になるので是非読んで頂けると嬉しいです。
どうやったか
- 「プレモーテムミーティング」をスプリントプランニングの後すぐに実施
- ざっくり15分程度でスプリントの失敗要因を洗い出し、そのあと35分程度で洗い出された失敗要因を深掘っていく
- 必要に応じて計画を修正する
得られた成果
- チーム全員で、スプリント最終日から逆算して「本当にスプリントを終わらせられるか」を考えるようになった
- 失敗要因と見直しの例)
失敗要因 | 見直し |
API連携を図ろうとしているサービスの提供者が仕様を後出ししてくる | ストーリーの優先順位を上げて先んじてガワだけのAPIを作り、I/Oが仕様に則っているかをサービス提供者に確認してもらう |
チーム外のメンバーに協力を仰ぐ必要があるが、相手の時間が確保できない | スプリントバックログの優先順位を見直す、相手の時間を先に押さえておく |
実装がうまくいかない可能性がある | リスクを踏まえて逆算し、そこからタスクの締め切り日を決める |
- リスクを洗い出す時間を明確に作ったことで、小さなリスクでも共有しやすい雰囲気を作れた
- 失敗要因と見直しの例)
失敗要因 | 見直し |
バグ対応で沼にハマりそう | 2時間調査して分からなかったらすぐにチームメンバーに相談する |
DBのテーブル作成にミスる | プルリクエストの内容をテーブル作成のみに限定し、全員でレビューする、問題発生時に復旧する手順をまとめておく |
- スプリント計画に対する自信を持てるようになった
- これでもかってくらい失敗要因が出るので、それを潰すと往々にして自信を持てる計画になっている
- 結果、計画がチームの誰にとっても機能する「物差し」になる
- 洗い出しの後半は大喜利になってくるので楽しい
- でも意外と大喜利のような内容からリスクを検知できたりする
全ての取り組みの結果
得られた成果
これらの取り組みを実施した結果、これまで紹介したような「属人性の排除」だけでなく、「ベロシティの安定化」という効果を得られるようになりました!
取り組みの導入後から2週間 × 4回のスプリントを回しましたが、その全てでスプリントゴールを達成し、殆ど積み残しもない状態になっています。
何故この成果を得られたか?
何故この成果を得られたか?について1つの仮説を出しました。
「属人性の排除」とはつまり、スクラムの3本柱の1つである透明性を獲得する行為だった、ということです。 計画やプロセスから属人性を減らすことで進捗状況が明確化され、検査や適応が可能になった。 そして検査と適応の結果、「ベロシティの安定化」を実現できたのではないか、と考えています。
ある程度スクラムを解った気になっていましたが、まだまだ学ぶことは多いな…と痛感しました。スクラムは常に発見が絶えないので楽しいですね。
注意点
これらの取り組みを導入したからといって、必ず属人性を排除できる、ベロシティが安定化する、という訳ではありません。 デイリースクラムといったセレモニーをきちんと機能させることが何より重要です。
また強引に取り組みを導入するのではなく、チームで合意することが大事だと考えています。 まずやってみることは重要ですが、メンバーが意義を感じられず納得できていないものに取り組んでも、そうそう上手くいくものではありません。
ちなみに今回は割愛しましたが、「ストーリーサイズを一定以上小さくする」といった試みも有効だと思います。私達のチームでは1ストーリーが大きくても8ポイント以下になるようスライスしています。
まとめ
スクラムで「ベロシティの安定化」の壁に悩まされている方は是非、今回紹介した以下の取り組みをやってみて下さい!
- WIP制限
- タスクサイズの制限
- 死亡前死因分析
ベロシティが安定してくるとチーム全体で自信が持てますし、自信が持てると「もっとポジティブな改善アクション」に目が向くようになります。
実際にやってみて、「ベロシティが安定してきた!」「チームの空気も良くなった!」といった声を聞けたら嬉しいです。
最後に
コミューン株式会社ではエンジニアを募集中です! カジュアル面談もできますので、記事を読んで弊社のスクラムに興味を持ってくれた方、是非気軽に応募してみて下さい!