LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@pbjpkas

第一世代のQAエンジニア(3)品質コスト

Posted at

1. はじめに

「第一世代のQAエンジニア(2)組織構造・業務範囲・権限・評価」で紹介したようにQA部門の評価尺度の一つに「出荷後のバグ・不具合件数」「出荷後の事故費用、回収不能コスト」がありますが、これは一般的に出荷後の不具合修正は桁違いにコストがかかるためです。今回はソフトウェアの品質コストを取り上げたいと思います。

2. ソフトウェアの品質コスト

2.1 不具合修正のコスト

不具合修正のコストは例えば「ソフトウェア開発201の鉄則」原則41『今すぐ要求仕様書の誤りを直せ』で解説されている要求仕様誤りの修正コストを「1」としたものが知られていますが、もとをたどると「B.W.Boehm, "Software Engineering", IEEE Transactions on Computers, Dec. 1976, pp. 1226-1241, vol. 25」です。

the-price-of-procrastination2.png
（出典：B.W.Boehm, "Software Engineering", IEEE Transactions on Computers, Dec. 1976, pp. 1226-1241, vol. 25 Fig.3 Software validation: the price of procrastination.に目分量で値を追記）

実装フェーズにおける不具合の修正コストを「1」とすると運用フェーズで見つかった不具合の修正コストは14倍と、文字通り桁違い（一桁大きい）な値となっています。

なお、これは1970年代のウォーターフォール開発が前提のようです。

2.2プロセスの成熟度とソフトウェア品質コスト

品質コストを「予防コスト(Pコスト、Prevention Cost)」「評価コスト(Aコスト、Appraisal Cost)」「失敗コスト(Fコスト、Failure Cost)」で分類する方法をPAF法と呼びます。失敗コストはさらに「外部失敗コスト」「内部失敗コスト」に細分化されます。

Krasner氏によるソフトウェア品質コストとCMMレベルの関連図を以下に引用します。

relating-cosq-and-cmm-level.png
（出典：Krasner, H., "Using The Cost of Quality Approach for Software", Cost of SW Quality, May 1999に品質コストの種別を日本語で追記）

これは図の左下に「Krasner, 1990, 1998; Knox, 1993; Hailey et al, 1995」とあるように三者の研究成果をKrasner氏が集約したもののようです。

ここでKnox氏はCMMレベル1～レベル5の間で変化する品質コストの傾向についての理論的な見解（モデル）を考案された方で次の仮定を前提としています。

  • CMMレベル1の品質コストを総開発コストの60%と仮定3
  • CMMレベル5に達すると総品質コストは2/3減少すると仮定4

Knox氏によるプロセスの成熟度とコスト構造の解説を抜粋し、DeepL翻訳して以下に引用します。

  • CMMレベル1
    このレベルでは、ソフトウェア品質の主なコストは、手戻りとメンテナンスによるものである。テストは散発的であるため、評価コストは最小限に抑えられ、ほとんどの欠陥は顧客が経験することになり、その結果、高額な保証コストが発生し、市場シェアを失うことになる。欠陥防止に関連するコストはゼロに近い。
  • CMMレベル2
    このレベルでは、主に、規定されたテスト標準への準拠を監視する品質保証組織が形成されるため、評価コストと内部障害コストが増加する。レベル2では、組織はテスト活動をより厳格に適用するため、より多くの欠陥が発見され、社内で手直しされる。
  • CMMレベル3
    品質達成は、顧客の問題に対する状況調査や、仕様および設計文書の正式な検査など、予防活動への投資を重視している。このような未然防止プロセスは、顧客要求をより正確に理解し、顧客要求への適合性を高めることを目的としている。予防に投資することで、外部故障コストが急減し、失われた市場シェアを取り戻すことができる。
  • CMMレベル4・CMMレベル5
    品質の支配的なコストは、主にメトリクス主導の継続的改善とプロセス管理のコスト要素による予防的要素によるものである。（略）レベル5では、評価と失敗のコストはシックスシグマ組織に期待されるレベルまで低下しています。
    （出典：Stephen T. Knox, "Modeling the Cost of Software Quality ", Digital Technical Journal Vol.5 No.4, Fall 19935をDeepL翻訳して引用）

なお、Krasner氏によるKnox氏の研究成果は次のような認識ですが、成熟度が上がるにつれて失敗が減って評価から予防に軸足が移り総品質コストが下がるというのは納得感があると思います。

ノックス氏のモデルは、製造ソフトウェア組織のTCoSQの公正な予測かもしれないが、実際の適合コストはモデルの予測よりもはるかに高く、不適合コストははるかに低いようである。
（出典：Krasner, H., "Using the Cost of Quality Approach for Software", CROSSTALK The Journal of Defense Software Engineering, Nov. 1998をDeepL翻訳して引用）

3. QAエンジニアに求められること

2.1節で示したように外部失敗コストは文字通り桁違いにコストがかかるため、まずメスを入れるのは外部失敗コストの止血です。

ただ、失敗コストの削減には欠陥の流出防止だけでなく混入防止も欠かせないことや2.2節で示したようにプロセスの成熟度に応じてソフトウェア品質コストの構造が変わってくることから、開発チームの成長を促す取り組みや成熟度に合わせた対応が求められます。例えばこちらは成熟度と品質施策のアンマッチに対してQAは予防（教育活動）を行ってほしいと開発サイドから要望が出ている例です。

QAチームいらないかな
そして、QAはテストだけでなく
探索的テスト観点を
コーチングする技術を学ぼう
（出典：アジャイル開発 QAチーム不要論、p.20）

開発チームの成長を促す取り組みの一例として静的解析ツールの導入・運用が挙げられます。JSTQB Foundation Level シラバス 日本語版 Version 2011.J026では次のように効果が紹介されています。

静的解析の効果は以下のとおり。

  • テスト実施前の早い段階に欠陥を摘出する。
  • 複雑度の計測などのメトリクスを測定することにより、欠陥が潜む可能性のあるコードや設計を早期に警告する。
  • 動的テストでは簡単に見つからない欠陥を摘出する。
  • リンクのように、ソフトウェアモデル間の依存性、非依存性を見つける。
  • コードや設計の保守性を改善する。
  • 開発中に学習することで欠陥を予防する。
    （出典：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02、p.39、強調筆者）

こちらはCEDEC 2012のスポンサーセッション「「プログラマ育成＋静的解析」という幸せな選択」のレポート記事ですが静的解析ツールがエンジニアの教育に役立っているとの話です。

また、エンジニアの教育という意味でも「Coverity Static Analysis」は大きな役割を果たしていると言います。「新入社員として入ってくるエンジニアでも学生時代にプログラムの経験があるという方は少なくありません。しかしデバッグやバグに対する意識はそう高くないのが殆どです。なかなかそれを教える機会もありません。今までは実際にプロジェクトに投入されてから、バグを量産して先輩に怒られるというのが一般的でした」。しかしツールを導入することで、手元でバグを教えてくれるため「どんな時にバグが発生するのか経験を積むことができ、バグに対する認識や意識の底上げになる」とのこと。
（出典：【CEDEC 2012】静的解析ツールがバグを潰し、新人を育てる）

静的解析ツールの導入や保守でやることを挙げるとざっとこんな感じです。

  • 静的解析ツールを選定する
  • 静的解析ツールをインストールする
  • 静的解析ツールで検査を実施する
    • 検査を自動化する
  • 静的解析ツールの指摘が処置されていることを確認する
    • 定期的にメトリクスを集計する
    • 解析結果を確認するよう開発者に依頼し、実施してもらう
    • 修正が滞っているようなら開発者へ修正を促す
  • 静的解析ツールを設計プロセスへ組み込む
  • 静的解析ツールの勉強会を適宜開催する
  • 必要に応じて予算を組んで有償の静的解析ツールを導入する
    • ツールベンダと打ち合せ
    • 見積
    • 予算化（稟議書を書いて承認してもらう）
    • 発注、検収
    • ツールのインストール、バージョンアップ
    • 開発者からの問い合わせ対応（ツールベンダのサポート窓口とやり取りする）

静的解析ツールの導入や保守は誰がやっても構わないわけですがそれなりにやることがあるため、静的解析ツールの整備をQAが巻き取って開発者に開発に専念してもらうのがよいと思います。

4. おわりに

第一世代のQAエンジニアで次のように書きました：

  • 品質が良いとは、顧客満足度が高く、よく売れて高値で売れること。
  • 品質が悪いとは、余分なコストがかかること。

品質コストはどちらかといえば後者（守りの品質7）に効いてくる話題ですが予防コストや評価コストを投下して開発組織のスキルアップを図りながら失敗コスト（無駄な支出）を減らすのもQAエンジニアの役割です。

第一世代のQAエンジニアは最初はあれもこれもはできない（ソフトウェア開発のよろず相談が日々寄せられて手が回らない）ため効果が期待される品質活動に優先的に取り組んでスケールする仕組みを整えたいですね。

付録. ソフトウェア品質コストの資料

  1. 参考：TRW Inc. ↩

  2. 参考：ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く ↩

  3. Knox氏が主に文献から得た内部失敗コストのデータとKnox氏の所属先であるDEC(Digital Equipment Company)が追跡した外部失敗コストに基づく ↩

  4. F. Gryna氏が引用した参考となるケーススタディの工業データ（F. Gryna, “Quality Costs,” Juran’s Quality Control Handbook, 4th ed. (New York:McGraw-Hill, 1988).）に基づく ↩

  5. 図表付きのDigital Technical Journalもググると見つかるものの一次配布元ではなさそうなため、hp社の資料へリンクを貼っています。 ↩

  6. 2018年度版のJSTQB FLシラバスやAdvanced Levelテクニカルテストアナリストシラバスには静的解析の効果の記述がないため、2011年度版のJSTQB FLシラバスを参照しています。 ↩

  7. 参考：攻めの品質、守りの品質 ↩

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?