自分たちの「運用」を知る - 運用設計の本質

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

第1回では、運用現場が抱える悩みを分析し、その多くは「高負荷、属人的、見えぬ費用対効果」という3つの問題点が複合化したものであり、以下の3つの要因によって引き起こされていることを示しました。

  1. 運用への期待が明確でない(期待というインプットが見えていない)
  2. 運用設計の不在(やっていることが見えていない)
  3. 期待と消費リソースのひも付けが不明確(結果というアウトプットが見えていない)

第2回の今回は、これら運用現場における悩みを解消するための糸口を探していきます。このうえで、糸口の中で運用現場が自らできることを中心に考察していきます。

運用現場の「悩み」を解消するための、3つのポイント

運用現場の悩みを解消するための糸口は、上記の3つの要因をそのまま裏返す形になりますが、以下の3点がポイントになると考えられます。

  1. 「運用」への期待を明確化
  2. 「運用設計」を確立
  3. 期待に対する消費リソースを測定

図1: 運用現場の「悩み」を解消するための、3つのポイント(クリックで拡大)


以下では、この3つのポイントについて、それぞれ説明していきます。やや、きれいごとが続きますが、お付き合いください。

悩み解消ポイント1. 「運用」への期待の明確化

まず、「運用」への期待を明確にする必要があります。

前回の問題点分析で説明した通り、ステーク・ホルダー全員のあらゆる期待に応えるためには、無限のリソースが必要になります。業務をあふれさせないためには「何をやらないか」の決断が重要です。この決断をするのは、ユーザーに対する最終的な責任を負い、予算決定権を持つ経営層と考えるのが妥当でしょう。

経営層からの「運用」への期待を明確にすることにより、以下の効果が期待できます。

1. 慢性的なリソース不足が解消
期待の明確化によって運用の守備範囲が明確になり、「なんでも運用」から脱却できる可能性が生まれます。肥大化する業務に比例して増大する現場のリソース要求に対し、経営層が「やらないこと」を適切に判断することで、リソース不足が解消します。これを運用現場の視点で表現すると、「予算が無いならやらない、やるなら予算よこせ」という感じでしょうか。
2. 慢性的な業務バーストが解消
「なんでも運用」と「リソース不足」から脱却した運用現場では、経営層の期待と自分達のリソースを基に、期待されている業務にリソースを集中できるようになります。リソースの集中は業務の効率化を生み、業務の効率化は的確な業務サイジングを可能にします。こうした運用現場では、業務がバーストするリスクが大幅に減っているでしょう。
3. 適切な運用設計が可能
期待の明確化によって、運用現場に求められる「アウトプット」とその「表現方法」が明確になります。これにより、「運用現場は何をコア・コンピタンスとするのか」という行動指針や「品質が重要なのか、コストが重要なのか」などの価値観が明確になります。行動指針と価値観を基に運用業務全体を捉えなおすことで、より適切な運用設計が可能となるでしょう。

悩み解消ポイント2. 運用設計の確立

次に、「運用設計」を確立する必要があります。

前回の問題点分析で説明した通り、自らの業務をきちんと把握できない状況は、運用現場自身の首を締めることにつながります。経営層からの「運用」への期待に対し、ブレ無く、モレ無く、ムダ無く、ムリ無く、かつ持続可能な運用業務をどう実現するのかを、「運用設計」を通じて明文化します。これにより、「期待」に沿った「自らの業務」を把握できるようになるでしょう。

運用設計を確立することにより、以下の効果が期待できます。

1. 「やらないこと」の明文化が可能になる
主要な「期待」に対応する運用の「業務」を文書化することで、運用現場の主要ミッションについて、ブレやモレを排除することが可能になります。同時に、「やるべきでないこと」や「優先順位が低いもの」が明確になり、ムダやムリを省くことができるようになります。こうして、限られたリソースを主要ミッションに集中できるようになります。実作業の優先順位付けを行なうことで、業務バーストの抑制も実現できるでしょう。
2. 本当に必要な「運用基盤」の整備が可能になる
ミッションの明文化により、ドキュメント作成/保守業務の優先順位付けが可能になります。優先順位の高いドキュメントを確実に整備することにより、要員の退職などによる事業継続性のリスクが減ります。また、ミッションに必要なスキルセットを明確にすることにより、運用メンバーの育成方針や具体的な教育方法も見えてきます。ドキュメントとスキルセットを基に本当に必要なツールを実装することで、適切な効率化を実現できるでしょう。
3. 運用実績の測定が可能になる
運用業務の文書化と運用基盤の整備により、運用業務の各作業について、測定ポイントを選定し、実際に測定できるようになります。これにより、短期間で、運用組織内部の定性的・定量的な「見える化」が実現します。例えば、業務量と運用リソースから業務負荷を予測してリソース配分を変更することで、業務を適切にサイジングできるようになるでしょう。

悩み解消ポイント3. 期待に対する消費リソースを測定

最後に、「期待に対する消費リソースの測定」を可能にする必要があります。

これは、経営層が拠出した運用リソースに対して、「その期待に沿うかたちで、どのくらいの成果を実現したか」についての説明責任を果たすことを意味します。日頃コスト・センターと言われ続ける運用現場にとって、運用の費用対効果について説明責任を果たすことは、一律的なコスト・カットを回避するだけでなく、現在の自らの立ち位置を確認する上でも非常に重要であると言えるでしょう。

期待に対する消費リソースの測定を可能にすることで、以下の効果が期待できます。

1. 「運用の効率化」が可能
運用実績として測定されたデータを基にすることで、経営層の視点に立った「運用の効率化」が可能になります。 「運用現場における効率化」が詳細なデータに対する分析を基に行なわれるのに対して、「経営層が求める効率化」では、多くの場合、必ずしも数学的な正しさは求められません。測定データを現場視点で合理的に組みあわせることで、経営層の理解が深まり、納得を得られやすくなるでしょう。
2. 運用の地位が適正化
運用への「期待」に合致した「成果」を実現することで、運用現場に対する評価が適正化され、現場業務に適したメンバーの成長や成果を適切に評価できるようになります。さらに、測定結果を基に、サービス企画/設計部門に対して的確に助言することで、運用現場の相対的な地位が向上し、他部門とより対等な関係に近づいていくでしょう。
3. より高度な「期待」が醸成
経営層が期待する「運用の効率化」を実現して「適正な評価」を受けるようになった運用現場は、その実績を基に新たな「期待」を醸成することとなり、新たな期待を満たすことで、さらに運用現場の地位向上を果たせるようになります。これにより、新たなリソースや高度な人材/技術の獲得が可能になり、より安定したサービスを提供できる強力な運用組織へと成長することになるでしょう。

運用現場の「悩み」を解消するためのサイクル

上記の通り、書いている著者自身きれいごと過ぎると思うような3つの解消ポイントですが、運用現場の悩みを解消するためには、経営層側も運用現場自身も、考え方をある意味根本に近いところから変える必要があるのではないでしょうか。

運用現場の「悩み」を解消することは、容易ではありません。とはいえ、いつまでも「悩み」に追われているわけにもいきません。

ここでは、3つの「悩み」を解消するポイントについて、

  1. 「運用」への期待を明確化(Plan)
  2. 運用設計を確立(Do)
  3. 期待に対する消費リソースを測定(See)

という「PDSサイクル」で継続的に実行することを考えていきます。

図2: 運用現場の「悩み」を解消するためのサイクル(クリックで拡大)


このPDSサイクルを実際にどうやって回していけばよいのかは、次ページで詳細に説明しますが、日々の運用業務に追われている中で、たとえ手が動かせないとしても、まずは、以下の3点から始めてみるとよいでしょう。

  • 「運用への期待」が何か、を意識してみる
  • 「優先順位の高い運用業務」と「運用実績の測定方法」を明確にするためにはどのような「運用設計」が必要になるのか、を意識してみる
  • 得られた「運用実績」をどう分析し、どう表現するか、を意識してみる

これにより、業務に対しての見え方が変わってくる可能性があります。こうして、見えてきた部分から着実に実現・改善していくことで、「安定して、楽で、評価される運用」に一歩ずつ近づいていくのではないでしょうか。

日本の運用現場にPDCAサイクルは合わない?

多くの国際規準を含む有名なフレームワークでは、継続的な改善を行なうプロセスとして、Plan/Do/Check/Actionの4ステップを踏む「PDCAサイクル」を採用しています。しかし、国内でも広く浸透しているISMS(ITセキュリティ・マネジメント・システム)をはじめ、PDCAサイクルで「現場に歓迎されて継続的に上手くまわっているもの」を、日本国内ではほとんど見たことがありません。多くの場合、1周目のActionまでで終わるか、2周目の途中で途絶えるか、現場の反発を受けながら無理矢理継続している例が多いように感じています。

日本の運用現場には、他国と比べて、比較的士気や教育レベルが高く、自律的に動けるという特徴があると思われます。こうした日本での改善活動には、Plan/Do/Seeの3ステップを踏む「PDSサイクル」の方が、リズム良く自走しやすいと考えられます。今回の「運用方法論」では、随所にPDSサイクルを意識した考え方が反映されています。

「悩み」を解消するためのサイクルを実践

次ページでは、上記の「悩み」解消サイクルをベースに「運用業務における改善プロセス」の全体像を俯瞰し、「悩み」解消へのアプローチ方法について検討していきます。

運用業務のライフサイクル

運用業務における改善プロセスを検討する前提として、ここでは運用業務の基本プロセスとなる「運用業務のライフサイクル」について考察します。

一般的に、運用業務のライフサイクルは、下記の3つのプロセスで構成されています。(1)運用業務の概要設計(サービス設計/Plan)、(2)運用業務の詳細設計(運用設計/Do)、(3)運用実績の蓄積(測定/Check)、です。

1. 運用業務の概要設計(サービス設計/Plan)

まず最初に、運用への期待が、明示的または暗黙的に発生します。

明示的な期待であれば、運用現場の都合を考慮した「サービス設計」を通じて「運用業務の概要設計」が行なわれます。

一方、暗黙的な期待の場合、運用現場の知らないところで人知れずに生まれているかもしれません。例えば、システム障害の通知先として、知らない間に運用現場が指定される、といったケースがあります。概要設計がされないまま運用業務に直接影響を与えてしまうリスクとして潜伏していきます。

2. 運用業務の詳細設計(運用設計/Do)

次に、1で行なわれた設計に従って、「運用業務の詳細設計」とも呼ぶべき「運用設計」を実施します。

まず、運用業務上のキーとなる「運用作業の一覧」を作成します。次に、各運用作業に必要な「ドキュメント」「スキルセット」「ツール」、すなわち「運用の三種の神器」の仕様を確定・整備します。運用の開始とともに、運用の三種の神器を利用してサービスを提供していきます。

3. 運用実績の蓄積(測定/Check)

運用の開始とともに運用実績の蓄積を開始します。測定結果はサービス設計に従って一定期間ごとに報告します。

この測定結果を基にサービス設計が変更されます。これを受けて運用設計が変更されます。こうして運用業務のライフサイクルが回りはじめます。最終的には、サービス自体の廃止によって、ライフサイクルが終了します。

運用業務における改善プロセスの全体像

運用業務の基本プロセスである「運用業務のライフサイクル」と、1ページ目の図1に示した、運用現場の「悩み」を解消するためのサイクルは、ともに同じ「PDSサイクル」となっています。これらを重ねあわせると、図3のようになります。

図3: 運用業務における改善プロセスの全体像(クリックで拡大)


図3が示すように、「運用業務のライフサイクル」を構成する個々のプロセスにおけるステーク・ホルダーと調整することによって、運用現場が持つ「悩み」の解消につながるアクションをとれるようになります。運用現場にとって、外部の主要なステーク・ホルダーは予算を握る「経営層」であり、内部の主要なステーク・ホルダーは実働する「運用メンバー」となるでしょう。

2つの「運用設計アプローチ」

「経営層との調整」と「運用設計」のどちらを優先するかによって、「運用設計アプローチ」は下記の2つに分かれます。

  • トップダウン・アプローチ
  • ボトムアップ・アプローチ

トップダウン・アプローチ

トップダウン・アプローチは、「運用業務のライフサイクル」に従って「運用設計」を行なうアプローチです。

経営層との調整後に「運用設計」が行なわれる、本来あるべき正しいアプローチです。運用に関して明確な設計思想やベスト・プラクティスが確立されている運用現場では、こちらが用いられているでしょう。

一貫した設計思想を適用しやすく、設計作業に必要な時間も短かくなることが期待できます。また、トップダウン・アプローチを実践できているということは、「運用への期待が不明確」という運用現場を悩ませる最大の「要因」が起こりにくいことが期待できます。このため、非常に大きなアドバンテージになると考えられます。

ただし、運用への期待や、運用設計の手法や方針が確立されていない場合は、運用開始後の軌道修正が頻ぱんに発生するといったリスクが考えられます。

ボトムアップ・アプローチ

ボトムアップ・アプローチは、すでに稼動している運用に対し、ミニマムな部分から「運用設計のやりなおし」に着手して、徐々に対象範囲を拡大していくアプローチです。必要となった時点で、経営層との調整に入ります。それまでは、影響範囲に注意しながら運用設計を進めます。

これは、運用業務のリバース・エンジニアリングとも言うべきものです。「設計思想」が失われた運用業務や、やり方が古くなった運用業務に対して、業務プロセスを解析しながら、仕様、目的、業務要素などを棚卸して再構成します。業務のシンプル化、非ブラックス・ボックス化、費用対効果の見直しを図ること、などを目的に実施します。

対症療法的であまり望ましくはないのですが、一番難しい「経営層との認識あわせ」をとりあえず保留して、まず「現状の見える化」と「現状からの見直し」に着手します。自分たちの実績と仕組みを固めてから経営層と同じテーブルに着くことで、論理的・合理的な議論へと誘導できることが期待できます。

まず運用現場での洗い出しから始めるため、「運用設計」の前に1回以上、改善プロセスを回わさなくてはなりません。この分、オーバー・ヘッドが発生します。一方で、運用現場だけで着手できるため、比較的現実的なアプローチとも言えます。また、ミニマムな部分から着手するため、その運用設計に無理があった場合でも、影響範囲が狭くて軌道修正が簡単である点もメリットです。

現時点では、ボトムアップ・アプローチの方が現実的という運用現場が多いのではないでしょうか。

図4: 2つの運用設計アプローチ(クリックで拡大)


そして「運用設計」へ

次ページでは、「ボトムアップアプローチ」を行なう場合に、運用現場が最初に直面する課題である「運用設計」について、その内容を考察していきます。

「運用設計」とは何か

「運用設計」という言葉は、運用現場で日常的に使われている割には「その実体がはっきりしない」という不思議な言葉です。では、「運用設計」とは何なのでしょうか。

「運用設計」の中身

「運用設計」とは、「各現場に適した、運用業務の枠組み(フレームワーク)を作り込むこと」と考えると、実際の仕事の内容を捉えやすいのではないでしょうか。

「フレームワーク」という言葉は、世間一般に「物事を整理する手法」という意味で使われているようです。この意味と共通する「客観的な立場に立ち、科学的/論理的手法を用いて分析し、継続的に見直しサイクルを構築する」という意図を、ここでは込めています(「KAIZEN」の概念に極めて近い、という指摘を受けたことがあるので、それなりの妥当性はあるようです)。

つまり、「運用設計」とは、個々の運用現場に特有の「事情」を念頭に置きつつ、その運用現場の業務のために、下記の性質を全て備える「フレームワーク」を作り上げること、と考えられます。

  1. 客観的な立場
  2. 科学的手法による測定(実績などの見える化)
  3. 論理的手法による分析(モデル化)
  4. 継続的な見直しサイクル

このときに、一貫した設計思想を基に、運用現場にとって効率的で分かりやすい「フレームワーク」を作り上げることが正しい「運用設計」であり、それを実現するのが「運用のプロ」の仕事なのではないでしょうか。

「運用設計」が無い現場はどうなるのか

では、「運用設計」を適切に実施していない運用現場は、どのような状態に陥ってしまうのでしょうか。以下のような状況になると考えられます。

  • 意見や分析が主観的になる
  • 感覚値で論じられることが多くなる(非科学的)
  • 論理的な議論ができず非合理的な結論になりやすい(非論理的)
  • やりっぱなしになる(非サイクル性)

残念ながら、「どこかで見た光景」と感じる方もいらっしゃるでしょう。もし、そうであれば「運用設計」を見直す意義は大きいでしょう。

「運用設計」の目的と本質

以上、「運用設計」とは何なのか、について分析してきましたが、そもそも「運用設計」の目的とは何なのでしょうか。

それは、「高負荷、属人的、見えぬ費用対効果」という運用現場が困ることを決して招かない「仕組みを作ること」です。

以下の3つの仕組みを、それぞれの運用現場の実情にあわせて作り上げる必要があります。

  1. 業務の「複雑化を許さない」仕組み
  2. 業務の「ブラック・ボックス化を許さない」仕組み
  3. 「業務価値の陳腐化を許さない」仕組み

運用設計の目的1. 業務の「複雑化を許さない」仕組み作り

運用現場の「高負荷」には、質と量という2つの側面があります。「量的な高負荷」に対しては、やや安直ですが、人を増やすことによって短期的には解消できるでしょう。一方、業務の複雑さに起因する「質的な高負荷」は、容易には解決できません。

運用設計の第1の目的は、こうした質的な高負荷を招かないために「業務をシンプルに保つこと」となるでしょう。「シンプルな業務」は、必要なスキル・セットやツール仕様の決定を容易にし、作業品質の安定、業務スケーラビリティの向上など、多くの恩恵をもたらすでしょう。

運用設計の目的2. 業務の「ブラック・ボックス化を許さない」仕組み作り

運用現場の「属人化」には、次の2つの意味があります。(1)定常運用のような「ブラック・ボックス化が許されない」領域と、(2)非定常運用や運用設計などのように、担当者の「ノウハウや個性」が期待される領域、です。運用現場において大きな問題になるのは前者です。事業継続性リスクを生み出すことにつながります。

運用設計の第2の目的は、「属人化が許されない領域」において、「常に業務が見える」状態を維持すること、になるでしょう。「常に見える業務」は、業務の効果測定や継続的な改善を容易にするとともに、運用メンバーの業務負荷平準化、要員の退職による事業継続性リスクの低減、対外的な業務説明責任能力の向上など、多くの恩恵をもたらすでしょう。

運用設計の目的3. 「業務価値の陳腐化を許さない」仕組み作り

「費用対効果」については、「費用」と「効果」で性質が異なることを考慮する必要があります。一般的に、「費用」は、何らかの事情が無い限り、時間が経過しても一定のままです。一方、「効果」は、時間の経過とともに経年劣化していくのが普通です。この経年劣化は、「技術の進歩による業務の陳腐化」や「運用の受け入れ当時は喜んでいたユーザーが、時間の経過とともに、だんだんそれが当たり前と感じてきている様子」などにより具現化していきます。

運用設計の第3の目的は、運用の「効果」を経年劣化させずに、少なくとも、その「効果の価値を維持すること」になるでしょう。可能であれば、その「効果」を増進させる必要もあります。これは非常に難しいことだと思いますが、現場視点からのサービス提案や改善提案などによって新たな業務価値を生むことができれば、運用現場のみならず、メンバー個々人の評価向上など、その運用現場で働く人々に多くの恩恵をもたらすでしょう。

図5: 「運用設計」の目的(クリックで拡大)


これら3つの仕組み作りを追求し、「サービスの安定、業務負荷の平準化、運用に対する評価の適正化」を実現することが、「運用設計」の本質ではないでしょうか。

「運用設計」の副次的な効果

「運用設計」を適切に実施して「客観的な立場に立ち、科学的/論理的手法を用いて分析し、継続的に見直しサイクルを構築」した場合、目に見える効果が出るまでには時間がかかるでしょうが、これとは別に、以下の3つの副次的な効果が期待できます。

1. 運用のステークホルダー間の共通言語の醸成
「運用設計」により運用業務を明文化することで、その運用現場に関わるステーク・ホルダー間で「共通認識」が確立され、同じ前提の上で議論できるようになります。
2. 現状と理想の差分の明確化
「運用設計」において、論理的・合理的な「理想」を描き、科学的手法を使って「現状」を測定することで、現状と理想の「差分」が明確になります。この「差分」を改善サイクルで解消していくことによって、より理想に近付けることができます。
3. 環境変化に柔軟に対応できる運用体制の構築
「運用設計」は、運用業務全体の「見える化」を実現します。これは、変化に対応するために必要な変更ポイントを明確にします。これにより、迅速で柔軟な対応が可能になります。

「運用方法論」の全体像

第1回では、以下の2点について解説しました。

  • 運用方法論の目的(「安定して、楽で、評価される運用」の実現)
  • 運用現場の問題点の分析(3つの「問題点」と3つの「要因」、「運用でカバー」による弊害)

今回の第2回では、以下の2点について解説しました。

  • 運用現場の問題点の分析(「要因」解消のための3つのポイント、解消サイクル)
  • 運用のフレームワーク化(運用設計アプローチ、「運用設計」とは何か)

これらを含めて「運用方法論」の全体像を示すと、図6のようになります。

図6: 「運用方法論」の全体像(クリックで拡大)


前述した通り、「運用設計」とは、「各現場に適した運用業務の枠組み(フレームワーク)を作り込むこと」です。

しかし、ゼロからフレームワークを作り込むことは、改善までなかなか手の回らない運用現場においては、非現実的と言えます。各現場での「フレームワーク」のひな型となる実践的な運用設計リファレンス「運用フレームワークfwop」を、筆者を含む有志による「運用研究会」では、継続的に検討・議論しています。

次回は最終回

本連載の最終回となる次回は、「運用フレームワークfwop」を中心に、運用設計の今後について展望していきます。

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

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

連載バックナンバー

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

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

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

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