SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

システム運用における品質管理について 第4回 運用品質へのアプローチツール(品質を測るツール)
2021年7月7日 10:00

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

 

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

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

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

  • ①ISO9000sの考え方での用語やワークフローを用い、
  • ②QC7つ道具、新QC7つ道具に代表されるQCのツールや各種の状況分析ツールを用い解決すべき問題を明確にし
  • ③QCDの面から改善目標値を量り
  • ④6W3HやM.A.R.T.を参考にしながら目標値の根拠や測定ポイントを明確にし
  • ⑤PDCAのPDで活動計画を立てて活動を開始し、
  • ⑥PDCAのC(経過観察)でKPTを用いて日常の定期的な活動チェックを行い
  • ⑦Planで定めた評価期限を迎えたらPDCAのCAでKPTの履歴も参照しながら結果の評価を行い、次の改善サイクルの計画を行う

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

 

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

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

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

 

■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)による優先順位を付けて順番に取り組むこともあります。

 

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

 

 

人材育成
システム運用における品質管理について
 システム開発での品質管理は様々な方法論があり、業務に適用し成果を上げ、標準化が浸透しています。  しかしながらシステム運用は品質管理の面からの業務の評価が遅れており、人員の流動性も高く、「良い仕事をした」という感覚を得るのが難しいジャンルです。  ここで、システム運用での品質とは何か、また品質の向上により何がもたらされるかの考え方を提案し、現場の仕事のやりがいに繋げていただきたいと思います.
記事一覧へ
筆者紹介

岩瀬 正
1960年生まれ
フリーランスエンジニア、情報処理学会ソフトウェア工学研究会メンバー
連想記憶メモリを卒業論文とした大学電子系学科を卒業。
国内コンピュータメーカーにて海外向けシステムのOSカーネルSEとアプリケーションSE、自動車メーカーにて生産工場のネットワーク企画から保守までの責任者、外資系SI企業の品質管理部門にてITIL,CMMI,COBITを応用した業務標準化に携わる。
合わせて30数年の経験を積んだのちにフリーランスとして独立し、運用業務の標準化推進や研修講師などに従事する。
80~90年代のUnix、Ethernetムーブメントをいち早くキャッチし、米カーネギーメロン大学や米イェール大学とも情報交換し、日本で最も早い時期でのスイッチングハブの導入も含めたメッシュ状ネットワーク整備を行うと共に、初期コストと運用コストをどのように回収するかの計画立案を繰り返し行い評価し、利益に繋がるネットワーキングという業務スタイルを整備した。
トライアルバイクとロックバンド演奏を趣味とし、自宅にリハーサルスタジオを作るほどの情熱を持っている。

コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

2021年7月 第15回システム管理者の会 感謝の日イベントの開会のご挨拶の様子を掲載いたします。

個人情報保護方針
運営者につい て
利用規約
サイトマップ