スクラム未経験者が初めてスクラムチームに入るときに必要な考え方
先月から、スクラムチームに入って仕事をするようになった。スクラムというやり方自体が会社としてほとんど前例のない取り組みであったため、うまくいっている所もあれば、チーム外に非常に迷惑をかけてしまっている部分もある。
個人的には、1人とか2-3人での仕事しかしたことがなかったため、スクラムの考え方が今までの仕事での考え方と大きく違うことに驚かされた。事前にスクラムガイド等は読んだものの、実際にスクラムを回してみて改めて分かったことも多いので、それをまとめておく。
なお、今のスクラム開発チームにおける詳細な進め方やアジェンダは書かない。スクラムは経験主義に基づいており、細かな手順に従うのではなく、各プロジェクトやチームの状況によって進め方を柔軟に変えることが良いものとされている。そのため、一つの進め方を記録してもあまり意味はない。
また、プロダクトオーナー(PO)の考え方・責務の話は除き、スクラムの開発チームでの考え方のみを書いている。
まず読むと良いもの
以下の資料を参照して基本的な用語の意味などを理解しておくと、スムーズに入りやすくなる。特にアジャイルプリンシプルとスクラムガイドは必須。
- アジャイルプリンシプル
- スクラムガイド
- Scrum 3355
- 正しいものを正しく作る
スクラムにおける開発チームの責務
- このドキュメントでの「スクラムにおける開発チーム」とは、開発を行うメンバーとスクラムマスターを指す。プロダクトオーナーは含まない。
スクラムにおける開発チームは、チーム外に対して以下のことを担保する。
- 自己組織化:
- チーム外から何も指示されなくても、ミッション達成に向けて何をどのように行うべきかを自分たちで判断し実行できる。仮に判断が間違っていても自分たちで気づいて修正できる。
- チーム内での作業の完結:
- 必要な職能を持つ開発者が揃っており、開発・リリースを全てチーム内で完結させられる。
- プロダクトの完成:
- 各スプリントごとに、特定の機能や修正が反映され動かせる状態のプロダクトを作り切ることができる。単に動けば良いのではなく、考えうる限り最良の仕様・設計に落とし込んで作ることが求められる。
- 透明性:
- チーム内の進捗や、今どのような作業をしているか・どのような問題が起こっているかについて、POやチーム外に緊密に連携する。
- 自己組織化:
スクラムにおける開発チームは、本来は以下のことは担保しない 。
- 要件の内容：
- 何を開発するかは、本来はプロダクトオーナーの責務。
- 納期/スコープ :
- あらかじめ決められた水準以上のパフォーマンス:
- 「経験主義」「持続可能性」の考え方のもとでは、1スプリントでどれだけのストーリーポイントを消化できるかを事前に予測したり、コミットメントしたりするのは不可能。1-2サイクル回してみて実績を測ることで、初めて1スプリントの消化量を計算し、スケジュールの見込みをチーム外に共有できる。逆にそれまでは、いつまでに開発が終わるかをチーム外に対して約束することはできないし、すべきでない。
- 逆に、自分たちの見積もりに基づいて1スプリントごとにどこまで終わらせるかを決める時は、それを守る責任が発生する。
- 要件の内容：
スクラムマスターの責務
- 理想的には、スクラムマスターはスクラムが円滑に回ることにのみ責任を負う。
- スクラムの円滑な実施を阻害するものであれば、あらゆることに対して対応する。(例: 仕様の細かい部分がわからない、技術力の差がありすぎてついていけないメンバーがいる、特定のタスクで時間を取られている等)
- 逆に、プロダクトの仕様やリリースの期日などに対しては、本来は責任を負わない。そこに責任を負うべきなのはプロダクトオーナー。
- スクラムマスターは以下のようなものではない。
スクラムに必要なもの
進め方に決まりはないが、以下のものは絶対に必要と言われている。
1. ユースケース
- ユーザにとって何が達成されれば良いかを表した言葉。プロダクトオーナーとの間でゴールの認識を合わせるために必要。
- ユースケースは「ユーザは◯◯することができる」という形で考えると良い
- ユースケースは以下の条件を満たす必要がある
- 意味が曖昧なところや、複数の解釈ができるところがない
- チーム間での認識の齟齬がない
- プロダクトオーナーに確認を取り合意する
2. プロダクトバックログアイテム(PBI)
- プロダクトに必要なものの一覧。次に何をやるべきか・どこまで終わったを整理するために必要。
- このバックログはスクラム開発チームとPOの両方が確認し、定期的に優先順位を入れ替える。
- スプリントは個々のPBIベースで進めていく。ストーリーポイントをつけるのもPBIに対して。PBIの開発が終わり、成果物に反映されたかどうかでスプリントの成果を判断する。
- PBIをどの粒度まで落とすかは特に決まりがない。チームにとって進捗判断がしやすい粒度を模索するしかない。
3. タスク
- 各PBIをさらに分解してできる、個々の開発タスク。
- 1つの目安として、1タスクが30分くらいで終わるくらいの粒度に分けると良い。
- これはあくまで目安でしかなく、本当に30分で終わったかどうかで速度を測るのはナンセンス。目的はタスクの粒度を十分細かくし、見通しを良くすること。
- 調査系のタスクがある場合、発散しやすく、議論しながらやるのにも向かない。PBIを作る際に行うのがベスト。
- タスクを切り終えたら、後はモブプロ形式で全員で進めても良いし、タスクを個々人に割り振っても良い。
- タスクは「個人が責任を負うもの」ではない。状況によってはチーム内でヘルプを求めたり、アサインを他の人に変えてもらっても良い。逆に自分に余裕があるときは、積極的に他の人のタスクのヘルプに入る。
4. ストーリーポイント
- PBIに対してストーリーポイントをつける。
- タスクにはストーリーポイントをつけない。スクラムの進捗は「どれだけのタスクをこなしたか」ではなく「PBIが完了したか」で判定すべきであるため。
- ストーリーポイントをつける時は、既に完了した特定のタスクを基準にするなどして、メンバー間で「1ポイント」がどれほどのものかの認識を合わせる必要がある。
5. スプリントレビュー
- ステークホルダーにここまでの成果物(動く状態のもの)を見せて、レビューをもらう
- ここまでの進捗がどれくらいか・それはなぜなのかをステークホルダーに正確に説明するのがスクラム開発チームの責務。それを正しく伝えることで、ステークホルダーが適切な事業判断を下すことができる。
6. レトロスペクティブ
- 今スプリントを振り返り、次スプリントで新たに行うNext Actionを決める。
- Next Actionは以下の2つを満たす必要がある。
- 誰が・何を・いつまでに行うかが明確である。(悪い例:「個人でもっと勉強する」)
- 今スプリント内で起こった課題に対応している。
- 課題に対する有効なNext Actionが思いつかないのなら、無理に出す必要はない。その場しのぎのNext Actionを出したりレトロスペクティブに時間を使いすぎたりするくらいであれば、Next Action無しで次のスプリントに入る方が良い。
- 有効なNext Actionが思いつかない場合、課題の認識がぼやけている・課題解決のための材料/データが足りていない・チーム内の改善だけでは手に負えない課題である等が考えられる。
- 「次のスプリントを同じように進めてデータを計測し、本当に課題かどうか判断する」というのも立派なNext Actionの一つ。
スクラムに入ってみて
最初は仕事に対する考え方があまりにも違いすぎてとまどうことが多かった。PBIを作る暇があったら速くタスクを進めたいとさえ思ったこともある。
ただ、下手にタスクを速く進めてしまうと、仕様に対する認識のすれ違いが発生したりして、余計な手戻りが起こりえる。チーム内での共通認識を取る・POとも合意を取るというステップをこまめに行うことで、急な要件追加や不確実性にも対応できるようにしているんだということが初めて理解できた。
一方で、最大の失敗は「プランニングの段階でそのスプリントのタスクを詰め込みすぎ、結局終わらなかった」というパターンがよく起こってしまっていることにある。スクラムでは、各スプリントでやると決めたタスクはそのスプリント中に必ず終わらせる責任が生じる。レトロスペクティブを通じて見積もりを修正するというのはもちろんだが、スクラムの成功は各メンバーのスキルにも大きく依存するということを痛感している。
1回のスプリントの期間は1週間~長くても1月ほどなので、1つのタスクをスプリントに入れるかどうかの判断を間違えると、その時点で進捗遅れが確定してしまう。その判断を正しくやるには、スクラム内で各領域の知識と技術力を持ったメンバーが正しい見通しを示さなければいけない。スクラムにマネージャーはいないので、一人ひとりが示す見通しがそのままチームの意思決定となる。
そしてこの正しい見通しを考える力が、今の自分に欠けているところでもある。判断ミスでチーム全体に迷惑をかけることがないよう、自分が知見を持っているところは念入りに調査・準備したうえでスプリントに臨むようにしたい。
