運用方法論〜システム運用現場の現状分析 そして運用設計へ 〜

波田野 裕一（運用研究会 / 日本UNIXユーザ会)
2009-11-26 InternetWeek 2009

インターネット運用の現状• インターネットの急速な普及および発展により、インターネットを含むIT情報基盤は社会基盤(インフラ)としての性格を色濃く帯びてきている。

• その一方でシステム運用およびサービス運用の現場においては、要員に対する恒常的な高負荷、属人的な運用、トラブルの多発などにより、事業継続性の面からもコストの面からもリスクを内在させ、効率面での課題を抱えつつも、
現場の個々人の過大な努力により日々の運用を維持しているのが現状である。

0. はじめに本セッションの概要

従来、現場ごとの個別事情によりやり方が異なるため標準化が難しいと言われてきた「運用」
について、運用設計という視点から諸要素を整理しなおし、各現場における諸問題を解消していく上で必要な業務分析および現場レベルでの実践的な運用設計の方法を解説する。

0. はじめに本セッションの目的‣ サービスの安定
社会基盤に相応しい安定運用。

‣ 業務負荷の平準化
個々人ががんばりすぎなくてもうまく業務が回る運用現場。

‣ 運用に対する評価の適正化
運用現場が適切に評価されるようにする。

これらを実現するために、「実践的な運用設計」への取り組みを促進すること。

0. はじめに本セッションで意識してほしいこと✓ 身近な運用現場で何が起きているか✓ その原因が何なのか✓ 解決するには何が必要なのか

0. はじめに本セッションから持ち帰ってほしい事✓ 多くの現場で起きている問題点の例
実は自分のところだけじゃない✓ 多くの問題点における共通の要素とは複雑そうに見える問題点を解きほぐす✓ アクションプランのための材料
まず何に手を付けるべきか

0. はじめにSection. 1
システム運用現場の諸問題

運用現場における典型的な声

1. 運用現場の諸問題

運用現場における典型的な声 (1)✓

業務が多岐に渡り、全てを把握することが困難になっている。

✓

ドキュメントが整備されていない。あっても更新されていない。

✓

どんなドキュメントが必要なのかがわからない。書き方がわからない。

✓

一部の人間にしかできない業務があり、業務が集中している。

✓

属人化が進み、ノウハウの継承ができていない。

✓

異動により現場が混乱することが多い。

1. 運用現場の諸問題

運用現場における典型的な声 (2)✓

人が育たない。優秀な人が入ってこない、定着しない。

✓

がんばっても評価されない。

✓

トラブルが多く、前向きな改善に着手する余裕がない。

✓

ツールが使いにくいが、改修にはコストと期間が必要なため我慢して使っている。

✓

新規のツールを設計したいが、どんな要求があるのか現場でもわかっていない。

1. 運用現場の諸問題

運用現場における典型的な声 (3)✓

サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」など設計側のその場しのぎの影響を直接受ける。

✓

依頼されてから動き出すまでのリードタイムが長い。

✓

声の大きいユーザが強く、必要以上のサポートを強いられる。

✓

コスト削減要求が強いが、どう効率化すべきなのかが見えない。

1. 運用現場の諸問題

何が問題なのか?

1. 運用現場の諸問題

問題点1 対応負荷が高い‣「運用」の守備範囲が不明確な現場が多く、タスクが落ちてきやすく
断わりにくい「なんでも運用」に陥っている。

‣

設計側の都合による「運用でのカバー」や、一部顧客に対する「特別対応」による新規フロー追加が日常的に発生している。

‣

その結果、タスクやフローが多岐にわたり、非効率になるとともにミスを誘発し、ミスに対するリカバリにより更に工数が圧迫されるな
ど、タスクがバーストしやすい状況を恒常的に生み出している。

1. 運用現場の諸問題

問題点1 対応負荷が高い‣ 「なんでも運用」‣ 設計の都合‣ 業務が多岐で非効率

1. 運用現場の諸問題

問題点2 属人的で暗黙知が多い‣

タスクやフローが多岐にわたるために、ドキュメントの作成や更新が追いつかなくなり属人化が生じやすくなっている。

‣

ドキュメント不足はオペレータの教育工数を増加させるとともに「オペレータ品質のばらつき」が「更なる属人化」を促進するという悪循環を生み出している。

‣

これら属人化によりオペレータの異動や退職によるノウハウの消失のリスクを各運用現場では常に抱えていると考えられる。

1. 運用現場の諸問題

問題点2 属人的で暗黙知が多い‣ ドキュメントが無い、古い‣ 属人化への悪循環 (育たないオペレータ)‣ 失われ行くノウハウ

1. 運用現場の諸問題

問題点3 費用対効果が見えにくい‣サービスのライフサイクル上に占める時間的ボリュームが「設計/導入」に比べ圧倒的に大きい「運用」であるが、今日のインターネットサービスにおいては、 新しいサービスを生むことに注意が向くあまり、運用のポジ
ショニングが曖昧で重要視されていないことが多い。

‣

現実には運用のためにキャッシュアウトが発生することから、運用を委託している側からは「運用コストが高い」と認識されやすい。

‣「コストの一律カット」など後ろ向きの「効率化」が横行し、運用の本質的な改善活動を制約し、定常的に現場の負荷が高くトラブルが頻発する要因ともなっている。

1. 運用現場の諸問題

問題点3 費用対効果が見えにくい‣ 重要視されていない「運用」‣ 喜ばない顧客‣ 後ろ向きの「効率化」と士気低下

1. 運用現場の諸問題

システム運用現場の諸問題 (まとめ)1. 対応負荷が高い
2. 属人的で暗黙知が多い
3. 費用対効果が見えにくい

1. 運用現場の諸問題

Section. 2
運用現場における諸問題の要因

2. 諸問題の要因

運用現場における諸問題の3大要因
問題点

要因

1.「運用」への期待が明確でない
2.「運用設計」の不在
3. 期待と消費リソースの紐付けが不明確

1. 対応負荷が高い
2. 属人的で暗黙知が多い
3. 費用対効果が見えにくい

2. 諸問題の要因

諸問題の3大要因 (その1)要因

1.「運用」への期待が明確でない

1. 対応負荷が高い

あらゆるステークホルダからの期待に全て対応するには無限にリソースが必要(どうやっても業務は溢れるし、実際に溢れている)

2. 諸問題の要因

「運用」という言葉の曖昧さ
1.「運用」への期待が明確でない

そもそも「運用」とは何か?
「運用」という言葉の概念が人によって異なることが、運用における最大の問題点と考えられる。
これにより「運用」に関わる各ステークホルダー間において、コミュニ
ケーションロスが生じており、運用に対する期待についても無視できない差異が生じている。

2. 諸問題の要因

諸問題の3大要因 (その2)要因

2.「運用設計」の不在

2. 属人的で暗黙知が多い

運用設計が適切できていないために、自らの業務をきちんと把握できていない。
(業務のブレ、モレを生み、トラブルやミスの要因ともなる。)

2. 諸問題の要因

諸問題の3大要因 (その3)要因

3. 期待と消費リソースの紐付けが不明確

3. 費用対効果が見えにくい「運用」への期待に対応する消費リソースの紐付けが実現できておらず、適切な分析や説明ができない。
(コストが高い! と言われたときに適切な削減もしくは反論ができない。)

2. 諸問題の要因

運用現場における諸問題の要因 (まとめ)1. 運用への期待が明確でない
2. 「運用設計」の不在
3. 期待と消費リソースの紐付けが不明確

2. 諸問題の要因

Section. 3
運用現場における諸問題解消へのポイント3. 諸問題の解消へ

諸問題解消への3つのポイント

要因

ポイント

1.「運用」への期待が

1.「運用」への期待の

明確でない

明確化

2.「運用設計」の不在

2.「運用設計」の確立

3. 期待と消費リソース

3. 期待に対する消費リの紐付けが不明確

ソースの測定化
3. 諸問題の解消へ

諸問題解消へのポイント (その1)
要因

ポイント

1.「運用」への期待が

1.「運用」への期待の

明確でない

明確化

(顧客に対する責任を直接負い予算決定権を持つ)「経営層」を最大のステークホルダーと考え、その経営層から運用への期待を明確化する。
(運用責任を最終的に負うステークホルダーの期待が最も重要である。)

3. 諸問題の解消へ1. 運用への期待の明確化 (まとめ)ポイント

1.「運用」への期待を

慢性的なリソース不足が解消

明確化する

慢性的な業務バーストが解消

適切な運用設計が可能

2.「運用設計」の確立

3. 諸問題の解消へ

諸問題解消へのポイント (その2)要因

2.「運用設計」の不在

ポイント

2.「運用設計」の確立

経営層からの「運用への期待」に対して、「ムリ/ムダ無く」「持続可能な活動」として 短いリードタイムで「的確/柔軟に応えられる体制」を確立する。
(論理的、科学的に「合理的な説明が可能」な運用設計の実現)

3. 諸問題の解消へ2. 運用設計の確立 (まとめ)ポイント「やらないこと」の明確化

2.「運用設計」の確立

運用実績の測定可能化

本当に必要な運用基盤の整備

3. 期待に対するコストの測定化

3. 諸問題の解消へ

諸問題解消へのポイント (その3)
要因

ポイント

3. 期待と消費リソース

3. 期待に対する消費リの紐付けが不明確

ソースの測定化

経営層が拠出したリソースに対して、「運用への期待」に沿う形で、どれくらいの成果を実現したか、説明責任を果たせるようにする。
(あわせて、新たな「期待」の醸成を誘発し、運用の地位向上を果たす。)

3. 諸問題の解消へ3. 期待に対する消費リソースの測定化

ポイント

3. 期待に対する消費リ
ソースの測定化
より高度な「期待」の醸成「運用の効率化」が可能
運用の評価適正化

1.「運用」への期待を明確化する

3. 諸問題の解消へまとめ 諸問題の解消へ
1.「運用」への期待の

慢性的なリソース不足が解消
慢性的な業務バーストが解消

明確化
適切な運用設計が可能
より高度な「期待」の醸成「やらないこと」の明確化

3. 期待に対する消費リ

本当に必要な運用基盤の整備

ソースの測定化「運用の効率化」が可能

2.「運用設計」の確立
運用実績の測定可能化

運用の評価適正化

3. 諸問題の解消へ

諸問題解消による想定効果‣ サービスの安定
社会基盤に相応しい安定運用。

‣ 業務負荷の平準化
個々人ががんばりすぎなくてもうまく業務が回る運用現場。

‣ 運用に対する評価の適正化
運用現場が適切に評価されるようにする。

3. 諸問題の解消へSection. 4運用設計とは

運用現場におけるフレームワークの確立

各現場に適した運用の枠組み(フレームワーク)を作り込むことが、いわゆる「運用設計」である。

4. 運用設計とは

フレームワークとは✓ 物事の整理の手法✓ 客観的な立場から、✓ 科学的手法による測定 (適切な見える化)✓ 論理的手法による分析 (モデル化)✓ 見直しサイクルの構築

4. 運用設計とは

フレームワークが無いと?

✓ 意見や分析が主観的になりがち✓ 感覚値で論じられることが多くなる (非科学的)✓ 論理的な説明がなかなかできない。(非論理的)✓ やりっぱなしになりがち。(非サイクル性)

4. 運用設計とは

フレームワーク化による副次効果‣ ステークホルダ間の共通言語の醸成‣ 現状と理想の差分の明確化‣ 変化に柔軟に対応できる枠組みの構築

4. 運用設計とは

運用のフレームワーク化 ポイント

‣ 負荷を軸にした業務分類‣

突発度、リソース占有度を軸とした分類基準‣ 「現実の直視」と「理想の提示」‣「ポリシーレベル」「ありえない運用」の許容と改善サイクルの実現‣ 業務プロセスの標準化、モデル化‣「作業カタログ」「業務機能ユニット」

標準化による効率化、モデル化による柔軟性確立

4. 運用設計とは

Section. 5運用設計の諸要素

運用設計プロセスのサイクル
運用の定義、期待「運用」への期待を明確化する

運用作業の測定
期待に対する消費リ
ソースの測定化

作業カタログの整備「運用設計」の確立

運用基盤の整備

5. 運用設計の諸要素

運用設計 2つのアプローチ
運用の定義、期待「運用」への期待を明確化する

本来の運用設計
経営層の期待からの運用設計

ボトムアップアプローチ

運用作業の測定
期待に対する消費リ
ソースの測定化

現場の実状からの作業カタログの整備

トップダウン
アプローチ「運用設計」の確立

運用基盤の整備

設計

今すぐ始められる
運用設計
5. 運用設計の諸要素

トップダウン アプローチ
経営層の期待からの運用設計「運用」への期待を明確化する経営層との合意

運用の定義、期待

作業カタログの整備「運用設計」の確立
運用現場

運用基盤の整備期待に対する消費リ
ソースの測定化運用作業の測定

5. 運用設計の諸要素

ボトムアップ アプローチ
現場の実状からの運用設計

作業カタログの整備「運用設計」の確立
運用現場
期待に対する消費リ

1周目

ソースの測定化

2周目「運用」への期待を明確化する経営層との合意

運用基盤の整備

運用作業の測定運用の定義、期待本セッションでは、現場ですぐ着手できるボトムアップ アプローチで解説する。
5. 運用設計の諸要素

運用設計の前提「運用」とは?

「運用」の定義
運用の定義

そのもののもつ機能を生かして用いること。活用。
(大辞泉)

運用とは、運用組織の外部に対して、安定的に何らかのサービスを提供し続けること、を言う。

5. 運用設計の諸要素

「サービス」の定義と特性
運用の定義「ヒト、モノ、システムなどの要素を組み合わせ、顧客に価値を提供する活動」のことを言う。
サービスは手にとって見たり触ったりすることのできない、形のない商品。
• 無形性• 生産と消費の同時性• 不均質性• 消滅性 (作り置きができない)

5. 運用設計の諸要素

「サービス」のプレイヤー (ITIL v3)
運用の定義

サービス設計サービス導入/廃止

Service
DesignService
Transition

サービス企画

Service
StrategyService
Operation
ITサービスのライフサイクル (ITIL v3)

サービス運用

5. 運用設計の諸要素

「サービス運用」の範囲 (ITIL v3)
運用の定義

専門性の異なる業務が、一緒くたに「運用」と現状では捉えられている。

サービス本質サービス導入/廃止

サービス設計サービス機能の変更の変更
ITサービスのライフサイクル (ITIL v3)

サービス運用

サービス機能の活用

5. 運用設計の諸要素

厳密には「運用」ではないもの (ITIL v3)
運用の定義

運用組織で実施することに問題はないが、異なる業務設計思想とベストプラクティスがあると考えられるため、(狭義の)「運用設計」上は「専門外業務」と捉える。
サービス本質の変更

サービス設計サービス導入/廃止

サービス機能の変更

ITサービスのライフサイクル (ITIL v3)5. 運用設計の諸要素

専門としての「運用」の範囲 (ITIL v3)
運用の定義

運用組織は少なくとも、「サービス運用」について、高度な専門能力を持つべき。
サービス運用

サービス機能の活用

ITサービスのライフサイクル (ITIL v3)5. 運用設計の諸要素

「サービス運用」まとめ
運用の定義‣ 現状の「運用」では専門性が混在‣

サービスの「設計」「導入/廃止」「運用」では専門性が異なる‣ 「サービス機能の活用」が運用の本旨‣

サービス活用(安定、向上)のための思想を設計サイドに助言する‣ 「サービス運用の専門性」を意識‣

各現場での「サービス運用」のベストプラクティス確立が必要

5. 運用設計の諸要素

「運用効率化」のために運用の定義「入口」戦略✓ 運用効率化には、運用を意識し「運用」を意識しない
自由なサービス設計

サービス毎に異なる「運用」方法たサービス設計が必須✓ 設計側に対して適切な運用のあり方を、メニューとして提示できる必要がある「運用」を意識した
サービス設計カタログ化された「運用」方法✓ 多彩な運用要求に応えられる柔運用リソースの拡散

軟な「運用設計」能力が求められる

運用リソースの計画配分「出口」戦略

5. 運用設計の諸要素

現状の見える化(step0. 何をやるか)現状の見える化

作業カタログの整備

運用全作業のリスト化「運用設計」の確立
リスト上の各作業の運用現場期待に対する消費リ運用作業の測定「運用」への期待を経営層との合意

ドキュメント、スキル、ツール情報の追記

1周目

ソースの測定化

明確化する

運用基盤の整備

リスト上の各作業の実績
情報の追記

運用の定義、期待

5. 運用設計の諸要素

作業カタログ のイメージ
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント

□□障害
作業カタログ定常イレギュラー
イレギュラー
基盤運用

運
用
基
盤

の整備
××対応

基盤定常運用

■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ

運用基盤の整備

運用作業の測定

現状の記述

実績の記述

5. 運用設計の諸要素

作業カタログ 作成の目的✓ 作業の全体像の把握✓ 必要な運用基盤の明確化✓ 消費リソースの明確化、予測可能化

5. 運用設計の諸要素

現状の見える化(step1. 現行作業の洗い出し)

運用作業の見える化

作業カタログの整備

運用全作業のリスト化「運用設計」の確立
運用現場
期待に対する消費リ

1周目

ソースの測定化運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

運用の定義、期待

5. 運用設計の諸要素

作業カタログ 作成の目的
作業カタログの整備✓ 作業の全体像の把握✓ 必要な運用基盤の明確化✓ 消費リソースの明確化、予測可能化

5. 運用設計の諸要素

運用作業の全体像
作業カタログの整備

Plan
分析

基盤整備
狭義の運用
定常運用
定時作業

See

申請作業

非定常運用
イレギュラー インシデント
情報

要員

予算

管理

管理

管理

Do

基盤運用

5. 運用設計の諸要素

作業カタログ の全体像
作業カタログの整備
発生予測
定
常

非

定時作業
定時作業

計画ベース

定常作業化
申請作業
申請作業

実績ベース

インシデントインシデント不可能 (必然)

イレギュラー
イレギュラー

不可能 (無駄多い)

基盤運用

基盤定常運用

実績ベース

分析
運用基盤分析

随時

定
常

運
用
基
盤

低負荷 / 非属人
測定

狭義の運用

高負荷 / 属人分析

(改善プロセス)
手順化して定常作業化

基盤整備
運用基盤整備随時

手順化

5. 運用設計の諸要素

運用作業の分類
作業カタログの整備
予測

変動要因

手順化

作業平準

スキル

定時作業
定時作業

計画ベース

内部

可

可能

低

常

申請作業
申請作業

実績ベース

外部

可

可能

低

非

インシデントインシデント

不可能

外部

可

不可能

中

イレギュラー
イレギュラー

不可能

外部

不可

不可能

中

基盤定常運用

基盤運用

実績ベース

内部

可

難

中

運用基盤分析
分析

不可能

内部

難

不可能

高

基盤整備
運用基盤整備

不可能

(内外)

難

不可能

高

定

初歩

定
常

運
用
基
盤

高度

5. 運用設計の諸要素

定時作業
作業カタログの整備

定常運用

発生予測

計画

可能

ベース

変動要因 手順化 平準化 スキル
内部

可能

可能

低

計画に従い定時に実施する作業
最も安定運用が容易で、省リソースで高品質化しやすい。
運用組織の最大ボリューム領域

5. 運用設計の諸要素

定時作業の具体例
作業カタログの整備✓ 計画イベント確認 (計画作業など予定の確認)✓ 定時状況/稼動正常性確認✓ 定時再起動、手動バッチ実行✓ 定時報告作成/送信 (日報、実績データ抽出など)✓ 引継ぎ✓ 日次進捗確認報告✓ 日報送信✓ チェックシート印刷✓ パスワード変更

5. 運用設計の諸要素

申請作業
作業カタログの整備

定常運用

発生予測

実績

可能

ベース

変動要因 手順化 平準化 スキル
外部

可能

可能

低

定常手順に従った申請作業
定時作業に次いで安定運用が容易で、省リソースで高品質化しやすい。
運用組織にとって定時作業を並ぶ二大領域。
(ITILで言う「リクエストフルフィルメント」(軽微な変更)に近い)
5. 運用設計の諸要素

申請作業の具体例
作業カタログの整備✓ 構成(各種リファレンス)情報の変更申請✓ (メンテナンス作業など)手順化済作業の実施申請✓ 申請作業の手順読みあわせ、実施など✓ (想定内での)対応フロー/手順書の新規依頼、変更、廃止✓ 現行基盤(ドキュメント/スキル/ツール)内で対応可能な✓ 新規運用受け入れ✓ 運用廃止✓ 担当者連絡先の変更✓ データ抽出申請✓ モニター設定変更、停止/再開申請✓ バッチ処理停止/再開申請など

5. 運用設計の諸要素

インシデント対応
作業カタログの整備

非定常運用

発生予測
不可能

変動要因 手順化 平準化 スキル
外部

可能

不可能

中

各種トラブルへの対応

本来は発生ゼロが望ましい作業。
迅速性と確実性が求められ、その実現のために設計部門への的確なフィードバックも期待される重要分野。

5. 運用設計の諸要素

インシデント対応の具体例
作業カタログの整備✓ サービス(ユーザ影響)インシデント対応✓ サービス基盤(冗長化が前提)インシデント対応✓ 運用基盤インシデント(サービス影響なし)対応✓ オペミス✓ 負荷過多(大量アラートなど)✓ 定時作業 想定外✓ バッチエラー対応✓ 顧客クレームなど✓ 想定外インシデントを含む (-> エスカレーション)✓ 障害の予兆(proactive)対応を含む
5. 運用設計の諸要素

イレギュラー対応
作業カタログの整備

非定常運用

発生予測
不可能

変動要因 手順化 平準化 スキル
外部

不可能 不可能中

手順化されていない突発依頼など
属人化の温床となっており、運用現場の高負荷およびリソース消費の最大要因。
業務柔軟性のため若干の発生は容認すべきと考えられるが、可能な限り「基盤整備」(手順明確化)を経て定常運用化することが望ましい。
5. 運用設計の諸要素

イレギュラー対応の具体例
作業カタログの整備✓ 未手順化作業✓ 申請作業イレギュラー (納期、内容、フローなどが非正規)✓ その他のイレギュラー (他の区分に分類できないもの)

5. 運用設計の諸要素

運用作業のリスト化 (狭義の運用)
作業カタログの整備
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

(狭義の運用)

インシデントインシデント□□障害

各作業を各分類に振り分け

イレギュラー
イレギュラー

××対応

基盤運用

基盤定常運用

■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ

定
常

運
用
基
盤

5. 運用設計の諸要素

基盤運用
作業カタログの整備運用に関わるモノ、ヒト、カネの管理をする。
運用に関連する要員の管理作業
運用に関連する情報や媒体の管理作業(シフト管理、運用
委託を含む)(物品の管理も含む。)

運用に関連する
予算/コストの
管理作業

要員管理
情報管理

予算管理

基盤運用

5. 運用設計の諸要素

情報/要員/予算管理の具体例
作業カタログの整備✓ 媒体管理情報管理✓ 契約管理✓ 情報リソース管理✓ ドキュメント改訂
業務フロー変更を伴わないもの✓ ツール設定変更など

要員管理 ✓ 要員契約管理✓ シフト管理✓ 能力管理など

予算管理✓ 予算管理✓ 支出管理✓ 予算実績レポートなど

5. 運用設計の諸要素

分析 と 基盤整備
作業カタログの整備

Plan
分析

基盤整備

改善サイクルの実現

See

Do

狭義の運用
情報

要員

予算

管理

管理

管理

基盤運用

5. 運用設計の諸要素

分析/基盤整備の具体例
作業カタログの整備

分析✓ 月次分析報告書✓ スポット分析報告書など✓ 現行基盤(ドキュメント/スキル/ツール)内で対応不

基盤整備

可能な
✓ 新規運用受け入れ✓ 運用廃止 (影響範囲が不明)✓ ドキュメント改訂 (業務機能ユニットレベルでのフロー変更を伴うもの)✓ スキル改訂✓ ツール改訂 (設定変更で対応できないもの)✓ 各種プロジェクトなど

5. 運用設計の諸要素

運用作業のリスト化 (運用基盤)
作業カタログの整備
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

イレギュラー
イレギュラー

××対応

基盤運用

■■管理

定
常

運
用
基
盤

基盤定常運用

分析
運用基盤分析

基盤整備
運用基盤整備●●分析(運用基盤)
各作業を各分類に振り分け▲▲改善/PRJ

5. 運用設計の諸要素

現状の見える化(step2. 運用基盤の洗い出し)

運用基盤の見える化

作業カタログの整備「運用設計」の確立
リスト上の各作業の運用現場期待に対する消費リ

ドキュメント、スキル、ツール情報の追記

1周目

ソースの測定化運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

運用の定義、期待

5. 運用設計の諸要素

作業カタログ 作成の目的
運用基盤の整備✓ 作業の全体像の把握✓ 必要な運用基盤の明確化✓ 消費リソースの明確化、予測可能化

5. 運用設計の諸要素

運用基盤とは
作業カタログの整備

Plan
分析

基盤整備
狭義の運用
定常運用
定時作業

See

申請作業

非定常運用
イレギュラー インシデント
情報

要員

予算

管理

管理

管理

Do

基盤運用

運用基盤
5. 運用設計の諸要素

「運用基盤」3要素
運用基盤の整備✓ まずは作業内容を的確に表現し狭義の運用たドキュメントがあることが大前提✓ それではじめて作業内容に必要な

情報

要員

予算

管理

管理

管理

基盤運用

スキル(教育内容)が明確になる。

分析✓ 前提となる作業とスキルが明確に運なって、はじめてツールの話ができ

用

る。

基
盤

ツール
スキル (教育)
ドキュメント基盤整備

5. 運用設計の諸要素

運用基盤の問題点
ドキュメントの問題点✓

どこにあるかわからない✓

作られない/更新されない✓

内容がわかりにくい/精度が低い

スキルの問題点✓

要員のスキルが不足している✓

どんなスキルが必要かわからない✓

育てる枠組みが無い/弱い

ツールの問題点✓

使いにくい (道具が業務を歪めている)✓

乱立しがち/連携できない✓

保守できない/柔軟に対応できない

5. 運用設計の諸要素

運用基盤1. ドキュメント (重要性)
運用基盤の整備✓ 運用ドキュメントと運用業務は表裏一体の関係にある。
✓ ツールやスキルに対する的確な要求は、客観的なドキュメントがあってはじめて実現可能となる。
✓ ドキュメントのない業務は、存在しないことに近く、客観評価されない。
✓ 事業の継続性は、ドキュメントがあってこそ確保可能となる。

5. 運用設計の諸要素

運用基盤1. ドキュメント (整備へ)
運用基盤の整備✓ どこにあるかわからない‣ 作業カタログにドキュメントの置き場を明記しておく。

✓ 作られない/保守されない‣ 作業カタログにドキュメントの有無、最終更新日を記載しておく。

✓ 内容がわかりにくい/精度が低い‣ 作業カタログ上で優先順位を付けて精度を上げる。

5. 運用設計の諸要素

ドキュメント管理ポリシー
運用基盤の整備

Level-0. 管理しない (個人任せ)
Level-1. 台帳管理 (リスト化)
Level-2. バージョン管理/検索機能
Level-3. 分散協調管理(集中管理は破綻するという仮説より)

5. 運用設計の諸要素

運用基盤1 ドキュメントの見える化
運用基盤の整備
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

定常イレギュラー
イレギュラー
基盤運用

運
用
基
盤

基盤定常運用

××対応
■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ•

ドキュメント管理者 (作業オーナ)•

ドキュメント所在••

ドキュメント情報
ドキュメントポリシー
最終更新日

5. 運用設計の諸要素

運用基盤2. スキル/教育 (重要性)
運用基盤の整備

✓ ドキュメントやツールをどんなに整備しても、使うのは人間である限り、要求スキルの明確化と教育は重要。

✓ その作業ができるようになるまで、どの程度の知識や経験が必要なのか、というボリューム感を示すことが大切。

✓ 要求スキルを適切に表現することで、オペレータの適切な採用と作業への最適なマッチングが可能となる。

5. 運用設計の諸要素

運用基盤2. スキル/教育 (整備へ)
運用基盤の整備✓ どんなスキルが必要かわからない‣ カタログの各作業に求められるスキルを記入していく。

✓ 要員のスキルが不足している‣ カタログの各作業に、作業ができる人を明記してみる。

✓ 育てる枠組みが無い/弱い‣

作業単位で、できることを徐々に増やしていく。

5. 運用設計の諸要素

スキル管理/教育ポリシー
運用基盤の整備

Level-0. 教育しない (口伝/技を盗む)
Level-1. ドキュメント整備/OJT教育
Level-2. 知識教育/試験制度
Level-3. 技術研修/試験制度

5. 運用設計の諸要素

運用基盤2 スキルの見える化
運用基盤の整備
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

定常イレギュラー
イレギュラー
基盤運用

運
用
基
盤

基盤定常運用

××対応
■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ•

スキルポリシー

•

スキル基準

•

スキル最終見直し日•

適合メンバー

スキル情報

5. 運用設計の諸要素

運用基盤3. ツール (重要性)
運用基盤の整備✓ 実は運用設計上の優先順位は低い。
✓ 業務にあわせてツールを整備すべき。
✓ ツールにあわせて業務を歪めてはならない。
✓ 要求されるレベルとリソースが見合うのであれば、極端に言うとメモ用紙でも構わない。

✓ 目的と手段が反対になりやすいので要注意。

5. 運用設計の諸要素

運用基盤3. ツール (整備へ)
運用基盤の整備✓ 使いにくい (道具が業務を歪めている)‣ カタログ化された作業を整理して、本当に必要なツールの仕様を明確にする。

✓ 乱立しがち/連携できない‣ カタログ化されたツールについて、機能や目的の重複したものを整理統合する。

✓ 保守できない/柔軟に対応できない‣ カタログ化されたツールの設計思想を標準化し、全体の再設計を行なう。

5. 運用設計の諸要素

ツールポリシー
運用基盤の整備

Level-0. 利用しない (メモ帳/脳内メモリ)
Level-1. 紙媒体管理/人力伝達
Level-2. ネットワーク媒体
Level-3. プロセスモデルシステム

5. 運用設計の諸要素

運用基盤3 ツールの見える化
運用基盤の整備
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

イレギュラー
イレギュラー

××対応

基盤運用

■■管理

定
常

運
用
基
盤

基盤定常運用

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ•••

ツールポリシー

ツール情報
ツール所在
ツール最終改修日

5. 運用設計の諸要素

現状の見える化(step3. 作業の実績記録)

運用実績の見える化

作業カタログの整備「運用設計」の確立
運用現場
期待に対する消費リ

1周目

ソースの測定化運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

リスト上の各作業の実績
情報の追記

運用の定義、期待

5. 運用設計の諸要素

作業カタログ 作成の目的
運用作業の測定✓ 作業の全体像の把握✓ 必要な運用基盤の明確化✓ 消費リソースの明確化、予測可能化

5. 運用設計の諸要素

工数管理ポリシー
運用作業の測定

Level-0. 管理しない (丼勘定)
Level-1. 作業の一覧管理
Level-2. 原価/予算管理
Level-3. リアルタイム計上/予測

5. 運用設計の諸要素

作業の測定化 (工数管理)
運用作業の測定
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント

□□障害

定
常

運
用
基
盤

イレギュラー
イレギュラー

××対応

基盤運用

■■管理

基盤定常運用

分析
運用基盤分析

基盤整備
運用基盤整備●●分析▲▲改善/PRJ•

月間作業実施件数 (作業負荷の予測基礎データ)

測定情報 (工数関連)• 単位作業時間 (最短、最長)•

単位作業コスト (効率性の指標)•

最終作業実施日 (棚卸しの基準)

5. 運用設計の諸要素

作業の測定化 (品質管理)
運用作業の測定
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

定常イレギュラー
イレギュラー
基盤運用

運
用
基
盤

××対応

基盤定常運用

■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ••

平均リードタイム (最短、最長)測定情報 (品質関連)

作業ミス件数、発生率、最終発
生日

5. 運用設計の諸要素

2周目. 作業の整理統合

(2周目) 運用作業の整理統合

各作業のフローパターン

作業カタログの整備を記載「運用設計」の確立
各作業の粒度を細かくして、類似作業を整理統合

運用現場
期待に対する消費リ

粒度にあわせてドキュメン

2周目

ソースの測定化

ト、スキル、ツールを再定義

運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

粒度にあわせて実績を測定

運用の定義、期待

5. 運用設計の諸要素

(2周目) 運用作業の整理統合

各作業のフローパターン

作業カタログの整備を記載「運用設計」の確立
各作業の粒度を細かくして、類似作業を整理統合

運用現場
期待に対する消費リ

2周目

ソースの測定化運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

運用の定義、期待

5. 運用設計の諸要素

業務プロセスポリシー
運用作業のカタログ化

Level-0. 管理しない (属人化の許容)
Level-1. 業務フローの台帳管理
Level-2. 業務フロー(プロセス)の標準化
Level-3. 業務フロー(プロセス)のモデル化

5. 運用設計の諸要素

標準化 / セグメント化 / 類型化
運用作業のカタログ化
類型化

セグメント
化

類型化

セグメント
化

類型化

セグメント
化

標準化

- 類似作業の共通化、ナレッジ化- 類型に基く個別モデル化- セミオートメーション化

セグメント
化

- 個別事情への柔軟な対応- 不統一によるオーバヘッドの削減- 全体問題点の明確化、改善サイクル化- 導入/展開の迅速化

5. 運用設計の諸要素

業務プロセス(標準化)の見える化
運用作業のカタログ化
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

イレギュラー
イレギュラー

××対応

基盤運用

■■管理

定
常

運
用
基
盤

基盤定常運用

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ

作業プロセス情報•

プロセス(フロー)パターンを追加•

標準手順 or 非標準手順

5. 運用設計の諸要素

標準化のための作業粒度

サービス運用全体の流れ

各組織

inboundチケット

outbound の繰り返し
5. 運用設計の諸要素

運用組織の要求機能 (基本)

顧客

支援

サービス

協調組織

inboundoutbound

作業チケットどんな運用組織でも、最低限、上記3機能は必要
5. 運用設計の諸要素

サービス運用における参照、支援各組織では作業チケット処理時に各種作業支援(ツール)、リファレンスを利用

5. 運用設計の諸要素

運用組織の要求機能 (フルセット)

モニター

計画イベント
問題チケット

顧客

支援

サービス

協調組織

inbound

作業チケットoutbound

コスト算定/請求作業ロジックサービスリファレンス

作業インタフェース

高度分析

5. 運用設計の諸要素

「ワークフロー」という概念
パターン化 = 標準化

各作業は個別機能の組合せとして「ワークフロー」を構成する。

業務プロセスの標準化ポイント
でもやりすぎると、現状では保守工数が高くなる。

顧客支援協調組織

サービス

4

1
モニター

outboundinbound3
計画イベント
問題チケット
作業インタフェース

コスト算定/請求作業チケット
作業ロジック2

サービスリファレンス

高度分析

5. 運用設計の諸要素

(2周目) 運用作業の整理統合

作業カタログの整備「運用設計」の確立
運用現場
期待に対する消費リ

粒度にあわせてドキュメン

2周目

ソースの測定化

ト、スキル、ツールを再定義

運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

運用の定義、期待

5. 運用設計の諸要素

(2周目) 運用作業の整理統合

作業カタログの整備「運用設計」の確立
運用現場
期待に対する消費リ

2周目

ソースの測定化運用作業の測定「運用」への期待を明確化する

運用基盤の整備

経営層との合意

粒度にあわせて実績を測定

運用の定義、期待

5. 運用設計の諸要素

期待の見える化(step4. 作業属性の洗い出し)「サービス」のプレイヤー (再)サービス設計サービス導入/廃止

Service
DesignService
Transition

サービス企画

Service
StrategyService
Operation
ITサービスのライフサイクル (ITIL v3)

サービス運用

5. 運用設計の諸要素

運用作業のプレイヤー属性✓

プレイヤーとして、運用組織でやっていいのかどうか。

✓

経営層が判断できる状況を作る。

✓

品質を求めるならば専門部署が必要。

✓

そこまで求めないならば(狭義の)運用✓

組織で実行が可能、そこの言質を取ることが大事。

5. 運用設計の諸要素

作業のプレイヤー属性見える化
運用の定義、期待
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

イレギュラー
イレギュラー

××対応

基盤運用

■■管理

定
常

運
用
基
盤

基盤定常運用

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ

プレイヤー属性情報•

プレイヤー種別を追加

5. 運用設計の諸要素

運用のステークホルダ
運用の定義、期待✓ サービス受益者 (コスト負担者)✓ 予算決定権者 (経営層)✓ 予算執行権者✓ 運用管理者✓ 運用デザイナー✓ サービス設計部門✓ サービス導入部門

5. 運用設計の諸要素

ステークホルダ最大の期待運用の定義、期待運用が追う/守るべきものは、どこにあるのか?
‣ 稼動時間、可用性なのか (常時性)‣ 必要な時に必要なだけなのか。(必要性)‣ キャパシティなのか。(量的)‣ クオリティなのか。(質的)‣ リードタイム短縮なのか (迅速性)
二兎を追えるようになるまでは一兎のみ
5. 運用設計の諸要素

ステークホルダーの期待見える化
運用の定義、期待
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

インシデントインシデント□□障害

イレギュラー
イレギュラー

××対応

基盤運用

基盤定常運用

■■管理

分析
運用基盤分析

●●分析

基盤整備
運用基盤整備▲▲改善/PRJ

定
常

運
用
基
盤

•

最大ステークホルダを追加• 定期(月次)報告の有無
プレイヤー属性情報• 報告内容、KPI情報

5. 運用設計の諸要素

作業カタログの最終形態

作業カタログ (最終形態)
作業名
定
常

非

定時作業
定時作業

○○作業

申請作業
申請作業

△△申請

•

運用基盤 (ドキュメント、スキル、ツール)

インシデントインシデント□□障害•

測定情報 (工数管理、品質管理)

イレギュラー
イレギュラー××対応•

業務プロセス(標準化)

基盤運用

基盤定常運用■■管理•

プレイヤー属性分析
運用基盤分析

●●分析•

ステークホルダーからの期待

基盤整備
運用基盤整備▲▲改善/PRJ

定
常

運
用
基
盤

約30項目

5. 運用設計の諸要素

Section. 6「運用設計」 と ISO 20000

ISO 20000 と 運用フレームワーク

サービスデリバリ プロセス
作業カタログの整備
情報

予算

管理

管理

運用の定義、期待運用作業の測定

コントロール プロセス「サービス導入/廃止」 の範疇「サービス導入/廃止」 の範疇

作業カタログの整備問題チケット
作業チケットリリース プロセス

解決 プロセス

作業カタログの整備
情報管理

関係 プロセス

運用基盤の整備

5. 運用設計の諸要素

運用の明日• 運用への期待は明確に• 運用設計が可能に• 運用の測定も可能に‣ サービスの安定
社会基盤に相応しい安定運用。

‣ 業務負荷の平準化
個々人ががんばりすぎなくてもうまく業務が回る運用現場。

‣ 運用に対する評価の適正化
運用現場が適切に評価されるようにする。

5. 運用設計の諸要素

Appendix

作業カタログシート
作業名
定
常

非

定時作業
定時作業
申請作業
申請作業

•

運用基盤 (ドキュメント、スキル、ツール)

インシデントインシデント•

測定情報 (工数管理、品質管理)

イレギュラー
イレギュラー•

業務プロセス(標準化)

基盤運用

•

プレイヤー属性•

ステークホルダーからの期待

定
常

運
用
基
盤

基盤定常運用

分析
運用基盤分析

基盤整備
運用基盤整備

業務機能ユニット マップ
顧客支援協調組織サービス

モニター

inboundoutbound

作業チケット計画イベント

コスト算定/請求作業ロジック

問題チケット

作業インタフェース

サービスリファレンス

参考文献

•

波田野 裕一 (2009)「運用方法論の研究について」/ 経営情報学会 2009年11月14日•

野村総合研究所 システムコンサルティング事業本部 (2008)「ITIL入門 ITサービスマネジメン
トの仕組みと活用」 / ソーテック社•

itSMF-NL (2007) 「ITマネジメントのためのフレームワーク (第1版)」 / Van Haren PUBLISHING•中西 晶 (2007) 「高信頼性組織の条件」 / 生産性出版•

中西 晶 (2006)「マネジメントの心理学」/ 日科技連出版社•

尾崎 雅彦 (2006)「ITIL導入のための BS15000/ISO20000 入門」/ ソフトバンククリエイティブ