品質や生産性などのメトリクス

はじめに

さいきん、品質や、(特に)生産性のメトリクスについて騒がれているので、まとめつつ自分なりの考察やおもうところを書いておく。

まだまだ、発展途上、勉強中のため正解を記載しているわけではないので、あくまで参考としてみていただければ。。。

そして、私が、脳筋長距離ランナーなので、自分でわかりやすいようにランナー風にも書いておく。

メトリクス

メトリクスとは「測定基準」が本来の意味で、何をどのように測定をするかを決めたもので、その「測定基準」によって計測された数値です。

健康診断、体力測定、ランニングのラップタイムや心拍数なども、バイオメトリクスと表現されますが、これもメトリクスです。

(基本は)なにかしら基準・範囲に入っているかを確認をして、維持、範囲外ならどのような対策をするか、これを決めるための単なる「値」です。

メトリクスは、単なる「値」であって単独では役に立たないもの

なんのためのメトリクスか

品質も生産性も、どうしてメトリクスをとるのでしょうか？
単純にいうと『ある目標』に向かいたいから、『ある目的』を達したいから、現状を把握するためです。

健康診断で体重・血液検査などや、ランニングのラップタイム・心拍数を計測するのも、『ある目標』を達成したいのか、現状を把握するために行うものです

健康診断、運動なども同様に、結果だけでは、単なる「値」で、それだけでは意味を持ちません。

「目標」、「目的」があって、はじめて意味を成す値になります。

よって、「目標」、「目的」がなければ何の意味も持たないただの数値であることは理解しておいたほうがよいです。

ただし、計測値がなければ『ある目標』を達成するためのリスクもわかりませんし、手法・手段も何をすればいいのかも判断できません。

例えば、血糖値が高いのか低いのか、わからなければ健康なのかどうかも判断できないという状況と同じです。

体調が微妙とか、まぁまぁ健康、なんか風邪っぽいとか言われても、判断できないのと同じです。

状況を把握するために定量化 (数値化) すること

メトリクスの使い道

最近(でもないと思いますが)では、ソフトウェア開発において、プロダクト・プロジェクトの品質測定というよりは、プロジェクト・プロダクトの継続的な改善、計画的な成長のために利用していくことが多いのではないかとは思っています。

アジャイル的には、ユーザの要望をどれだけ実現できたかなどもあるかもしれません。

人命やお金が関わるようなミッションクリティカルなものについてはリリース判定の一つとして利用はされているかとは思いますが。。。

メトリクスは (いつから) とるべきか？

いきなり計測して、健康か不健康か判断できないので、「目標」、「目的」があいまいであっても、『まずは』不要だと思っていたとしてもある程度のメトリクスは取得することをお勧めします。

品質、生産性が落ち始めたり、向上し始めたりするきっかけが全く分からなくなるためです。

あとから、いつから糖尿病になったんだ？っと言って、体調悪くなってから健康診断しても、ときすでに遅しということです。
体調が悪いなーって思って検査したら手遅れという事態もありますよね。

メトリクスはできるだけ早めにとるべきです

プロジェクト (スプリント) ごとにやりかたなど違うと比較できないのか？

やりかたが違うのであれば、なおさら取っておいた方がいいと思います。
どのやり方がよいのか、異なる手法を分析をするための数値となるためです。

どの薬が効果があるのか、どのトレーニングが効果があるのかを把握するためと同じようなものだと考えています。

どんなメトリクスを取得するのか

プロダクト(サービス) の健康度合いを計測した「値」です。
「ソフトウェアメトリクス」はソフトウェアの品質や開発プロセスを数値で評価する方法であり、様々な測定方法があります。

最近は「生産性」が注目をあびていますが、プロダクト、プロセスの品質などもメトリクスを取得することができます。

プロダクト品質のメトリクス

品質のメトリクスとしては、過去に整理をしていました　。
https://qiita.com/bakachou/items/53d7332fd11ad4dc08f9

(これだけではないですが)

プロセス品質のメトリクス

VSM などを利用してプロセスの品質も以下のようなメトリクスで表現できます。

• プロセス・パフォーマンス指標 (プロセス開始から終了時間、成功率など)
• 差戻し回数(時間)
• 承認回数(時間)

生産性のメトリクス

ここ最近の生産性というブーム？で、有名となった Four Keys があります。
4keys の「測定基準」は、名前の通り4つで、以下になります。

• デプロイの頻度
• 変更のリードタイム
• 変更障害率
• サービス復元時間

目標・目的の設定

健康や運動などの目標、目的は、はっきりして立てやすいですが、品質に対して目標、目的は立てづらいかと思います。

そこで、目標・目的を設定しやすいように、いくつかのモデルがあります。

• GQM (+SMART)
• SLO

その他なにかあるかも。。。

GQM モデル

GQM とは何のために測定するのか、前提となるモデルは何か、結果をどう解釈するかを定義する測定モデルで、簡単に言うと以下の3つです。

たぶん一番わかりやすいモデルだとは思います。

* Goal (目標、達成したいこと)
* Question (目標達成のために、どこで(どのプロセスで)、何をして、どのようなことに関心があるか)
* Metrics (計測方法、計測値)

GQM を考えるうえで、プロジェクトの要求・要件のドキュメントに一部記載されている項目と重複するとこもありますが以下のようなことを考えます。(GQM ゴールデンテンプレートと言われています)

• 対象
• 目的
• フォーカス
• ステークホルダー
• コンテキスト

GQM をきめるときに SMART という概念が重要ですが、こちらは別で書こうと思います。
(長くなるので)

ゴール

到達したい『目標』、達成したい『目的』です。
なので、まずはプロジェクト(スプリント) で、何を達成したいのかを明確にすることが大事です。

例えば、私の場合は以下のようなことを考えていました
(私がテスター・QAのため、品質メトリクスです)

* 機能性でのバグは 0 にすること
* プロダクト(コード)もテストも再利用できること
* 保守(サポート) で1回で解決できるようにすること

クエスチョン

目標を達成するために、評価すべきものの定義です。
ゴールが達成できたかどうかを判断する基準を決めます。

1つのゴールに対して複数のクエスチョンが関連付きます。
(1つだけでも構いませんが、おそらく複数の達成基準が出てくるとは思います)

プロジェクト(スプリント) 内で、生産性は、流行りで行くとデプロイ数とかなので、品質よりも計測しやすいと思いますが、品質のメトリクスを取るのは、なかなか困難かもしれません。
※) 品質はプロセスに組み込まれていくものと考えているためですが

なので、品質のメトリクスは一連のプロジェクト(スプリント)が終わったときに整理することが多いかと思います。

もちろん、細かくすればするほど精度が上がると思いますが、自動で計測するぐらいではないと実質は難しいと思います。

できれば数値で定量的に表現できたほうがよいです。
私があげていた例ですが、以下のようなものがあります。

* ユニット・結合のテスト網羅性
* 機能性のテスト網羅性
* ユースケースの範囲性

などなど

ちなみに、設定した基準に到達しない可能性もあります。

達成しないことが悪いのではなく、達成しない理由を考えるための 『基準』 であることをと認識してください。
もちろん達成することにこしたことはありませんが。。。

メトリクス

計測する方法・基準と、それに沿って計測された値です。
1つのクエスチョンに対して複数のメトリクスが必要になってくるかと思います。
また、それぞれのメトリクス同士で依存関係があることが多いです。

https://qiita.com/bakachou/items/53d7332fd11ad4dc08f9
こちらにも記載していますが以下のような項目があります。

• テスト密度
• バグ密度
• レビュー指摘密度
• レビュー工数密度
• レビュー指摘効率

その他にも計算できるメトリクスはいくつもあると思います。

その他にも自動化率などありますが、クエスチョンによって計測内容は変わってきます。
こちらも私の例になりますが以下のようなことを考えていました。

ユニット・結合のテストカバレッジ (C1) 率
機能性のテスト密度、バグ密度
開発規模とユースケース数の関係(率)

SLO

SLA になると契約になって厳密になるのでこちらはおいといて。。。。
(SLA を達成するための目標として SLO を決めるのではあるんですが。。。)

SLI、エラーバジェットなどを組み合わせて性能、運用性などなどの水準を決めていくやりかたです。

こっそりですらやったことがないので、まだ未知数です。。。。

メトリクスの分析

種類、数がたくさんメトリクスがあるほうが、様々な視点から分析できるかと思いますが、1つだけでも分析は可能です。

上記にもありますが、目標・目的をどれだけ達成できたかのふりかえりや判断材料ぐらいにはなります。

分析手法

分析する手法については、どれを使うのか(合うのか)は目標・目的次第なのでどれがいいとかはいえません。

• Five Core Metrics (初めて学ぶソフトウェアメトリクス)
• SLO サービスレベル目標
• アジャイルメトリクス
• ソフトウェアアーキテクチャメトリクス

プロダクトの品質測定

プロダクトの品質測定としてメトリクスを利用するのであれば、QC 7つ道具にある以下のような分析手法がいいかもしれません。

• 散布図
• パレート図
• 管理図

。。。が、ソフトウェアは工場で歩留まりを検査するのとはことなるので、なかなか合わない気がしています。
長年メトリクスを取り続けていると散布図とかから傾向が出てくるのかもしれません。

改善と成長

改善や成長は以下ようなふりかえり手法を用いたほうが有効ではないかとは考えています。

• Fun・Done・Lean
• 帆船のふりかえり

KPT(A)、YWT、ORID でもいいとおもいますが、これだと、達成しなかった (できなかった) ことに注力しやすくポストモーテム化しやすい傾向があるかと思うので、未来(将来)を見やすいふりかえりほうがいいかと思いました。

出来なかったことに注力するのであれば、特定要因図、5Why を組み合わせていくのがいいかと思います。

正直、改善と成長、ポストモーテムのどっちもやったほうがいいんじゃないかとは思っていますがｗ

さいごに

計測した値(メトリクス) は単に数値なだけです。
上記に記載しましたが、『ある目標』がないと、何の意味も立ちません。

自分たちで作り上げるプロダクトをどのようにしたいのか、どうあるべきなのかを意識を持たないとメトリクスはただのゴミになります。

まずは、目標・目的を持つことが大事だと考えています。

『フルマラソンでサブ4を狙う』ゴールを達成する練習をするときに、どのような練習メニューで、どれぐらいの練習をするかを決めていくのと同じです。

さらに、計測の結果、ゴールに達成しない場合であったとしても、これは悪いわけではなく、ゴールに達成しなかったなにかしらの要因を考えることが重要だと考えています。

プロジェクト・プロダクトの継続的な改善、計画的な成長のためのメトリクスだとすれば、期待値と異なる場合があっても、それは悪いことではないということです。

たとえばですが。。。

尿酸値が基準値より高いからと言って、痛風を発症しない可能性もあるのです。(強度な運動していると、すぐに自然と基準値を越えます)
尿酸値が高くなることを知り対策・改善を行うきっかけや手段を知ることの方が重要になってきます。

フルマラソンで予想タイムに届かなかったときなど、様々な要因が考えられます。
『向かい風が強すぎ』とか『坂道多すぎ』とか『寒すぎ・暑すぎ』、『二日酔い』などなど

自分だけ (特定のプロジェクトの) メトリクスが悪いのか、全員 (全プロジェクト) がのきなみ悪いのか というふりかえることができます。

そして、現状で目標、目的がなくて、あとあと役に立つと思って簡単にとれるメトリクスぐらいは取っておいた方がよいと思います。

体重、体脂肪率とか、体温などと同じように、すぐわかるものぐらい。。。

それでは、よいメトリクスライフを。