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

運用ノウハウを学ぶ

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

システム運用における品質管理について 第1回 よく聞くIT分野での品質はどのようなものだったか
2021年4月7日 10:00

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

 

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

 

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

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

· お客様の要求する品質を十分に把握し、
· これに適合する品質の製品を経済的に作り出して、適時に供給し、
· お客様の満足を得るために、企業の全部門が品質の改善と維持を効率的に行う活動

  と定義されます。

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

 

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

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

· お客様にとってのQ.C.D.を満足させるためのメジャメントであること
· 自社の収益向上のためのメジャメントであること
· 個人、会社のスキルアップのメジャメントであること

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

顧客や社会の要求を満たす製品やサービスを作り提供する際に必要となる、業務および商品の目標設定と目標実現のための活動

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

 

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

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

· 自分たちが仕事をする際の業務プロセスが、どのような流れか理解する
· 自分たちのアウトプットが顧客や市場の期待や要望を実現できるかどうか評価を行う
· アウトプットが要求仕様を実現しており指定の範囲内で正しく動作するか保証する
· アウトプットを作り出す仕事の流れがスムーズであったか評価する
· 悪かったところの改善の他に、上手くできた仕事のポイントを組織横断的に推進する
· プロセス改善の目標、基準は、顧客満足度に置く

 

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

標準・体系

ISO9000シリーズ
SQuBOK(JSTQBという資格試験があります)

ITIL(FoundationとMasterの資格があります)

COBIT、CMMI、シックスシグマ など

活動プロセス PDCA、OODA
カイゼン、ヒヤリハット、KY(危険予知) など
活動の評価ポイント

QCD、KPT

S.M.A.R.T. など

 

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

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

 

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

 

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

 

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

 

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

 

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

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

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

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

· 目標の設定(健康であること)
· 目標達成や維持を図る手段の設定(体温や血圧を測る)
· その手段での正常値の定義(値が36.5度や75/125など)
· 有効な測定周期(朝イチ、食後や入浴直後以外など)
· 誤差の許容(平常範囲外の値なら測りなおし、同じなら異常とみなすなど)
· 異常値を示した場合の行動(親や上司に連絡しお医者さんにかかるなど)
· 決めた周期、タイミングに従って測定を実施(日常生活を送る)
· 測定値を、定めた値で評価(問題が発生していないか確認)
· 評価結果により、定めたルールにて行動を実施(問題なしであれば周期的評価を継続)

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

 

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

 

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

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

コメントを書く

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

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

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

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

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

皆様からのご要望にお応えして、第14回システム管理者の会 感謝の日イベントでご講演いただきましたauカブコム証券株式会社 道場 大様の講演動画を公開いたします。 見逃してしまった方や、もう一度観たいといった方はこちらからご覧ください。

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