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

運用ノウハウを学ぶ

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

システム運用における品質管理について 第2回 品質を考えるポイント
2021年5月12日 10:00

第1回では品質を管理する必要性について説明しました。第2回では、IT品質について取り組む際に、何をどうしたら品質が評価できるかということについて品質工学での用語を用いながら説明します。

 

■品質について語る際の品質とは何を意味するか■

 工程品質は主に生産(開発)工程を軸にした品質評価で、満足度品質は顧客(利用者)の満足度を軸にした品質評価です。この満足度品質の表現方法を深化させた技法が、アトリビュートマトリクスです。
アトリビュートマトリクスは3つの要素と3つの特性の組み合わせで、利用者の感覚から品質レベルを定義しています。これは企画段階で「どこを狙うか」が無いと意味を持ちません。
品質の評価軸を考えることは、製品や業務の品質目標を定める際に非常に重要となります。

工程品質とは何か

企画品質

企画品質とは、企画段階で決まる品質で、ユーザーの要求している品質を定義し、製品コンセプトに盛り込む品質のことです。

設計品質

設計品質(狙いの品質)は設計工程で規定された品質で、運用上のバランスを加味して開発者が決めたものが品質目標です。

開発品質

開発品質(出来栄えの品質)は実際に開発されたものの品質で、適合品質ともいわれます。

設計品質と違い、スキルレベル、開発環境などの影響で品質が変動します。この品質を維持する活動が開発の標準化となります。

使用品質

使用品質とは、ユーザーに製品が提供され、実際に使用したときの品質で、一般的には開発品質と使用品質は一致しません。

フィールドでの問題や意見を集約し、上流工程にフィードバックする標準手法の確立が重要です。

 
満足度品質とは何か

当たり前品質

当たり前品質とは、あって当たり前と受け止められている特性です。

あって当たり前と思っているので、満たされている時よりも、欠けている時に気が付きます

当たり前品質は“不満足がない”という状態の品質で、全て揃っていることを当然と思い、少しでも欠けていると欠陥と考えられてしまう品質です。

この品質は後向き品質(backward quality)と言います。

一元的品質

一元的品質とは、私たちは自分のニーズがうまく満たされないとがっかりとし、うまく満たされれば、満たされるほど満足感を得る特性です。

例えば、洋服の場合、価格や着心地などがこれに該当します。

ニーズが満たされていない時は“不満足である”という当たり前品質の性質を強く持つようになります。

逆に、ニーズがうまく満たされた時は、“満足である”という魅力的品質の性質を強く持ちます。

魅力的品質

魅力的品質とは、私たちをよい意味で驚かせる。私たちもやってもらえるとは思っていなかったニーズ、誰もが期待していなかったニーズを満たすことです。

無くても利用者が意識していないため負の効果はありませんが、あれば正の効果を持ちます。

魅力的品質は強化すればするほど、その効果は比例的以上に大きくなると考えられています。

顧客満足度はある意味では、魅力的品質そのものです。

この品質は前向き品質(forward quality)と言います。

 

アトリビュートマトリクスとは何か

 

基本的要素

差別化的要素

決定的要素

肯定的特性

あって当たり前

他とはちょっと違う

非常に嬉しい

中立的特性

だから何なの?

タダなら欲しい

何とも思わない

否定的特性

我慢できる

文句を言いたい

許せない/訴える

品質を保証する活動は、生産活動のどこにフォーカスを当てているのかを明確にして目標を立てないと、的外れで効果の上がらない活動となり、結果として頑張っているにも関わらず品質が改善しない現象が起こります。最悪、「たぶんこんなものだろう」という目分量で裏付けも意味もない成果を計上するのみになります。これでは時間の無駄であり、かつ仕事で利益を出そうとする動きに逆行し、やればやるほど損失となりますので、目標設定は非常に重要です。

 

■品質保証活動の種類はどう分類できるか■

大きく分けて品質改善策は、発見した問題が商品としてリリースされる前に対処する流出対策と、問題が発生する前に原因となる作業パターンを改善して発生を抑える源流対策の2つに分けられます。

品質保証活動の種類

種類

概要

活動単位(例)

手法(例)

 

流出対策

工程の最後に検査を設けて、不具合を次工程へ流出させなくする方法

工程

QAレビュー、問題管理

プロジェクト

テスト工程、パイロット運用

プロジェクト

リリース管理、変更管理

源流対策

将来の危険性を予知し、問題が発生する前に問題を解決する方法

プロジェクト

問題管理

変更管理

構成管理など

 
流出対策と源流対策について、もう少し深堀りします。
ここで用語に注意していただきたいのは、「問題の発生」「問題の発見」は違うということです。当たり前と思われるかもしれませんが、筆者が関わったシステム開発の経験では、問題管理で発見工程は記録され統計分析されるものの、発生工程との関係を分析するケースは少なく、記入欄があっても発生発見が混乱して記載されるため分析データに使えないことがありました。
正確に使い分けができれば、発見できた問題について、「もともと発生した(作り込んだ)工程はどこで、実際に発見した工程はどこで、そのタイミング差のロスがどの程度あって、プロジェクトとして発生する前の作業の進め方に問題や工夫の余地はないだろうか?」、「発見精度の向上のヒントはないだろうか?」という源流対策、流出対策両方の基本データに使えるようになります。
流出対策は過去の経験や実績値から潜在する品質不良を予測し、危険性の高い部分を重点的にチェックし正しく作られているか判断し、問題を発見すれば製造工程に戻します。
源流対策は問題発生の原因を追及し問題が発生するフローを断ち切ることで、問題そのものを無くします。
以下にそれぞれの対策のメリットとデメリットを列挙します。
【流出対策のメリット・デメリット】
  • 〇発見できた不良の流出は止められます
  • 〇統計的に潜在問題を予想し易く、品質評価が比較的簡単に行えます
  • ×過去の経験を正確に分析しないと的外になります
  • ×レビューやテストを厳しくすると不良検出率は上がりますが元々の不良が減るわけではありません
  • ×カバレージ100%は不可能であるため、ある程度の不良が流出することは避けられません
  • ×過去の経験、実績データがないと実施できません
  • ×発見した不良の修正にコストがかかります
  • ×不良個所の修正にかけたコストは商品価値をマイナスから通常に戻すコストであり商品価値を生み出す訳ではありません

 

【源流対策のメリット・デメリット】
  • 〇真の原因を潰すため不良率が下がり後工程の無駄時間を削減できます
  • 〇対策を取りこぼしそうな与件(変えられない条件)を推測し機能としてのエラートラップの実装などで被害拡大を抑える仕組みを作りこむことができます
  • ×工程を遡って分析し対策を施すためのコスト(工数、時間)が大きくなります
  • ×対策のためにある程度の経験や高い技術力を必要とするため即効性が期待できません。

 

■品質管理のコストパフォーマンスを考える■

メリット・デメリットを比較すると、必要とするコストがフォーカスポイントになることが分かると思います。品質管理、品質向上にかける工数と効果は、一般的にゴンぺルツ曲線で表されると言われます。

ゴンペルツ曲線は、あるレベルに達すると工数を費やしても効果が上がらないことを表しています。つまり、100%の品質でサービスや商品は作れないということです。但し、上手く管理すれば近づけることはできます。品質管理に失敗しているとカーブが低迷します。
予想できる範囲で上記ゴンペルツ曲線の青線に近い活動を行った上で、例えばプログラミングでは予測していない値の場合にエラールーチンに制御を渡すなどのフェイルセーフを組み込んだり、機械的な製品であれば人に迷惑をかけないように動きを止めるなどの工夫が欠かせません。赤線に近い状況であれば異常対応処理からも漏れ、利用者に迷惑をかけたり、財産や命に関わりかねません。
ここでの課題は、「予想していない値をどうやって予想するのか」という点が技術力になります。禅問答のようですが、これはこれで技術分野の一つになっています。ということは、解決方法あるいは解釈手法があるということです。本コラムではこれ以上の深入りはしませんが、品質管理技術において大きなテーマであり、様々な考え方や手法が提起されています。

 

システム開発での品質では、設計工程までと製造工程以降で品質の考え方が変わるといいます。つまり、設計工程までは顧客のニーズを分析し、雲を掴むような話を論理的なシステムに置き換えることから創造的工程という点で魅力的品質を管理すると考え、製造工程以降は仕様を実現するという点で当たり前品質を管理すると考えるようです。
システムのライフサイクル全体で品質管理の考え方が体系化されていますが、現実にはなかなか運用側から見て実務に有用な情報が見えてこないケースが多いと思われます。
上記の工程品質での使用品質については、設計時点では非機能要件の中で設計することが多いと思います。

 

■非機能要件グレードとの関係■

IPAが発行する非機能要件グレードでの運用業務の定義では、機能性、信頼性、使用性(操作性や習得の容易さなど)、効率性、保守性、移植性、障害抑制性、効果性(ROIなど)、運用性、技術要件(システム構成や開発手法など)の10種類に分類して設計することを定めています。この非機能要件は慣れていなければ解釈が難しいと言われます。ありがちなケースでは、直接システムに関する(つまり顧客から指定された明確な)運用条件はきっちり決まりドキュメント化されているのに対し、サーバーマシンやネットワークのようなインフラ部分に対してはアバウトな目標値のみが設定され、その測定方法や測定条件、危険性(リスク)、優先順位が示されてないというようなものがあります。開発技術のスキル以外にも、開発側に現実の運用スタイルが十分に伝わっていない、あるいはプラットフォームが変わってしまっていて設計した運用手順が役に立たないというケースもあります。当初からSaaS,PaaSへの実装として設計され、インフラが読めないことも多々あります。
逆の立場で、SaaS,PaaSをサービスしている場合、アプリケーションのパフォーマンス要求が曖昧であるとニーズの変化への追従が遅れ、サービスの低下の原因となってしまう場合があります。
この結果、提供するシステム品質の保証範囲が不明確になり、何か起きた場合の責任問題のみならず、障害分析や対応にてボールの投げ合いになり利用者にとっては甚だ迷惑に感じることが発生することがあります。
このようなことが発生した際には、「誰のために動かしているシステムなのか?」を原点に、決め事は熱いうちに決めておくことをお勧めします。

 

第2回では、品質の評価技術について品質工学の用語を用いて説明しました。統計学と関わりが深い分野ですので取っ付きにくい表現が多いかとは思いますが、何となく用語を知っておく程度で捉えていただければ良いと思います。第3回では、システム運用という業務範囲にターゲットを絞り込んだ場合の品質について説明します。

 

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

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

コメントを書く

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

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

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

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

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

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

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