前職のスクラムが神がかっていたので忘れないうちにまとめる

どんなエントリ？

コニチハ、経営管理クラウド ログラスのエンジニアの佐藤です。

前職（ビズリーチ）チームのスクラムが社内でもトップクラスの完成度だったので忘れないようにまとめようと思います（事実上の退職エントリ）。

スクラムの知識を前提としてスクラムイベントで気をつけていたことを順番に書いていきます。

注意: ここで書かれていることはあくまで前職のチームでは、ということなので、公式のスクラムガイドで明確に定義されていることから逸脱している可能性があります。

リファインメント

リファインメントは1週間スプリントに対して週2時間固定で行います。POとステークホルダーであるデザイナーとチームメンバーが参加します。

リファインメントのゴールは以下の3つでした。

1. PBI（チケット）の受入基準を明確化する
2. ストーリーポイントを見積もる
3. 3pt以上のPBIを可能な限り分割する

リファインメントのイメージは薪割りに似ています。課題という巨大で曖昧な薪を細かく割って不確実性の低いものにしていきます。

受入基準は箇条書きでその機能がリリースできるための基準をテストケースのように書いていました。実装時はそのテストケースに対してTDDで開発をします。

ストーリーポイントの見積もりはいわゆるプランニングポーカー形式でした（「せーっの、3！あ、5かー、俺も5と迷ったわーー」みたいなやつ）。

見積もりのルールは、以下のような感じでした。

A. 過去のPBIを各ポイントごとに一つずつ指定してそれを基準とする
B. 1段階ずれている場合は高い方が優先される。
C. 2段階ずれている場合は認識に大きな差異があるとしてなぜそのポイントにしたのか議論を行う

時間は1PBIにつき7分でおこなっていました。1つのPBIが大体2~3ポイントだったので9つ見積もるとだいたい20ポイントちょっとで1時間ですね。

残りの40分くらいは大玉機能の大まかな仕様詰めをしていました。

また、リファインメントでは大きすぎるPBIの分割を行っていました。
3ptより分割した結果2ptと2ptになることもよくあり、それはそれで認識していない問題がわかったからいいよねということにしてました。

PBIは小さければ小さい方がいいです。

しかし小さすぎると際限がないのでユーザーが画面上から自力で動きを確認でき、シナリオが完結するという条件を満たす限り可能な限り小さくするとしていました。

ようするにフロントエンドだけやバックエンドだけのPBIは作ってはいけないということです。なぜなら例えばバックエンドだけでリリースしてもテストの仕様がなく、バグを仕込んでしまう可能性があるためです（逆も然り）。

またよくあるのがユーザーに価値がある単位でPBIを切ると言われますが、そうすると大玉機能などの最低限一式機能が揃わないと価値のないPBIが巨大MAXになってしまいます。なのでそれはしません。

その場合はフィーチャートグル、限定公開機能などを使い、検証環境だけ見れるようにします。そしてやはり価値はなくても画面上から自力で動きを確認できるという単位で細かくリリースしてしまいます。

リファインメントは薪割り。細かく割った方がいいです。

プランニング1

次はプランニングです。プランニングは1と2があります。

プランニング1のゴールは今スプリント何ポイント分積んで、どのPBIを行うかを決めることです。

この時間までにPOはバックログの順番を並び替えます。開発者の知識が必要なPBIについてはプランニング1の最初の時間にその知識を考慮してさらに並び替えます。

1スプリントで取り扱うポイント数が20ポイントだったので基本的に上から20ポイント分取ればプランニング1は終わります。

差し込みやリファインメントが十分にできていない場合はPBIをさらに見積もる必要があるのでリファインメントと同じようなことをこの時間で行います。

プランニング2

次はプランニング2です。

プランニング2のゴールは全てのPBIについてSBI（スプリントバックログアイテム、チケットに紐づく細かいタスクのこと）を洗い出すことです。

プランニング2は以下の3つのパートで行います

1. 詳細なテストケースの洗い出し
2. SBIの洗い出し
3. 洗い出したタスクをメンバー全員に共有

まずは詳細なテストケースを洗い出します。受入基準がそもそもテストケースのように書いてあるので大きく修正することはないですが、漏れがないか今一度確認します。

次はSBIの洗い出しです。このSBIは基本的に30分で終わるくらいの粒度で出します。SBIは上記で出した各テストケースに紐づかせ、そのケースを満たすために積んでいきます。

SBI出しは基本並列作業で一人で行います。この作業が終わった後、一人がチームメンバーにタスクを一つ一つ説明していきます。SBI出しを行った人がスプリント中そのSBIをするとは限りません。

プランニングは基本上記のゴールを満たすまで続きます。平均3時間~4時間くらいかけて行っていました。

プランニングはスクラムの心臓です。ここでミスるとスプリントが壊滅します。

文字だけでつらいので心臓の画像でも貼っておきます。

スプリント

いよいよスプリント(1週間だった)がスタートします。

スプリントのゴールはPBIをこなしていきリリース可能な状態を目指すことです。

スプリント中は特に以下のような点を大事にしておきました

- 30分で終わらなかったSBIはなぜ終わらなかったのかを書く
- 考慮外の差し込みSBIは付箋の色を変えて追加する
- テストコード（=受入基準）を先行しながら書いて、SBIをこなしていく
- リリース可能状態になったものはスプリント中でも細かくリリースを行う
- 一気にPBIを並行してなるべく行わない

最後のだけ解説します。一気に複数のPBIを並行して行わないようにします。
これはなぜかというと、複数のPBIを並行して行うとスプリントの最後に多くがリリースされるか逆に全然されないかの2択となってしまいリスキーだからです。

一つのPBIを可能な限り複数人で取り扱います。ソースコードの競合は細かく解消します。

リリース可能な状態とは？

スクラムイベントではないですが、大事なので共有しておきます。

リリース可能な状態は明確な定義がありました。
それは受け入れ条件と完成の定義を満たしている状態です。

受け入れ条件とはそのPBI特有の受け入れるための条件です。（例えばCSVアップロード機能だと、正常にアップロードできるとか、tsvファイルはアップロードできないとかそういう条件のこと）

完成の定義は受け入れ条件とは違い、そのプロダクトにおける普遍的なリリース可能な条件を指します。基本的に全てのPBIについて同じ完成の定義が適用されます。

例えば前職のチームでは以下のような完成の定義がありました（一部抜粋）。

- 一人以上のソースコードレビューがされている
- マージ前のCIテストが全て通っている
- マージ後のE2Eテストが全て通っている
- 事前に作成したテストケースを手動でテストしている

完成の定義は基本的に自動でチェックできるものが好ましいです。レビューやCIが通っていないとマージできない仕組みにしたりするのは簡単ですね。

スプリントレビュー

次はスプリントレビューです。

スプリントレビューのゴールは「作った機能についてフィードバックをもらい、次作る機能の方向性を決める」です。

前職で作成していたサービスは社内でドッグフーディングも行っていたので、その社内ユーザーとカスタマーサクセスの人を呼んでレビューを行っていました。

作ったものの受入条件を確認したり、バグを見つける会ではないです。

このレビューで触れるものはちゃんとリリース可能な状態をクリアしたPBI達であり、その機能をさらに進化させるには？という視点で臨みます。

レトロスペクティブ

スプリントレビューが作ったものの改善に注目しているのに対して、レトロスペクティブのゴールはチームの働き方をよくするための改善策を出すことです。

レトロスペクティブはスプリントの最後に行い時間は1時間でした。重要なことは事実に基づく大きな課題に注目することです。

ここで重要になってくるのはスプリント中のタスクです。30分以上かかったタスクはその理由がメモされていたり、差し込みタスクは違う色の付箋になっているのであとで振り返りやすくなっています。

スプリントの進捗を著しく遅らせたPBIに着目して、そのPBIの特に時間のかかったタスクの原因や差し込みタスクが多かった原因を考えていきます。

改善策については定量的に確認できるようなものを出すよう心替けていました。多少実験的で効果が見込めないかもしれなくても、改善策が少ないよりは良いです。レトロスペクティブの敗北は改善策が一つもないことです。

スクラムチームが目指すもの

これでスクラムイベントの説明は終わりです。

最後にスクラムチームが目指すものについて説明します。スクラムチームの命題は

1. ベロシティを増やす
2. 完成の定義を拡張する
3. ビジネス的に価値のある機能を作る

の3つだと思います。

2の完成の定義のとこだけ解説すると、完成の定義は拡張することができるものです。

前述ではE2EテストやCIテストしか確認していなかったところを、余裕ができてきたからSLOを完成の定義に組み込もうとか、脆弱性チェックツールを入れて脆弱性もPBIごとにチェックできるようにしようとか無限に拡張ポイントはあります。

重要なのは多すぎると完成の定義を通すことや確認することに時間がかかってしまいベロシティが落ちるという点です。

そのため完成の定義を拡張するときはいかに自動で確認ができるかがポイントになってきます。最初は手動確認で始めて、それを自動化。余裕ができるのでさらに新しい項目について完成の定義を拡張するという流れが好ましいです。

作ったものが安全にリリースされ、その量が多く、作ったものが常にビジネス的価値が高い。そんなチームを作りたいものですね。

もし興味を持ったなら、、

あなたがもし僕の前職のチームに興味があったらぜひチームを目掛けて転職してください。

スクラムの練度や相性は同じ会社であってもチームによって千差万別なので、必ずチーム指定で話を聞くようにして欲しいです。

Twitter @Yuiiitoto にDMしてくれれば可能な限りご紹介します。

We're Hiring !!!

現職の株式会社ログラスでも強いエンジニアを募集しています。
スクラムをむしろゼロから整備していきたい、という野心的な心がある方は弊社向きです。

こちらもぜひTwitter経由でご連絡していただければと思います。

https://www.notion.so/Loglass-Job-Board-da7d4b2b62b04d4da0de327c6434dd1f

親愛なるチームメンバーへ

チームメンバーの人間がこの非常に長い記事をここまで目を通すとは思わないですが、最後に謝辞を述べておきます。

前職では素晴らしいメンバーに恵まれました。国内でもトップクラスのレベルのスクラムマスターがスクラムを整備し、全員フルスタックなエンジニアが協同して機能を作ることができていました。

POもデザイナーも非常にレベルが高く、常にユーザーと対話し、確度の高い課題を抽出してくれていました。

多くのことを学ばせていただき本当に感謝しています。新天地でも頑張ります。

ではでは、みなさんここまで読んでいただきありがとうございましたー！！