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

目次

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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