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

運用ノウハウを学ぶ

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

システム運用における品質管理について 第5回 運用業務品質への取り組み方
2021年8月4日 10:00

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

 

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

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

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

 

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

最も基本となるシステムの価値は、クライアントと約束したRFP等を基にした要求条件のはずです。開発段階までの間に運用で必要となる性能目標値と測定方法について、顧客とどのような約束をしたかをしっかり引き継ぐことが重要です。また運用の取り決めについても顧客によっては特有の情報収集や報告を約束している場合があるので、運用段階になる前に明確にし、運用開始の前に何を運用するのかを正確に把握することが大切です。この指針は運用した結果として評価されます。もし明確な定義がされていないのであれば、ITIL を参考にして、顧客ニーズに近く、運用上実現できる項目を洗い出し、成果をどのように収穫するかを設計します。堅苦しい言い方をすれば、サービスレベルの定量的目標値の設定という作業を行います。
顧客向けの目標値が設定できたら、その目標を実現すべく、サービスレベルを支える運用業務を細分化し、各運用業務品質の個々の目標を定義します。つまりサービスレベルを満足しているかの判断には、日々の運用で個々の仕事がどのような結果や経過になれば仕事が効果的に行われたかが分かるように紐づけします。その目標値はいつも安全にクリアされる訳ではなく、日々工夫をして結果の辻褄を合わせていることも多々あるでしょう。その業務の改善を暗黙の裡に行うのではなく、チームとして明確なストーリーを持たせて進めるために、業務品質の改善プランの設計を行います。
運用業務において、クライアントと約束した要求条件は当たり前品質であり、運用業務改善は魅力的品質で表されるという感覚になります。

 

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

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

  • · Plan時に問題分析結果を定量評価できないレベルまでしか落とし込めていない
  • · Do時に成果を得られる行動になっているか経過確認をしていなくルートから外れてしまう
  • · Check時に成果を評価せずに日程的な進捗だけを確認している
  • · Actionが改善のアクションではなく、報告するなどの品質向上には結びつかない作業で完結してしまっている

という、PDCAの流れが定義されず、それぞれの工程で出す結論がバラバラで間違っている場合が多いように思われます。
特にPlan段階できちんと結果の求め方を決めることがポイントですが、なかなか難しいと思われがちで時間切れになり、はしょってしまうかもしれません。
この対策として、QCDに6W3HとITIL の組み合わせを入れ込み、測定基準を定めるという手法があります。

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

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

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

運用上の障害での業務改善の方向性を決めた例

分類

改善したい要素

原因分析の概要

ITIL分類

6W3H要素

Quality 作業手順の中に個人レベルのチェックが無く、リーダーも個々のチェックをしていなかった 作業を行う際の手順があいまいで、対象としているシステムの目的が維持されているかの確認が足りず、システムの品質と運用の品質の両方を落としてしまった

移行の計画立案

What

リリース管理

How To

妥当性確認及びテスト

Why

Cost 作業準備に時間がかかり実施時間を圧迫した 作業時間の管理が甘く実施工数しか見積もっていなく、現状確認から実施手順を定める手順と工数があいまいだった

移行の計画立案

How To

運用管理

What

構成管理

Where

Delivery 作業開始時に必要な情報が揃っていなかった 作業のリクエストが発生した際から完了までの工程と書くステップを始めるにあたっての前提条件が不明確なため出戻りが多く発生した

構成管理

How

サービスカタログ管理

How Many

サービス継続性管理

Why

この表では非常に大雑把な内容表現で実際にはもっと細かいレベルで記述しまとめますが、この例での分析から、何に対して、どこを目標として対策を打つべきかのポイントが分かります。PDCAを回す際は、この分析から外れないように注意して具体的な目標設定、対応策の実施、日々の確認、結果の評価を行います。特に6W3H要素はキーワードしか書いていませんが、実際の評価値に何を使うか、値の範囲はいくつが妥当かを導き出さなくてはいけません。

筆者の経験で実際にあった運用業務での事例を少々アレンジして載せますので、問題点と改善策を考えてみましょう。

 

事例1:とにかく長い報告書と説明に費やされる会議
◆月度運用報告書に運用で取得したデータをまとめ、表やグラフで載せる。しかし、そのデータが何を意味しているかを記述していなく、報告会はデータの説明に終始する。

  ➢ 契約内容によるものの、運用データを分析解釈し、結論として問題の有無を判断するのは運用側の責務です。
報告先の特徴によって順番が変わることはあるものの、最初に結論を述べてから根拠を示すべきです。現状判断があり、予測が来て、未知の要素があれば利用者側に変化があるか確認し、双方のメリットにつながる提案があれば議題として挙げる、という流れを基本として運用業務の契約内容によってアレンジするかと思います。
報告先の顧客から「だから何だったと言いたいのですか?」と言われたらアウトです。
報告の品質に対して、依頼側が何を知りたいか、運用側は何を伝えたいかを、QCD+ITIL+6W3Hで定義して、業務の目標達成度合いの討議の場としないと無駄な会議になります。

 

事例2:形式になっている24H365Dの契約
◆24H365Dでの運用として契約しているが、緊急連絡網に利用者側の標準勤務時間帯の連絡先しか取り決めていない。

  ➢ この契約が法的に間違っているとは言い切れませんが、時間外の連絡先の定義がなければ、利用者側が休日出勤や残業している時に起きた問題で、利用者への連絡や利用制限等を通知できず、結果的に利用者の利便性を損なうことになります。「そのあたりは常識的に臨機応変に対応してくださいよ」と軽く言われるケースもありますが、これは「当たり前品質」が存在しないことになります。仮にたまたま居た利用者と相談して対応し利用可能となった場合でも、事前に相談することが取り決められてなければ越権行為で非常に危険ですし、そもそも再開して良かったのかにも疑問が残ります。万が一責任問題になった場合、復旧させた側の責任が問われることが多いようです。ITIL の参照と6W3H要素の割り当てとアクションの定義を行っていれば問題が潜在していることが最初から分かったはずです。

 

事例3:すでに全ての業務が標準化され工夫の余地がない現場
◆メンバーが作業に精通し、マニュアルも整備され、例外なく全ての業務がミスも無く遂行されているので改善の必要がない。

  ➢ あり得るのでしょうか?人の作業にミスが発生しないなど、古今東西ありません。
この場合、一つは手順にないことが起きても表面化させないで担当の腹の中に隠してしまい良い結果だけ残すケース、もう一つは問題が出ても他責とし、自チームの問題としてカウントしていないケースなどが考えられます。
この現場もかつては苦労をして作業標準を整備し訓練したこととは思いますが、その後の品質分析と継続的改善が業務の一環として定義されなかったのかと思えます。対象となるシステムは日進月歩どころか秒進分歩で変化します。担当者のスキルは日々変わりますし、担当者そのものもいずれ変わります。システムと人の間を取り持つ手順書・標準書が変化しない訳がありません。品質管理では問題が無い(見出せない)こと自体が問題であり、改善しなくてはならない重要ポイントと解釈します。

 

おそらくここまで極端な事例が身近にはあるとは思いませんが、ケーススタディとして、どの時点で何を定めて、どのような行動を取れば良かったのか考え、自分たちが担当する範囲へ応用すると運用業務の精度が上がると思います。
繰り返しますが、現象と原因を深く掘り下げてください。表面的にはこのようなことは起きないでしょうが、しっかり掘り下げると、これらの原因に近いことは身の回りで起きているはずです。
実務で起きた事例をケーススタディとして問題の原因を潰しておけば、類似業務での被害を防ぐことができます。同様に問題の予兆を敏感に感じ取る行動をしていれば、やはり問題が顕著化する前に対策を施すことができて利用者への被害を防ぐことができます。
実際に起きていること、一般常識的にやるべきこととされている事項だけ行っているより、業務精度もスキルも向上し、その活動が外から見た信頼に繋がります。

 

第5回では品質管理への取り組み方についてPDCA,QCD,ITIL,6W3Hというツールを通して説明しました。最終回となる第6回では、品質管理活動を人任せや言われ仕事にするのではなく、まず自分から始める意義について説明します。

 

 

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

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

コメントを書く

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

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

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

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

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

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

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