7割にも及ぶ運用業務をスクラムで扱うためには？
そんな運用業務と組み合わせにくいと言われるスクラムだが、中井氏が所属するチームでは新旧2つのプロダクトを「LeSS（Large-Scale Scrum）」で開発している。
担当している2つのプロダクトは新旧の社内プラットフォーム。新プロダクトはこれから伸びていくプロダクトで、利用者も少なく、まだ足りていない機能があるなど開発がメインとなっているが、「定常業務はそこそこある」と中井氏。一方の旧プロダクトはそろそろ引退が見えているが、規模も利用者も大きく定常運用業務が多いことに加え、障害がよく発生するため、突発運用業務も多いという。
直近半年から1年で実施した運用業務量のプロダクト業務に対する割合は、新プロダクトは約4割、旧プロダクトは約8割になる。つまり2つのプロダクトを担当するチーム全体で考えると、「約7割が運用業務となっていました」と中井氏は語る。
そこでこの7割にも及ぶ運用業務をスクラムで扱うために、中井氏たちは4種類の取り組みを試した。
最初の取り組みはすべての業務をバックログで扱うようにすること。「やるべきことが可視化され、運用業務にもちゃんと着手できる。運用と開発にバランス良く携われるようになるといいな」と中井氏たちは期待したという。だが、実際に起きたことは、後から追加された開発アイテムがより優先順位の高い位置に入ってくるので、運用業務の優先順位がなかなか上がらなかったのだ。「スプリント開始前は運用業務も実施できそうだと思ったが、どんどん開発アイテムが入ってくることで、運用業務の優先順位が下がっていきました」（中井氏）
なぜこのようなことになったのか。「一連の作業を1スプリントで終わるよう小さく複数のアイテムに分割したため」と中井氏はその理由を話す。例えばキャパシティを拡大するために必要な作業であれば、「作業の準備（事前申請作業）」「作業その1」「作業その2」「監視設定など」「ユーザー提供開始」に分割したため、一つ一つのアイテムで提供できる価値がなくなり、優先順位が下がってしまうのだ。そのため、なかなか着手されなくなってしまうのだ。「この結果、キャパシティの拡大が遅れて、ユーザーに多大な迷惑をかけてしまったことがありました」（中井氏）
それだけではない。価値があっても数が多くてまったく終わらないものもあったという。例えばソフトウェア・アップデートのためのアイテムを、クラスタ単位でたくさん作成し、できるタイミングで1アイテムずつ実施していたという。すると他のアイテムがより優先順位の高いところにどんどん入ってくることもあり、いつまで経っても終わらない状況に陥ってしまったのだ。
第二の取り組みは、スプリント固定のアイテムをつくること。「固定アイテムを、実施を予定しているスプリントに入れることで、あらかじめ決めた日に確実に作業が実施できること、定期的に行う必要のある作業が遅れないこと、インクリメントがなくても計画的に実施できることを期待しました」（中井氏）
実際、固定アイテムはプランニング時点で優先順位が一番上に来るので、確実に実施できるようになる。長期間にわたるリリースをスケジュール通りに実施でき、スプリントプランニングで優先順位を考えやすくなったという。
「期日から逆算して実施日を決めることで、毎スプリント、少しずつ進められるようになった」と中井氏。例えばキャパシティの拡大やソフトウェア・アップデートという業務であれば、複数のアイテムに分割し、期日から逆算して実施日を決める。そして実施すべきスプリントにあらかじめ配置しておくのである。こうすることで確実に実施されるようになったのだ。
運用作業の中でも「リリース日が固定されている作業にマッチしました」と中井氏。例えば実施したいタイミングがある証明書更新はその一つ。「実施日が決まるとその日付を含むスプリントに配置して固定し、実施する。優先順位が高いので確実に実施される形を作ることができました」（中井氏）
