テクニカルデットの定量化：CodeClimate・SonarQubeによる可視化手法

COLUMN コラム

2025年03月03日
テクニカルデットの定量化：CodeClimate・SonarQubeによる可視化手法
- ＩＴ系

テクニカルデットを「見える化」する重要性

ソフトウェア開発の現場で「技術的負債（テクニカルデット）」という言葉を聞かない日はないでしょう。しかし、多くのチームが「負債があります」と感覚的に認識しながらも、その深刻度を定量的に把握できていないのが実情です。私自身、過去に携わった複数のプロジェクトで、テクニカルデットの蓄積がリリース速度の低下やバグ率の上昇として表面化するまで放置されるケースを何度も見てきました。

テクニカルデットの定量化は、経営層への説明やリファクタリングの優先順位付けにおいて極めて重要です。「このモジュールの複雑度が閾値を超えており、修正に推定40時間かかる」と言えれば、改善施策の承認を得やすくなります。本記事では、業界で広く使われているCodeClimateとSonarQubeを用いた可視化手法を実践的に解説します。

SonarQubeによる静的解析と負債の可視化

SonarQubeのセットアップ

SonarQubeはオープンソースのコード品質管理プラットフォームで、コードの複雑度、重複率、セキュリティ脆弱性、テクニカルデットの推定工数を一元的に管理できます。まずはDockerを使った環境構築から始めましょう。

version: '3'
services:
  sonarqube:
    image: sonarqube:community
    ports:
      - "9000:9000"
    environment:
      - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonar
      - SONAR_JDBC_USERNAME=sonar
      - SONAR_JDBC_PASSWORD=sonar
    volumes:
      - sonarqube_data:/opt/sonarqube/data
  db:
    image: postgres:15
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
      - POSTGRES_DB=sonar
    volumes:
      - postgresql_data:/var/lib/postgresql/data
volumes:
  sonarqube_data:
  postgresql_data:

プロジェクトのスキャン実行

SonarScannerを使ってプロジェクトを解析します。CI/CDパイプラインに組み込む場合は以下のように設定します。

# sonar-project.properties
sonar.projectKey=my-project
sonar.projectName=My Project
sonar.sources=src
sonar.tests=tests
sonar.language=java
sonar.java.binaries=target/classes
sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

# 品質ゲートのカスタム閾値
sonar.qualitygate.wait=true

# GitHub Actionsでの実行例
name: SonarQube Analysis
on: [push, pull_request]
jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: SonarQube Scan
        uses: sonarsource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

SonarQubeのダッシュボードでは、テクニカルデットが「推定修正時間」として表示されます。例えば「5d 3h」のように、負債を解消するために必要な工数が一目でわかる。これはSQALE（Software Quality Assessment based on Lifecycle Expectations）というモデルに基づいています。

CodeClimateによるメンテナビリティスコアの活用

CodeClimateの特徴

CodeClimateはSaaS型のコード品質分析ツールで、特にメンテナビリティスコア（A〜F評価）が直感的にわかりやすい。GitHubとの連携が容易で、PRごとに品質チェックを自動実行できるのが強みです。

# .codeclimate.yml
version: "2"
checks:
  argument-count:
    enabled: true
    config:
      threshold: 4
  complex-logic:
    enabled: true
    config:
      threshold: 4
  file-lines:
    enabled: true
    config:
      threshold: 300
  method-complexity:
    enabled: true
    config:
      threshold: 10
  method-count:
    enabled: true
    config:
      threshold: 15
  method-lines:
    enabled: true
    config:
      threshold: 30
  return-statements:
    enabled: true
    config:
      threshold: 4
plugins:
  eslint:
    enabled: true
  duplication:
    enabled: true
    config:
      languages:
        javascript:
          mass_threshold: 50

実践的な閾値の設定

筆者の経験上、デフォルトの閾値は厳しすぎる場合が多い。チームの状況に合わせて段階的に厳格化していくのが現実的なアプローチだ。まずは現状のスコアを基準として、四半期ごとに改善目標を設定するとよい。

両ツールの比較と使い分け

SonarQubeとCodeClimateはそれぞれ異なる強みを持っています。SonarQubeはセルフホストが可能でセキュリティルールが充実しているため、エンタープライズ環境やセキュリティ要件が厳しいプロジェクトに適しています。一方、CodeClimateはセットアップが簡単でGitHub連携が優秀なため、スタートアップやOSSプロジェクトとの相性が良い。

実際のプロジェクトでは、両方を併用するケースも少なくない。SonarQubeでセキュリティとバグの検出を行い、CodeClimateでメンテナビリティの監視を行うという棲み分けだ。

テクニカルデット管理を組織に定着させるために

メトリクスの定期レビュー

ツールを導入しただけでは意味がない。スプリントレトロスペクティブでテクニカルデットのトレンドを確認し、増加傾向にあれば対策を講じる仕組みが必要です。具体的には、以下の指標を週次で追跡することを推奨します。

テクニカルデット比率（負債の推定工数 / 開発工数）が5%以下を目標とします

新規コードのコードカバレッジが80%以上を維持する

Cognitive Complexityの平均値が前週比で増加していないことを確認する

重複コード率が3%以下を維持する

品質ゲートによる自動ブロック

最も効果的なのは、品質基準を満たさないコードのマージを自動的にブロックする仕組みだ。SonarQubeの品質ゲートやCodeClimateのPRチェックを活用し、チーム全体で品質基準を守る文化を醸成しましょう。

# SonarQube品質ゲートのAPI確認例
curl -u admin:token "http://localhost:9000/api/qualitygates/project_status?projectKey=my-project" | jq '.projectStatus.status'

テクニカルデットの定量化は、開発チームの健全性を測る重要なバロメーターだ。感覚ではなくデータに基づいた意思決定を行うことで、持続可能な開発速度を維持できます。まずは小さく始めて、チームに合った運用方法を見つけていただきたい。