この業界にいると様々な計測対象に出会うかと思います。

• カバレッジ

• テストピラミッド

• Four Keys

ここで得られる数値は併せて推奨される「数値」があったりします。
特定の数値以上だと良いとされるというものです。

そもそもこの値自体にどのような意味があるのか、そしてその値があるゆえに「それを単に追うこと」が目標になるケースが往々にしてあるなと感じています。

また現状の数値「だけ」をみて安心してしまうということもあります。
たとえば、カバレッジが90％近くあるから（きっと）大丈夫だろうとか。

計測値と推奨される値

先程挙げた3つの計測値についてちょっと見てみましょう。

カバレッジ

カバレッジであれば、Googleは以前次のようなことを述べていました。

• 60％を「許容可能」、75％を「推奨」、90％を「模範的」という一般的なガイドラインを提供

• 90％から95％に到達する方法に執着するべきではない

なお、次の本では具体的な数字を出さずに別のことを言っています。

上述したようにカバレッジが低いことはテストコードがないことを表していますが、カバレッジが高いからテストコードで守られていて安心というわけではありません。

自動テストはあるものの不十分なものはよくあります。
確認している箇所が足りないというのもあれば、意味のないところ（本質からずれるところ）を確認していることもあります。

そもそも自明すぎる箇所までテストコードを追加する必要性があるのかというのがあります。

またサーバサイドやクライアントサイドによってカバレッジの差は出やすいものの、コードカバレッジは80％以上であるべしという数値ばかりに目がいったような話がよく言われているようにも思えます。

テストピラミッド

テストピラミッドは色々なところで言及されているものになりますし、聞いたことは多いかと思います。
例えば、次にあるようなAndroidの公式ドキュメントで次のように述べています。

ちなみにこれは日本語版には書いてありますが、英語版にはテストピラミッドの画像もありません。

Googleではテストサイズの話をしていて、今は上記の記事でも小規模・中規模・大規模といっていますが、以前はここはテストピラミッドの図にあるのと同様にUnitテストなどのような分類で書かれていました。

この数字を元に自分たちのテストコードがどういった割合かを確かめるということをしたケースもあるかと思います。

アンチパターンとして言われるアイスクリームコーンになってないかどうかとか、ここで言う大規模テストが多くなってないかを確認したりなどあったりするかもしれません。

Four Keys

ここ数年よく話題に上がるのはこのFour Keysだと思います。
次の書籍で紹介され認知度は上がった認識です。

これらについては毎年、DORAチームによって調査結果の情報が公開されています。

このFour Keysの指標は次のようなものです。

• 変更リードタイム

• デプロイ頻度

• 変更障害率

• サービス復元時間

この中で「デプロイ頻度」や「変更障害率」を計測したいう話はよく聞いたりします。
また、これらの指標をとるためのサービスなどもある状況です。

本件においては、上述の4つの指標の数値がいくつであれば「Elite」であるなどと言っています。

推奨される数値

これらのような数値があることは、良いこともあれば悪いこともあると思っています。
単にその数値を追うという「目的化」することがよくあると思っています。

たとえば、カバレッジも80％以上が良いとされ、それを追いかけているケースを定期的に見ます。

目標がわかりやすく、それに対してアクションをしやすいという意味では価値があるものだと思います。

反面、その数字を追うことが目的になってしまい単にカバレッジが上がるだけでテストとしてはあまり価値のないテストコードを実装してしまうケースも起きます。

そして、これが評価対象となるとハックしやすい数値は意味をなさなくなるだけではなく問題になるケースも起きるかと思います。

これらを表す言葉として「グッドハートの法則」というのがあります。

他にも「ビルドトラップ」という言葉もあります。

なにかしらを判断するために、定量的な数値というのは大事です。
大事ですが、本来の目的を忘れてしまうと価値を失ってしまいます。

ここってむずかしいところだなと常々思います。

おわりに

結局のところ、良いとされる（推奨とされる）数値があったとしても、それが自分たちにとって「妥当」な「意味のある」ものなのか？
目指すべき数値なのか？というのはちゃんと考える必要があります。

定量的な数値を「追う」という行為においての難しさがあると思っています。

上述したようなケース以外にも、手動テストをx%、自動化しようというケースもみかけます。

（そもそも手動テストをそのまま自動化するという行為自体の妥当性もありますが）その数字を目標とすることにどんな意味があるのかどうか。

いろいろなものを可視化したときも、その見えている数字を良くすることが「目的化」するケースはよく起きます。

定量的な数値は大事ですが、我々は本来の目的を見失わずに、それに向き合うことが重要なんだなとつくづく思うのです。