ソフトウェアのメトリクスについて
ソフトウェアのメトリクスについてと、メトリクスについて最近思うことを書いておこうと思います。
メトリクスとは
ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。
ソフトウェアの品質を数値化して確かめる：初めてのソフトウェアメトリクス（前編） - ITmedia エンタープライズ
ソフトウェア測定法（ソフトウェアそくていほう）またはソフトウェアメトリック（英: Software metric ）とは、ソフトウェアやその仕様の属性の尺度である。
定量的手法の威力は他の分野で証明されていたことから、計算機科学の分野でも同様の手法をソフトウェア開発に持ち込もうとする努力が続けられてきた。トム・デマルコは DeMarco, T. (1982) Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, USA, p3 の中で「測定できないものは制御できない」と記している。
プロセスや、プロダクトを評価する目的で測定し、導出される値がメトリクスです。
一般的には、色々なものを評価して、改善する目的で色々な値を取ります。
GQM(Goal-Question-Metrics)アプローチ
メトリクスをトップダウンで取得するために整理するフレームワークとしてGQM(Goal-Question-Metrics)があります。
GQM パラダイムは，V.R. Basili らによって提案された計測の枠組みである．
計測目的とメトリクスの 対応関係が明確になり，何のために計測のためのデータを収集するのかの確認が容易になる．
従って，デー タ収集のよい動機付けにもなる．
その計測原理は以下の 2 つである．
• 計測はトップダウンで行われるべき．つまり，先 ず計測の目標があり，その目標を遂行するために 尺度 (メトリクス) が定義され，計測が行われな ければならない．
• データ分析は何らかの目的や仮説に基づいて行 われるべき． GQM パラダイムは，図 1 に示すようなモデルを 用いる．
モデルを構成する，Goal, Question, Metric の意味は，次の通りである．
Goal(目標：概念レベル) 計測の目標を，計測対象，計測理由，視点，環境等に基づいて明確にしたものである．
Question(質問：操作レベル) 特定の Goal を評価，あるいは，達成する方法を質問の集合を用いて特徴づける．
Metric(尺度：量的レベル) Question に 定量的に答えるためのデータの集合である．データ は客観的データ (計測対象のみに依存し，計測の視点には依存しない) と主観的 (計測対象と視点の両方に依存する) データに分かれる．
https://www.jstage.jst.go.jp/article/jssst/29/3/29_3_29/_pdf
https://www.cs.umd.edu/users/mvz/handouts/gqm.pdf
私はすべてのメトリクスがトップダウンで取られるべきとは思いませんが、トップダウンで取る場合には、何を目的として、どういったメトリクスを取るのか、その整理のためにGQMで整理するのはとても重要だと思っています。
最近ではスクラムなどのアジャイル開発の文脈では、チームの改善はチームメンバ内の意見、活動で行われます。
そういった場面では、ボトムアップでメトリクスを取得し、評価して改善や改善提案していく方法は有効だと思っています。
Goalを定義するテンプレートは、上で引用した2つのサイトで微妙に異っているため複数の方法があるようです。
下のページでは、Goalを定義する際には、「誰の視点で」、「品質問題は何か」、「何を」、「どうしたいか」という観点で整理していくと紹介されています。
経験的にですが、GQMはGoal→Question→Metricsという順番も重要であると思っています。
Metrics→Question→Goalと整理すると、無理矢理感のある繋がりになるため良くない気がしています。
余談ですが、組織目標とGQMを紐付けるGQM+Strategiesというのもあります。
https://www.jasa.or.jp/expo/2017/conference2017/doc/ET_IoT_Technology2017_TSE_3.pdf
メトリクスでの評価
プロセスやプロダクトに課題を見つけたり、改善したりする目的でメトリクスを取るわけですが、メトリクスを取る作業というのにも工数がかかります。
特に、今取っていなくてこれから新規で取ろうとする場合や、気軽に取れない値を取得しようとする場合は、それなりに仕組みを考える必要があると思っています。
そのため、取るべきメトリクスというのは、GQMなどで整理して、ゴールと紐付いたメトリクスを決め、そのメトリクスを取る方が良いと思っています。
また、数値というのは人によっては強力なバイアスがかかることがあるため、メトリクスを可視化する際には、それなりに注意する必要があると思っています。
取らないほうがよいメトリクス
数値が低いことを可視化してしまうと、逆に改善しない理由を求められることがあります。
そういったことは余計な工数を生む原因になることがあると思っています。
そのような取得するべきでないメトリクスというのは、例えば以下のようなものです。
- 個人評価に関連するもの
- 誤解を招くもの
- 比較することが適切でないもの
- 改善する合意が取られていないもの
- 数値で評価することが適切でないもの
もっと具体的に示すと以下のようなものがあると思います。
- バグチケットの起票者で起票数をカウントする
- バグ検出ではなく、品質保証を目的としているテストチームの評価のためにバグ検出数をカウントする
- チーム毎に作成したソースコード規模を取得する
これらのメトリクスを取得することが常に悪いかどうかは分かりません。
コンテキスト次第では取得するべきという状況はあるのかもしれません。
ただ、本当にそのメトリクスを取る意味があるのかどうかは良く考えたほうが良いと思っています。
まとめ
取るべきでないメトリクス、取得することに工数がかかるメトリクスというのはあります。
取るべきメトリクスはGQMで背景や、ゴールを明確化して決めていくのが良いんじゃないかと思っています。
この記事を作成するにあたり、一部、ChatGPT(GPT4)さんにご協力していただきました。
