明日の運用現場のために - 運用フレームワークという視点

2010年12月16日(木)
波田野 裕一

前回までに、

  • 「運用方法論」の目的
  • 「運用現場の問題点」の分析
  • 運用の「フレームワーク」化

の3点について、説明してきました。

最終回の今回は、運用現場において実際に運用設計をする上でのリファレンスとなる「運用フレームワーク」について触れ、運用設計の今後について展望していきます。

「運用フレームワーク」 とは

ここで「運用フレームワーク」とは、各運用現場における業務について「客観的な立場に立ち、科学的/論理的手法を用いて分析し、継続的に見直すサイクルを構築する」手助けをする枠組みのことを言います。運用設計を行うときや、運用業務の分析/評価時にも参照されることを想定しています。

その立場や価値観によって、いろいろな「運用フレームワーク」があってもよいと考えています。ここでは、筆者を含む有志による「運用研究会」で継続的に検討・議論している「運用フレームワーク fwop」(FrameWork of OPeration)について、駆け足ですが概要と利用場面を見ていきます。

「運用フレームワーク fwop」 の概要

第1回第2回とエラそうなことを書いていますが、われわれも運用現場で直接もしくはその支援で日々苦労しています。fwopは、このような現場の人間が「なんとか楽したい」という思いからスタートしています。そしてまだまだ道半ばです。

もし何かしら参考になるところがあれば「いいとこ取り」もOKですし、足りないところがあればツッコミを入れていただき、より良いものにしていければ、という思いを持っています。

fwop 3つの特徴

「運用フレームワーク fwop」は、以下の3つの特徴を持っています。

1. 現場への負荷による作業分類: 「作業カタログ」
fwopでは、運用の各業務について「作業カタログ」という作業一覧を作成して「やっていることの見える化」を行ないます。一覧化された各作業について「現場に対する負荷」により分類することで、その運用現場の負荷状況を定性的に分析できるようにします。短期的には「実績の見える化」はこの「作業カタログ」上で行われ、負荷状況の定量的な分析をすることも想定しています。
2. 運用業務プロセスのモデル化: 「業務機能ユニット」
fwopでは、業務プロセスを「業務機能ユニット」という10種類の機能ユニットで表現することで、標準化による効率化、モデル化による柔軟性を実現しようとしています。中長期的には「実績の見える化」はこの業務機能ユニット上で自動的に行われることになると想像しています。
3. 現実の直視と理想の提示: 「ポリシー・レベル」
fwopでは、運用業務の各要素について、現実と理想を"0"から"3"の4段階の「ポリシー・レベル」という相対的な尺度で表現します。これによりさらに具体的な、運用に対する「期待」や「やらないこと」の見える化を実現しようとしています。

fwopの全体像

fwopの全体像は、現時点で以下のようになっています。

fwop本体(運用設計リファレンス)
運用設計を行う上で必要な検討事項や評価基準を集めた、運用設計のリファレンスとなるものです。
  • 運用の定義
  • 運用概要設計(期待分析、成果設計、組織設計)
  • 運用詳細設計(作業一覧設計、運用基盤設計、業務プロセス設計)
  • 改善スキーム(測定、分析、計画、棚卸し)

図1: fwopの全体像
運用設計ガイドライン
運用設計を手軽に実践するためのテンプレートやアプローチ手法(第2回の図4)をまとめたものです。 fwop本体を参照しなくても最低限の運用設計が可能になるガイドブック的なものを目指しています。 また、その支援ツールについても試行錯誤中です。

やりたいことは非常に多いのですが、具体化するにはまだまだ時間が必要なのが現状です。

運用業務の分類方法と「運用基盤」

今回は、紙面の関係もあり、運用現場の「やっていることの見える化」をしていく上で重要と考えている「作業カタログ」について簡単に触れていきます。まず運用業務の各作業の分類方法を説明し、各作業を支える「運用基盤」について見ていきます。

現場への負荷による作業分類(3つの負荷要素)

「作業カタログ」では、以下の3つの評価軸で、運用業務の各作業を、定時作業、申請作業、緊急作業、属人(専門)作業という4つの分類に各業務を振り分けていきます。

  1. ドキュメントの有無(有/無)
  2. 突発具合(3段階)
  3. 起因組織(内部/外部)

図2: 負荷による作業分類

1. ドキュメントの有無

各作業について、ドキュメントがあるかどうかは運用現場にとって非常に重要です。ドキュメントが無いということは、その作業について特定の個人への依存性が高いことを意味します。個人依存性の高さは、特定の人に負荷がかかりやすいかどうか、メンバーの異動や退職による業務継続性リスクが高いかどうかを見える化します。

2. 突発具合

各作業について、その発生を事前予測することは、必要な業務リソースを確保する上で重要です。事前予測が不可能な作業が多い運用現場では、業務バーストするリスクが非常に高いと考えられます。負荷予測性の高さは、業務リソース・コントロールの難易度、要員に対する過負荷リスクを見える化します。

3. 起因組織

各作業について、ステーク・ホルダーとの調整の難易度を知ることは大切です。運用現場が高負荷になった場合の短期的な納期調整や、各作業の改善など根本的な見直しを検討する際の障壁の高さを見える化します。

4つの作業分類

4つの作業分類は、下記のような特性を持ちます。

図3: 作業分類の特性

定時作業

定常運用の1つで、計画ベースで事前に定まった時間に実施されるものです。 外的な変動要因が少なく、最も安定運用が容易で、一般的に少ないリソースで高品質化しやすいのが特徴です。定時ジョブ実行や定型レポート作成などのイメージに近いでしょう。

申請作業

これも定常運用の1つで、外部からの依頼ベースで、定常手順に従って実施されるものです。 発生が外部要因なので、定時作業ほど発生予測の精度は高くありませんが、実績ベースで、事前にある程度は予測が可能となります。定時作業に次いで、少ないリソースで高品質化しやすいのが特徴です。構成変更申請や登録情報変更申請などのイメージに近いでしょう。

緊急作業

これは非定常運用の1つで、外部から突発ベースで発生し、定常手順に従い実施されるものです。本来は発生しないことが望ましい作業ですが、実際に発生を抑えることは難しく、運用組織への期待が大きい領域です。しかし、あくまでもリアクティブな対応なので、なかなか評価されにくい点は意識しておく必要があります。トラブル対応やクレーム対応などのイメージに近いでしょう。

属人作業

非定常運用の1つで、手順書のない作業はすべて属人作業として扱います。「運用でカバー」している部分もここに含まれます。第2回で、運用現場の「属人化」には2つの側面がある、と書いた通り、各作業についてどちらの側面が強いのか検討が必要ですが、今回は割愛します。

次ページでは

次ページでは、各作業を支える「運用基盤」について俯瞰(ふかん)し、「作業カタログ」の最初の版を完成させていきます。

1ページで「現場への負荷による作業分類」「4つの作業分類」の概念をみてきました。ここでは、各作業を支える「運用基盤」について俯瞰し、「作業カタログ」の最初の版を完成させていきます。

運用業務を支える3つの「運用基盤」

運用作業を確実に遂行し、これらの作業品質を上げるために、作業自体を支援するものを総称して「運用基盤」といいます。 fwopでは、主にドキュメント、スキル、ツールの3つが「運用基盤」を構成している、と考えています。

運用基盤1. ドキュメント

fwopでは、下記の理由から、3つの運用基盤の中で「ドキュメント」が最も重要だと考えています。

  • ドキュメントのない作業は、運用現場自身でも正確な内容把握が難しいため、作業内容のブレやモレを生みやすく、ミスやトラブルの温床になりやすい。
  • ドキュメントのない作業は、正確な業務引き継ぎが困難であり、メンバーの異動や退職により運用現場を混乱させるリスクが高い。
  • ドキュメントのない作業は、対外的な説明が難しく、(ユーザー視点では)存在しないことに近い。そのため評価されにくい。
  • ドキュメントのない作業においては、その作業に必要なスキルやツールを、運用現場が的確に定義し、正確に相手に提示することが難しい。

運用現場において求められるドキュメントには、主に下記の2つがあります。

作業定義書(5W文書)
各作業について、何を(what)、いつ(When)、どこで(where)、誰が(who)、なぜ(why)行うのかを明記した文書です。 主に、運用設計を行う時や、運用業務の分析/評価時に必要となるほか、メンバーのOJT時に各作業の意図を理解してもらう上で非常に重要な文書となるでしょう。中でも、why(なぜ)は文書化されていないと失われやすく、作業を形骸(けいがい)化させる原因となりえるので留意が必要です。
作業手順書(1H文書)
各作業について、どのように(How)行うのかを明記した文書です。 実際に作業を行う上で必須ともいえる重要な文書です。 更新されていない手順書は、トラブルを誘発するなどかえって有害となることもあるので、作業手順書の更新は最優先で行うなどの留意が必要です。

運用基盤2. スキル

fwopでは、下記の理由から、ドキュメントの次に「スキル」の明確化が重要だと考えています。ここで言う「スキル」とは、「ドキュメント」の内容を正確に理解し、特に「作業手順書」に記述された内容に従って確実に作業を遂行する能力のことを言います。「スキル定義」とは、運用メンバーに求められるスキルセットの定義と、そのスキル体得に必要な教育の枠組みを指します。

  • スキル定義のない作業は、どの程度の知識や経験があればその作業ができるようになるのか分からず、作業ができる人が増えていかない。
  • スキル定義のない作業が多い場合、その運用現場に適切なメンバーの採用や各作業への最適なアサインが難しくなる。
  • スキル定義のない運用現場では、メンバー自身が育つ方向性が分からないため、「人が育たない」状況になってしまう。

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

運用現場において、メンバーに求められるスキルには、主に下記の3つがあります。

業務スキル
各運用現場で固有の知識と技能です。その運用現場での経験量に、ある程度依存します。運用現場の作業一覧のうち、できる作業の数によってある程度客観的な評価ができ、育成方針も明確にすることが可能になるでしょう。
技術スキル
その運用現場に依存しない、専門技術としての知識と技能です。 例えば、IT基盤運用の場合は、ITSS(情報処理推進機構の定めるITスキル標準)のうちレベル1~3により、中級スキルまではある程度客観的な評価ができ、育成方針も明確にすることが可能になるでしょう。
基礎スキル
社会人としての一般的な知識と技能です。 状況判断力、コミュニケーション力、創造力、リーダーシップなどが含まれます。 運用現場だけでは、客観的な評価や育成ははなかなか難しく、組織全体で検討することが必要でしょう。

運用基盤3. ツール

fwopでは、ドキュメントやスキルと比べてツールの優先順位は実は低い、と捉えています。これは「どんな業務を、どんなスキルの人たちが行うのか、が明確になって初めて、必要なツールが明確になる」と考えているからです。

「的確に設計されたツールが運用業務を適切に支援するのであって、ツールにあわせて業務をゆがめてはならない」という、過去から現在までの苦い思いから導かれた結論です。要求されるレベルとリソースが見合うのであれば、やや極端かもしれませんが、付せん紙やホワイト・ボードへの手書きでも構わないでしょう。

ツールについては、大きな効果が期待できる一方で、目的と手段が反対になりやすいので注意が必要です。

「作業カタログ」の作成

3つの負荷基準で4つの作業分類に整理した各作業について、作業カタログに記入していきます。作業カタログ自体は単純な表なので、作成には表計算ソフトがあれば十分です。

次に、この作業一覧に3つの運用基盤(ドキュメント、スキル、ツール)の管理者、所在、最終更新日を記述していきます。これにより、極めて簡素ですが運用現場における作業の一覧と、それらを支える運用基盤の現状が見える化できました。

図4: 作業カタログのイメージ

一般的に、上段の作業が多ければ多いほど「負荷が低く、非属人的」であり、下段の作業が多ければ多いほど「負荷が高くなりやすく、属人的」と考えられるでしょう(この時点では「費用対効果」については見えてきません)。

見える化の次は、現状に対する改善となります。あるべきドキュメントが無い場合は作成に着手することになるでしょう。スキル定義があいまいなものは、明確にしていく必要があるでしょう。ツールが現場にあっていない場合は、改善を検討することになるでしょう。突発度の高い作業は、事前に察知できるように工夫することになるでしょう。「作業カタログ」を眺めていて気づいた点を、どんどん改善していきます。

さらに、この「作業カタログ」を基に、各作業の実績測定、運用現場の特性による強み弱みの分析を行い、運用基盤の整備を経て、運用現場を成長させていくことになるでしょう。

分析や基盤整備も含めた「運用業務」の全体像は、下記のような図になると考えられます。

図5: 「運用業務」の全体像

2つの作業カタログ作成モデル

作業カタログをいきなり運用業務全体に対して詳細に実施するのは、非常に工数もかかり、継続すること自体が負担になる可能性があります。このため、作業カタログ作成については、2つのモデルを検討しています。

モデル名 内容 特徴
フルカバレッジ・モデル 現場における全運用業務について、当初は粒度を粗めに整理し、徐々に詳細化していくモデル手法。 業務の全体像を俯瞰しやすい。
ミニマムスタート・モデル 現場における運用業務のうち、特定スコープについて詳細に「見える化」していくモデル手法。 工数と効果の調整がしやすい。

例えば、「ミニマムスタート・モデル」では、 以下の3ステップで、運用業務の見える化をしていきます。

  1. 運用現場の3大業務は何かを明確にしてみる
  2. 3大業務の業務フローを7工程で表現してみる
  3. 21工程のうち、1工程についてまず作業カタログを作成してみる

これにより、工数と効果のバランスを取りながら、徐々に現場の見える化を図ろうとしています。

本連載におけるfwopの解説は、以上になります。 次ページでは、運用設計に関するいくつかのトピックに触れて、本連載を締めたいと思います。

「運用」とは何か

ここまで「運用設計」のあり方を中心に眺めてきました。では「運用」とは何でしょうか。

いまさら何を言うのか、と思われるかも知れませんが、実は「運用」という言葉の概念が人によって異なるのが現状です。このことは各ステーク・ホルダー間の「運用」への期待や評価を曖昧にし、議論が噛み合わず「運用」への理解を妨げるなど多くの弊害を招いています。

今回の「運用方法論」においては、「運用」とは「運用組織のリソースを活用し、 対価や評価を得ることを目的に、 外部に対して、継続的に何らかのサービスを提供し続けること」、つまり「サービスを継続的にデリバリすること」と捉えています。

図6: サービス「運用」全体の流れ

「運用」をサービス・デリバリと捉えることによるメリットは2つあります。

1つ目は、運用業務をQ(品質)、C(コスト)、D(納期)で評価できるようになることです。とかく稼働率とコストというマイナス要素で評価されることが多い運用現場で、Q(品質)、D(納期)という他の評価軸で考えられるようになることは大きな意味を持つのではないでしょうか。

2つ目は、「サービス・デリバリ」となれば、相手の期待値を適切にコントロールしつつその期待値を上回るサービスを提供する、という視点が生まれることです。とかくお役所対応になりがちな運用現場は、相手からはホスピタリティが低いと評価されることが多いように思われます。安定稼動のために必要という側面はありますが、それではあくまでも「道具のお守り」に過ぎず、コスト・センターと評価されても仕方なくなってしまいます。

過剰な期待に対する「運用でカバー」を適切に回避しつつ、「サービスを提供する立場」として自分たちのやっていることの価値や意味を見出すことは、その運用現場の存在意義をユーザーや経営層に対して認めさせる大きな切り口になるのではないでしょうか。

ネットワーク運用などの低レイヤーやバック・オフィス系の業務では「ユーザー」をイメージしにくいかもしれませんが、自分の仕事相手に対するQCDを考えることで、自分たちの付加価値や改善点として何か見えてくるものがあるのではないかと考えています。

「運用の品質」とは何か

「運用」をサービス・デリバリと捉えることでQCDで評価できるようになる、と書きました。このうちC(コスト)は金額、D(納期)は時間という物性により、それぞれ定量的な評価が可能です。しかし、運用の品質についてはどう定量的に評価すればいいのでしょうか。

製造業においては、製品の歩留まりという定量的な品質基準を元に、「製造工程に問題があるのか、原材料に問題があるのか」などの科学的な分析が可能であり、これらは生産工学という学問の中で100年以上にわたる知見の蓄積があります。その知見を実践するために「ISO9000シリーズ」「QC7つ道具」「原価計算」「サプライ・チェーン」などの品質/コスト分析改善フレームワークも確立されており、製造業における常識となっているようです。

図7: 製品の品質

しかし、運用現場を含むサービス業においては、「サービス工学」や「運用工学」といった学問は未だ確立されたものがないのが現状です。今後は、自分たちの蓄積された実績データを基に、今回の「運用フレームワーク」のような運用のための分析手法を通じて自分たちの運用現場の実績を定性的定量的な分析する力を養い、自分たちの売りとなる「品質」とは何かを追求していくことが必要となっていくでしょう。決して易しいことではないでしょうが、それができる運用現場は格段に高い強みを発揮することは間違いないでしょう。

図8: サービスの品質

前向きな「運用でカバー」

第1回で、「運用でカバー」には弊害が多いと書きました。それは多くの場合「マイナスをゼロにする活動」であり、「運用の見えない化」を促進するから、というのが理由でした。しかし、仮に「運用の見える化」を十分に実現し、ユーザーの期待値を上手にコントロールした上で、プラスの「運用でカバー」を実現できれば、事情はまったく異なります。

ユーザーが感じる「サービス品質」の大半が運用組織によって作られていることに異論を唱える人は少ないでしょう。ユーザーの要望が多様化し、個別化・特殊化している今日では、そのような個別なニーズに適切に応えていくことが、運用現場の強みにもなり、その組織全体の強みにもなります。

では、自分の運用組織の具体的な強みとは何でしょうか。その手がかりは、このページ冒頭に示したように、自分たちの業務を「サービス・デリバリ」と捉え、QCDで客観的に分析することで得られるのではないでしょうか。また、「運用フレームワーク」によって日常の運用業務を把握していく中で、そこで行なわれているプラスの「運用でカバー」に、先進的なユーザーのニーズや、ほかのサービスやほかの運用現場との差別化要素が潜んでいる場合もあるかもしれません。

いずれにしても、自分たちの運用現場において、比較優位な業務を見つけ出し、売りとなる「品質」を見い出し、追求していくことで、ほかの運用現場には無い特徴や、自分たちの運用現場発の新たな価値を生み出していくことができれば、それは十分に「武器」になりえるでしょう。

「運用方法論」の今後

今回まで3回にわたって、「運用方法論」について解説をしてきました。この「運用方法論」は、実に多くの方々の考えや助言をいただいて形作られてきています。今回の記事における多くの拙い部分は著者の力不足によるものとお考えください。

運用研究会は、今から半年後の2011年5月に最終報告を出して、いったんその活動を終えます。その成果は可能な限り公開する予定です。是非この記事を読まれたみなさんにも意見を伺えればと考えております。

またどこかでお会いしましょう。

運用設計ラボ合同会社 / 日本UNIXユーザ会

ADSLキャリア/ISPにてネットワーク運用管理、監視設計を担当後、ASPにてサーバ構築運用、ミドルウェア運用設計/障害監視設計に従事。システム障害はなぜ起こるのか? を起点に運用設計の在り方に疑問を抱き、2009年夏より有志と共同で運用研究を開始し、2013年夏に運用設計ラボ合同会社を設立。日本UNIXユーザ会幹事(副会長)、Internet Week 2013プログラム委員、Internet Conference 2013実行委員など各種コミュニティ活動にも積極的に参加している。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています