はじめに
コードカバレッジが上がった。
テスト件数も増えた。
それでも、品質が上がったとはまだ言えません。
メトリクスが示すのは、測定した対象の変化です。私たちが本当に知りたい状態まで、直接表してくれるわけではありません。
この記事では、メトリクスを目標ではなく、品質の変化を捉えて次の行動を決めるためのシグナルとして考えます。
TL;DR
測定は、取得できるメトリクスから始めるのではなく、何を判断したいのかから逆算します。
メトリクスは、品質を採点する数字ではありません。
変化を捉え、次にどこを調べるかを決めるための手掛かりです。
1. 測れる数字と、知りたい状態は同じではない
品質を改善しようとすると、まず測定できる数字に目が向きます。
コードカバレッジ、テスト件数、不具合件数などは取得しやすく、増減も追いやすいからです。
ただし、測りやすいことと、その数字が品質を表していることは別です。
コードカバレッジから分かるのは、テスト実行時にどれだけのコードを通過したかです。
その数字だけでは、重要な振る舞いを検証できているのか、過去の問題を再発させないのか、変更を安心してリリースできるのかまでは分かりません。
もちろん、カバレッジに意味がないわけではありません。
テストされていない範囲を見つけ、追加で確認すべき場所を探すためには役立ちます。
問題は、その数字を品質そのものとして扱うことです。
メトリクスはシグナルを観測するための代理である
Googleがエンジニアリング生産性の測定に用いているGoals–Signals–Metricsでは、測定を次の3段階で考えます。
ここで重要なのは、メトリクスがゴールを直接表しているわけではないことです。
メトリクスは観測可能な代理なので、必ず情報が抜け落ちます。
そのため、数字が正確に集計されていることと、その数字から正しく判断できることは分けて考えなければなりません。
数字を目標にすると、行動も数字へ寄っていく
品質を改善するためにカバレッジを見始めても、カバレッジ自体が目標になることがあります。
これは、誰かが意図的に数字をごまかしているという話ではありません。
目標として設定された数字を改善しようとするのは自然な行動です。
だからこそ、メトリクスを置くときには、次の問いが必要になります。
この数字が改善したとき、現場では何が良くなるはずなのか。
この接続を説明できなければ、その数字を品質目標として扱うのは危険です。
DORAも、メトリクス自体を目標にすると、チームが数字を攻略する方向へ動きやすいと注意しています。複雑なソフトウェアデリバリーを一つの数字だけで評価することも避けるべきだとしています。
2. メトリクスではなく、答えたい問いから始める
では、どのように測るものを決めればよいのでしょうか。
最初に置くのはメトリクスではなく、判断したい問いです。
例えば、次の問いを考えます。
現在のテスト活動は、重大な不具合をリリース前に発見することへ貢献しているか。
「品質は高いか」と問うよりも、何を確かめたいのかが明確です。
この問いから、必要なシグナルとメトリクスを順番に考えます。
どのような変化が見えれば、改善と言えるのか
テスト活動が重大な不具合の事前発見に貢献しているなら、不具合が見つかるタイミングに変化が現れるはずです。
これまで本番で初めて発覚していた問題が、結合テストやリリース前の確認で見つかるようになる。
同じ原因による重大な問題が、本番で繰り返されなくなる。
ここで見たいのは、テストの数ではありません。
不具合の発見が、利用者へ影響する前へ移動していることです。
これが、観測したいシグナルになります。
シグナルを測定できる数字へ落とす
シグナルが決まったら、初めてメトリクスを考えます。
今回なら、重大な不具合がどの工程で見つかったかを記録する方法が考えられます。
この順番で考えると、なぜその数字を測るのかを説明できます。
一方で、最初からカバレッジやテスト件数を選ぶと、その数字が問いに答えられるのかを後から考えることになります。
測定の出発点が違うと、同じ品質改善でも選ぶメトリクスが変わります。
3. メトリクスの変化から、すぐに原因を決めない
重大な不具合が本番前に見つかる割合を測った結果、その割合が下がったとします。
ここで分かるのは、事前に発見できなかった問題が増えていることです。
しかし、なぜ増えたのかまでは分かりません。
ここで「テストが足りない」と即断すると、対策がずれる可能性があります。
要件の認識違いであれば、必要なのはテストケースの追加ではなく、受け入れ条件の見直しかもしれません。
外部サービスとの前提がずれていたなら、連携部分の契約や異常系の確認が必要です。
性能条件でしか起きないなら、通常の機能テストを増やしても問題は見つかりません。
メトリクスは原因ではなく、調べる場所を示す
メトリクスの役割は、原因を自動的に教えることではありません。
変化が起きている場所を示し、追加調査を始めることです。
数字が変化したら、まず実際に起きた問題を確認します。
どのような条件で発生したのか。
なぜ開発中に見つけられなかったのか。
どの情報や検証が不足していたのか。
そこまで調べて、初めて改善策を選べます。
一つの数字には複数の解釈がある
メトリクスは代理指標なので、同じ変化でも複数の説明が成り立ちます。
例えば、本番不具合が減ったとします。
数字だけでは、どの説明が正しいか分かりません。
そこで、結論を出す前に、
別の理由でも、この変化は起こらないか。
と考えます。
DORAがソフトウェアデリバリーを、変更の速さと不安定さを含む複数のメトリクスで捉えているのも、一つの数字だけでは全体を判断できないためです。現在のDORA指標も、スループットと不安定性を組み合わせて評価する構成になっています。
これは、むやみにメトリクスを増やすという意味ではありません。
最初の数字だけでは区別できない解釈があるときに、判断に必要な情報を補うということです。
4. メトリクスを改善サイクルの一部にする
測定した数字がダッシュボードに並んでいても、それだけでは改善になりません。
メトリクスを決めるときは、数字が変化した場合に何をするのかまで設計します。
今回の問いなら、次のようにつながります。
ここで、特定の数値を超えたら即座に「品質が悪い」と判定する必要はありません。
品質メトリクスは、合否を決める基準よりも、調査を始める条件として使いやすいものです。
一時的な増減で判断するのではなく、複数回のリリースで同じ傾向が続いたら調査を始める。
改善を行ったあとは、観測していたシグナルが変化したかを確認する。
この流れに組み込むことで、メトリクスは評価表ではなく、改善のための道具になります。
DORAも、メトリクスを現状把握、改善対象の特定、施策の検証に使い、チームで改善サイクルを回すことを推奨しています。
数字を見ても行動が決まらないなら、測る目的を見直す
メトリクスは、一度決めたら追い続けるものではありません。
数字の変化から次の行動を決められないなら、問いかメトリクスのどちらかがずれています。
測定には、収集、集計、分析、共有のコストがかかります。
判断に使えない数字を増やすのではなく、役目を果たしていないメトリクスをやめることも測定設計の一部です。
おわりに
測れるものと、測るべきものは同じではありません。
コードカバレッジやテスト件数が示す事実には意味があります。
ただし、その数字を改善することが、品質の改善と一致するとは限りません。
大切なのは、メトリクスから考え始めないことです。
メトリクスは目標ではありません。次にどこを調べ、何を変えるかを決めるためのシグナルです。
数字を追うことではなく、問いから改善までをつなげることが、測定の目的なのだと思います。