お役立ち資料
Introduction
ソフトウェアの品質管理では、「メトリクス」というわかりやすい数値データで品質を見える化します。
プロジェクトの数値データと、標準的な数値データを比較することによって、品質の状態を客観的に、かつ定量的に判断し、そのソフトウェアに要求される品質に到達するよう、本番稼働に向けて管理(モニタリング＆コントロール)していきます。
本コラムでは、メトリクスとは何か、どのようにデータを収集、管理するのかなどについて解説します。
目次
メトリクスとは？
測定基準、尺度、計量、距離などを意味する名詞“metric”の複数形です。
特にソフトウェアの品質を数値化して定量的に評価することや、その際の評価手法・基準などの体系
のことを「ソフトウェアメトリクス」(software metrics)といいます。
代表的な測定量を例にあげると
・規模
・バグ件数
・バグ密度
があります。
この測定量に対し、測定方法をそれぞれ
・規模は、コメント行と空行を含まないSLOC(Source Lines Of Code=ソースコード行数)とする
・バグ件数は、同一原因のバグを1件とカウントする
・バグ密度は、バグ件数÷規模とする
などと定義します。
このように測定方法や測定量を定義しておくことで、過去のプロジェクトや組織を超えたプロジェクトデータとの比較が可能になります。
過去のプロジェクトデータがまだなく、これからメトリクス管理をはじめる方は、IPA(独立行政法人 情報処理推進機構)などの公開データとの比較をおすすめします。
IPAの公開データによると、新規開発のバグ密度は、平均0.109件／KSLOC、中央値0.010件／KSLOCです。(KSLOCはSLOC の1,000倍)
一度、比較してみてください。
比較した結果、品質が低ければ、他のメトリクスも併用して原因を分析します。
その後、分析結果に基づき対策を立てて、対策の効果もまたメトリクスで測定し、分析することで品質を高めていきます。
(出典：IPA「ソフトウェア開発分析データ集2022」)
メトリクス管理の仕方・手法
メトリクスは、Plan(計画)、Do(実行)、Check(測定・評価)、Action(対策・改善)というPDCAサイクルで管理します。
PDCAサイクルはデミング博士(1990～1993)によって提唱され、日本の製造業において、高い品質を生み出す管理手法として根づきました。
ソフトウェアの品質管理でも、PDCAサイクルは有効です。以下、PDCAの順に解説します。
Plan(計画)
メトリクスの目標値を設定します。
目標値は、すでに標準の数値がある組織でしたら、標準を使用していただければ問題ありませんが、これから標準をつくっていく段階の組織では、IPAの「ソフトウェア開発分析データ集」などの公開データを参考に、目標値を設定するようにしてください。
「ソフトウェア開発分析データ集」には「金融保険業編」「情報通信業編」「製造業編」もあります。
なるべく業種や規模などの条件が近いデータから目標値を設定してください。
Do(実行)
メトリクスを収集しながらプロジェクトを進めます。
メトリクスを収集する作業は、少なからずプロジェクトメンバーの負担になるため、必要最小限にとどめ、バグ・トラッキング・システムの活用などで負担軽減をはかります。
また、メトリクス収集の目的や効果を説明し、理解を得ることも大切です。
Check(測定・評価)
計画で設定したメトリクスの目標値と実行で収集したデータを比較します。
例えば、基本設計フェーズのレビュー指摘件数が目標値より少ない場合、本当に品質がよい可能性とレビュー不足の可能性が考えられるため、レビュー工数や、レビューアの経験年数などから状況を見極めます。もし、レビュー工数不足が原因の場合は、なぜ不足したのかも追求します。
Action(対策・改善)
対策を実行します。
例えば、分析の結果、レビュー工数不足と評価された場合には、追加レビューを実施します。
また、レビュー工数の不足が進捗の遅れによるものだった場合、レビュー工数を確保するために納期調整や、メンバーの増員などの対策をとります。
さらに、将来のプロジェクトのためにレビュー工数密度の指標を教訓に残します。
品質評価におけるメトリクス
規模
ドキュメントはA4ページ換算のページ数、プログラムはSLOC(ソースコード行数)などで、WBSの単位(作業別、機能別、チーム別、個人別)ごとに算出します。
SLOCは、開発エディタがEclipseならStepCounterというプラグイン、VisualStudioならコードメトリックで把握することができます。他の開発エディタでも検索すると、SLOCを計測するツールは見つかります。
コメント行や空行は、多くの公開データや会社で除外しているため、計測ツールの設定で除外してください。
工数
工数はレビューやテストにかけた時間です。
WBSの単位(作業別、機能別、チーム別、個人別)ごとに工数を記録します。
レビュー指摘件数
レビュー指摘密度などの算出に使用します。
テストケース数
テスト密度の算出に使用します。
バグ件数
同一原因のバグは1件としてカウントします。これは多くの公開データや会社で採用されているルールのため、比較するためには合わせておく必要があります。
バグ密度の算出に使用します。
メトリクスは、PDCAサイクルのCheck(測定・評価)の段階で分析に使用したいと考えても、すぐにデータが集まらないことは想像できると思います。
Plan(計画)のときに、分析に使用するメトリクスの検討を充分にしておきましょう。
他にも、分析を見据えた収集データのヒントとして、5W1Hを使った考え方をご紹介します。
What
バグ自体の種類(仕様ミス、コーディングミス、テストデータミス、テスト手順ミスなど)、重要度(深刻度)
Where
バグのあった機能
When
バグをつくった工程、バグを見逃した工程
Who
開発の担当者／チーム、テストの担当者／チーム
How
バグをつくりこんだ経緯、バグを見逃した経緯
Why
バグの原因の種類、バグ未検出原因の種類(理解不足、不注意、環境設定誤りなど)
5W1Hによる分析データは、バグの原因を深掘りする際に役立ちます。
基本的なメトリクスの分析とともに、ぜひ取り入れてみてください。
メトリクスを活用した不具合分析
まずは基本的なメトリクスで分析します。
プロジェクトの進捗に伴い、状況は変化していきます。分析は、定期的に行なってください。
生産性
規模÷工数で算出します。
WBSの単位(作業別、機能別、チーム別、個人別)ごとに算出し、目標値と比較することで、問題が起きている場所に気づくことができます。
レビュー指摘密度
レビュー指摘件数÷規模で算出します。
WBSの単位(作業別、機能別、チーム別、個人別)ごとに算出し、目標値と比較することで、レビュー対象ドキュメントの品質を把握することができます。
レビュー指摘密度が高いときは、誤字脱字レベルの指摘が多い場合と、技術的・業務的に深い指摘が多い場合とでは対策が変わるため、指摘内容に注目して品質を見極めましょう。
レビュー指摘密度が低いときは、本当に品質がよい場合と、レビュー工数やレビュー観点の不足により残存バグがある場合があります。
品質が低いと判断した場合は、同じ機能、同じチームや作成者の品質も確認し、対策を考えます。
テスト密度
テストケース数÷規模で算出します。
WBSの単位(作業別、機能別、チーム別、個人別)ごとに算出し、目標値と比較することで、テスト不足を防ぎます。
IPAの公開データによると、総合テストのテスト密度の中央値は、金融・保険業で13.8件／KSLOC、情報通信業で8.8件／KSLOC、製造業で6.6件／KSLOCと業界によって変わります。
同じプロジェクトでも重要度、影響度から機能によってテスト密度を変える場合があります。
バグ密度
バグ件数÷規模で算出します。
WBSの単位(作業別、機能別、チーム別、個人別)ごとに算出し、標値と比較することで、対象プログラムの品質を把握することができます。
品質が低い場合は、同じ機能、同じチームや作成者の品質も確認し、対策を考えます。
つづいて5W1Hで、どのバグが(What)、どの機能に(Where)、いつ(When)、誰によって(Who)、どのようにつくり込まれ(How)、なぜ見逃されたのか(Why)を分析します。
メトリクスとともに5W1Hのデータも使用すると、深掘りが可能になり、的を射た対策を立てることができます。
ただし、あくまで「データ上は」であることを意識するようにしてください。
例えば、データ分析の結果、不注意によるバグが特定のチームに多かった場合、関係者と会話をしたり、作業場所を見に行ったりすると、実はプロジェクトルームのエアコンが故障していて暑い中で集中できず、エアコン修理後はチーム全体のバグが激減したなどということもありますので、コミュニケーションや現物確認も大事にしてください。
対策を立てた後は、効果も測定してください。
また、念のためになりますが、個人攻撃にはならないよう配慮してください。
測定されるものは改善される
1982年、ソフトウェア工学の祖の1人トム・デマルコが「測定できないものは制御できない」という一文からはじまる名著を書きました。
それから40年程たったいまでは、品質管理をはじめとするさまざまな管理に「測定＝メトリクス」は欠かせないものになりました。
2015年には、国連のレポートにも「測定されるものは改善される」と記載され、SDGsは各国の統計専門家を中心としたデータ収集と分析をもとにPDCAサイクルで施策が進められています。
SDGsが目指す「誰一人とり残さない(leave no one behind)」は、すべてのメトリクスの目標を達成することと同じ意味をもちます。
まとめ
メトリクスの歴史を紐解くと、初期に「規模、工数、バグ件数」で管理していたものが、ある時期からメトリクスの種類が膨大になり、管理が困難になった時代を経て、再び、「規模、工数、バグ件数」の管理に戻ったという経緯があります。
メトリクスを厳選してプロジェクトメンバーの負担を最小限に、また、バグ・トラッキング・システムの採用により効率よく、分析力を活かして効果的なメトリクス管理をしていただくことが理想です。
本コラムが、その理想を実現する一助になれば幸いです。
この記事を書いた人
SHIFT Group 技術ブログ_連載記事
- 連載①：SDGs初心者がSDGs検定を受けるまで https://note.com/shift_tech/n/n0d2f84128472
- 連載②：SDGs初心者がSDGs検定に受かるまで https://note.com/shift_tech/n/na08c0fcd4856
- 連載③：SDGs講座が出来るまで(１) https://note.com/shift_tech/n/n6f4e4b3d1aa4
など多数
関連コラム
-
- ソフトウェアテスト・品質保証
QAエンジニアとは？テストエンジニアとの違いや業務、必要なスキル・資格を解説
2024.04.10
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストを効率化するには？テスト設計・テスト実行それぞれの方法を解説
2024.02.29
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説
2024.02.22
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説
2024.02.05
詳しく見る
-
- ソフトウェアテスト・品質保証
負荷テストとは？目的や種類ごとの観点、実施の流れについて解説
2024.01.23
詳しく見る
-
- ソフトウェアテスト・品質保証
品質保証（QA）とは？品質管理との違いや具体的な業務内容について解説
2024.01.22
詳しく見る
-
- ソフトウェアテスト・品質保証
SREとは？意味やDevOpsとの違い、実現できることを解説
2024.01.16
詳しく見る
-
- ソフトウェアテスト・品質保証
PMOとは？PMとの違いや職種別の役割・業務内容について解説します
2024.01.12
詳しく見る
-
- ソフトウェアテスト・品質保証
DevOpsとは？アジャイル開発との違い、導入するメリット・デメリットについて解説
2024.01.12
詳しく見る
-
- ソフトウェアテスト・品質保証
verificationとvalidationの違いとは？ソフトウェア開発における意味・定義を解説
2024.01.12
詳しく見る
