定常運用業務や突発的な障害対応をスプリントに組み込むコツ
第三の取り組みは、固定の定常運用業務を自動化するアイテムを作ること。「定型化された定常運用業務が減ることでトイルが削減され、より開発業務に取り組めるようになることを期待しました」（中井氏）
つまり定型化された定常運用業務のアイテムを自動化することで価値を生み出すアイテムにするのである。例えば利用者からの申請への対応作業は、自動化により一連の作業が必要なくなったことで運用者のトイルが削減されるだけではなく、利用者が申請されてから対応されるまでの時間の短縮も実現した。「私たち運用者と利用者双方にとって、Win-Winの効果が得られました」と中井氏は話す。
一方で優先順位が上がらず、未着手になったアイテムもあったという。それが年1回などたまに実施する作業を自動化するアイテムである。他アイテムと比較してバックログの適切な場所に置かれるのだが、作業頻度と量に対して自動化するコストが高いため、優先順位が上がらない。「自動化されずに手作業が残っています」（中井氏）
第四の取り組みはPagerアイテムで備えること。つまりアラートや障害対応などの突発運用業務をあらかじめ各スプリントに入れておくのである。「アラートや障害などの突発運用業務が他のアイテムに影響なく実施できることを期待しました」と中井氏は説明する。
結果、Pagerの枠で突発運用業務が吸収されるので、スプリントへの影響を与えにくくなり、障害を気にせず開発アイテムを進められるようになったという。その一方で、Pagerの枠で突発運業務の改善を実施するため、Pagerアイテムのブラックボックス化を招いてしまった。例えば対応不要のアラートが出てきた場合は、そのアラートが出ないようにするための改善や、ユーザーに提供しているドキュメントの不備の修正もPagerの枠で行うことになる。「Pagerという枠に隠れて改善策が見えなくなってしまいました。Pagerアイテムのブラックボックス化をどう改善していくか、これから考えるべき課題となっています」（中井氏）
またある程度の規模を上回るとPagerで対応しきれず、スプリントを中止することもあったという。「このようなことはめったに起きないことですが、昨年末に世界的に影響の大きな脆弱性が発生した際に、このような対応をとることとなりました」（中井氏）
これらの4種類の取り組みからわかるように、運用業務とスクラムは組み合わせにくいというわけではない。扱うには工夫とコツが必要になるというわけだ。
最後に中井氏は次のように語り、セッションを締めた。
「スクラムの検査と適応を、プロダクトだけではなく仕組みに対しても実践していくことで、扱い方をアップデートしていける。そうすることで運用業務とスクラムという一見、組み合わせにくいものでもうまく組み合わせていけると思います」（中井氏）
