第３回でシステム運用での品質の概念と定量的評価の重要性について説明しました。第４回では品質を測るツールを説明します。
ツールはいくつかあり、代表格がPDCAとOODAです。個人的な感覚では、運用業務全体の継続的改善を主体に考察する際は、OODAよりもPDCAが向いていると思いますので、ここではPDCA中心で話を進めていきます。但し個人レベルでの自発的業務改善にはOODAが有利とも思いますので、興味があれば調べてみてください。

目次

■運用品質の定量的評価とは■

■「カイゼン」と「なぜなぜ」がとても重要■

■Planは改善活動の最も重要な部分■

■運用品質の判断での悪い例■

■運用品質の定量的評価とは■

ここまでの話で重要なキーワードは、品質管理というのは品質を向上するためのツールということです。向上させる取り組みを行わない限り向上することはあり得ませんので、品質管理という仕組みを使って効率的かつ効果的に業務品質を向上させることが目的となります。
このためには、どのくらい向上するか予測し、向上したかを判断するための変化を測定するために現状を測らなければいけません。
どんなに頑張って仕事をしても、結果が測れないことは、「信頼されない」、「評価されない」、「頑張ることしかできない」という評価にしかなりません。
定量的に測るための重要ポイントは、PDCAサイクルのPlan段階で成果をどのように測るかを定義することです。
逆の表現をすると、「成果を計測できないのであれば誰のメリットにもならないことになるのだから、やらなくていい仕事ではないか？」と割り切って考えなければなりませんので、Plan段階でクリアしておかないと活動が無駄になります。

とは言うものの、品質を測るというのは、慣れていないと難しいものです。また、評価の基本データとなる業務分析にて原因と現象がごちゃごちゃになり一過性の現象潰しになってしまうことも多々あります。
ちゃんとやっているはずなのに効果が出ない時は、まず「原因の分析が間違っていたのではないか？」と考えます。分析の流れを間違えると、設定した測定ポイント以外の部分に成果が現れる現象や、成果が薄く広がってしまい測定不能になることがあります。
問題解決における「原因の分析」は最初に行わなければならなく、しかし敷居が高く悪路急坂が続く作業です。原因の分析を行うにあたり、品質管理のツールが役に立ちます。
品質管理のツールとしては、第１回で述べたツールを組み合わせることが一般的です。これらのツールは単体で効果を生み出すものではなく、ルール、プロセス、値の評価、のセットになります。
簡略化して言えば、

というような順序になると考えます。

■「カイゼン」と「なぜなぜ」がとても重要■

このような業務フローの問題解決の流れは「カイゼン（KAIZEN）」というキーワードでも調べることができます。「SQuBOK 1.2.2 S-KA：改善の考え方」にも記載があります。
＜すでに登場している用語ですが、ここの話では、「現象」と「原因」が文章に混在して出てきます。まず、「現象」と「原因」をしっかり区別して、主語と述語がどちらかを明確に意識して読んでください＞
現象の直接の原因を明確にしても、それは何らかの対策ができる原因ではなく、別の原因によって発生した現象が原因と見えているのではないか？　という考察を行わないと表面的な対策で終わってしまい、ほんのちょっとの環境の変化で再発してしまいます。これを防止して効果のある対策に注力するためには深掘りして「真の原因」を探り当てなければなりません。この深掘りする手順を「なぜなぜ分析」と呼びます。
なぜなぜ分析とは問題の原因を「なぜそれが起きた？」という思考から探り出し、その原因が実はさらに何かの原因による現象ではないかと考え「なぜそれが起きた？」と分析を続け、真因を単体で定量的に測れる形まで単純化・表面化して、効率的かつ決定的に対策する手法です。 （「なぜなぜ分析」の詳細な手順については、ネットや書籍で解説を読むことができますので、ここでは省略いたします）

「５回、なぜ？を掘り下げる」と言われますが、５回は相当に高い関門です。品質管理技法の高度な知識・経験が要求され不慣れな場合は工数ばかり消費し成果を出すことが難しいため、ゴンぺルツ曲線での「効率的な管理レベル」に収まることを優先し、最初のうちは循環思考に陥ったり焦点が他の課題に移るようなことがないように３回掘り下げるなど、回数を減らす判断も必要でしょう。掘り下げられないからと言って問題分析を100%諦めたら品質は絶対に向上しませんし、何も掘らずに形だけ整えても効果は出なく辛いだけです。まずは掘り下げが浅くても、正しい手順をしっかり理解して、小さくても多少の曖昧さがあっても成果を体得することが優先です。但し、いつまでも分析を端折っていてはいけません。訓練しないと永遠に５回は実現できるようにはなれません。努力が報われるか約束できませんが、努力しなければ絶対に報われないことは保証します。

■Planは改善活動の最も重要な部分■

原因分析を行う際は、分析手順を機械的に実施するのではなく、定量的な結果を出せるかを判定しながら進めることが重要です。
品質管理で最も重要なのはPlanであり、PDCAサイクルの成否が決まるのはPlanになります。これは当然のことで、経営戦略であろうとプロジェクト計画であろうと、計画で明確な数値目標を立てない限り成果を測ることはできません。ゲームであってもポイントを稼ぐために様々な工夫とテクニックを身に着ける訳ですから、目標値を定量的に定めようとする活動自体は特定の役職やスキルが無いと実行できないということではありません。慣れていないと効果的ではないというだけです。効果的な目標値を導き出すために努力し経験するのですから、この段階で手を抜いては品質の向上は見込めません。Planで行うことがスケジュール表の作成だけと勘違いしないように注意してください。念のために申し上げますが、Planを固定することが重要なのではありません。環境が変わり効果回収が期待できなくなればPlanから作り直します。
堅苦しく書いていますが、皆さんが趣味で熱中するのと同じ形で入ればいいと思います。料理が好きなら、素材を研究し調理方法を調べて実際の料理を味わい再現方法を考えます。楽器演奏が好きなら、楽器の使い方を調べ繰り返し練習し曲に合わせてみて出来ているか判断して不足部分を見出しさらに練習します
同じことです。品質管理においても書籍やセミナーのテキストに書いてある通りに実行しても上手くいきません。環境が違うのだから当然です。自分の仕事やスキルに合わせて成果が測れる形へのアレンジが必要です。

■運用品質の判断での悪い例■

運用品質の判断で陥りがちな点、逆に言えば改善の基となる点の例を挙げます。

① 作業手順に沿って作業することが品質管理とみなす
作業手順書がないために問題が発生し、その対策として手順書を作り効果が出ているか確認しているのであれば品質向上の対策と言えます。
しかし既に効果が検証され、業務標準として確立されれば、この手順書に基づく作業は品質向上活動ではなく標準化された業務手順となります。
作業手順に沿っているかの確認はDoの経過観察になりますが、作業自体は品質管理の対象ではありません。

② 問題を過小評価する
例えばソフトウェアのバージョンが変わって極僅か手順が変わる場合に変更部分の周知だけ行い、手順書を直さず運用しているケースが見受けられます。この状態は「潜在的な危険の内包」であり顕著化する前に早急な対策を行う必要があります。またこのような事例が見つかった場合、他にも同様な危険の内包がないか全体を見直す必要があります。
「極僅か」を問題の芽として扱わなかったミスになります。（ヒヤリハットやKYの事例で扱われることがあります）

③成果の刈り取りを行わない
問題分析し、対策としてチェックシートを作成し、チェックしながら作業し同じ間違いが起きないように工夫したとします。チェックにより作業ミスがあってもすぐ直せたので問題が顕在化しなかったという場合です。これは何も問題がないと思いがちです。
これは実施手順として正しいのですが、品質管理としては片手落ちです。チェックシートによるチェックで一発OKとならなければ問題が発生したことになります。ここを見逃していたら源流対策になっていませんので再発します。そして再発は無駄なコストを生みます。
チェックシートでNGが出る作業は見直さないといけません。

④続けるうちに惰性で行ってしまう
あまりにいつもチェックシートに全項目OKが続くと、ついつい勢いでOKを付けてしまい問題を見逃すことがあります。自己レビューと対面レビューの成績が大きく違うケースもこれに当たります。思い込みや勢いを避ける工夫は必要でしょう。「勢いOK」で問題を見逃して大問題が起きたニュースをよく聞きますので、そのようなニュースを機会に再チェックすることも効果的と思います。定期的に勉強会を開催し旬のニュースを取り上げて事例研究を行うと、品質管理への注意力を維持できるようです。

上記のような点を見逃さず、問題を見出し、PDCAサイクルを作ることが大切です。PDCAサイクルはたくさんあっても構いません。全ての作業はPDCAサイクル上に存在してなければならないというのが品質管理に基づいた仕事の進め方です。
手順書やチェックシートは、それによって何が改善されるのかを意識して定期的および問題発生時に振り返り、間違えていないか、陳腐化していないか、現場の役に立っているかを判断し必要に応じて更新（進化）させるものです。
定期的なKPTでPDCAサイクルが予想した効果を得られるよう回っているか意識統一を図ることも有用です。
ツールのパワーが小さいと感じるかもしれませんが、小さく、速く、繰り返し、ミスすればリカバリーする、というスタイルで多数のPDCAを回し、PDCAはもちろん、KPTで瞬間的な評価を押さえておかないと品質は改善しません。
恐らく問題は掘れば掘るだけ出てきますので、PDCAサイクルの定義が多すぎる状態になったら、ダウンサイドリスクを予測し、COQ(Cost Of Quality)による優先順位を付けて順番に取り組むこともあります。

第４回では、運用品質を測るためのツールと考え方について説明しました。「現象」と「原因」、PDCAの仮説検証サイクルがキーポイントです。第５回では、実際の運用業務に品質管理ツールを適用し、どのように仕事の品質を向上させるべきかについて説明します。