本コラムでは、システム運用における品質管理について、IT業界の経験が浅い人にも概念が分かるように、全６回の中でなるべく平易な言葉で説明します。まず第１回は、品質管理という行為は何を意味するのか、主に「SQuBOK 3.10 KA：運用および保守の技法」に関係する内容について説明します。

※ITIL®は AXELOS Limited の登録商標です。
COBITⓇはISACAおよびITGIの登録商標です。
CMMI®は、カーネギーメロン大学の登録商標です。
シックスシグマ®は米国モトローラの登録商標です。
SQuBOK® は、日科技連による登録商標です。

目次

■品質管理とは何を行う活動なのか■

■品質という不定形なものを評価するポイント■

■品質を改善するためには何をすればいいのか■

■品質を考える際の取り組み姿勢について■

■品質管理とは何を行う活動なのか■

　品質管理の定義について気にする方は少ないようですが、品質管理を行うということは、

　 と定義されます。

IT業界でよく聞く話ですが、品質＝不具合（バグ）数という表現です。そして不具合を見つけ出して数えるのが品質管理という枠組みにしてしまうケースです。
上記の定義に沿っているでしょうか？
品質を管理する目的は、品質の改善です。改善のために修正する行為は単なる業務です。つまりバグを見つけてプログラムを修正する行為は、プログラミングやインスタレーション業務という不具合対策の手順であり、品質改善の主プロセスではありません。そのようなバグを作り出さない手順を見いだし、作業に織り込むことが品質改善です。少し論調が理解しにくいかも知れませんが、この前置きを今すぐに理解する必要もないので、このまま先へ進んでいきましょう。

■品質という不定形なものを評価するポイント■

　品質を評価する際のポイントは、

　 であり、これら３つの要素を上手にバランスを取りながら業務を行う事で、誰もが納得できる成果物を作り出すためのツールが、品質管理の仕組みです
品質管理の活動を一言で述べると、

と言えます。

品質を管理する対象は、商品やサービスだけではなくそれらを生み出すプロセスも含まれます。これは、品質の高いプロセスが、品質の高い商品を生み出す要因の一つであるという考え方に基づきます。

■品質を改善するためには何をすればいいのか■

品質を改善するための品質管理の活動は以下のように行います。

この活動を行う際に、数々の標準やツールがあります。

もう少し具体的な話で説明します。 システム開発でのQCDは、 Q：レビュー指摘件数やバグ数の終息度合い C:工数 D:工程進捗（行程進捗） を管理することでコントロールするケースが多いと思います。しかしこれは開発中のプロジェクトにて管理するもので、顧客には関係ありません。

それでは、顧客から見たQCDはどうでしょうか？
そのシステム（＝商品）に対する、クオリティは業務課題の解決度、コストは契約金額、デリバリーは納期、になるはずです。顧客から見たQCDを満足するように提供しているでしょうか？
納品時にQCDをまとめて報告する際、
D：「本日、約束した納期ですので、ここに納品させていただきます」
C：「当初契約に沿って受け入れ頂きましたので、お支払いをお願いいたします」
Q：「当初のご要望からご要望が変わりましたがそれぞれお望み通りに動くと思います」
という話になるとしたら、品質について報告する内容が曖昧と感じると思います。しかしこのような例は数多く見てきました。

­ ー­ この文章で、QCDの話にも関わらず順番が違うのは、多くの場合で、Delivery, Cost, Qualityの順番で話を進めるケースが多いため、わざとその順番で記述しています。ここにも何か本質と現実の齟齬（そご）がありそうですね。

さらに納品後にうまく動かない場合に顧客が「まぁそういうこともあるかな」や「こんなもんで仕方ないかな」とスルーしてくれればラッキーですが、逆の立場で考えると、そんなに生易しい話にはならないと思えます。現実では、「言った、言わない」で決裂することが多いかと思います。脱線しますが、正直、契約にルーズなビジネスパートナーとは別の部分でもモメそうなのであまりお付き合いしたくないと感じます。

また、開発段階と運用段階のどちらでも聞く話として、「スケジュールがどうしようもなく押してきてしまったので、品質を多少犠牲にしてスケジュールを優先するので残業で対応してください」という、緊急事態宣言が発せられる場合があります。「品質を多少犠牲にして」というのは相当の緊急事態です。
この場合、延ばしたスケジュール(Delivery)が提示され、上司は残業分の予算(Cost)を掻き集めます。ここまでは当然ながらやらないと何もできません。しかしここで、犠牲にする品質(Quality)の具体的な値を指示しているかが問題です。
「レビュー回数を減らします」や「テスト項目の一部を省略します」という手段を聞きますが、この削減は、主にスケジュールの遅延を最小化するための工数効果でカウントされることがほとんどです。レビューやテストという品質に関係する工程での成果を、具体的にどのような品質レベルまで減らすか語られないケースが多く見られます。

上記のシステム開発でのQCD、顧客から見たQCDのいずれも、“Q”の評価が難しいと感じるかと思います。これは”Q”の評価を定量的に行うためにノウハウが全体的に不足していることによると考えています。

■品質を考える際の取り組み姿勢について■

品質向上のために改善ポイントを追求するスキルは「細かいな」と思うほどの注意力が源泉になります。
身近な例で注意力の例を挙げます。
天気予報や健康食品のCMなどで、「体調管理に気を付けてお過ごしください」と聞くことがあるのですが、日本語が不正確です。これでは本末転倒です。
体調を良いコンディションに維持する手段（ツール）として、体調を管理するのです。管理するだけでは意味がありません。

皆さんも普段行うと思いますが、いつもに比べて体調が悪いと思ったら、熱や血圧について定量的な測定をします。そしていつもの値と比較して評価をします。ポイントは、常に同じ手順で値を取得し、値がいくつなら異常と見なすかという基準を作っているから役に立つのです。体温計や血圧計を持っているだけで健康になる訳ではありませんし、値がいくつならば異常なのかを知らなければ測定する意味がありません。さらには、異常な場合にどのように治すか手段を知っておく、あるいは調べておかなければ、そもそも健康を管理する意味がありません。

品質管理は、この例のような注意力と論点で取り組みます。上記の健康管理を単純化して段階で表現すると、以下の手順の流れになります。

実務上はこのような単純な因果関係でストーリーを組み立てることはほぼ不可能です。とは言え、難しいからと言って無視することはできません。
かつての情報処理技術での品質管理では、ほとんどのコンピュータは人間が指定した通りに動くことを前提として人的要因による品質低下の対策を中心に行いました。つまり、商品品質は人が何を指定したか次第であるため、これをどのように定量的評価に結び付けるかが重要として因果関係を深く追及し改善しました。
現在の主流であるクラウドコンピューティングでは状況を全て把握することができない複雑系になっていることから、基本的に品質にある程度の誤差（揺らぎ）を考慮する必要が出てきます。また自分の業務範囲外に要因があり手を出せないケース（与件と言われます）も多く出てくると思います。
このため、自分たちで品質管理、つまり品質改善を行う際には、技術分野としての傾向分析の他に、業界やシステム分野でのシステムトレンドを考慮した予測を行い、自分たちがとって与件ではない業務の中での品質誤差を小さくする工夫も必要となっています。
品質を左右する要因の実データを収集し分析することから見いだし、問題点や評価方法を単純化し、一つ一つ積み上げて成果を出していかなければなりません。また可能な範囲で品質測定の仕組みを組み込んでサービスを提供する技術も必要です。
目標達成のための手段と手段ごとの評価基準を定め、細かく成果を拾い取って積み上げることが重要です。

第１回では品質を管理する必要性について簡単にまとめました。品質管理技術に詳しい方にとっては、曖昧に見えたり正確性に欠けたり感じるかも知れませんが、復習としてお読みいただけると幸いです。今回は触り程度の連載ですので、これを機会にSQuBOKのほか、世に出ている素晴らしい書籍やサイトを勉強することで、正しい知識を身に着けていただきたいと思います。
第２回では、品質のどのような要素を、どのような観点で管理すれば役立つのかという点について、品質工学での考え方を説明します。