ソースコード品質のメトリクス 〜メトリクスの活用戦略 DevOpsとマイクロサービス時代のQA〜
はじめに
5月22日にソースコード品質のメトリクス 〜メトリクスの活用戦略 DevOpsとマイクロサービス時代のQA〜という記事を書いたのですが、内容が薄かったのでアップデートします（笑）。
DevOpsとマイクロサービス時代のQA：高品質なソフトウェアを目指してという記事を執筆しました。この記事では、DevOpsおよびマイクロサービスにおける「品質が良い」という状態を定義しました。今回の記事では、メトリクスに焦点を当てて言及します。
品質向上はソフトウェア開発における永遠のテーマです。特に、DevOps文化とマイクロサービスアーキテクチャが普及している現代では、品質管理のアプローチも進化しています。本記事では、品質向上を目指す際に重要となるメトリクスに焦点を当て、DevOpsとマイクロサービス環境での適用方法について解説します。
PR
2024年6月12日から14日まで、出島メッセ長崎にてソフトウェア・シンポジウム2024が開催されます。シンポジウムの2日目と3日目には、今こそ考えたい！データを活用した品質改善戦略！と題したワーキンググループを主催いたします。品質改善にご興味のある方はぜひご参加ください！
本記事の目的
コード品質について、具体的なケーススタディを通じて、実践的な知見を共有します。この記事は、GQMモデルを用いてソースコード品質を評価・改善する方法を探求し、読者が自身のプロジェクトで同様の手法を適用できるように支援することを目的としています。
ソースコード品質のGQMモデル
GQMを使って整理します。
整理されたGQMは非常に明確で、具体的な目標達成に役立つと思います。
参考
ISO/IEC 25010 SQueRE 品質特性における保守性
ソースコードの品質は、品質特性における保守性に関連します。副特性ごとに目標・質問・メトリクスを整理します。
保守性の副特性
副特性は下記の5つです。リンク先に詳細な説明があります。
- モジュール性: ソフトウェアが独立したモジュールまたはコンポーネントに分割されている程度
- 再利用性: ソフトウェアのコンポーネントやモジュールが、異なるアプリケーションやプロジェクト間で共有され、再利用できるかを指す
- アナライザビリティ: ソフトウェアのコードや構造を理解し、問題を診断し、原因を特定するための労力を指す
- 変更性: ソフトウェアの柔軟性と適応性を測る指標
- テスト性: ソフトウェアのテスト計画の作成、テストケースの実行、およびテスト結果の評価が容易である程度
モジュール性のGQM
保守性の副特性：モジュール性のメトリクスをGQMに基づいて考えます。
目標（Goal）
- 目標: ソフトウェアのモジュール性を向上させ、保守性と再利用性を高める。
- 目的: システムの柔軟性を向上させ、変更や拡張を容易にし、開発効率を改善する。
- 範囲: 新規開発中のソフトウェアプロジェクト、または既存のソフトウェアシステム。
- 品質観点: ソフトウェアアーキテクチャ、コード構造、コンポーネント設計。
質問（Question）
- 質問1: ソフトウェアはどの程度モジュール化されているか？
- 質問2: 各モジュールの独立性はどの程度保たれているか？
- 質問3: モジュール間の結合度はどの程度低いか？
- 質問4: モジュールの再利用性はどの程度高いか？
- 質問5: モジュールの変更が他のモジュールに与える影響はどの程度制限されているか？
メトリクス（Metric）
- メトリクス1: モジュール数 - システムを構成する独立したモジュールの総数。
- メトリクス2: 結合度（Coupling） - モジュール間の相互依存の度合いを測定するメトリクス。
- メトリクス3: 凝集度（Cohesion） - モジュール内の要素がどれだけ機能的に関連しているかを測定するメトリクス。
- メトリクス4: 再利用率 - 他のプロジェクトやモジュールで再利用されているコードの割合。
- メトリクス5: 変更伝播度（Change Propagation） - あるモジュールの変更が他のモジュールにどれだけ影響を与えるかを測定するメトリクス。
ただし、これらをすべて集計するのは予算・リソース・運用的に困難な場合が想定されるので、ある程度絞ります。
ソースコードの重複度（Duplications Lines, Duplicated Blocks）を計測することで、結合度と凝集度と再利用率が「ある程度」測れると考えます。
また、結果的にモジュール性の良さは開発効率として効果が現れるはずなのでFour Keysの生産性をメトリクスとします。
課題
- 結合度・凝集度・変更伝播度に関しては、SonarQubdeだけでは正確に測れないので、プラグインなどを検討する。ただし、優先度は低いです。
再利用性のGQM
保守性の副特性：再利用性のメトリクスをGQMに基づいて考えます。
目標（Goal）
- 目標: ソフトウェアの再利用性を向上させ、開発効率と品質を高める。
- 目的: コードの再利用を促進し、開発コストの削減と迅速な市場投入を実現する。
- 範囲: 新規および既存のソフトウェアプロジェクト。
- 品質観点: コードの汎用性、モジュール化、およびコンポーネントの独立性。
質問（Question）
- 質問1: ソフトウェアのどのコンポーネントが再利用可能か？
- 質問2: 再利用可能なコンポーネントの品質はどの程度か？
- 質問3: 再利用による開発時間の削減はどの程度か？
- 質問4: 再利用コンポーネントのメンテナンスはどの程度容易か？
- 質問5: 再利用コンポーネントの統合における技術的な障壁は何か？
メトリクス（Metric）
- メトリクス1: 再利用コンポーネント数 - 再利用されているコンポーネントの総数。
- メトリクス2: 再利用率 - プロジェクト全体のコードのうち、再利用されている割合。
- メトリクス3: 開発時間削減率 - 再利用によって削減された開発時間の割合。
- メトリクス4: バグ率 - 再利用コンポーネントにおけるバグの発生率。
- メトリクス5: 統合労力 - 再利用コンポーネントを新しいプロジェクトに統合するために必要な労力。
ただし、これらをすべて集計するのは予算・リソース・運用的に困難な場合が想定されるので、ある程度絞ります。
メトリクス: 再利用率
- SonarQubeはコードの重複度（Duplicated Lines）を測定しますが、これは再利用率とは異なる概念です。再利用率を正確に測定するには、プロジェクト間で共有されているコードの追跡が必要です。
- ですが、重複度が低い＝再利用率が高いと捉えます。
メトリクス: 開発時間削減率
- Four Keysのデプロイ頻度・変更リードタイムで間接的に測定します。
メトリクス: バグ率
- SonarQubeはコードのバグを検出する機能を提供しており（Bugs）、再利用コンポーネントにおけるバグの発生率を測定するために使用できます。
課題
再利用コンポーネント数はSonarQubeで取得できないので、検討が必要です。また、再利用率は直接的な指標ではないのでどのような相関があるかを検討する必要があります。
メトリクスが多いと実際の運用が難しくなるので、可能な限りシンプルにしたいと考えており、上記としました。
アナライザビリティのGQM
保守性の副特性としてのアナライザビリティに関するメトリクスをGQMに基づいて検討します。
目標（Goal）
- 目標: ソフトウェアのアナライザビリティを向上させ、問題の特定と修正を迅速かつ効率的に行えるようにします。
- 目的: システムの理解を深め、保守作業の効率を高めることで、全体的な開発サイクルを短縮します。
- 範囲: 新規および既存のソフトウェアプロジェクト。
- 品質観点: コードの可読性、ドキュメントの完全性、アーキテクチャの明確性。
質問（Question）
- 質問1: ソフトウェアのコードやアーキテクチャを理解するのにどの程度の労力が必要ですか？
- 質問2: 問題の原因を特定するために必要な時間はどの程度ですか？
- 質問3: システムのどの部分が最も理解しにくいですか？
- 質問4: 静的解析ツールは問題の特定にどの程度役立っていますか？
- 質問5: ドキュメントは十分に整備されており、問題解決を支援していますか？
メトリクス（Metric）
- メトリクス1: コードの複雑度 - サイクロマティック複雑度をSonarQubeで取得します。
- メトリクス2: 問題特定までの時間 - バグや障害が報告されてから原因が特定されるまでの平均時間。これはFour Keysのリードタイムで測定します。
- メトリクス3: コードの可読性 - コードの構造、命名規則、コメントの有無などに基づく評価。これはSonarQubeのBugsやCode Smellsの値で評価できます。
- メトリクス4: 静的解析ツールの警告数 - コードの品質問題を指摘する静的解析ツールの警告の数。これはSonarQubeのBugsやCode Smellsの値で評価できます。
- メトリクス5: ドキュメントの完全性 - ドキュメントのカバレッジや更新頻度、利用者のフィードバックに基づく評価。
課題
SonarQubeとFour Keysを用いて多くのメトリクスを取得できますが、ドキュメントの完全性に関しては別途検討が必要です。また、コードの可読性や静的解析ツールの警告数はSonarQubeで評価可能ですが、これらのメトリクスがアナライザビリティに与える影響を正確に理解するためには、さらなる分析が必要になる場合があります。
変更性のGQM
保守性の副特性としての変更性に関するメトリクスをGQMに基づいて検討します。
目標（Goal）
- 目標: ソフトウェアの変更性を向上させ、新しい要件への適応や既存機能の改善を迅速かつ効率的に行えるようにする。
- 目的: システムの柔軟性を高め、継続的な改善と市場の変化への迅速な対応を可能にする。
- 範囲: 新規および既存のソフトウェアプロジェクト。
- 品質観点: コードのモジュール性、結合度、テスト容易性、ドキュメントの完全性。
質問（Question）
- 質問1: 新しい要件を実装するために必要な労力はどの程度か？
- 質問2: 既存のコードを変更する際のリスクはどの程度か？
- 質問3: システムのどの部分が変更に対して最も脆弱か？
- 質問4: 変更による影響範囲をどの程度正確に予測できるか？
- 質問5: ドキュメントは変更の実施を支援するために十分な情報を提供しているか？
メトリクス（Metric）
- メトリクス1: 変更に必要な時間 - 新しい要件や機能の実装にかかる平均時間。Four Keysの「変更リードタイム」で間接的に測定する。
- メトリクス2: リグレッション発生率 - 変更後に発生するリグレッションバグの割合。Four Keysの「変更失敗率」で間接的に測定する。
- メトリクス3: コードの結合度 - モジュール間の依存関係の度合いを示すメトリクス。
- メトリクス4: 変更影響分析の正確性 - 変更による影響範囲の予測と実際の影響との一致度。
- メトリクス5: ドキュメントの更新頻度と完全性 - ドキュメントが最新の状態に保たれているか、および変更に関連する情報がどれだけ詳細に記載されているか。
課題
「コードの結合度」「変更影響分析の正確性」「ドキュメントの更新頻度と完全性」はSonarQubeやFour Keysでは直接取得できないので検討します。
テスト性のGQM
保守性の副特性としてのテスト性に関するメトリクスをGQMに基づいて検討します。
目標（Goal）
- 目標: ソフトウェアのテスト性を向上させ、効率的かつ効果的なテストプロセスを実現する。
- 目的: テストの自動化を促進し、バグの早期発見と修正を可能にすることで、ソフトウェアの品質を高める。
- 範囲: 新規および既存のソフトウェアプロジェクト。
- 品質観点: テストカバレッジ、テストの自動化、テストケースの維持管理、テストデータの準備。
質問（Question）
- 質問1: ソフトウェアのテストカバレッジはどの程度か？
- 質問2: テストケースの作成と実行にかかる労力はどの程度か？
- 質問3: テストプロセスの自動化はどの程度進んでいるか？
- 質問4: テストデータの準備は容易か？
- 質問5: テスト結果の分析とフィードバックのプロセスは効率的か？
メトリクス（Metric）
- メトリクス1: テストカバレッジ - コードのどの程度がテストによってカバーされているかを示す割合。SonarQubeで取得できます。
- メトリクス2: テストケース作成時間 - 新しいテストケースを作成するのに必要な平均時間。
- メトリクス3: テスト自動化率 - テストケースのうち自動化されている割合。テストカバレッジが間接的なメトリクスになります。ブラックボックステストについては別で検討します。
- メトリクス4: テストデータ準備の労力 - 適切なテストデータを準備するのに必要な時間や労力。
- メトリクス5: テストフィードバックサイクル時間 - テスト結果を分析し、フィードバックを開発チームに提供するまでの時間。
課題
テストケース作成時間、テストデータ準備、テストフィードバックサイクル時間はSonarQube以外のツールの検討が必要ですが、テストカバレッジを測定可能です。
ISO/IEC 25010 SQuaREの保守性の副特性に基づいたソースコード品質の目標（Goal）
総合的な目標（Goal）
- 目標: ソフトウェアの保守性を向上させ、モジュール性、再利用性、アナライザビリティ、変更性、およびテスト性を高める。
- 目的: システムの柔軟性と理解を深め、新しい要件への適応、既存機能の改善、問題の特定と修正を迅速かつ効率的に行い、開発効率とソフトウェア品質を全体的に改善する。
- 範囲: 新規および既存のソフトウェアプロジェクトにおけるソースコードの品質向上。
- 品質観点: ソフトウェアアーキテクチャの明確性、コード構造のモジュール化、コンポーネントの独立性、可読性、テストカバレッジ、自動化の進捗、ドキュメントの完全性、およびメンテナンスの容易性。
以下は、ISO/IEC 25010 SQuaREの保守性の副特性に基づいたソースコード品質の質問（Question）をコンパクトにまとめたものです。
総合的な質問（Question）
- 質問1: ソフトウェアの構造はどの程度明確で、コンポーネントはどの程度独立しているか？
- 質問2: システムの各部分の理解しやすさ、再利用性、および変更の容易さはどの程度か？
- 質問3: 新しい要件や機能の実装、および既存機能の改善に必要な労力とリスクはどの程度か？
- 質問4: テストプロセスはどの程度効率的で、自動化されているか？また、テストカバレッジは十分か？
- 質問5: ドキュメントは最新かつ完全で、開発とテストの両方を支援するために十分な情報を提供しているか？
総合的なメトリクス（Metric）
- メトリクス1: システム構成 - システムを構成する独立したモジュールや再利用コンポーネントの総数。
- メトリクス2: コード品質 - 結合度、凝集度、再利用率、バグ率、および静的解析ツールの警告数を含むコードの品質指標。
- メトリクス3: 効率性 - 新しい要件や機能の実装、テストケースの作成、およびテストデータの準備にかかる時間や労力。
- メトリクス4: プロセス効率 - 変更リードタイム、リグレッション発生率、テストフィードバックサイクル時間を含む開発プロセスの効率性。
- メトリクス5: ドキュメントとフィードバック - ドキュメントの更新頻度と完全性、およびテスト結果からのフィードバックの迅速性。
SonarQubeやFour Keysを利用したメトリクスの取得
システム構成（メトリクス1）
- SonarQube: プロジェクト内のファイル数やディレクトリ数を通じて、モジュールやコンポーネントの数を推定することができます。ただし、再利用コンポーネントの総数を直接測定する機能は提供していません。
コード品質（メトリクス2）
- SonarQube: コードの品質指標として、バグ数、コードスメル数、脆弱性数、および重複度（Duplicated Lines）などのメトリクスを提供します。結合度や凝集度は直接測定されませんが、関連するメトリクスとしてコードの複雑度（Cyclomatic Complexity）などが利用できます。
効率性（メトリクス3）
- Four Keys: 「変更リードタイム」を測定して、新しい要件や機能の実装にかかる時間を間接的に評価します。テストケース作成時間やテストデータ準備に関しては、Four Keysでは直接測定されませんが、プロジェクト管理ツールや時間追跡システムを使用して測定することができます。
プロセス効率（メトリクス4）
- Four Keys: 「変更リードタイム」と「変更失敗率」を測定して、開発プロセスの効率性を評価します。これにより、変更に必要な時間とリグレッション発生率を間接的に測定することができます。
ドキュメントとフィードバック（メトリクス5）
- SonarQube: ドキュメントの完全性を直接測定する機能は提供していませんが、コードのコメント量を通じてドキュメントの一部を評価することができます。
- Four Keys: テストフィードバックサイクル時間は、CI/CDパイプラインのデータを利用して測定することができます。これにより、テスト結果からのフィードバックの迅速性を評価することができます。
総合的な課題
- ツールの制限: SonarQubeは結合度、凝集度、変更伝播度などの特定のメトリクスを直接測定する機能を提供していないため、これらのメトリクスについてはプラグインの利用や他のツールへの検討が必要です。
- 再利用性の評価: 再利用コンポーネント数の取得や再利用率の正確な測定には、SonarQubeだけでは不十分であり、プロジェクト間で共有されているコードの追跡や相関関係の分析が必要です。
- ドキュメントとフィードバック: ドキュメントの完全性やテストフィードバックサイクル時間はSonarQubeやFour Keysでは測定できないため、ドキュメント管理システムやプロジェクト管理ツールの利用が必要です。
- メトリクスの運用: メトリクスが多すぎると運用が難しくなるため、実際のプロジェクトにおいては、必要なメトリクスを選定し、シンプルなセットに絞ることが重要です。
- 影響の理解: コードの可読性や静的解析ツールの警告数など、SonarQubeで測定可能なメトリクスが保守性に与える影響を正確に理解するためには、追加の分析が必要になる場合があります。
改善活動
このGQMモデルに基づいて、ソースコードの品質改善に向けた具体的な活動を実施することができます。
改善活動の提案
-
ツールとプロセスの統合:
- SonarQubeとFour Keysのデータを統合し、ソフトウェアの品質指標を一元的に管理するダッシュボードを構築します。
- 結合度や凝集度などのメトリクスを測定するために、SonarQubeのプラグインエコシステムを活用するか、専門的な設計解析ツールを導入します。
-
再利用性の促進:
- コードベースを定期的にレビューし、再利用可能なコンポーネントを特定してカタログ化します。
- プロジェクト間で共有されるライブラリやフレームワークの使用を標準化し、再利用を容易にします。
-
ドキュメントの改善:
- ドキュメントの完全性とアクセシビリティを向上させるために、ドキュメント管理システムを導入または最適化します。
- 開発プロセスにドキュメントの更新を組み込み、変更ごとにドキュメントを維持管理する文化を育成します。
-
テストプロセスの最適化:
- テストカバレッジを向上させるために、テストケースの作成とメンテナンスを定期的にレビューします。
- テスト自動化を推進し、CI/CDパイプラインに統合することで、テストフィードバックサイクルを短縮します。
-
メトリクスの選定と運用:
- プロジェクトの目標と制約に基づいて、最も影響力のあるメトリクスを選定し、運用をシンプルに保ちます。
- メトリクスの結果を定期的にレビューし、品質改善のためのアクションプランを策定します。
-
教育とコミュニケーション:
- 開発チームに対して、ソフトウェアの品質特性と保守性の重要性についてのトレーニングを実施します。
- チーム間のコミュニケーションを促進し、品質改善のためのアイデアやベストプラクティスを共有します。
Discussion