システム運用のDX推進に向けた検討ステップ

従来、多くのシステム運用部門では、ITによる効率化が十分に検討されてきておらず、属人化や人手による手作業での対応が当たり前のように行われてきました。
近年、ワークスタイルの多様化に伴い、お客様環境でのクラウドサービスの利用拡大や、それに伴うセキュリティリスクの増大など、システム運用部門において、外部環境の変化に伴う様々な課題に柔軟に対応するため、システム運用のDX推進が緊急の課題となってきました。

最近増えている取り組みテーマ

最近、特に多くのお客様から「取り組みたい課題」として要望が上がっている項目を以下に記載します。
これらは、いずれもシステム運用のDX推進としての重要なテーマであり、高優先度で取り組みを開始される事例が増えています。

◆システム運用の高度化/自動化
現場担当者の作業負荷の軽減や属人化排除を目的に、従来人手で実施していた業務を抜本的に見直し、極力人手を排除して、自動化を目的としたデジタルワークフローとして再整備するという取り組みです。
整備にあたっては、ITSMツールで業務フローを定義して、手動作業はRBA/RPAツールで置き換え、運用業務全体の高度化を目指していきます。
これを実現することで、運用コスト削減だけでなく、故障対応の迅速化や、運用品質（サービスレベル）の向上も達成することが可能となります。

◆構成管理/資産管理の整備（CMDBの構築）
企業内に散在しているIT資産や構成管理情報を一元管理することで、適正なライセンス契約に基づいた利用を促し、コストの最適化やコンプライアンス遵守につなげたいという要望です。
特に、昨今、金融機関におけるシステム障害やサイバーセキュリティに対する対策の強化も求められており、この取り組みが、脆弱性管理への活用、さらには、故障対応での影響分析の把握やシステムの安定稼働にも寄与することができます。

失敗してしまう取り組みパターン

前述したような課題を解決すべく、システム運用のDX推進を開始されるお客様が増えていますが、最初に取り組みの方向性を誤ってしまうと、施策導入後も十分な効果を得ることができずに、結果として失敗に終わってしまうこともありますので注意が必要です。
以下によくある失敗パターンを記載します。

現場の運用作業プロセスをそのままデジタルフロー化する

現場の運用業務の作業フローをそのままデジタルフロー化しようとしてしまうパターン。
この場合、現場担当者主導で検討を進めることが多く、担当者の慣れ親しんだ作業フローを機械的に実装してしまい、業務改善もないまま、ツールの導入を目的としてしまう。
本来は導入検討時に運用業務のBPRも合わせて実施する必要がある。

（例えば・・・）
非効率な手作業ベースの業務プロセス（不要な承認フローの繰り返しや多数の関係者への通知の踏襲など）をそのままITSMツールに実装してしまう。
その際に、画面や入力項目も、以前利用していた表計算ソフトの項目をそのまま利用してしまい、結果として、ツール実装のための工数やメンテナンス費用、ライセンス費用のみが増大して、運用業務の効率化ができず、高価なツールで既存業務と同じフローを実装して終わってしまう結果となった。

現行業務範囲を超えたToBeをゴールにしてしまう

現行業務のコストやサービスレベルを考慮せずに、理想の業務プロセスであるToBeのみを設定してしまい、関係者との調整やコストの見直しもないまま、既存の運用業務の範囲を超えたToBeに向けて実装をおこなってしまうパターン。
これにより、既存作業への追加や新規作業が多く発生してしまい、結果として、新たな作業とその運用品質の維持を含めた大幅な作業工数の増加となってしまう。
本来は、理想であるToBeを踏まえて、上位方針やコスト、関係者との調整を元にCanBeを設定する必要がある。

（例えば・・・）
構成管理のDX推進に伴い、これまで管理していなかったサーバのインベントリ情報（パッチ情報等）までCMDBで詳細に管理することで、その対応稼働や維持工数（棚卸作業等）が増大してしまった。
これにより、関連部門との契約範囲以上の運用業務（構成管理作業）を実施してしまい、費用対効果に見合わない作業をおこなうことで、現場担当者も疲弊してしまった。

ポイントを絞って現状の運用業務の可視化からスタートする

「失敗してしまう取り組みパターン」に記載したような問題が発生してしまう大きな要因としては、現行の運用業務の可視化や分析が十分にできていない状況からスタートしてしまうことです。
このため、取り組みの最初のステップとしては、現行のシステム運用業務を把握することから開始することが重要です。
現行の業務の作業概要の把握と共に、作業工数や提供品質、コスト、関係者、利用ツール、課題などを整理していきます。
可視化の作業というと、全ての運用業務を隅々まで分析するというイメージで、大人数で何ヶ月もかけて実施すると思われるかもしれませんが、ここでは、既存ドキュメント（「運用業務一覧/作業チーム」や「運用業務フロー」、「作業工数概算」など）をベースに全体を大まかに把握して、対象とするスコープを絞り込むことからスタートします。
まずは1-2週間程度でざっくりと優先的に対処する運用業務の絞り込みをおこないます。
その後は対応可能な期間に応じて、優先度の高い業務から分析を進めていきます。
検討スコープの優先度付けの方法としては、以下のような観点がありますので参考にしてください。

工数が最も多くかかっている運用業務に絞る
手動作業が多い業務や、他部門との調整や上位承認を含む業務などの工数が多い業務にフォーカスする
（例：監視メッセージの人手での対応作業や、環境変更時の各部門への承認の連絡対応など）
自動化による効果が大きい運用業務に絞る
イベント管理やインシデント管理、レポート作成や通知等、一般的に自動化による削減効果が大きい業務にフォーカスする
（例：故障通知の自動対処（イベント管理）、ダッシュボードによるリアルタイム表示（レポート作成）など）
高優先度で取り組む方針の運用業務に絞る
会社の上位方針として高優先度で取り組むべき方針が出ている運用業務にフォーカスする
（例：セキュリティ対策強化のための構成管理、脆弱性管理等）

検討スコープの優先度付けの観点例

現行のシステム運用業務を可視化から目標設定する際に利用するフレーム例とその使い方を紹介します。