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

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

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

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

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

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

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

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

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

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

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

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