テクニカル

メトリクスとはなんだろう? Vol.3

システム開発を進めると必ず必要になるのはメトリクスによる状況把握です。

3回に渡って、メトリクスとは
①何のためにとるのか
②どのようなものがあるのか
③どうやって評価するのか
などを考えていきます。

これまで、第一回第二回と、以下の内容についてお知らせしてきました。

第一回:メトリクスは何のためにとるのか
 ・各個人の作業進捗や品質を確認する
 ・作業遅延抑止やリスク把握の材料
 ・上流工程〜下流工程への品質推移把握
 ・品質状況や作業近況の報告
 ・他のシステムの実績との比較
 ・トラブル発生時の点検の材料
 そして、メトリクスを正しく採取するためには、メンバへの十分な動機づけが重要。

第二回:メトリクスにはどのようなものがあるのか
 ・採取可能なメトリクスの主なもの
  開発工数
  開発規模
  レビュー時間
  レビューでの問題検出数
  テスト項目数
  テストでの問題検出数
 ・これらを規模あたりで計算したり、人別で整理し、意味のある判断を行うこと
  テストの密度(開発規模、テスト項目数)
  問題の検出率(開発規模、問題検出数)

(例)上記の組み合わせにより判断可能な事項
  →テストの内容が適切で無い(観点不足など)可能性あり

さて、最終回は③どうやって評価するのか、です。


③どうやって評価するのか

前回、メトリクスの組み合わせによる意味のある判断の事例をご紹介しましたが、他にも評価の事例は数多くあります。

例えば、以下のメトリクスで何が判断可能となるでしょうか?

「レビュー時間」「開発規模」

これは明確ですね。レビュー密度です。

では、次はどうでしょうか?

「レビュー時間」「問題検出数」

答えはレビュー効率です。
特定の機能のレビュー効率を見るのではなく他の機能のレビュー効率と比較することでいろいろな想定に利用可能です。
例えば、他の機能と比べて値が極端に高いのであれば、以下のような可能性があります。

A)レビュー対象の品質が他と比べて悪い
B)レビューアの検出能力が突出して高い
C)機能が画面系機能であり、表示上の位置が微妙にずれているなどの詳細な問題が多くなった

これら可能性のどれがあてはまるのかをきちんと確認する事が正しい判断に繋がります。
上記の場合であれば、以下のメトリクスも合わせて参照すると良いでしょう。

A)レビュー対象機能を作成した人に着眼し、同じ人が作成した他の機能の品質状況を確認する
 もしくは、レビュー対象機能の作成難易度を評価する
B)該当レビューアがレビューした他の機能の実績を確認する
C)他の機能と比較してどのような特徴がある機能なのかを確認する
 そして、同類の機能の実績と比較してみる

上記の確認を行うことで、問題の根っこにある原因が明確になり、効果的な対処ができるようになるでしょう。

さて、三回にわたってメトリクスについて考えてきました。効果的に活用することで、品質向上に大きく役立つことがわかると思います。
メトリクスは取ることが目的ではなく、活用することが目的であるということを再確認いただければと思います。

Tumisu, please consider ☕ Thank you! 🤗によるPixabayからの画像