スクラム開発における不具合（バグ）発生時の対処方法
こんにちは。ソリューション開発部 認定スクラムマスターの飯出(いいで)です。
システム開発をしていると頻度はチームによってまちまちですが、不具合に遭遇することが良くあると思います。えっ、不具合なんて全く発生しない！？すばらしいチームに所属されているようですね。残念ながら、私たちのチームはそのようなチームではありません。多少の不具合に遭遇することはあります。
今回はスクラム開発における不具合発生時の対処法について書いてみようと思います。あくまでも経験を踏まえた個人的な考え方ですが、参考になれば幸いです。
この記事を書こうと思った経緯
最近、以前に比べて不具合に遭遇するケースが多いと感じています。
私がスクラムマスターとして従事していたチームですが、現在はスクラムマスターのポジションを後輩に任せ、私はプロダクトオーナー（PO）のひとりとして従事しています。もしかしたら、不具合に遭遇するケースが多いと感じているのは、その立場が変わったからかも知れません。あくまでも、主観です。
不具合とは
不具合とは、「システムが想定通りに動作しない状況。および、その状況の原因となっている問題」を指す言い方ですね。「障害や欠陥、不良品、バグという言葉を使うことを回避するための、日本語特有の言い回し」とも言われます。
ここでの不具合は、スクラム開発において「プロダクトバックログ・アイテム（PBI）が完了（done）した後に見つかった不具合」、端的に言えば「スプリントを逃れた不具合」とします。すなわち、スプリントで実装中の PBI における不具合ではないということです。
実際の判断基準はチームによって異なると思いますが、実装上の不具合や要求を満たしていなかったもの。ですね。
不具合の対処方法
スクラム開発における不具合対処法を、（良きも悪きも）いくつか並べてみます。
半日程度で直るならPOと相談してすぐ修正する
私が認定スクラムマスター研修を受けた際に James O. Coplien氏 がそう話していました。後述しますが、付け焼き刃で対処しないことが重要だと思います。そう考えると、本当に軽微な不具合が対象となるでしょう。
優先順位の低いPBIとの入れ替えをPOと合意する
開発チームが対応可能と判断している場合において、優先順位の低い PBI との入れ替えを PO と合意し、不具合修正に着手するやり方です。これも、軽微な不具合が対象になるのではないかと思います。
POがPBIのひとつとして優先順位付けをする
スクラム開発において、一番ポピュラーなやり方ではないでしょうか。即座に不具合修正に着手せずに、最速で次スプリントでの対処となるパターンです。言わずもがな、次スプリントでの着手となる場合は、PO が優先順位を高く設定した場合です。この場合において、開発チームは不具合修正のストーリーポイントを算出します。
POが「不具合の緊急度が高い」と判断した場合
PO の判断により不具合における業務影響が大きい等と判断した場合、スプリントの中止（スプリント緊急停止）を行います。重要なのは「PO による判断であること」です。私たちのチームでは、PO がスクラムマスターに必ず助言を求めるようにしています。これは、「スプリント緊急停止の乱発を抑えること」と「スクラムマスターがより良い対処（処方箋）ができるように」という効果を期待しています。
不具合の発生に備えた余力を残しておく
予め開発チームのキャパシティから不具合への対応時間を差し引いておくやり方です。「どのくらいの余力を残しておけば良いか」という課題がありますが、各スプリントで割り当てられた不具合修正の履歴から算出できるのではないかと思われます。
ただし、不具合修正スプリントを作ることは推奨しません。なぜなら、
- 不具合をためこんで、あるタイミングで一気に消化する悪い癖が付く
- PO は PBI に対して、常に優先順位付けをすること。それを怠ってしまう
という理由です。
付け焼き刃で対処しない
「本番環境で動くからいいや。」ではいけません。自動化されたテストケースが存在するのであればそれも修正対象ですし、必要に応じてドキュメント修正も発生するかも知れません。何も言わないと、BTS への記載すらしない人も見受けられますね。
不具合対処チームを別途準備する
この手法は私たちのチームではなく、別のチームが実践している手法です。通称「バグ・バスターズ」なんて言われたりもしています。このチームには、「品質保証チーム」や「CS（顧客サポート）チーム」が存在するようですので、不具合の緊急度が高い状況には陥りづらいのかもしれません。
ただ、運用保守も同時に実施している私たちにとって、そのような「よろず対応」と「通常の追加開発」をチーム分けしたらメリットがでるのではないか。と考えたこともあります。
スクラムマスターを作業者にしてしまう
ダメなやつです。でも、このケースが多いのではないでしょうか。
スクラムマスターがタスクを持ってしまうと、本来やるべき「チームがスクラムのルールに則ることを支援する」「積極的に進行の障害物を取り除く」「外部の割り込みからチームを守る」作業ができなくなってしまいます。
同様に「PO が技術的解決策を指定する」も、ダメなやつです。
不具合発生時における一次切り分けの直後に、ついつい技術的解決策について話をしてしまうケースがあります。技術的解決策は、開発チームに出して貰いましょう。実はこれ、私の反省点です…
不具合の事後処理
さて、不具合も無事修正して本番環境にリリースを実施し、平穏な日々が戻ってきました。しかし、そこで終わりではありません。ちゃんとチームでも事後処理をしましょう。
「ふりかえり」でチームに問題提起をする
なぜ当該スプリント実施中、すなわち実装中に今回発生した不具合を見つけることができなかったか。というテーマについて議論しなければなりません。チームによってさまざまなアプローチがあると思いますが、解決策はきっとあるでしょう。同じミスは2度繰り返してはいけないのです。
BTSを見てみるのも良い
スクラム開発に限った話ではないのですが、「現象」「原因」「対処」の3本立てが BTS に記載されていないケースがあります。このような場合において、分析がしっかりできていないままに不具合の修正をした可能性を感じてしまいます。要は「また不具合が発生する可能性」を秘めているかもしれません。カイゼンするために、チームに「適切なテスト」についての学習を促した方が良いと言えるでしょう。
あくまでも、私の経験則ですが。
不具合もPBIのひとつだと言いますが
不具合も PBI = ユーザーストーリーのひとつという考え方に少し違和感を覚えています。そもそも、間違ったソースコードを書いて後から修正するということは、お客さまは余分なお金を支払うことになるのです。
お客さまは怒った方が良い
スクラム開発のルールに則り、不具合も PBI のひとつとして扱うことに慣れてくると、それを当たり前のように振る舞う技術者が存在することも確かです。実際にそのようなケースもありました。
- 不具合だらけのプロダクトバックログ・リスト
- 不具合改修ばかりで業務やシステム改善が滞る
発生している不具合ばかりに高い優先順位を付けてみれば、違和感を感じるのではないでしょうか。不具合はもともと、チームの不適切な開発プロセスから発生していることが多いのです。
私たちのお客さまはとても紳士的で、無謀な割り込みもせず、スプリント緊急停止も我慢してなんとか切り抜けようとするお客さまです。そのようなお客さまだからこそ、不具合発生時にはきちんと怒っていただいた方が良い。なんて考えたりもします。
おわりに
文頭に書きましたが、もう一度言います。
あくまでも経験を踏まえた個人的な考え方ですが、参考になれば幸いです。
世の中にあるさまざまなスクラム開発チームのすべてが、より良い開発になると良いですね。スクラム開発において、不具合の取り扱い方については規定がありませんので、色々な資料を読んだり、作戦を試行してみるのが良いと思っています。
スクラム開発を始めたいと思っている方がいらっしゃいましたら、参考にしていただけますと幸いです。スクラム開発に興味のある方、新たな開発チームを構築したいと考えている方はこちらまで お問い合わせ ください。
