システム運用における品質管理について

第5回運用業務品質への取り組み方

概要

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

第4回では、品質を評価するツールとして、「現象」と「原因」、PDCAサイクルなどについて説明しました。第5回は、具体的な品質管理を実業務へどのように組み入れるかについて説明します。

目次
運用品質の価値をどう定量評価するか
運用品質を設計するということ
PDCAサイクルの具体的適用とは
QCD,ITIL,6W3Hの組み合わせ

運用品質の価値をどう定量評価するか

第一に意識しておいていただきたいことは、運用業務がコストセンターと言われるケースに甘んじてはいけないという気持ちを強く持ち、忘れないことです。運用業務は決してコストセンターではありません。経営価値を生み出しています。これを理解し納得してもらうためには定量的な価値を報告していく必要があり、それは運用の現場で仕事をする私たちでなければ算出できません。 この価値の考え方についてまとめているのが ITIL の体系です。運用業務品質についての活動を行う際に非常に参考になります。 ITIL V3までは成功事例を集めた体系で、V4ではアーキテクチュア全体に応用し価値を重視する姿となりましたが、ITILの基本的な捉え方はあくまでも参照しアレンジして利用するもので、記載内容通りに適用したからといって成功するテンプレートやマニュアルの類ではありません。 ITILは先人たちが苦労して導いて成功させた実績のある事例ですので、「ここに書いてある内容は今の自分の作業に使えそうだ」と思った部分を見出し、実務に合わせてアレンジを加えて実施することで、良い結果を得ることは十分に期待できます。本コラムではITIL の詳細な内容については専門書に譲るとして説明しませんが、ITIL で紹介されている技法と重なる部分を記述します。参考にしていただきITIL に記述されている内容を調べてみると理解が深まるかと思います。 またシステム開発においても、運用側がどのような課題分析を行うかを理解しておくためにITIL の内容を理解しておくべきと考えます。 今回のコラムの内容に関係が深い「7つの原則」だけ挙げておきます。この先をお読みになりながら、この原則のどれに沿った内容が書いてあるのかを連想できれば、ITILの資料も読み易くなるかと思います。

【ITIL V4における7つの指針となる原則】
 · 価値にフォーカスする
 · 現在あるものから始める
 · 短期間のフィードバックを繰り返し進める
 · コラボレーションと可視化を推進する
 · 全体的な視点で考え行動する
 · シンプルで実践的であること
 · 最適化と自動化を推進する

運用品質を設計するということ

運用作業を行っている時に、例えば、何か起きてしまった場合など、リカバリー作業を実施し、対応後に、「参ったね、ミスってたよ」「注意しないとね」という会話があったとします。
これだけで終わってしまうケースは非常に多く見受けられます。会話だけでなく、きちんと再発防止策を行わないと、仮に同じミスは起こさずとも似ているミスは起こします。何かが起きた時は改善のチャンスとして、きっちり後始末を行うべきです。
この「きっちり後始末」の習慣が運用品質を上げる重要ポイントです。ここを甘くすると無駄時間が増えてしまい技術力も伸びませんし、何よりやる気を無くしていきます。
この再発防止への仕組みプロセスがPDCAサイクルです。
PDCAサイクルで重要なのは、技術的手順的に明確な測定方法と具体的な目標値です。そしてそれを定めた分析の流れを後から追い掛けられるように残しておきます。そうしないと環境が変わった場合に不適切になる場合があり、変化に追従するためには、それまでの分析フローを振り返り修正できるように準備する必要があります。
非常にありがちな残念なパターンは、Checkが「改善活動の締め切り日の成果の集計」だけになることです。これは改善活動の是非を問わず活動自体に価値を見出すだけになり、活動した事実の満足感だけ得られ、改善には結びつきません。
こうなるケースは、

 

PDCAサイクルの具体的適用とは

運用作業を行っている時に、例えば、何か起きてしまった場合など、リカバリー作業を実施し、対応後に、「参ったね、ミスってたよ」「注意しないとね」という会話があったとします。 これだけで終わってしまうケースは非常に多く見受けられます。会話だけでなく、きちんと再発防止策を行わないと、仮に同じミスは起こさずとも似ているミスは起こします。何かが起きた時は改善のチャンスとして、きっちり後始末を行うべきです。 この「きっちり後始末」の習慣が運用品質を上げる重要ポイントです。ここを甘くすると無駄時間が増えてしまい技術力も伸びませんし、何よりやる気を無くしていきます。 この再発防止への仕組みプロセスがPDCAサイクルです。 PDCAサイクルで重要なのは、技術的手順的に明確な測定方法と具体的な目標値です。そしてそれを定めた分析の流れを後から追い掛けられるように残しておきます。そうしないと環境が変わった場合に不適切になる場合があり、変化に追従するためには、それまでの分析フローを振り返り修正できるように準備する必要があります。 非常にありがちな残念なパターンは、Checkが「改善活動の締め切り日の成果の集計」だけになることです。これは改善活動の是非を問わず活動自体に価値を見出すだけになり、活動した事実の満足感だけ得られ、改善には結びつきません。

こうなるケースは、

 ・Plan時に問題分析結果を定量評価できないレベルまでしか落とし込めていない

 ・Do時に成果を得られる行動になっているか経過確認をしていなくルートから外れてしまう

 ・Check時に成果を評価せずに日程的な進捗だけを確認している

 ・Actionが改善のアクションではなく、報告するなどの品質向上には結びつかない作業で完結してしま   

  っている

QCD,ITIL,6W3Hの組み合わせ

6W3Hの全てを使うのではなく、PDCAを回すために必要な要素をピックアップします。
注意点があります。「QCD」の「CD」において、「Costイコールお金だから人件費や設備費でHow Much?」、「Deliveryイコール納期や締め日だからWhen?」と単語の語感で自動的に割り付けてしまうケースがありますが、これは間違いです。ここで用いる「QCD」は目標達成へのチェック要素ですので、カイゼンに必要なリソースとして6W3Hを割り付けるのです。この6W3Hは改善活動の振り返りでの定量的評価に用います。

例えば、二重系システムを運用している際に片系が落ち、切り替えに失敗しシステムダウンを招いたとした場合の業務改善での目標設定です。問題内容が「否定的特性:決定的要素」に分類されますので、対応を早急に行わねばなりません。
以下の表は、本コラムの第4回の④に該当します。①~③の分析で、「バージョンアップ作業の際に自動切り替え機能を一時停止し、作業終了時に元に戻すことを忘れたことにより発生した」ことが分かったとします。

お問い合わせ

連載一覧

コメント

筆者紹介

岩瀬 正(いわせ ただし)
1960年生まれ。
フリーランスエンジニア
情報処理学会ソフトウェア工学研究会メンバー

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

バックナンバー