チケットは登録するだけでは減らない——運用保守チームにScrumを使った話
以前、大規模ECサイトの運用保守チーム立ち上げに関わったことがある。
そこには、さまざまな依頼が集まっていた。
不具合報告。
軽度の改善要望。
システム化されていない定型的な業務依頼。
たとえば、データ抽出や調査依頼のようなものだ。
こうした依頼をチケット管理システムに登録して管理すること自体は、珍しい話ではない。
ITSMの現場ではごく自然な運用だと思う。
ただ、チケットを登録しただけでは、チケットは減らない。
チケット管理システムは、依頼を可視化してくれる。
だが、チームがどの順番で、どの量を、どのリズムで消化していくかまでは決めてくれない。
ここに、運用チーム立ち上げ時の難しさがある。
ITILだけでは、チームの動き方までは決まらない
ITILやITSMの知識は、運用チームにとって重要だ。
インシデント管理。
サービス要求管理。
問題管理。
変更管理。
こうした分類や考え方を持っていないと、運用チームは依頼の種類を整理できない。
一方で、実務ではもう一段具体的な問いが出てくる。
今週、どのチケットを消化するのか。
突発対応が入ったとき、どこまで予定を崩すのか。
未完了になったチケットをどう扱うのか。
チームの処理能力をクライアントにどう説明するのか。
これは、ITSMの分類やプロセスだけでは埋まりにくい領域だ。
そこで、Scrumの考え方を部分的に取り入れた。
1週間スプリントでチケットを消化する
やったことはシンプルだ。
スプリント（タイムボックス）は1週間。
月曜日にスプリントプランニングを行う。
その週に対応する予定のチケットを決める。
金曜日には出来高を確認する。
完了したチケット、未完了のチケット、翌週に持ち越すチケットを整理する。
その結果をクライアントに報告する。
毎朝、デイリースクラムに相当する朝会も行った。
昨日、何が終わったか。
今日、何をやるか。
想定外の事象は起きているか。
誰かが詰まっていないか。
これだけでも、チームの見通しはかなり良くなった。
運用保守の現場では、予定どおりに進まないことが多い。
突発的な障害、緊急の調査依頼、クライアント都合の優先順位変更もある。
だからこそ、毎朝の短い確認が効いた。
ベロシティ（処理速度）が見えると、説明できるようになる
この運用で特に効果があったのは、チケットの週次消化数が見えるようになったことだ。
毎週、何件のチケットを完了できたのか。
どの種類のチケットが多かったのか。
突発対応によって、予定チケットがどれだけ押し出されたのか。
これらを記録すると、チームのベロシティが見えてくる。
もちろん、開発チームのScrumのように、ストーリーポイントできれいに測れるわけではない。
ITSMのチケットには、粒度のばらつきがある。
5分で終わる調査もあれば、複数日にまたがる調査もある。
関係者確認が必要で、チーム内では作業が終わっていても、完了扱いにできないものもある。
それでも、週次の出来高をグラフ化すると、クライアントへの説明材料になる。
今週は何をしたのか。
チームの処理能力はどの程度か。
突発対応によって、通常チケットの消化にどのような影響が出たのか。
感覚ではなく、見える形で説明できるようになる。
週次報告書が定型フォーマットに穴埋めするだけで作れるようになった。
これは、運用チームにとって大きい。
Scrumをそのまま適用したわけではない
ここで重要なのは、Scrumを厳密に導入したわけではないということだ。
ITSMの現場には、ITSM固有の事情がある。
障害対応は待ってくれない。
緊急度の高い依頼は、スプリント中でも割り込んでくる。
チケットの粒度は一定ではない。
関係者確認待ちで、チームの手を離れても完了にできないチケットもある。
複数週にまたがるチケットもある。
そのため、Scrumを教科書どおりに適用しようとすると、かえって無理が出る。
大事なのは、Scrumの形式を守ることではない。
週のはじめに予定を決める。
毎日、進捗と障害を確認する。
週の終わりに出来高を確認する。
結果を見える化して、次の計画に活かす。
このリズムを運用チームに持ち込むことだ。
複数分野の知識は、こういうところで効く
この経験が面白かったのは、ITSMとScrumを横断していたことだ。
ITSMだけを見ていると、チケットの分類や管理に意識が向きやすい。
Scrumだけを見ていると、プロダクト開発の文脈に引っ張られやすい。
だが、実際の現場では、その中間に課題がある。
チケットはある。
チームもある。
依頼も次々に来る。
しかし、チームとしてどう消化するかのリズムがない。
そこにScrumの考え方を部分的に持ち込むと、運用が安定することがある。
これは、Scrumを知っているからできたというより、ITSMとScrumの両方を知っていたからできたことだと思う。
知識は、単体で使うものとは限らない。
ある領域の知識を、別の領域の未整理な部分に当てることで、実務上の解決策になることがある。
ITSMチーム運営にScrumを取り入れた経験は、その一例だった。
このnoteでは、プロジェクトマネジメント、資格、AI時代の働き方、組織の中での判断について、実務を通じて考えたことを書いています。
併せて読んでほしい関連記事：
