ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。
1冊は、『初めて学ぶソフトウェアメトリクス』。
原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。
もう1冊は、『アジャイルメトリクス』。
原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されています*2。
後者はその名の通り、アジャイル開発にフォーカスしています。一方の前者は、ウォーターフォール開発に加えて、スパイラルモデル・反復型開発を意識した記述になっていますが、「アジャイル」という言葉は出てきません。
また、「新」側の理解を深めるために、『LeanとDevOpsの科学』にも少し目を通しています*3。
こちらの原著『Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations』は、2018年の出版ですね*4。
この記事の目的は「比較」であって、優劣について語るものではありません。
また「旧」「新」という呼び方は、「旧」にネガティブな印象があるので、以降は「従来型」「アジャイル」と呼ぶことにします。
品質メトリクスの本質的な違い
結論として、従来型とアジャイルの品質メトリクスは、根本から別モノだと感じます。
表大好きマンなので、わたしの理解を表にしてみます。当然ですが、「このようにカッチリ分かれる」ということではなく、「そのような傾向がある」というものです。
| 項目 | 従来 | アジャイル |
|---|---|---|
| 品質の位置づけ | リリース物に欠陥が少ないこと | ・リリース物がユーザの要求に近いこと ・近づける能力を組織が有すること |
| 品質メトリクスの用途 | ・計画のために見積もる ・開発中の品質状況を把握する |
品質の継続的な改善につなげる |
| 基本データの取得タイミング | 主に開発中のデータ | 開発中と運用中のデータの両方 |
| 基本データの源泉 | ソースコード管理システム、チケット管理システム | 左記＋その他の開発基盤・本番環境 |
以下、一つずつ見ていきます。
品質の位置づけ
『アジャイルメトリクス』の「第8章 ソフトウェア品質を測定する」では、アジャイルの原則である「物事を素早く頻繁に変えていくことの重要性」について説明しています。品質のメトリクスも、この原則から導出されていきます。
「ユーザの要求は継続的かつ頻繁に変化していくものであって、それに迅速に追随できる能力が、品質の代替指標になる」という考え方であると解釈しています。
一方『初めて学ぶソフトウェアメトリクス』の方は、要求の変化を強く意識してはいません。もちろん当時から、仕様についての認識齟齬やスコープクリープ*5の問題はあったと思いますが、「あるべき要求・仕様が一意に決まる」が暗黙の前提になっているように思います。
その「あるべき」をどれだけ満たしているかが、従来型の品質メトリクスであり、シンプルには「開発中の欠陥が少ないこと、収束していること」になります。
品質メトリクスの用途
『初めて学ぶソフトウェアメトリクス』には、以下のような記述があります。
メトリクスの効果があるのは、(中略) ソフトウェア開発プロセスの開発から終了までである。(中略) ソフトウェア開発作業は、メトリクスで計測し、評価し、必要があれば、計画を考え直さねばならない。
このあたりの記述を読む限りは、従来型のメトリクスの目的は、「開発の状況を把握・コントロールする」「計画のための見積もりに使う」ことでしょう。品質メトリクスも同様で、たとえば「計画した通りのバグ摘出にならないようであれば、テストを見直す」といったアクションを取ることになります。また管理者にとっては、「リリースするに足る品質か」を判断するための指標にもなるでしょう。
一方でアジャイルにおける品質メトリクスは、「自分たちの開発の仕組みやプロセスを継続的に改善していくために使う」ことが意識されています。
たとえば代表的なメトリクスであるMTTRは、ざっくりいうと「インシデントが発生してから、修正版がデプロイされるまでの時間の平均」ですが、その数字だけを計測してもあまり意味はありません。MTTRを「問題のトリアージ」「開発」「ビルド」「テスト」「デプロイ」というステップに分割して推移を調べることで、改善すべきステップを特定します。「手動リグレッションテストばかりで、テストに時間を食う」のであれば、自動化を検討する、といった具合です。
もちろんアジャイルにおける品質メトリクスも、計画の見積もりに使うことはできるでしょうが、メインの目的はあくまでも「自分たちの能力を知り、改善する」ことにあるようです。
基本データの源泉と取得タイミング
メトリクスの算出には基本データが必要です。
たとえば上述のMTTRを簡単に計測したければ、インシデントを記録したチケットのステータスから、発生によるオープンと、リリースに伴うクローズのデータを取得できるでしょう。この場合、源泉はチケット管理システムであり、タイミングは開発と運用の両方にまたがります。
従来型とアジャイルでは、この源泉とタイミングも異なる傾向があります。
従来型の品質メトリクスは主に欠陥に注目しているため、源泉はまず、チケット管理システムになるでしょう。あとは、コード行数などの把握のためにソースコード管理システムも源泉になります。取得のタイミングはいずれも、開発中が中心になります。
一方アジャイルにおける品質メトリクスの源泉は、上述の2つに加えて、CI/CD基盤、コード解析ツール、セキュリティスキャンツール、本番環境のモニタリングツールなどが加わってきます。取得タイミングは、開発と運用にまたがります（そもそもこの2つはずっと並行していることになる）。
もう少し大まかにいうと、従来型で見るのは主に開発中のソースコードとそれに付随するバグであるのに対し、アジャイルでは開発基盤から本番環境まで多くのところからデータを取得しています。
プロダクトそのものに注目するか、開発・運用プロセスも含めた全体に目を向けるかの違いといってもいいでしょう。
具体的な品質メトリクス
従来型のメトリクス
『初めて学ぶソフトウェアメトリクス』では、以下の5つを「中核メトリクス」（Core Metrics）と呼んでいます。以下、本書第2章から抜粋します。
- 機能量。最終的に、コンピュータで実行する機能の総量。通常、ソフトウェアの大きさ（サイズ）であり、ソースコード行数やファンクションポイント数で計測する。
- 生産性。投入した時間や工数あたりに開発した機能量で表現する。
- 時間。プロジェクト完成に要したカレンダーの月数。
- 工数。投入した作業量を人月で表わしたもの。
- 信頼性。欠陥率あるいは、バグ検出の間隔で表わしたもの。
品質メトリクスはこの5つ目で、具体的なメトリクスは「欠陥率」「バグ検出の間隔」です。ともに、開発中のメトリクスであることに注意してください。
「第8章 欠陥率による信頼性測定」では、運用に関連づいたメトリクスも含めて、4つが説明されています（表現は一部あらためています）。
- 総欠陥数: ソフトウェア製品の開発中に摘出した欠陥を累積した数。
- 残存欠陥数: リリース時に残っている欠陥の数。リリース時点では知りえない。
- 欠陥率: プロジェクト開発工程中の1週間、あるいは1か月あたりの発生欠陥数*6。
- この逆数がMTTD（Mean Time To Defect）。1つの欠陥数を見つけてから次を摘出するまでの平均時間。
- 障害率: MTTF（Mean Time To Failure、1つの障害から次の障害までの平均時間）の逆数。
4.の障害率が唯一、運用まで意識した品質メトリクスになっています。
アジャイルのメトリクス
『アジャイルメトリクス』では、品質特性をきわめて大まかに「保守性」と「ユーザビリティ」に分けています*7。
保守性のメトリクス
品質が高い ← 変化や問題に素早く追随できる ← 修正がしやすい ← コードの保守性が高い という理屈になります。
従来型では保守性は、品質特性の中でも「大事だけど地味」な印象（わたしだけ？）ですが、アジャイルにおいては本質的に重要な意味を持っていることになります。
「8.3 保守性の測定」で言及されているメトリクスは、以下の6つです。
- 平均修復時間（MTTR）: インシデント発生から修正・デプロイまでの時間平均
- リードタイム: 新しい機能が定義されてからユーザに届くまでの時間平均
- コードカバレッジ: 単体テストでカバーされているコードの量
- コーディング規約ルール: 言語の規約の順守率
- コード変更量: 機能追加やバグフィックスのためにどのくらいコードを変更しなければならないか
- バグ率: 新機能の本番投入に伴って発生したバグの数
この中で特に重要視されているのが、MTTRとリードタイムです。両者は計測開始の契機こそ異なりますが、要は「どれだけ迅速にモノが出せるか」であり、構成する要素はかなり近いです。
「バグ率」も軽視されているわけではないのですが、バグそのものを問題視するというよりは、バグが多い → 保守性が悪化しているので改善の必要がある、と判断するための指標と位置付けられています。
この他には、以下のようなメトリクスも説明されています。
- FRP（Fix-Release Percentage）: 総修正数 / 総リリース数。要は「1回のリリースにどれだけ修正を詰め込んでいるか」であり、この値が高ければ「低頻度でしかリリースできないので、いろんなものをまとめてリリースしようとしており、失敗のリスクが高い」ことを意味します。よって低い方がいいです。
- 各種コードメトリクス: コード行数、重複（コードクローン）、複雑度などに言及があります。
- 手戻り率: 開発者が実装したものをQAが却下する頻度が高ければ、MTTRやリードタイムに悪影響を与えます。
ユーザビリティのメトリクス
ユーザビリティもまた、（わたしの中では）「付加価値」的な品質特性でしたが、ここでは重要な特性として扱われています。
ユーザビリティは、可用性と信頼性、セキュリティの2つに分けて、メトリクスが紹介されています。
可用性
- アップタイム: アプリケーションが機能している時間の割合
- ページ応答時間
信頼性
- 平均故障間隔
- 応答時間*8
- エラー率: ログ上に記録されたエラーの割合
どれも、「ユーザが問題に直面する程度」の指標であることがわかります。
一方で、ISO/IEC 25010で言うところの「ユーザビリティ」とは異なることも明らかでしょう。『アジャイルメトリクス』でいう「ユーザビリティ」は、習得性・エラー防止性・アクセシビリティといった、「使いやすさ」とは別モノです。
セキュリティ
- 静的コード解析
- 動的コード解析
これらはそのまんまですね。手動テストが一切入っていないところも、隠れたポイントかもしれません。
Four Key Metrics
最近人気のFour Key Metricsは品質メトリクスというわけではなく、「ソフトウェアデリバリのパフォーマンスを測定する尺度」（『LeanとDevOpsの科学』 第2章）と位置付けられ、以下の4つを挙げています。
- デプロイの頻度
- 変更のリードタイム
- MTTR
- 変更失敗率
これらは概ね『アジャイルメトリクス』でいうメトリクスと重なっています。このことからも、アジャイルにおける品質とは「デリバリーのパフォーマンス」そのものであり、「ユーザの要求とその変化に、いかに素早く追随していけるか」という能力のことであると考えられます。
両者の類似点
「品質」の位置づけが違うことから、類似点はあまりないように思えます。同じ「品質メトリクス」であるにも関わらず、ここまで異なるものになるのは驚きです。
共通するものとしては、MTTF（平均故障間隔）があります。ただアジャイルメトリクスでは、「いかに壊れないか」のMTTFよりも、「いかに早く直すか」のMTTRを重視しています。
品質メトリクスについての（わたしの）課題
従来型の開発からアジャイル開発に移行してきた人にとって、「品質メトリクス」の大きな目的の1つは、「リリース可否判断」なのではないかと思います。というか、わたしの調査のモチベーションがそれでした。。
しかしながら、アジャイル系2冊の本で紹介されている品質メトリクスの主たる目的は、リリース可否判断ではありません。主たる目的は、自分たちの現状と改善ポイントを理解することです。よって、これらのメトリクスの値が改善していければ、従来型の品質も自然と満たされていく・・・めでたしめでたし。
・・・いや、そうは言っても、そうは言っても～・・・
リリース「後」の品質メトリクスを継続してモニタリングして、値の改善や異常の検知に利用できるのは素晴らしいと思う。
— Kazu SUZUKI (@kz_suzuki) 2023年1月31日
一方でマネージャー層は、「リリース可能な品質か」の情報も必要だと思うんだよなあ。それはもはや重要視されていないのか、効果的なメトリクスはないと判断されたのか。
やっぱり、「開発物の品質を、リリース前に知りたい！」という思いは捨てられないですよねえ。
『アジャイルメトリクス』で紹介されているメトリクスは、開発基盤や本番環境からほぼ機械的に取得できるデータを加工し、保守性やユーザビリティを表現することで、間接的に*9品質を測定しています。
一方で、「このリリース物が十分な品質を持っているか」を知りたければ、「テストの十分性」というとっても難しい、主観的な響きを存分に持った属性に切り込んでいく必要があるのだと考えています。「アジャイルの品質ってそうじゃないんだよ」と言われるかもしれませんが、この点はすぐに放棄していい話じゃないなーと。
これが、わたしの今後の課題です。
補足
品質の位置づけの変化について
わたしの以下のつぶやきに対し、にしさんから以下のようなリプライをいただいたので、残しておきたいと思います。
ありがとうございます。
こう考えると、従来重視されていた品質メトリクスは、リリース「前」の品質を知ろうとする傾向があり、モダンな品質メトリクスはリリース「後」の情報で品質を知ろうとする傾向がある、という解釈もできるのかな。安易かもだけど。
— Kazu SUZUKI (@kz_suzuki) 2023年1月31日
後者も、コードカバレッジなど「前」のメトリクスに言及はしている。
ある意味では「信頼性」になったのですよね
— Yasuharu NISHI (@YasuharuNishi) 2023年1月31日
ある意味では「信頼性」になったのですよね
品質って、元々は出荷時の良さや悪さを指す概念なんです。もちろん狭義ですが。それに対して信頼性は出荷後の良さや悪さを指す概念なんです。こちらも狭義ですが。
いわゆるハードウェアの信頼性工学が保守の理論体系を作っていたりMTBFなどのメトリクスを数理的に解析しているところからも類似性は分かりますね。だからSREなのかもしれません。
QCDの三方よしについて
@t_wadaさんが講演でたびたび主張されている「品質とスピードは両立する」という命題について、文脈は若干違うながら、同じような話が『初めて学ぶソフトウェアメトリクス』にも出てきました。
第4章に出てくる表4-1を引用します。
| 要望 | 開発期間 | 工数 | 信頼度 | 大きさ | 生産性 |
|---|---|---|---|---|---|
| 早い | ▽ | ▲ | ▽ | ▽ | ▲ |
| 良い | ▲ | ▲ | ▲ | ▲ | ▲ |
| 安い | ▲ | ▽ | ▽ | ▽ | ▲ |
この表によると、品質（良い）とスピード（早い）を両立する方法は2つあります。
1つは、工数をかけることです。「早い」を維持するためには、日数ではなく人数を増やすことになります。もちろんブルックスの法則*10を意識する必要はあるでしょうけれど。
もう1つは、生産性を上げることです。
@t_wadaさんのおっしゃる両立は、こちらに近いではないかと覆います。良いコード、保守性の高いコードは、生産性の向上につながります。
参考
「アジャイルSQC研究会」という研究会があります。
その委員でもある荻野 恒太郎さんがよく品質メトリクスについての発表をされていたので、それにも言及したかったのですが、体力が尽きました。。 www.swtest.jp過去に調べたアジャイルのメトリクスは、こちらで記事を書いています。 www.kzsuzuki.com
MTTRについては、こちらで記事を書いています。 www.kzsuzuki.com
『アジャイルメトリクス』の「拡張性」については、こちらで記事を書いています。 www.kzsuzuki.com
*1:邦訳は2005年。
*2:邦訳は2022年なので、だいぶ間が空いている。
*3:というか、どの本も「少し目を通した」だけで、精読・精通できていません。といういつもの免責。。
*4:最初の本が「Five Core Metrics」を、最後の本が「Four Key Metrics」を謳っているのは、なかなか面白い対比だと思います。
*5:「プロジェクト管理において、プロジェクトが開始した後のどこかで起こるプロジェクトのスコープの変化、継続的または適切な管理無しでの増大を指す。」by Wikipedia
*6:欠陥率というと、「欠陥密度」、つまりソースコード行数あたりの欠陥数を連想するが、本書ではこのメトリクスには言及がないようだ。
*7:本章のこの章で使う言葉は、従来の用語より拡張されているため、誤解を招くことが多そうと感じる。たとえばこの章でいう「ユーザビリティ」には、セキュリティや信頼性が含まれる。また「信頼性」という言葉の中に、画面の応答時間という、従来は「性能」と呼んでいた属性を含めている。
*8:可用性の方に挙がっている「ページ応答時間」との違いは特に説明されていない。
*9:品質メトリクスはそもそもすべて、間接的な指標かもしれませんが。
*10:「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」by Wikipedia
