運用業務がスクラムと組み合わせにくいと言われる理由
「運用業務とスクラムは本当に組み合わせにくいのか」というテーマで行われた、中井氏のセッション。このテーマを選ぶきっかけとなったのが、「スクラム関連のイベントで、運用業務をスクラムと組み合わせにくいという話を耳にすることが多かったため」と中井氏は話す。
例えば「運用業務ってどうスクラムで扱っているのか」「障害対応とかは予測できないし、スプリント計画に入れられなくて困っている」「定常的な運用業務が多くて、インクリメント（具体的な成果物）と言えるものがない」「手順が決まっているので、プランニングがいらない。ただタスクをこなすだけになってしまう」「スケジュールありきだと、スクラムと合わない」などだ。だがこのような話を聞くたび、中井氏は「本当にスクラムと運用業務が組み合わせにくいのか、疑問を持っていました」と語る。
運用業務は大きく、定常的に実施する業務（以下、定常運用業務）と外的要因により突発的に実施する業務（以下、突発運用業務）の2種類がある。定常運用業務を具体的に挙げると、定期的に行う証明書更新やソフトウェア・アップデート、需要に応じたキャパシティの拡張やライフサイクルへの対応、負荷が高くなるイベントへの事前準備と対策などである。一方の突発運用業務とはユーザーからの問い合わせへの対応や突発的に発生する障害やインシデントへの対応とその対策などである。
ではこれらの業務となぜスクラムが組み合わせにくいのか。「スクラムガイド2020年版」によると、スクラムとは「複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワーク」と記されている。この中の「適応型のソリューション、価値を生み出すためというところが、運用業務と組み合わせにくい理由ではないか」と中井氏は指摘する。つまり定常運用業務はインクリメントが小さく優先順位が下がりやすい、スケジュールベースの作業が多い、タスクをこなすだけになりやすいこと、突発運用業務は事前に計画がたてにくいことなどが、スクラムと組み合わせにくい理由だと考えられるわけだ。
7割にも及ぶ運用業務をスクラムで扱うためには？
そんな運用業務と組み合わせにくいと言われるスクラムだが、中井氏が所属するチームでは新旧2つのプロダクトを「LeSS（Large-Scale Scrum）」で開発している。
担当している2つのプロダクトは新旧の社内プラットフォーム。新プロダクトはこれから伸びていくプロダクトで、利用者も少なく、まだ足りていない機能があるなど開発がメインとなっているが、「定常業務はそこそこある」と中井氏。一方の旧プロダクトはそろそろ引退が見えているが、規模も利用者も大きく定常運用業務が多いことに加え、障害がよく発生するため、突発運用業務も多いという。
直近半年から1年で実施した運用業務量のプロダクト業務に対する割合は、新プロダクトは約4割、旧プロダクトは約8割になる。つまり2つのプロダクトを担当するチーム全体で考えると、「約7割が運用業務となっていました」と中井氏は語る。
そこでこの7割にも及ぶ運用業務をスクラムで扱うために、中井氏たちは4種類の取り組みを試した。
最初の取り組みはすべての業務をバックログで扱うようにすること。「やるべきことが可視化され、運用業務にもちゃんと着手できる。運用と開発にバランス良く携われるようになるといいな」と中井氏たちは期待したという。だが、実際に起きたことは、後から追加された開発アイテムがより優先順位の高い位置に入ってくるので、運用業務の優先順位がなかなか上がらなかったのだ。「スプリント開始前は運用業務も実施できそうだと思ったが、どんどん開発アイテムが入ってくることで、運用業務の優先順位が下がっていきました」（中井氏）
なぜこのようなことになったのか。「一連の作業を1スプリントで終わるよう小さく複数のアイテムに分割したため」と中井氏はその理由を話す。例えばキャパシティを拡大するために必要な作業であれば、「作業の準備（事前申請作業）」「作業その1」「作業その2」「監視設定など」「ユーザー提供開始」に分割したため、一つ一つのアイテムで提供できる価値がなくなり、優先順位が下がってしまうのだ。そのため、なかなか着手されなくなってしまうのだ。「この結果、キャパシティの拡大が遅れて、ユーザーに多大な迷惑をかけてしまったことがありました」（中井氏）
それだけではない。価値があっても数が多くてまったく終わらないものもあったという。例えばソフトウェア・アップデートのためのアイテムを、クラスタ単位でたくさん作成し、できるタイミングで1アイテムずつ実施していたという。すると他のアイテムがより優先順位の高いところにどんどん入ってくることもあり、いつまで経っても終わらない状況に陥ってしまったのだ。
第二の取り組みは、スプリント固定のアイテムをつくること。「固定アイテムを、実施を予定しているスプリントに入れることで、あらかじめ決めた日に確実に作業が実施できること、定期的に行う必要のある作業が遅れないこと、インクリメントがなくても計画的に実施できることを期待しました」（中井氏）
実際、固定アイテムはプランニング時点で優先順位が一番上に来るので、確実に実施できるようになる。長期間にわたるリリースをスケジュール通りに実施でき、スプリントプランニングで優先順位を考えやすくなったという。
「期日から逆算して実施日を決めることで、毎スプリント、少しずつ進められるようになった」と中井氏。例えばキャパシティの拡大やソフトウェア・アップデートという業務であれば、複数のアイテムに分割し、期日から逆算して実施日を決める。そして実施すべきスプリントにあらかじめ配置しておくのである。こうすることで確実に実施されるようになったのだ。
運用作業の中でも「リリース日が固定されている作業にマッチしました」と中井氏。例えば実施したいタイミングがある証明書更新はその一つ。「実施日が決まるとその日付を含むスプリントに配置して固定し、実施する。優先順位が高いので確実に実施される形を作ることができました」（中井氏）
定常運用業務や突発的な障害対応をスプリントに組み込むコツ
第三の取り組みは、固定の定常運用業務を自動化するアイテムを作ること。「定型化された定常運用業務が減ることでトイルが削減され、より開発業務に取り組めるようになることを期待しました」（中井氏）
つまり定型化された定常運用業務のアイテムを自動化することで価値を生み出すアイテムにするのである。例えば利用者からの申請への対応作業は、自動化により一連の作業が必要なくなったことで運用者のトイルが削減されるだけではなく、利用者が申請されてから対応されるまでの時間の短縮も実現した。「私たち運用者と利用者双方にとって、Win-Winの効果が得られました」と中井氏は話す。
一方で優先順位が上がらず、未着手になったアイテムもあったという。それが年1回などたまに実施する作業を自動化するアイテムである。他アイテムと比較してバックログの適切な場所に置かれるのだが、作業頻度と量に対して自動化するコストが高いため、優先順位が上がらない。「自動化されずに手作業が残っています」（中井氏）
第四の取り組みはPagerアイテムで備えること。つまりアラートや障害対応などの突発運用業務をあらかじめ各スプリントに入れておくのである。「アラートや障害などの突発運用業務が他のアイテムに影響なく実施できることを期待しました」と中井氏は説明する。
結果、Pagerの枠で突発運用業務が吸収されるので、スプリントへの影響を与えにくくなり、障害を気にせず開発アイテムを進められるようになったという。その一方で、Pagerの枠で突発運業務の改善を実施するため、Pagerアイテムのブラックボックス化を招いてしまった。例えば対応不要のアラートが出てきた場合は、そのアラートが出ないようにするための改善や、ユーザーに提供しているドキュメントの不備の修正もPagerの枠で行うことになる。「Pagerという枠に隠れて改善策が見えなくなってしまいました。Pagerアイテムのブラックボックス化をどう改善していくか、これから考えるべき課題となっています」（中井氏）
またある程度の規模を上回るとPagerで対応しきれず、スプリントを中止することもあったという。「このようなことはめったに起きないことですが、昨年末に世界的に影響の大きな脆弱性が発生した際に、このような対応をとることとなりました」（中井氏）
これらの4種類の取り組みからわかるように、運用業務とスクラムは組み合わせにくいというわけではない。扱うには工夫とコツが必要になるというわけだ。
最後に中井氏は次のように語り、セッションを締めた。
「スクラムの検査と適応を、プロダクトだけではなく仕組みに対しても実践していくことで、扱い方をアップデートしていける。そうすることで運用業務とスクラムという一見、組み合わせにくいものでもうまく組み合わせていけると思います」（中井氏）
