コンサルタントのコラム
IT運用マネジメント力の向上
~IT運用業務の見える化~
2011年9月(2020年10月改訂)
はじめに
今回のテーマである「IT運用業務」は情報システムを安定的かつ効率的に運用し、IT投資の効果を最大限引き出すための重要な機能です。
しかし、当社が提供するITマネジメントレベル簡易診断の結果をみると、多くの企業でシステム運用は他の領域に比べてレベルが低く、「IT運用業務」が自社の現状に満足できるレベルだと考えている企業は少ないのが実態です。
本コラムでは、IT運用マネジメント力向上に不可欠な「IT運用業務の見える化」のポイントについて考察します。IT運用業務の見える化は、IT運用人材の育成や、運用業務でのアウトソーシング活用検討のベースにもなります。
IT運用業務見える化の重要性
IPA(独立行政法人情報処理推進機構)の「IT人材白書2011」によるとユーザ企業内におけるIT人材の中で、「社内システムの開発・導入・保守」に次いで、人数が多いのがIT運用業務・管理に関わる人材です。
「社内システムの運用管理計画策定」と「社内システムの運用・管理実施」の人数を併せると全体の31.6%が運用に携わっています。
【ユーザー企業側(IT利用側):共通キャリア・スキルフレームワーク人材像別人材数推計結果】
IT 戦略策定・IT 企画 (12.2%)
IT 投資案件のマネジメント (12.0%)
社内IT基盤の設計 (10.6%)
社内システムの開発・導入・保守 (25.6%)
社内システムの運用管理計画策定 (14.3%)
社内システムの運用・管理実施 (17.3%)
運用のアウトソースには見える化が必須
一方で、「子会社等外部への委託を進めたい業務」は、「社内システムの運用・管理実施」が、35.1%と一番多く、企業では自社で抱えた運用要員をマネジメント領域等に移行しつつ、運用業務はアウトソースしていきたいと考えていると言えます。この傾向は、昨年からほとんど変わっていません。
筆者も、企業のIT部門の方々から運用は面倒だからアウトソースしたい・・・という意見を良く聞きますが、一気にはアウトソースが進まないのが現状です。
一気に進まない原因としては、企業側とアウトソースを担当するITベンダーとの認識ギャップが大きく影響している様に思います。
企業側は、「運用は面倒だし、中身が良く分からないからアウトソースしたい」と考えますが、中身が分からない状態は、ITベンダー側では「お客様の困っている状況が漠然としていて、お客様が求めている要件がはっきりしない」ということにつながってしまいます。
お互いの漠然として中身が分からない状態から抜け出すためには「IT運用業務の見える化」を図っていかなければなりません。
「見える化」するということは、IT運用業務の現状を把握して、運用基準の設定と測定を行い、実態を改善出来る状態、即ちマネジメントできる状態にしていくことです。
IT運用業務の見える化における2つの視点
IT部門に十分なリソースが割り当てられ、運用の専任者が配置されるような大企業に比べて、中堅中小企業の場合は、一人の担当者がITの企画から調達、開発・導入、運用までを担当したりするケースが多いのが現状と思われます。
こういった企業では、IT運用業務がマネジメント出来ていないことで起きる問題があります。
運用担当者によって作業品質や作業範囲にばらつきが起きたり、特定の運用担当者に依存しすぎて、作業のボトルネックが発生したり、これらは「サービス範囲や作業分担(社内外含む)」の問題と言えます。
また、サービスレベルが不明確なために、障害やトラブルがそのまま利用者の不満になり、その不満が運用担当者のモチベーションを下げ、またミスが起きるという悪循環ともなる「サービス品質に対する利用者と運用者のギャップ」の問題が発生することもあります。
こういった問題点から「運用の見える化」の視点は、下記が考えられます。
- 「サービス範囲や作業分担(社内外含む)」の問題→作業範囲・分担の見える化
- 「サービス品質に対する利用者と運用者のギャップ」の問題→サービス品質の見える化
作業範囲・分担の見える化
作業範囲や分担を明確にすることで、以下の様な効果が期待できます。
- 運用担当者個々人の役割や責任範囲が明確になる
- 各プレーヤー間(運用者、利用者、ITベンダー)の役割分担の認識違いがなくなる
- 作業量の見積精度が上がる 化
また、明確になった作業範囲をもとに自社で実施すべき作業と自社で実施すべきでない作業の切り分けが可能になり、リソース配分見直しやアウトソーシング検討に活かすこともできます。
作業範囲明確化の進め方
- 作業項目の整理(実施すべき作業項目一覧)
- 現状作業範囲の調査
整理すべき作業項目は、現在の担当者から現状業務のヒヤリングから帰納的なアプローチで作成することも可能です。
しかし、ガイドラインなどを参考に演繹的なアプローチで整理した方が、実施すべき事項の中で自社が出来ていないことを明確にすることにも役立ちます。
ガイドラインのベースに自社に合うよう取捨選択・追加/修正をして、粒度にも気をつけて纏めていくとよいでしょう。
参考になるガイドラインとして、IPAの情報システムユーザスキル標準(UISS)や共通フレームワーク(SLCP-JCF2007)、経済産業省の「システム管理基準」などがあります。
UISSの定義を参考にすると、システム運用の作業項目としては以下の様な内容になります。
作業項目 | 作業内容 | |
---|---|---|
1 | システム管理計画 | (1) システム管理要件の定義、(2) システム管理サービスの明確化、(3) サイトの選定と配置、(4) サービスに対する費用/対価の算出、(5) 運用ルールの作成、(6) システム管理計画書の作成 |
2 | システム管理 | (1) システム運用、(2) ユーザー管理、(3) オペレーション管理、(4) 課金管理、(5) コスト管理、(6) 要員管理、(7) サイト管理 |
3 | 資源管理・変更管理 | (1) ハードウェア管理、(2) ソフトウェア管理、(3) データ管理、(4) ネットワーク資源管理、(5) 施設設備管理 |
4 | リリース管理 | (1) リリースの計画・準備、(2) リリースの実施 |
5 | 構成管理 | (1) 構成管理計画・設計、(2) 構成管理の実施 |
6 | 問題管理 | (1) 問題の監視、(2) 問題の特定、(3) 問題の解決・回復処理、(4) 再発防止・予防処置、(5) 問題の記録 |
7 | セキュリティ管理 | (1) セキュリティ侵害の監視と状況分析、(2) セキュリティ強度の確認、(3) セキュリティ監査対応、(4) セキュリティ対策の実施 |
8 | 性能管理 | (1) 性能評価の実施、(2) 性能管理 |
9 | システム移行 | (1) 移行の準備、(2) 移行の実施、(3) 運用引継ぎ |
10 | 運用に関するシステム評価 | (1) 評価目的・評価対象・評価項目・評価基準の設定、(2) 評価の実施、(3) システム改善提案 |
11 | システム利用者対応 | (1) ユーザーサポート |
これら作業項目を誰が実施しているのか、その作業のアウトプットは何かといった内容をまとめます。
このアウトプットは「SOW(Statement Of Work)」と呼ばれ、日本語でも「作業範囲記述書」「作業記述書」「役務記述書」「業務仕様書」などと様々な表現で呼称されています。
作業分類 | 作業項目 | 作業内容 | 担当 | アウトプット | |||
---|---|---|---|---|---|---|---|
責任者 | 担当者 | ITベンダ | 利用者 | ||||
システム管理計画 | システム管理要件の定義 | 作業範囲を明確にして記述書を作成する | ◎ | ○ | △ | SOW | |
システム管理 | オペレーション | ◎ | |||||
・・・・ |
主担当:◎、サブ担当:○、支援:△
サービス品質の見える化(SLA・SLM)
サービス品質の見える化は、サービス品質の水準(レベル)を定めて、測定できる状態にすることが重要です。
サービス品質の水準を定めて、そのマネジメントを行う・・・この考え方がSLA・SLMです。
本コラムでは、下記のように捉えています。
-
SLA
サービスを提供する側と、その利用者との間に結ばれるサービス品質の定義とその内容に関する約束事
-
SLM
SLAを効果的に利用し、サービス品質を継続的に改善する管理手法
SLA・SLMのメリット
サービス品質は、サービスの提供する側と受ける側双方に見える化が必要ですが、SLA・SLMの活動は、サービスの受け側・提供側それぞれで下記のようなメリットがあります。
-
受け側
- 希望するサービスレベルが明確になる
- IT利用にかける労力やコストに見合ったサービスを受けることに繋がる
- クレームになるかどうかの判断ができる
-
提供側
- サービスに対する要求品質や内容が明確になる
- サービスの適切さを説明できる
- 自らが何をすべきかの品質目標レベルが分かる
- 運用担当者のモチベーションが維持・向上できる
IT業務の局面においてのSLAの内容明確化
IT運用業務の局面では、利用者、運用者、ITベンダーの3者の関係で、SLAの内容を明確にしていくことが必要です。
既にITベンダーに運用業務をアウトソースしている企業の場合は、運用者は利用者へのサービス提供の立場と、ITベンダーからサービスを受ける立場の両面があります。
したがって、下記のようにSLAの内容を明確化にします。
-
社内SLA
利用者とのサービス品質水準の約束事
-
社外SLA
ITベンダーとの約束事
社内SLAと社外SLA
サービス品質見える化の進め方
- SLA項目の設定
- SLMの方法検討
- SLMの実行
SLA設定は、ITを使ったサービス提供が「“システム構成要素(ハード・ソフト等)”の機能を、運用者の“作業プロセス”を通じて、利用者に対する“サービス提供”を行うこと」に着目して、3つの分類で考えることができます。
SLA設定の3つの分類指標分類(対象) | 説明 | 指標例 |
---|---|---|
サービスレベル指標(サービス提供) | 利用者に直接影響を与える指標で、利用者から見たサービス品質を計る指標 |
|
プロセス指標(作業プロセス) | システム運用の作業プロセスにおける有効性や効率性を示す指標 |
|
システムパフォーマンス指標(システム構成要素) | システム構成要素の可用性やパフォーマンスを示す指標 |
|
「プロセス指標」は、「SOW(作業範囲記述書)」の中で運用者の役割として記載した項目に対する水準の設定です。
SLAとSOWは密接な関係にありますので、後述するSLMの活動では、両者の見直しを視野に活動することが必要です。
これらの指標に対して、評価値や測定方法を定義して、「SLA仕様書」などの文書にまとめます。
SLAの仕様書の例
SLMによる継続的改善
SLMの目的は、『サービス品質に対する、合意、監視、報告、レビュー、およびプロセスの改善を行い、投入するリソース(費用、労力など)に見合ったサービス品質の維持、さらにはサービス品質を継続的に向上させること』です。
SLMによる継続的改善イメージ
SLAの設定と合わせて、その管理手法であるSLMの方法についても明確になっていなければなりません。
最低限以下の項目は決めておくことが必要です。
- レポート内容、頻度(毎月、四半期、半期、年間)
- レビュー方法、頻度(毎月、四半期、半期、年間)
- 見直し対象(SLA・SOW)
SLMを無理なく進めるためには、現実的な対象範囲でのSLAの設定・合意、監視から始めて、徐々にその範囲を広げていくことがアウトソーシングの活用を含めた継続的改善につながります。
現実的なSLAとしても、実績がない状態では、水準が分からないため、試行的な要素を含むトライアルSLAの設定・監視(ステップ1)から、正式なSLAの設定・監視(ステップ2)を経てSLM本格運用(ステップ3)に段階的に取り組む必要があります。
本運用までは、短くても半年、長ければ1年以上かかります。
アウトソースの活用が一気に進まないひとつの要因ではありますが、実態の把握の先にしか改善はありません。地道な取組が必要です。
SLM本格運用までのステップ
まとめ
企業では、社内のIT要員の中でも多数を占める運用要員について、業務範囲をマネジメント領域にシフトできるように人材育成しながら、アウトソースの有効活用を図っていく必要があります。
アウトソースの活用に当たっては、企業側とアウトソーサとなるITベンダー側の認識のギャップの要因となっている運用業務の中身を見える化することです。
本コラムで「作業範囲」と「サービス品質」の2つの側面から運用業務を見える化する方法について述べてきました。
また、SLMという継続的な改善の方法についても触れました。
IT運用マネジメントができる人材が不足している企業において、運用業務の整理・想定、改善というサイクルを確立して、運用人材の育成とアウトソーシングの有効活用が実現されることを期待しています。
参考文献
- 「IT人材白書2011」 独立行政法人情報処理推進機構(IPA)
- 「情報システムユーザスキル標準 ver2.2」 独立行政法人情報処理推進機構(IPA)
執筆
NECネクサソリューションズ
コンサルタント 松吉 賢幸
[公認情報システム監査人(CISA)、システム監査技術者]
本コラムに関連するコンサルティングサービス
- ITマネジメントレベル簡易診断
IT部門が取り組むべき課題を見つけて、マネジメントのレベルアップを支援します。