コードの品質は測定可能です。この言葉は、CTOがソフトウェア製品を購入する前に、あるいは技術リーダーがリファクタリングプログラムに着手する前に尋ねる質問、「コードの品質をどうやって判断するのか？」に答えようとするまでは、当たり前のことのように聞こえます。「動作する」だけでは答えになりません。「チームがレビューした」だけでも答えになりません。答えには、一貫して適用される客観的な測定が必要です。関数ごとの循環的複雑度、モジュールごとの保守性指数、1000行あたりの欠陥密度、コンポーネントごとのテストカバレッジ、スプリントごとのファイルごとのコード変更などです。これらはすべて数値です。数値は傾向分析、ベンチマーク、そして対策に活用できます。
課題は、コード品質指標が互換性がなく、普遍的に解釈できるものではないという点です。COBOLプログラムにおける高い保守性指数は、Pythonスクリプトにおける同じスコアとは異なる意味を持ちます。循環的複雑度15は、十分にテストされたステートマシンでは許容範囲内ですが、検証関数では深刻な問題となります。1,000行あたり2つのバグという欠陥密度は、システムプログラミングでは優れていますが、安全性が重視される組み込みアプリケーションでは警戒すべきレベルです。指標を有効活用するには、それぞれの指標が何を測定しているのか、何が指標を増減させるのか、そして状況に応じてどのような閾値が適切なのかを理解する必要があります。この記事の残りの部分では、まさにその点について解説します。
コード品質とは何か？
コード品質とは、ソースコードが、正確性、保守性、可読性、効率性、セキュリティ、テスト容易性といった、測定可能な特性をどの程度満たしているかを示す指標です。単一の特性だけで品質を定義できるものではありません。正しく動作するものの可読性が低いコードは、変更のたびに品質が低下します。なぜなら、コードを理解できない開発者は安全に修正できないからです。可読性はあってもテストされていないコードには、隠れた欠陥が潜んでいます。テスト済みであっても構造が複雑なコードは、複雑性が高まるにつれて、予期せぬ変更によって何かが壊れる可能性が高まるため、欠陥が蓄積されていきます。
ISO/IEC 25010規格の正式な定義では、ソフトウェアの品質特性として、機能適合性、性能効率、互換性、ユーザビリティ、信頼性、セキュリティ、保守性、移植性の8つが挙げられています。ソースコードに関しては、実行時動作ではなくコード自体から直接測定できる特性は、保守性、信頼性（欠陥および複雑性メトリクスで近似）、セキュリティ（静的解析による）、および機能適合性（テストカバレッジによる）です。その他の特性は、コードを実行して測定する必要があります。したがって、コード品質メトリクスは、ソフトウェア品質の全体ではなく、定義済みかつ重要なサブセットをカバーしています。
コード品質が重要な理由
技術チームはコード品質がなぜ重要なのかを理解しています。ビジネス関係者や社内でその重要性を説明する必要のあるチームにとって、その関連性はコストと時間にあります。マッキンゼーとITソフトウェア品質コンソーシアム（CISQ）の調査では、開発者が新しい機能の開発ではなく、既存の技術的負債の回避に時間の30～40%を費やしていることが一貫して示されています。コード品質の低さは、技術的負債が蓄積されるメカニズムです。早期に発見されなかった欠陥、必要以上に複雑な機能、個別に保守しなければならない重複したロジックブロックは、次の変更のコストを増加させます。コード品質が高いほど、そのコストは継続的に削減され、システムのライフサイクル全体にわたって効果が積み重なります。
コード品質指標：完全リファレンス
以下の指標は、コード品質測定の主要なカテゴリすべてを網羅しています。各指標について、定義、測定方法、許容範囲、および解釈について説明します。以下の表のしきい値は、広く引用されている業界ベンチマークを反映しています。安全性が重視される環境や規制の厳しい環境で活動するチームは、より厳しいしきい値を適用する必要があります。
複雑度メトリクス
循環的複雑性 関数またはメソッドを通る線形独立なパスの数を測定します。これは 1976 年に Thomas McCabe によって導入され、現在でも最も広く使用されている複雑性指標です。この式は、決定点、 if, else if, switch ケース、ループ条件、 catch ブロック、条件演算子、および 1 を追加します。分岐のない関数の循環的複雑度は 1 です。
| 循環的複雑性 | 解釈 |
|---|---|
| 1-5 | シンプルで、テストも簡単 |
| 6-10 | 適度で管理しやすい |
| 11-20 | 複雑になり、テストが難しくなる |
| 21-50 | 非常に高いリスク、リファクタリングを推奨 |
| 50件以上 | 検証不可能で、ほぼ確実に欠陥が含まれている |
高い循環的複雑度は、欠陥密度と強い相関関係があります。IEEE Transactions on Software Engineeringに掲載された研究によると、循環的複雑度が10を超える関数は、より単純な関数よりも欠陥率が著しく高いことが分かりました。レガシーコードベースにおける循環的複雑度分析の課題は、長年の保守作業の中で、全体構造のリファクタリングが一度も行われずに、意思決定ロジックが蓄積されてきた関数を見つけることです。
NPath 複雑度は、ネストされた条件やループによって生成されるパスを含め、関数内の一意の実行パスの数をカウントします。循環的複雑度が分岐を線形にカウントするのに対し、NPath 複雑度は分岐を乗算します。例えば、3 つの if-else ブロックが連続する関数は、循環的複雑度は 4 ですが、NPath 複雑度は 8 になります。これは、各条件が独立して真または偽になる可能性があるためです。NPath 複雑度はネストが深くなるにつれて指数関数的に増加します。200 を超える値は、どのチームも現実的に作成できるテストケースの数よりも多くのテストケースを必要とする関数であることを示しています。
認知複雑性 SonarSourceによって導入され、コードに含まれるパスの数ではなく、コードの理解の難しさを測定します。線形分岐よりもネストを厳しくペナルティします。 if 内部 while 別のものの中に if 3回連続でより高いスコア if 同じ循環的複雑度を持つステートメント。認知的複雑度は、開発者がコードを読む際に実際に経験する困難さにより近い値です。メソッドあたりの認知的複雑度が15を超える場合は、一般的にレビュー対象としてフラグが立てられます。25を超える場合は、ほとんどの開発者にとって理解するのが非常に難しい関数であることを示します。
ハルステッド・メトリクスは、ソースコード内の4つのカウント（異なる演算子（n1）、異なるオペランド（n2）、演算子の総数（N1）、オペランドの総数（N2））から一連の指標を導き出します。ハルステッドはこれらから以下の値を計算します。
- 出来高 (N × log2(n)): 情報コンテンツにおける実装のサイズ
- 難しさ (n1/2 × N2/n2): コードの記述や理解の難しさの推定値
- 準備 （ボリューム×難易度）：コードを実装または理解するために必要な推定総精神的労力
ハルステッド指標は、類似した循環的複雑度を持つ関数を比較し、どちらが理解しにくいかを判断する際に特に有用です。明確な名前の変数に関する10個の分岐を持つ関数は、計算されたインデックスと1文字の識別子に関する10個の分岐を持つ関数よりも、ハルステッド難易度が低くなります。
保守性指標
保守性指数は、ポール・オマンとジャック・ハーゲマイスターによって開発され、後にマイクロソフトのVisual Studioで標準的な保守性指標として採用された複合指標です。ハルステッドボリューム、循環的複雑度、コード行数を単一のスコアに統合しています。
Visual Studio の数式は、0 から 100 までのスコアを生成します。
| 保守性指数 | 評価 |
|---|---|
| 20-100 | 維持管理しやすい（グリーン） |
| 10-19 | 中程度のメンテナンス上の懸念（黄色） |
| 0-9 | 維持管理が難しい（赤） |
保守性指数は要約統計量です。これは、グリーンゾーンのモジュール間の詳細な比較よりも、レッドゾーンのスコアを持つ外れ値、ファイル、またはモジュールを特定するのに最も役立ちます。Python では、 radon ライブラリは保守性指数を直接計算します。Visual Studio では、コード メトリクス ウィンドウに表示されます。 静的コード分析 プラットフォームにおいては、保守性指数は、循環的複雑度やコード行数と並んで、標準的な出力の一つとして一般的に用いられます。
コード行数（LOC）とKLOCは、コードベースのサイズを行数または千行数で測定します。LOCだけでは品質については何もわかりませんが、他の指標の重要な分母となります。欠陥密度はKLOCあたりのバグ数、コメント密度はLOCあたりのコメント数、テスト密度はLOCあたりのテストアサーション数です。LOCは複雑さのコストも反映します。循環的複雑度が20の500行の関数は、同じスコアの50行の関数よりもはるかに大きな問題です。
コードチャーンとは、時間の経過とともにコードが変化する割合のことで、単位時間あたりにファイルごとに追加された行数、削除された行数、変更された行数を合計して測定されます。コードチャーンが高いということは不安定さを示しています。頻繁に変更されるコードは、最初から正しくなかった設計、不安定な要件、またはパッチを繰り返し必要とするバグに対応している可能性があります。マイクロソフトの調査によると、コードチャーンが上位10%のファイルには、チャーンが低いファイルよりも5倍多くの欠陥が含まれていました。コードチャーンと欠陥率を並行して追跡することで、頻繁な変更が品質向上につながっているのか、それとも新たな問題を引き起こしているのかが明らかになります。
コードカバレッジメトリクス
単体テストカバレッジとは、コードベース内の行、分岐、または条件のうち、単体テストによって実行される割合のことです。最も意味のある形式は分岐カバレッジです。これは、コード内の各判断が、真と偽の両方の結果において、少なくとも1つのテストによって到達可能かどうかを示します。行カバレッジは操作しやすく、何もアサートせずにすべての行を実行するテストは、行カバレッジ100%を達成しますが、何も検出できません。
単体テストのカバレッジに関する業界ベンチマーク：
- 50%未満：不十分。ほとんどの欠陥はテストで検出されない。
- 50～75％：中程度、主要な経路は網羅されているが、例外的なケースは見落とされている可能性が高い
- 75～90%：ほとんどのアプリケーションコードに適しています
- 90%以上：安全性が極めて重要なシステムや高信頼性システムが適している
安全性が極めて重要なアプリケーションにおけるコードカバレッジは、より厳格な基準に従います。航空ソフトウェアに関するDO-178Cおよび機能安全に関するIEC 61508では、標準的な単体テストでは達成できないカバレッジ要件（最高レベルの重要度におけるMC/DCカバレッジ）が規定されています。安全性が極めて重要なアプリケーションにおけるコード品質を向上させるには、条件/判定カバレッジを追跡し、認証機関が要求する正式な証拠を生成できるカバレッジツールが必要です。
テスト密度は、本番コードのサイズに対するテストアサーションの数を測定することで、カバレッジを補完します。カバレッジが高くテスト密度が低い場合は、動作を意味のある形で検証せずにコードを実行しているテストが存在する可能性があります。テスト密度が高くカバレッジが低い場合は、テストがコードベースのごく一部に集中していることを示します。
欠陥指標
バグ密度（欠陥密度とも呼ばれる）とは、コード1,000行（KLOC）あたりの確認済み欠陥数を指します。これは、コードの正確性を最も直接的に定量的に示す指標です。CISQの業界ベンチマークによると、市販の既製ソフトウェアはテスト前は平均して1,000行あたり15～50個の欠陥があり、テストとリリース後には、高品質の市販ソフトウェアは通常1,000行あたり1個未満の欠陥に抑えられています。
静的解析結果 テストや本番環境での使用によって欠陥が確認される前に、おおよその欠陥密度を推定します。SonarQube、Checkmarx、および SMART TS XL 既知の欠陥や脆弱性に関連するパターンをコードベースから分析し、深刻度別に分類された潜在的な問題の数を算出します。重大な問題や障害となる問題の発見数とコード行数（LOC）の比率は、コードがテスト段階に入る前に、コード品質の早期指標となります。
コードスメル密度は、 1000行あたりのコード数で、アンチパターン、重複コード、長すぎる関数、過剰なクラス結合、機能羨望、ゴッドオブジェクトの存在を計測します。コードスメルは即座に障害を引き起こすわけではありませんが、将来の欠陥や保守コストを予測する指標となります。コードスメル密度が高いコードベースでは、蓄積された構造上の問題に対処する必要があるため、将来のあらゆる変更コストが高くなります。
読みやすさとスタイルの指標
コメント密度 コメント行数とコード行数の比率です。最適な範囲は言語やチームの慣習によって異なりますが、通常は 10 ～ 30% です。10% 未満は、ドキュメントが不十分なコードを示している可能性があります。50% を超えると、コードが複雑すぎて、自明でないロジックについて詳細な説明が必要になる可能性があります。コメントの質は量よりも重要です。コードの動作を言い換えるコメント (// increment i by 1）は何も追加しないが、特定のアルゴリズムが選択された理由を説明するコメントは大きな価値を追加する。
命名規則準拠とは、プロジェクトの命名規則に準拠している識別子（変数、関数、クラス）の割合を測定するものです。自動化ツールは、リンティング設定の一部として命名規則を強制することができます。一貫性のある命名は、開発者が識別子の名前だけでその目的を予測できるため、馴染みのないコードを読む際の認知負荷を軽減し、可読性を向上させる上で最も効果的な方法の一つです。
コード重複率は、コードベースのうち複数の場所に重複して存在するコードの割合を示します。重複率が5%を超えると、通常は問題視されます。コードの重複は保守作業を大幅に増加させます。重複したロジックにバグがある場合、すべてのコピーでバグを見つけて修正する必要があり、動作の変更もすべてのコピーに一貫して適用しなければなりません。また、重複によってコードベースの実際のサイズが分かりにくくなることもあります。例えば、100,000万行のコードがあるように見えるシステムでも、実際には40,000万行が固有のロジックで、残りの60,000万行がコピーである可能性があります。
セキュリティと技術的負債の指標
SonarQubeでは、技術的負債比率を、コードベースの推定修復コストと推定開発コストの比率として定義しています。技術的負債比率が5%未満であればクリーンなコードベースとみなされ、20%を超えると、将来の開発を著しく遅らせるほどの重大な負債が蓄積されていることを示します。
セキュリティホットスポット密度は、1,000行あたりのコード行数で、セキュリティレビューが必要なコードパターン（脆弱性の確認ではなく、セキュリティレビューが必要な箇所）の数をカウントします。例としては、パラメータ化されていないSQLクエリ、非推奨の暗号化関数の使用、検証されていない入力処理などが挙げられます。静的解析ツールはこれらのパターンを識別し、手動によるセキュリティレビューが必要な項目として提示します。
脆弱性密度は、1,000行あたりの確認済みセキュリティ脆弱性の数をカウントし、通常はCVSSの深刻度別に分類されます。この指標は、リリース後のセキュリティ監査や継続的なセキュリティ監視パイプラインにおいて最も有効です。
コード品質を測定する方法：実践的なアプローチ
コード品質の測定は、単発的な作業ではなく、開発ワークフローに組み込まれた継続的な実践です。測定されていないコードベースから始めるチームには、実践的な4段階のアプローチが効果的です。
フェーズ1：ベースラインを確立する。変更を加える前に、コードベース全体に対して完全な静的解析を実行します。循環的複雑度分布、ファイルごとの保守性指標、欠陥密度、カバレッジ、重複率の現在の値を記録します。このベースラインは、今後のすべての測定値を比較する出発点となります。ベースラインがないと、変更が品質を向上させているのか、それとも低下させているのかを判断できません。
フェーズ2：しきい値を定義する。各指標について、状況に応じた適切な許容しきい値を設定する。商用Webアプリケーションと安全性が極めて重要な医療機器では、適切なしきい値は異なる。これらのしきい値をプロジェクトの品質基準に文書化し、チーム全体に周知する。
フェーズ3：CI/CDへの統合。CIパイプラインを構成し、コミットまたはプルリクエストごとに主要なメトリクスを計算するようにします。メトリクスが許容範囲外になる変更にはフラグを立てます。循環的複雑度がしきい値を超える新規コード、カバレッジがしきい値を下回るコード、または重要な静的解析結果をもたらすコードを導入するマージはブロックします。これにより、メトリクスのしきい値がガイドラインから強制的な標準へと変わります。
フェーズ4：スナップショットではなく、傾向をレビューする。単一のメトリック値は情報を提供するが、傾向は具体的な行動につながる。特定のモジュールにおけるコード変更の増加傾向、リリースサイクル全体におけるカバレッジの低下傾向、特定のファイルにおける保守性インデックスの低下傾向は、スナップショット測定では見逃される可能性のある問題を示している。各スプリントの振り返りで、メトリックの傾向をレビューする。
エンタープライズ、アジャイル、および安全性が重視される環境におけるコード品質指標
アジャイル開発におけるコード品質指標
アジャイルチームは、コード品質指標に関して特有の課題に直面します。短いサイクルで動作するソフトウェアを提供することに重点を置くと、品質問題が解決される前にリリースしなければならないというプレッシャーが生じる可能性があるのです。解決策は、指標を放棄することではなく、完了の定義に指標を含めることです。ストーリーは、機能が動作するようになった時点で完了したのではなく、機能が動作し、かつ新しいコードがチームの品質基準を満たした時点で完了したと言えるのです。
アジャイル開発における先行指標（問題が発生する前に予測する指標）には、コード変更率、スプリントごとに新たに発生する技術的負債、リリースごとの静的解析における発見件数の推移などが含まれます。遅行指標（既に発生した成果を測定する指標）には、テストで発見された欠陥密度、保守作業時間と新機能開発時間の比率、リリースごとの本番環境におけるインシデント発生率などが含まれます。
技術デューデリジェンスにおけるコード品質
M&A取引、ベンダー選定、システム買収プロセスにおける技術デューデリジェンスでは、コードベース全体にわたるコード品質の構造的な評価が求められます。この文脈において最も重要な指標は以下のとおりです。
- 保守性指標の分布コードベースのうち、赤、黄、緑のゾーンに該当する割合はどれくらいですか？
- 技術的負債比率開発コストに対する修復費用の見積額はどのくらいですか？
- 欠陥密度: 1,000行あたりに既知の欠陥がいくつ存在するか、また、これは業界ベンチマークと比較してどうなのか
- テストカバレッジコードベースのうち、自動テストでカバーされている割合と、そのレベル（行、分岐、条件）
- 依存度の健康: 外部依存関係がいくつ存在するか、そのうちいくつが古くなっているか、または放棄されているか、そしてアーキテクチャの結合度はどの程度か。
- コードの重複コードベースのどのくらいの割合が重複しているか、つまり保守リスクはどのくらいか。
エンタープライズコード評価における影響分析の文脈で検討されているように、各コンポーネントが品質指標でどのようなスコアを獲得するかだけでなく、コンポーネント同士がどのように依存しているかを理解することが、正確なデューデリジェンスにとって不可欠です。孤立した低品質のモジュールは、管理可能な修復コストで済む可能性がありますが、密な依存関係グラフの中心にある同じモジュールは、はるかに大きなリスクを表します。
安全性が重視されるアプリケーションおよびフィンテックアプリケーションにおけるコード品質
航空、自動車、医療機器、産業制御などの安全性が極めて重要なアプリケーションでは、一般的な商用ソフトウェアを超えるコード品質基準が求められます。主な違いは以下のとおりです。
- 循環的複雑度の制限は通常10以下に設定され、例外には正式な正当化が必要となる。
- 補償要件では、ライン補償またはブランチ補償ではなく、MC/DC（修正条件/決定補償）を使用します。
- 静的解析は認定されたツールを使用して実施する必要があり、違反事項は文書化して解決するか、正式に承認されなければならない。
- コードの変更頻度は安全性の指標として監視されます。安全性が重要なモジュールで変更率が高い場合は、追加のレビューと再検証が行われます。
フィンテックアプリケーションも、規制枠組みから同様の圧力を受けています。PCI DSSでは、セキュアなコーディング標準とコードレビュープロセスが求められます。財務報告システムにおけるSOXコンプライアンスでは、要件からコード、テストに至るまでのトレーサビリティが文書化されていることが求められます。コード品質指標は、これらのプロセスが機能していることを客観的に証明します。カバレッジレポートはテストが存在することを証明し、静的解析レポートは既知の脆弱性パターンがチェックされたことを証明し、複雑性レポートはレビュー担当者がコードを適切に評価できることを示します。
言語別のコード品質指標
Pythonコード品質指標 次のように計算できる。 radon （循環的複雑度と保守性指数） pylint （コードの悪臭とスタイルの違反） coverage.py （テストカバレッジ） bandit （セキュリティ上の問題） mypy or pyright （型の正確性）。保守性指数は radon Python用に調整された修正ハルステッド式を使用します。グレードAは20以上、グレードBは10～20、グレードCは10未満です。
RPGコードの品質 IBM i では、標準的な品質メトリックツールでは RPG 構文を解析できないため、専用のツールが必要になります。 SMART TS XL RPGプログラムの循環的複雑度、コード行数、および依存関係分析を提供します。これは、これまで品質測定の自動化が不可能だった大規模なレガシーコードベースを管理するIBM i環境にとって特に価値があります。
コードレビュー指標
コードレビューは、その有効性を測定できる品質管理活動である。
- カバレッジを確認するマージ前に正式なレビューを受けたコミット済みコードの割合
- レビューで発見された欠陥レビュー対象の変更セットのサイズに対する、レビュー中に検出された欠陥の数
- レビューの所要時間プルリクエストが作成されてからレビューされ、マージされるまでの時間
- レビューコメント解決率コード変更につながるレビューコメントの割合と、却下されるレビューコメントの割合
高いパフォーマンスを発揮するチームは、一般的にレビューのカバー率が90%を超え、レビュー100行あたり平均1～3件の欠陥が発見され、レビュー期間も短いという特徴があります。レビュー指標は、コードレビューが品質ゲートとして機能しているのか、それとも単なる形式的なものになっているのかを判断するのに役立ちます。
継続的なコード品質監視
一度限りのコード品質測定は、継続的なモニタリングに比べてはるかに価値が低い。コード品質はコードベースの固定的な特性ではなく、コミットごとに変化する。品質指標を継続的に追跡しなければ、今日良好な測定結果を示したコードベースでも、開発を急いだ3スプリント後には著しく劣化する可能性がある。
効果的な継続的コード品質監視には以下が含まれます。
- コミットごとのメトリック計算: サイクロマティック複雑度と静的解析の結果は、プッシュごとに計算されます
- トレンドダッシュボード: 主要指標の時系列表示（日次またはリリースごとに更新）
- CI/CDにおける品質ゲート保守性、セキュリティ、欠陥リスクに影響を与える指標の最小しきい値の自動適用
- 回帰検出：リリース間で指標が大きく誤った方向に動いた場合にアラートを発する
コード品質向上の先行指標、つまり次期リリースで品質が向上するか悪化するかを予測するシグナルは、カバレッジの傾向方向、スプリントごとに導入される新たな複雑性、そして解決されたコードスメルと新たに導入されたコードスメルの比率です。これらが正しい方向に動いている場合、品質は向上します。そうでない場合、品質の低下は完全に発生する前に予測可能です。
認定条件 SMART TS XL コード品質を測定し、改善する
SMART TS XL この記事で説明されているコード品質メトリクスの全セットを、開発環境のすべての言語とプラットフォーム (COBOL、JCL、Java、.NET、Python、JavaScript、TypeScript、RPG、SQL など) で計算します。ほとんどの品質ツールは一度に 1 つの言語で動作しますが、 SMART TS XL システム全体の統一された品質モデルを構築することで、言語間での品質比較、ファイルレベルではなくシステムレベルでのメトリクスの追跡、単一言語ツールでは検出できないコンポーネント間の品質問題の特定が可能になります。
大規模で多言語のコードベースを持つ企業組織にとって、 静的コード分析 の能力 SMART TS XL 技術デューデリジェンス、レガシーシステムの近代化計画、継続的な品質改善に必要な基準となる測定値を提供します。 依存関係マッピング この機能は、品質評価を構造的な懸念事項にまで拡張します。つまり、どのコンポーネントに最も依存しているか、どの変更が最も大きな影響を及ぼすか、そして品質指標と依存関係の中心性を組み合わせた場合に、コードベースのどの領域が最も高い保守リスクを示すか、といった点です。
SMART TS XLのコード品質メトリクスは、API を介して DevOps パイプラインと統合され、CI/CD レイヤーで品質ゲートを実現します。コミットによって循環的複雑度がしきい値を超える関数が導入された場合、カバレッジが設定された最小値を下回った場合、または重大な静的解析結果が検出された場合、パイプラインはビルドを失敗させ、開発者に何が測定され、なぜしきい値に達さなかったのかを正確に伝える特定の診断メッセージを表示できます。これにより、品質管理の実施がリリース後の監査から開発中のフィードバックへと移行し、修正コストが最も低い段階で品質問題を検出することで、コストを削減できます。
コード品質はチームで取り組むべきものであり、報告書ではない。
コード品質メトリクスの価値は、チームがそれらをどのように活用するかによって完全に決まります。誰も行動を起こさない四半期ごとのコード品質レポートは、レポートがないよりも悪いと言えます。なぜなら、コードベースが放置されたまま劣化しているにもかかわらず、品質が管理されているという錯覚を生み出すからです。メトリクスは、具体的な行動を促すときに価値を発揮します。例えば、新しい関数の循環的複雑性の急増が、その関数をマージする前にリファクタリングの議論を促したり、モジュールのカバレッジの低下がテストスプリントを促したり、特定のコンポーネントの欠陥密度の増加が、そのコンポーネントの設計の正式なレビューを促したりするような場合です。
そのような文化を構築するには、リリース後ではなく開発段階の適切なタイミングで指標を可視化し、それを具体的なチームのコミットメントと結びつける必要があります。スプリントごとの振り返りでコード品質の傾向をレビューし、完了の定義に品質の閾値を含め、指標の悪化を機能の悪化と同様に真剣に扱うチームは、保守コストが低く、本番環境でのインシデント発生件数も少ないコードベースを構築できます。測定は出発点であり、規律こそが結果を生み出すのです。
