- コードの行数・複雑さ・バグ密度などを数値で測定してソフトウェアの品質・規模・保守性を定量的に評価する指標の集まりのこと。Metricsは「測定基準」の意
- 主観的な「なんか読みにくいコード」という感覚を「循環的複雑度が30を超えている」という客観的な数値に置き換えることで、改善の優先度を誰でも判断できるようになる
- ただし数値が全てではない。コード行数を生産性の指標にすると「短く書くより長く書く方が高評価」という逆インセンティブが生まれる落とし穴がある
【深掘り】これだけ知ってればOK！
実務でよく使われる主要なメトリクスを整理すると次のとおりだ。LOC（Lines of Code：コード行数）はコメント行と空行を除いたソースコードの総行数で、規模の目安になる。循環的複雑度（Cyclomatic Complexity）はThomas J. McCabeが1976年に提唱した指標で、コード内の分岐（if・for・while等）の数をカウントする。値が高いほどテストケースが増えバグが混入しやすくなる。一般的に10以下が望ましく、20を超えると要リファクタリングのサインだ。
品質メトリクスとしてはさらにバグ密度（バグ件数÷LOC）・テストカバレッジ（テストが通るコードの割合）・結合度（CBO：クラス間の依存関係の数）・凝集度（LCOM：クラス内の機能的まとまりの欠如度）なども重視される。結合度が高くなるほどクラスを単独でテストしにくくなり、修正の影響範囲が広がる。
ソフトウェアメトリクスの落とし穴は「目標が指標に置き換わるグッドハートの法則」だ。LOCをKPIにすると冗長なコードを書く開発者が増え、バグ件数をゼロにすることを目標にするとバグを報告しない文化が生まれる。数値はあくまで現状把握と改善の手がかりであり、評価や報酬に直結させると数値が操作されやすくなる点には注意が必要だ。
よくある誤解
LOCが多いほど仕事量が多いという誤解
コードの価値は量ではなく機能と品質で決まる。同じ処理を10行で書いたエンジニアより100行で書いたエンジニアの方が仕事をしたとは言えない。むしろ短く・シンプルに書けるエンジニアほど技術力が高い場合が多く、LOCを生産性指標にすることで逆インセンティブが生まれるリスクがある。
テストカバレッジ100%なら品質が完璧という思い込み
カバレッジはコードの何%がテストを通過しているかを示すが、テストの質は問わない。意味のないテスト（アサーションのないテスト）でもカバレッジの数値は上がる。100%を追求するよりも、バグリスクが高い複雑な箇所に絞ってテストの質を上げる方が実際の品質向上につながるでしょう。
会話での使われ方
このモジュール、循環的複雑度が45になってます。ソフトウェアメトリクス的にはリファクタリング必須ですね。テストも書きにくいはずです。
コードレビューでテックリードが開発者に改善を促している場面。主観的な「難しいコード」を数値で示して説得力を持たせている。
DORAメトリクス、うちのチームは変更失敗率が5%超えてます。デプロイ頻度は高いのに品質が追いついてない状態ですね。
エンジニアリングマネージャーが四半期振り返りでチームのパフォーマンスを分析している場面。速さと品質のバランスが崩れていることをデータで提示している。
コード行数をKPIにするのは危険ですよ。長く書いた方が評価されるなら、誰もシンプルなコードを書かなくなりますから。
エンジニアが人事担当者に評価制度の見直しを提案している場面。メトリクスの使い方次第で組織行動が変わるリスクを具体的に説明している。
【まとめ】3つのポイント
- 感覚を数値に置き換えて品質改善を可視化する：ソフトウェアメトリクスはコードの問題を主観ではなく客観的な数値で示すことで、チーム内での議論と改善の優先順位付けを容易にする
- 循環的複雑度とテストカバレッジが実務の基本指標：複雑度10以下・カバレッジの質を重視という基準を覚えておくだけで、コード品質に関する多くの会話についていけるようになる
- 数値は手段であり目的にしてはならない：LOCやカバレッジをKPIにすると逆インセンティブが生まれる。メトリクスはあくまで品質把握と改善の道具として使うことが健全な活用法だ
よくある質問
- Qソフトウェアメトリクスを自動で計測できるツールはありますか？
- A
SonarQubeが最も広く使われている静的解析ツールで、LOC・循環的複雑度・バグ密度・テストカバレッジを一括計測できます。言語を問わず対応しており、CIパイプラインに組み込んでPRごとに自動計測する運用が一般的です。無料のコミュニティ版から有料のエンタープライズ版まであります。
- Q循環的複雑度はどの言語でも同じ方法で測れますか？
- A
基本的な計算方法（分岐の数を数える）は言語に関わらず共通です。ただし計測ツールによって計算の細部が異なる場合があります。PythonではRadon、JavaではCheckstyle・PMD、JavaScriptではESLintのプラグインで計測できます。SonarQubeは多言語に対応しているため、マルチスタック環境では特に便利です。
- Q小規模チームでもソフトウェアメトリクスを導入すべきですか？
- A
3〜5人程度の小規模チームでも、コードレビューにSonarQubeを組み込むだけで品質の可視化と改善サイクルを回せます。最初から全指標を追う必要はなく、まず循環的複雑度とテストカバレッジの2指標だけ監視するところから始めるのが現実的です。チームが育つにつれて指標を追加していくアプローチが継続しやすいでしょう。
- Qソフトウェアメトリクスとコードレビューの関係はどうなりますか？
- A
メトリクスとコードレビューは補完関係にあります。メトリクスは数値で「どこに問題がありそうか」を自動的に絞り込んでくれます。コードレビューはその箇所を人間が文脈を踏まえて判断・改善する役割を担います。メトリクスのアラートが付いたPRをレビュアーが優先確認することで、限られたレビュー工数を最も効果的に使えるようになります。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| テスト | テストとの関係を知ると全体像がつかみやすくなります。テストというのは、作ったソフトウェアが意図した通りに正しく動くかどうかを確かめる検証作業のことなんだ。 |
| カバレッジ | カバレッジは関連分野でよく登場する重要キーワードです。カバレッジの主要な特徴と用途を理解することで、関連する技術・制度・概念を正確に把握できるようになる |
| アイコン | アイコンを押さえると本記事の理解がさらに深まります。アプリやファイル、操作ボタンなどをひと目でわかる小さな絵で表したもの、それがアイコンだ |
| DevOps | 次のステップとしてDevOpsを学ぶと知識が広がります。Development（開発）とOperations（運用）が協力して継続的にソフトウェアをリリース・改善する文化・手法・ツールセットの総称だ |
| プラグイン | 本記事のテーマと実務上セットで使われることが多い用語です。ソフトウェアやブラウザに、後から好きな機能をちょい足しできる拡張パーツ（改造部品）のことだよ。 |
【出典】参考URL
https://service.shiftinc.jp/column/8492/ ：メトリクスの概要と活用方法（SHIFT）
https://jp.mathworks.com/discovery/cyclomatic-complexity.html ：循環的複雑度の解説（MathWorks）
https://kobesoft.co.jp/mikata/words/system-development/software-metrics/ ：ソフトウェアメトリクスとDORAメトリクスの解説
https://sel.ist.osaka-u.ac.jp/research/metrics/index.html.ja ：大阪大学SELのソフトウェアメトリクス研究
コメント