運用へのScrumの適用
運用には様々な業務がありますが、大きく分けると、
1. 稼働している（運用中）のシステムのソフトウェア、サービスの改修業務
2. 定例業務、定例オペレーション
3. 新規ソフトウェア、新規サービスのリリース
です。
それぞれの業務に沿って話を進めます。
■運用しているシステムのソフトウェア、サービスの改修業務への適用
Scrum＋XPのプラクティスに沿って適用していくことが可能です。
この改修要求の記載方法はどのようにしていますか？
ITILではRFC（Request for Change）があります。この改修要求の記載方法を、Scrumのバックログに記載するユーザー・ストーリーを使用してください。
とくに改修要求が多く発生して、その整理に忙殺されているような場合、このユーザー・ストーリーを正しく使うと、個々の改修要求の優先順位付けをやり易くしてくれます。特にビジネス的価値が認められない、要求に関しては受付を却下する判断にも役に立ちます。
複数の改修要求をプロダクトバックログとしてシステム毎に一纏めにして管理する事で、改修要求の優先順位付けもScrumで実践している様に行えます。
そして、適時SLAの内容を照らしわせて見直す事も必要です。
当然、このリストの管理はプロダクト・オーナーと同じ役割を持つ運用担当者を設けて開発と同じように実施します。
スプリントの期間はどの程度が良いでしょうか？
まずは、ご自身のチームの能力に合わせてこの期間を設けるのが良いと思いますが、能力を見える様にして、チームの成長を確認しながら、この期間を短くすることをお勧めします。マイルストーンとして二週間以内、そして、成熟度にあわせて更に短くします。
なぜ、この期間を、より短くする必要があるのでしょうか？
経営効率を高める為のJIT（Just in Time）の大前提の一つに後工程引取りという考えがあります。これは、後工程は必要な時に、必要なものを必要なだけ前工程から引取り、前工程は引き取られた分だけ生産する仕組みです。
これを読み換えると、ユーザーは必要な時に自分が望むシステムの機能をユーザーが望む量のデータを処理出来るように、運用チームへ要求します。運用チームはそれが実現できる分のサービスを提供します。
あるべき姿（理想）では、今必要であれば今となりますので、極論を言えば、直ちにです。ですから、期間は短くするという姿勢、心構えで臨む必要があります。
運用チームはユーザーが接しているビジネス現場のスピードに合わせた、もしくはそれ以上のスピードで自らの業務を行える事が課題になってくるでしょう。
昨今の社会規範により、様々なガイドラインやコンプライアンス上の制約があるので、短くするには限度があるので、理想は論外だという方もいるでしょう。
ビジネススピードは社会規範が整うよりも、早く事態は起こっています。
ある程度で良いとか、この程度の目標で良いと、定めてしまっては緩やかな方に流れてしまい、いつまでたってもJITに近づくことはできません。
数年前にある大手金融機関から商品開発サイクルについて知見を求められた事がありました。
その当時、コンペとなる海外の金融機関では年に7、8種の新しい金融商品を送り出しています。このスピードに敵う方法はあるでしょうか？
という漠然とした相談内容でした。すこし、ヒアリングを進めて行くと金融商品のプロトタイプ評価から様々な工程やレビューがあり、今までのプロセスを踏襲したのでは、海外のそれには追いつくことも出来ないというものでした。
制度、規制というものは時として自らのビジネスのスピードを緩めてしまう側面を持ってます。ですから、各工程の価値や何故必要なのかの議論、精査して、そのプロセスを、よりアジリティを高め成熟度を上げる事は可能です。
その為にも、Scrumのプロセス、イベントの目的を捉えて、自らの組織マネジメントに応用するのはとても良いアイデアを生み出してくれる切っ掛けになると思います。
改修したソフトウェア、アプリケーションを実運用にリリースするか否かの判断はScrumを適用すれば、スプリントレビュー時に行うことになります。
スプリントの品質も完了の定義で明確にして進める事ができます。
■定例業務、定例オペレーションへの適用
運用チームの重要なミッションに定期ジョブを運用するといったシステムの定例運用業務があります。
こちらも、バックログリストに載せて同じように扱います。ただ、年間スケジュール、月間スケジュールがあるでしょうから、そこから週単位として切り出し、さらに日単位に詳細化するのが良いでしょう。
タスクボードは期日管理が出来るように、デザインを考慮すべきです。
例えば、ToDo、Doing、Doneの三つの枠で表すのではなく、当日を締日として、その右側に締日前日（－１日）、締日前々日（－２日）・・・と必要な分（おおよスプリント期間－一日程度）と更にその右側に（Todo）と欄を設けて、締日にあと何日残っているかを直ぐに分るデザインにして、毎朝のデイリースクラムで進捗をボードに貼っているチケットを確認しながら行う方法が良いでしょう。
ある組織では運用定例ジョブの業務、仕事スキルの平準化を、実際に仕事をしながら、実施したい場合にも、タスクボードのレイアウトを工夫する事によって、各メンバー同士の共同作業を見える化して、各メンバーの業務、仕事の平準化を推進する事ができます。
ある別の運用チームではソフトウェア、アプリケーション改修業務と定例業務、定例オペレーション業務の作業レベルのタスクを同じタスクボードで見える化していました。このタスクボードでは、業務の性格を明確にする為に、横枠（レーン）を設けて、例えば上半分がソフトウェア、アプリケーション改修業務、下半分が定例業務、定例オペレーション業務と分り易くする工夫をしていました。
障害対応など緊急時には、タスクボード全面を『緊急対応中』と書かれた布で覆い隠し、その横に対応時間を計測するストップウォッチも同時に掲げていました。SLAで記載した事項を適時、見直しをして整合性を図る事も必要です。
■新規ソフトウェア、新規サービスのリリース
開発チームがScrumを実施しているのであれば、積極的にスプリントレビューに参加することをお勧めします。その際に、日々の運用中の課題やシステム容量、運用状況といた現場の生の情報を把握していることが重要です。この情報から開発チームの成果を評価するだけでは無く、実際にリリースする時、リリース後に自らのチームで滞りなく運用できるのかも評価すべきポイントです。
さらに、障害時復旧訓練、ユーザーへの新たな教育、訓練の必要性もチェックします。
リリースされてから発見、表面化しては手遅れになる事をスプリントレビュー時に確認することです。開発チームがスプリントで定義、宣言した『終了の定義』の内容を確認し、それが遵守されて実施しているかも重要な確認ポイントです。ITILの検視からもこの確認は重要です。
ITILを導入しているのであれば、開発のアジリティに影響を与えないようにするには、何が必須で、何を止めるのか、もしくは開発チームの見える化データでどの様に補え、評価するのか？という観点で研究、実施してください。その際の重要な観点は『ビジネスの継続性（BCP）を重視』し、『ビジネスの変化に即応するアジリティの向上』です。
もし、運用からの評価が悪ければ、その弱点を指摘するだけでなく、明確なプロダクトバックログとして提示して、開発チームへ運用チームからの要望を渡すべきです。
開発チームと運用チームは対等の立場であることを忘れないで、このイベントに望んでください。
毎日、開発チームの現場へ行き、その様子を観察し、様々な見える化を実施しているボードを見てください。
この行動で、開発チームが何に拘っているのか分かってきます。
即ち、単に開発にだけ拘っているのか、品質にも拘っているか、運用リスクにも拘っているのか、障害復旧のし易さへも拘っているか、という観点が必ず、見えてきます。
何か頼りない点があれば、スプリントレビュー時にその点を指摘して、開発チームの成熟度を上げる気付きを与えることも重要な行動の一つです。