アジャイルガイド · ソフトウェア以外のアジャイル
IT運用におけるアジャイル：運用チームによるアジャイルとDevOpsの活用
IT運用におけるアジャイルとは、見える化された作業、短いフィードバックループ、継続的改善といったアジャイルの価値観とプラクティスを、インフラ、ネットワーク、サービスデスク、本番システムを運用するチームに適用することです。運用の仕事は計画したプロジェクトと計画外のインシデントが混在するため、運用チームはかんばんと、DevOpsを通じた開発との緊密な協働を好む傾向があります。
要点
- 運用チームは、すべての作業を見える化し、割り込みを見越して計画することでアジャイルを適用します。
- 運用には通常、厳格なスプリントよりも、サービスクラスとWIP制限を備えたかんばんの方が適しています。
- 計画外の作業のためにキャパシティを確保し、自動化に着実に投資しましょう。
- DevOpsを通じた開発との緊密な協働により、効果はさらに大きくなります。
運用が異なる理由
開発チームは通常、スプリントを計画してそれを守ることができます。運用チームは、インシデント、サービス要求、セキュリティパッチ、緊急の変更といった割り込みに絶えず直面します。厳格なスプリントのコミットメントは数日で崩れることがよくあります。それでもアジャイルは役立ちますが、プラクティスを調整する必要があります。
| 作業の種類 | 例 | 典型的なアプローチ |
|---|---|---|
| 計画外 | 障害、セキュリティアラート、緊急の修正 | 特急レーンで即座に対応 |
| 定型的な依頼 | 新規ユーザーアカウント、アクセス権の変更 | 可能な限り標準化・自動化し、ボードで流す |
| 計画した改善 | データベースクラスターのアップグレード、バックアップの自動化 | 小さなアイテムに分割し、バックログで優先順位を付ける |
| 保守 | パッチ適用、証明書の更新 | キャパシティを確保した定期的な作業としてスケジュールする |
運用チームで機能するアジャイルのプラクティス
- WIP制限付きのかんばんボード： すべての種類の作業を見える化し、進行中の量を制限します。参考： WIP制限.
- サービスクラス： インシデント用の特急レーン、期限のある作業用の固定日レーン、その他すべてのための標準レーン。参考： かんばんのスイムレーン.
- 確保したキャパシティ： 自チームの実績に基づき、キャパシティの一部（たとえば30～40%）を計画外の作業のために確保します。
- ボードの前での短いデイリースタンドアップ： ブロックされたアイテムと滞留しているアイテムに焦点を当てます。
- 定期的なレトロスペクティブとインシデント後のレビュー： 具体的な改善につながる、非難のないレビュー。
- バックログの作業としての自動化： 繰り返し発生するタスクの自動化を、計画した改善アイテムとして扱います。
- 開発との共同オーナーシップ： 共同のオンコール、共有のメトリクス、Infrastructure as Code。参考： DevOps.
運用チームにアジャイルを導入する方法
- すべての作業を見える化する： 他は何も変えずに、インシデント、依頼、プロジェクトを2～4週間、1つのボードに載せます。
- 作業の内訳を測定する： 計画外の作業と計画した作業の量を数えます。
- サービスクラスとWIP制限を設定する： 計画した作業に割り込めるものについてのルールに合意します。
- キャパシティを確保する： 測定した計画外の作業に見合う分を確保します。
- 改善作業を優先する： 明確な担当者を決めて、自動化と信頼性向上のアイテムのバックログを作成します。
- ケイデンスを追加する： 週次の補充ミーティングと隔週のレトロスペクティブから始めるのがよいでしょう。参考： かんばんのケイデンス.
- メトリクスを毎月見直す： 次を確認します： サイクルタイム, スループット とインシデントの傾向を確認し、適応させます。
計算例
6人のインフラチームが4週間分の作業を記録したところ、完了したアイテムの45%が計画外であることがわかりました。チームはキャパシティの約半分を計画外の作業のために確保し、同時に1件までに制限した特急レーンを導入し、ボード全体でWIP制限を8に設定しました。毎週、バックログから上位の改善アイテムをプルします。2か月後、チームは最も頻度の高い3つの依頼（レガシーシステムのパスワードリセット、テスト環境の構築、ログへのアクセス依頼）を自動化し、計画外の作業の割合は約3分の1に下がりました。標準的な依頼の平均サイクルタイムは8日から4日に短縮されました。
アジャイルな運用のメトリクス
| メトリクス | 重要な理由 |
|---|---|
| サービスクラスごとのサイクルタイム | 作業の種類ごとにどれだけ早く完了するかを示す |
| スループット | チームが週に完了するアイテム数を示す |
| 計画作業と計画外作業の比率 | 改善作業が割り込みを減らしているかを示す |
| 平均サービス復旧時間 | チームがインシデントからどれだけ早く復旧するかを示す |
| 変更失敗率 | 変更がどれだけの頻度で問題を引き起こすかを示す |
| サービスレベルの達成状況 | 合意した目標が達成されているかを示す。参考： サービスレベル合意書 |
よくある間違い
- 割り込み主体のチームに、2週間のスプリントのコミットメントを強制する。
- 計画外の作業をボードに載せず、忙しいのにチームが手持ち無沙汰に見える。
- 改善のための時間を一切確保せず、同じインシデントが繰り返し起こる。
- アジャイルとITサービスマネジメントのフレームワークを敵対するものとして扱う。それらのプロセスはアジャイルな働き方と共存できます。
- 開発と運用を厳しく分離しすぎて、問題が壁越しに投げ渡される。
このトピックの無料テンプレート
よくある質問
IT運用チームはアジャイルな運用のプラクティスを使えますか？
はい。計画外の作業に対応できるように調整して使います。通常は、かんばん、確保したキャパシティ、開発との緊密な協働を組み合わせます。
アジャイルなIT運用にはスクラムとかんばんのどちらが適していますか？
割り込みの継続的な流れに対応できるため、通常はかんばんの方が適しています。計画したプロジェクト作業が中心のチームはスクラムを使えます。参考： かんばんとスクラムの比較.
アジャイルな運用チームはインシデントにどう対処しますか？
緊急の作業が通常の待ち行列を飛び越えられる特急レーンやサービスクラスを使い、同時に進める特急アイテムの数を厳しく制限します。
アジャイルな運用とDevOpsの違いは何ですか？
アジャイルな運用はアジャイルのプラクティスを運用チームの内部に適用するものです。一方、 DevOps は開発と運用を結び付け、ソフトウェアの構築、リリース、運用を共同で行う方法です。
アジャイルな運用チームは計画外の作業のためにどのくらいのキャパシティを確保すべきですか？
自チームの実績に基づいて決めましょう。数週間分の作業を記録し、計画外の割合を測定して、その程度の量を確保します。
アジャイルなIT運用はITILと併用できますか？
はい。ITILはサービスマネジメントのプラクティスを、アジャイルはチームの働き方を説明するものです。多くの組織が両方を使っています。
アジャイルな運用チームはどのようなメトリクスを追跡すべきですか？
サイクルタイム、スループット、計画作業と計画外作業の比率、サービス復旧時間、変更失敗率、サービスレベルの達成状況です。
アジャイルな運用チームにプロダクトオーナーは必要ですか？
多くのチームは、改善作業の優先順位を付け、依頼のバランスを取る担当者がいると効果があります。これをサービスオーナーと呼ぶこともあります。
アジャイルな運用チームはスタンドアップをどう行いますか？
ボードの前で短く行い、個人の進捗報告ではなく、ブロックされたアイテム、滞留しているアイテム、特急のアイテムに焦点を当てます。
アジャイルな運用における非難のないインシデント後レビューとは？
誰が原因かではなく、システムとプロセスがどのようにインシデントの発生を許したかに目を向け、改善に合意するレビューです。
アジャイルなIT運用に適したツールは？
かんばんボード、依頼の受付、自動化をサポートするツールです。選択肢の比較は次をご覧ください： プロジェクト管理ツール 。