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

目次

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

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

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

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

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

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

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

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

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

流出対策と源流対策について、もう少し深堀りします。
ここで用語に注意していただきたいのは、「問題の発生」と「問題の発見」は違うということです。当たり前と思われるかもしれませんが、筆者が関わったシステム開発の経験では、問題管理で発見工程は記録され統計分析されるものの、発生工程との関係を分析するケースは少なく、記入欄があっても発生と発見が混乱して記載されるため分析データに使えないことがありました。
正確に使い分けができれば、発見できた問題について、「もともと発生した（作り込んだ）工程はどこで、実際に発見した工程はどこで、そのタイミング差のロスがどの程度あって、プロジェクトとして発生する前の作業の進め方に問題や工夫の余地はないだろうか？」、「発見精度の向上のヒントはないだろうか？」という源流対策、流出対策両方の基本データに使えるようになります。
流出対策は過去の経験や実績値から潜在する品質不良を予測し、危険性の高い部分を重点的にチェックし正しく作られているか判断し、問題を発見すれば製造工程に戻します。
源流対策は問題発生の原因を追及し問題が発生するフローを断ち切ることで、問題そのものを無くします。
以下にそれぞれの対策のメリットとデメリットを列挙します。

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

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

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

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

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

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

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