スクラムで問題(バグ)対応するときのアプローチ

先日、現場の人から質問を受けました。

「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」

バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。

問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。
POが優先順位が1番だと判断したからといって、READYであるとは限らない。スプリントに入れて開発チームで取り組む準備ができていなかったら、スプリントに入れられない。
問題が大きそうで、プロダクトやプロジェクト(リリース)へのインパクトも大きいのであれば、スプリントに入れるのとは別の理由で、できるだけ早く見積もりができるほうがよいはず。リリース日の変更や、リリースに含める機能の大幅な変更、関係者への連絡や調整などのためにも、できるだけ早く見積もりがほしい。
粗く当たりをつけた当初の見積もりは、関係者に早く伝えるのが重要かつ、状況が変わったら随時伝え続ける、現状を更新し続けるのも重要。問題はとりわけ、どんどん対応工数がふくらみやすいので、最新の現状を共有しないといけない。相手にもよるが、あまり楽観的に伝えない方が先々お互いに安心。
問題の調査を開発チームがする必要があるのであれば、その作業を解釈としてはリファインメントの時間と考えることもできる。ガイドではリファインメントはスプリントの10%までだが、一時的に越えるのは大きな影響はないと思う。
問題の調査、切り分けはスプリント期間中、一定の時間枠(タイムボックス)を取って進める。逆に言うと、スプリントの他の開発も並行して進める(「4.1.20 常に誰かが進捗させる」組織パターン)。すべてが止まってしまうと後から立て直すのがしんどい。調査に12時間使う、1ペアはずっと問題調査に充てる、あるいは3～4人はモブでずっと問題調査をするなどということにして、残りの人数は他のPBIを進められる。12時間ならベロシティは通常の28/40になる。5人チームで1ペアが問題調査をするなら、ベロシティは通常の3/5になる。
ペアプロやモブプロのスタイルで調査をする。問題調査は心が折れやすい仕事で、ペアやモブだと心が折れにくい。どこにあるかわからない、なにかもわからないものを探すのには、目玉と脳味噌が多いほうが良い。スタイルはゆるくてよく、自分のPCでちょっと確認するとか、相談した上で手分けをするタイミングが、あったりしてもよい。またペアやモブのメンバーもゆるく、時々入れ替わったり、誰かを呼んで教えてもらったり手伝ったりしてもらう。
問題調査もできるだけブレークダウンして、個別のタスクに切り出す。思いついたところから手当たり次第に進めたり、各自が勝手に調べたり、あるいは誰かが脳内で整理しつつ指示をするようなやり方は、効率が悪い。おそらくスプリント単位(1週間)でタスクを切り出すのは困難なので、タスク出しは随時おこなわれることになる。(Mikado Methodも便利。テストとリファクタリングに関する深い方法論 #wewlc_jp の36枚目など)
調査の状況や進捗は、できるだけ記録に残す。ラフで良く、またアナログ、できれば目の前のホワイトボードを占有するようなやり方がよい。作戦司令室とか、あるいは捜査本部みたいな感じで、その場に来れば状況が分かる、いま何を調べていて、どこまで進んでいて、次に何をすべきか全員がつかめるようにする。問題調査はカオスになりがちなので、そのカオスをそのまま表現する。
調べた結果は、できるだけ自動テストや自動化スクリプトなどで残す。調査自体も自動化しながら進める。勘違いや見落としを後から確認できるし、パターンを追加するのも容易。他の人が確認した内容を正確に共有できる。問題を特定したら、その問題を再現するテストを自動化しておく。
問題調査にキリがついて、対応方針が確定して、あとは直すだけというところまできたら、直すという作業をPBI(ストーリー)にする。あとは他のPBIと変わらない(見積もりをして、大きければ分割し、受入条件を作り、プロダクトバックログに並べる)。
そもそも問題に緊急性が高く、スプリントで扱いきれないようであれば、スプリント緊急中止を検討する。本来のスプリント中止では、そこから新しいスプリントを計画する。また別の案として、スクラムそのものを停止して、全員で問題の調査や対応に全力で対応する。どうしても必要なときに検討すべき手段だが、あとでスクラムを再始動するのにかなりエネルギーがいることを覚悟する。
そもそも問題調査を開発チームでやるのがいいかはわからず、外部の人に頼む、別にチームを作るなどのアプローチもできるはず。