スプリント中の差し込みタスクの対応

スクラムを導入したが、スプリントの中に想定外のタスクが差し込まれてしまうことが多いという話をよく聞く。
想定外のタスクが入った結果、スプリントゴールをなかなか達成することができないという話だ。
そして、差し込みタスクはサービス運用上避けられないので、スプリントゴールが守れなくなることを許容してもいいのではないかという考えが出てくる。
このスプリントゴール達成の優先度が下げられてしまうことに対して、スプリントゴールの達成を阻害する差し込みタスクをスプリントの途中からいれるべきではないと私は考えている。
もし、その差し込みタスクが本当に重要なのであれば、プロダクトオーナーの判断でスプリント自体の終了を宣言すべきである。
片手間でスプリントゴール達成を目指すようなものになってはいけない。
差し込みタスクをどんどん入れてスプリントゴールを達成できない状況を受け入れるようになってしまうと、スプリントゴールが陳腐化してしまうからだ。
スプリントゴールはチームが一丸となって目指す目標なのに、スプリントゴール自体が陳腐化してしまうと自己組織化したチームを作ることが難しい。
ステークホルダーからの要望に振り回され続ける主体性のないチームとなってしまう。
よく言われることだが、スクラムは守破離で進める必要があり、まず最初はスクラムの型を守るところから始めなければならない。
スクラムの一部分だけを切り取って実行しても、スクラムの本当の力を活用することはできない。
最初から自己流で型を守らないことは、スクラムの有名なアンチパターンの1つだ。

差し込みタスクを知るのが第一歩

そもそも差し込みタスクとは具体的になんだろうか？
想定外の仕様変更、障害、顧客からの緊急の要望、アラート対応、経営陣からの指示など、差し込みタスクという言葉で多くのタスクが表現されている事が多い。
ほとんどの差し込みタスクは、実はすぐに対応しなくてもいいものが多い。
しかし、ちょっとの作業で終わるし、頼まれたことだからすぐに解決してやりたくなる。
これでは、スクラムの5つの価値基準である確約 (Commitment)、集中 (Focus)、公開 (Openness)、尊敬 (Respect)、勇気 (Courage) の１つである、集中ができていないことになる。
自分を頼ってきた目の前の困っている人を助けたい気持ちは理解できる。
しかし、優先度の高いタスクは大量にあり、差し込みタスクをやると他のタスクに必ず影響する。
たかだか数十分数時間の作業だから問題ないとして、他のタスクへの影響を無視してはいけない。
このような小さなほころびからスクラムが機能不全になり、価値のあるプロダクトの達成から遠ざかるのだ。

差し込みタスクが起こる原因

スプリント中の差し込みタスクが発生する原因として考えられる5つを紹介する。

1. 不十分なスプリントプランニング
2. 長過ぎるスプリント
3. 障害の発生
4. ステークホルダーのスクラムへの理解不足
5. エンジニアへの直接依頼

【1. 不十分なスプリントプランニング】
スプリントプランニングを十分に実施していないチームは実は多い。
だいたいやるべき方向性を考えて、あとは臨機応変に対応していこうというふうに走り出している。
こういうチームは、スプリントプランニングの時間をしっかり取ることも大事だが、そもそもチーム内でのスプリントゴールに対する認識を改めることも重要だ。
スプリントゴールはスプリントの単なる指標ではない。
スプリントゴールはプロタクトオーナーと開発チームの間で合意した必ず達成する目標で、開発チームはスプリントゴールのために全力で取り組まないといけない。
スプリントプランニングを曖昧にすると、スプリントゴールに関連するタスクがスプリント中に多く発生し、計画の変更を余儀なくされるし、スプリントゴール外のタスクの発生も予期できない。
もちろん、実際に作業したあとに新たなタスクが発生することが完全に防げるわけではない。
しかしプランニングをしっかりやることで、大抵の場合、突発的な差し込みタスクの多くを防ぐことができる。

【2. 長すぎるスプリント】
スプリントが長ければ長いほど、スプリントプランニングは難しくなる。
また、次のスプリントの開始までの期間が長くなるので、緊急で対応してほしいと依頼されてしまうタスクを次のスプリントに回しづらくなる。
そのため、もし差し込みタスクに悩まされているのであれば、スプリントの期間を短くすることを検討するとよい。
スプリントが短ければ、プランニングもしやすいし、差し込みタスクを次のスプリントに回しやすくなる。
もちろん、スプリントが短いと達成できるスプリントゴールは小さくなる。
そのため、大きな機能は、スプリントで達成できる小さな機能に分解できないから、短いスプリントでスプリントゴールを設定できないと考える人もいる。
しかし、機能を分解できない場合の多くは、顧客の課題をきちんと捉えきれていないことが多い。
多くの課題を一度に解決しようとしているから機能が大きくなる。
大きな機能開発は大きなリスクを持つし、単に思考停止している状態と言ってもいい。
機能を小さく分解し、リリースして、課題解決されているかどうか検証するというサイクルを短く回して、不確実性に対処していくことがプロダクト開発では大切だ。

【3. 障害の発生】
障害はサービスを提供者としては避けられないものだ。
障害が発生した場合、スプリントを中止して対応することを最優先で対応することを検討したほうがよい。
もちろんスプリントゴールが達成できるのであれば、スプリントを中止せずに差し込みタスクをやるという選択肢もある。
いずれにせよ、プロダクトオーナーに判断を仰ぐことが必要である。

【4. ステークホルダーのスクラムへの理解不足】
ステークホルダーはスクラムチームの外にいる存在なので、スクラムのことをよく理解していないのが一般的だ。
つまり、ステークホルダーはスクラムチームがどのようなワークフローに従って働いているかを知らないということになる。
そのため、ステークホルダーとしては、どのタイミングで開発へ依頼をしていいのか分からないため、悪意なく差し込みタスクを依頼してしまう。
これに対応するために、障害などの緊急タスク以外は、基本的にスプリント中は差し込めないことをステークホルダーに理解してもらう必要がある。
ステークホルダーにスクラムを理解してもらうためには、スクラムマスターによるスクラムの布教活動も重要だ。
悪意のない差し込みタスクを発生させないために、チケットを起票できるようにしておくなど、依頼の受け皿を用意しておくことも重要だ。
起票されたチケットが、特定のタイミングで考慮されることを伝えておくと、ステークホルダーも安心することができる。

【5. エンジニアへの直接依頼】
エンジニアへの直接依頼が、見えない差し込みタスクを生む。
ちょっとしたお願いやちょっとした聞きたいことがあった場合、公開された場所ではなくDMで聞いてしまうということがよく起きる。
しかし、そのちょっと思われている依頼が実は無視できない工数になることは多い。
そして、直接頼まれるとエンジニアは断りづらいため、スクラムチームに共有することなく、ついつい個別対応をしてしまいがちだ。
自己組織化された組織では、お互いが何をやっているかを把握している。
そして、スプリントゴールという共通目標に向かって全員が同じ方向を向いている必要がある。
しかし、見えないところで発生するエンジニアへの直接依頼がこれを妨げる要因となる。
これを避けるためには、直接依頼を明確に禁止する必要がある。
優先度判断の責任を持つのはプロダクトオーナーなので、プロダクトオーナーが優先度判断するラインに依頼事項を乗せられるプロセスを作ることが重要だ。

最後に

スプリント中は、障害などの緊急自体以外やることを変更せず、次のスプリントに回すことを徹底することで、スプリントプランニングの重要度が増し、よりよいスプリントにできる。
そのためにも、今までどんな差し込みタスク発生したのか、それが緊急だったのかどうか、仕組みで解決できるものではないかを考えることが大切だ。