コード品質分析
コード品質分析についてご紹介します🙋
機能概要
コード品質分析は、エンジニアリングマネージャーやチームリーダーが、チームが保守しているコードベースの品質状況を定量的に把握し、改善の意思決定をするのに役立ちます。
ソースコードを静的解析し、複雑度・保守性・サイズなどの観点からファイル単位・リポジトリ単位の品質スコアを算出して可視化します。属人的になりがちな「このコードは読みづらい」「ここは将来怖い」といった感覚を、共通の数値指標として議論できるようにします。
以下は、コード品質分析がどのような課題に対して効果を発揮するかを整理した一覧です。
| 課題 | この機能がどう解決するか |
|---|---|
| コードの品質状況を客観的に把握できていない | 循環的複雑度・認知的複雑度・保守性指数などをファイル/リポジトリ単位で可視化し、共通の指標で議論できるようにします |
| 技術的負債が積み上がっているが、どこから手をつければよいか分からない | 品質スコアが低いファイル・複雑度が高いファイルを特定し、改善対象に優先順位を付けられます |
| コード品質の改善活動の効果を説明しにくい | 品質スコアの推移を継続的に追跡することで、リファクタリングや改善施策の成果を定量的に示せます |
| 新しくジョインしたメンバーがどのファイルが読みにくいか分からない | 認知的複雑度や保守性指数から、レビュー時に重点的に説明すべきファイルを事前に把握できます |
| プロダクトや経営層に対してリファクタリング工数の確保を説明しにくい | スコアの低いコードが多いリポジトリを示し、改善投資の必要性を客観的なデータで議論できるようになります |
注意事項
- 現在はβ版として提供しており、今後さらに機能改善・拡張を予定しています。
- 対応しているコード管理ツールは GitHub Cloud 版のみです。
- Personal Access Token（PAT）による接続は未対応です。
- 解析処理は1日1回のバッチで実行されます。設定変更や新しいコミットの反映は翌日以降になります。
- アーカイブされたリポジトリは解析対象に含まれません。
ご利用に必要な設定
- Findy Team+ の管理者ユーザーが「コード品質設定」画面から機能を有効化する必要があります。
- 詳細は下記の「必要な設定」のセクションをご参照ください。
対象プラン
以下のプランを対象に機能提供しています。
- Enterpriseプラン
- Advancedプラン
※今後、機能提供の方法を変更する可能性がございます。
対象ロール
以下のロールを対象に機能提供しています。
- 管理者
- マネージャー
- スタッフ
対応言語
以下の言語のソースファイルが解析対象です。
| 言語 | 拡張子 |
|---|---|
| TypeScript | .ts, .tsx |
| JavaScript | .js, .jsx |
| Ruby | .rb |
| Python | .py |
| Go | .go |
| Java | .java |
| C++ | .cpp, .cc, .cxx, .hpp, .hh, .hxx |
| PHP | .php, .phtml |
なお、以下のファイル・ディレクトリは自動的に解析対象から除外されます。
- テストファイル（
*.spec.*/*.test.*など） - テスト慣習ディレクトリ（
__tests__,__mocks__,__fixtures__,testdataのみ） - 依存パッケージ・ビルド成果物ディレクトリ（
node_modules,vendor,dist,build,coverageなど） - VCS / IDE 関連ディレクトリ（
.git,.idea,.vscodeなど）
これらに加えて、任意のファイル・ディレクトリを除外したい場合は、次の「解析対象ファイルの除外設定（.teamplusignore）」をご参照ください。
解析対象ファイルの除外設定（.teamplusignore）
自動生成されたコードや実験用のコードなど、品質改善の対象外としたいファイルを解析対象から除外できます。
解析対象リポジトリのルート（デフォルトブランチ）に .teamplusignore という名前のファイルを作成し、除外したいパスを .gitignore と同じ構文で記述してください。
# 自動生成コード
generated/
**/*.gen.ts
# 実験用コード
sandbox/
除外設定をコードと同じリポジトリで管理できるため、変更履歴も Git に残ります。
記述ルール
#から始まる行はコメントとして扱われます。- パターンはリポジトリのルートからの相対パスに対して評価されます。
- ファイルサイズの上限は 1MB です。上限を超えると、そのリポジトリの解析はエラーとなります。
注意事項
.teamplusignoreは「自動的に解析対象から除外されるファイル・ディレクトリ」への追加の除外としてのみ機能します。!による否定パターンは.teamplusignore内に記述した他のパターンの打ち消しにのみ使用でき、テストファイルやnode_modulesなどの自動除外を解析対象に戻すことはできません。- 除外に一致したディレクトリは配下がすべて解析対象外となるため、除外ディレクトリ配下の一部ファイルだけを否定パターンで解析対象に戻すことはできません。
.teamplusignoreの追加・変更・削除は、翌日のバッチ処理実行後に解析結果へ反映されます。パターンを削除（またはファイル自体を削除）した場合は、除外されていたファイルが再び解析対象に戻ります。
必要な設定
コード品質分析を利用するには、以下の2つのステップが必要です。
1. 設定画面から機能を有効化する
Findy Team+ の管理者ユーザーが、コード品質設定画面からコード品質分析機能を有効にする必要があります。
この機能ではソースコードに対して解析処理を行うため、管理者による明示的な確認が求められます。
※ ソースコードは保存されることはなく、処理完了後すぐに削除されます。データの取り扱いに関する詳細は、Findy Team+ のカスタマーサクセス担当までお問い合わせください。
2. 対象リポジトリを設定する
解析対象とするリポジトリを選択してください。
解析対象ブランチはカスタマイズできず、各リポジトリの GitHub 上のデフォルトブランチが対象になります。デフォルトブランチの最新コミット（HEAD）の状態に対して解析が行われます。
注意事項
- 解析対象リポジトリの変更内容は、翌日のバッチ処理実行後に解析結果へ反映されます。
- アーカイブされたリポジトリは解析対象に含まれません。
画面の見方
コード品質分析画面には2つのタブがあります。
リポジトリ一覧タブ
解析対象リポジトリ全体の品質サマリーを一覧表示します。
| カラム | 説明 |
|---|---|
| リポジトリ | リポジトリ名 |
| 平均品質スコア | リポジトリ内の各ファイルの品質スコアの平均（0〜100、高いほど高品質） |
| 最大ネスト深度 | リポジトリ内のファイルの最大ネスト深度のうち最も大きい値 |
| 平均保守性指数 | リポジトリ内の各ファイルの保守性指数の平均 |
| 平均認知的複雑度 | リポジトリ内の各ファイルの認知的複雑度の平均 |
| 平均循環的複雑度 | リポジトリ内の各ファイルの循環的複雑度の平均 |
リポジトリ単位で品質状況を俯瞰し、どのリポジトリから改善に取り組むかの優先順位付けに活用します。
ファイル一覧タブ
リポジトリを選択して、配下のファイル単位での品質メトリクスを一覧表示します。
| カラム | 説明 |
|---|---|
| ファイル | リポジトリルートからのファイルパス |
| 品質スコア | ファイル単位の総合品質スコア（0〜100、高いほど高品質） |
| 最大ネスト深度 | ファイル内の最大ネスト深度 |
| 保守性指数 | ファイルの保守性指数（0〜100、高いほど保守しやすい） |
| 認知的複雑度 | ファイル全体の認知的複雑度の合計 |
| 循環的複雑度 | ファイル全体の循環的複雑度の合計 |
| 実コード行数（SLOC） | コメント・空行を除いた実コード行数 |
| 関数定義数 | ファイル内の関数・メソッド定義数 |
| 改善優先度 | 品質スコアの低さと直近90日間の変更頻度をもとにした、リポジトリ内での改善の優先順位（0〜100 のパーセンタイル。100に近いほど優先度が高い。90日以上変更のないファイルは空欄） |
| 変更回数 | 直近90日間のコミット回数（変更頻度の目安） |
| 最終コミット日時 | 直近90日間で最後にコミットされた日時（90日以上変更のないファイルは空欄） |
改善優先度・変更回数・最終コミット日時は、ファイルの Git 更新履歴（直近90日間）をもとにした指標です。算出仕様は「指標定義と解釈」セクション内の「Git 更新情報」をご参照ください。
ファイル一覧では、表示する列を絞り込めます。Git 更新情報のうちデフォルトで表示されるのは改善優先度のみで、変更回数・最終コミット日時は列の表示切り替えから表示できます。
スコアが低いファイル・複雑度が高いファイル、または改善優先度が高いファイルにソートすることで、改善対象のファイルを効率的に特定できます。
指標定義と解釈
品質スコア（0〜100）
ファイルの各メトリクスを「複雑度」「サイズ」「保守性」の3カテゴリに分類し、各カテゴリのサブスコアを重み付き合計して算出する 0〜100 の整数値です。値が高いほど高品質を示します。
| カテゴリ | 構成メトリクス |
|---|---|
| 複雑度 | 循環的複雑度 / 認知的複雑度 / 最大ネスト深度 |
| サイズ | 実コード行数（SLOC） / 関数定義数 |
| 保守性 | 保守性指数 |
平均品質スコアのランク（Elite / High / Medium / Low）
平均品質スコアは、その値に応じて以下の4段階のランクに分類されます。
| ランク | スコア範囲 |
|---|---|
| Elite | 90以上 |
| High | 80〜89 |
| Medium | 65〜79 |
| Low | 65未満 |
循環的複雑度（Cyclomatic Complexity）
McCabe の循環的複雑度。ファイル内の条件分岐・ループ・例外処理の数に基づき、コード内の独立した実行パスの本数を数えた指標です。値が大きいほど、テストでカバーすべきパスが増え、バグの混入リスクや理解の難易度が上がります。
認知的複雑度（Cognitive Complexity）
SonarSource 方式の認知的複雑度。「人間がコードを読むときに、どれだけ脳に負荷がかかるか」を測る指標です。ネストの深さや制御フローの中断（早期 return、break、continue 等）を加味して算出されます。値が大きいほど、レビューや改修の際に理解しづらいコードであることを示します。
保守性指数（Maintainability Index）
Microsoft の保守性指数をベースにしています。実コード行数（SLOC）と循環的複雑度をもとに算出する 0〜100 の指標で、値が高いほど保守しやすいことを示します。実コード行数が多く、循環的複雑度が高いファイルほど値が低くなります。
最大ネスト深度（Max Nesting Depth）
ファイル内の制御構造（if / for / while / try など）が最も深くネストしている部分の深さ。深いネストは可読性を著しく下げるため、リファクタリングの目印になります。
関数定義数 / 実コード行数（SLOC）
- 関数定義数：ファイル内の関数・メソッド定義の数
- 実コード行数（SLOC）：コメント・空行を除いた実質的なコード行数
ファイルあたりの責務が大きすぎないかを判断する材料になります。
スコア算出の目安となる閾値
各メトリクスは以下の閾値を基準に正規化されます。値が閾値を下回る（保守性指数は上回る）ファイルは「良好」、それを超えるファイルから段階的にスコアが下がっていきます。
なお、行数系の指標は実コード行数（SLOC）のみで評価します。コメント・空行の行数はスコアに計上されません。
複雑度
| メトリクス | 良好 | 注意 |
|---|---|---|
| 循環的複雑度 | ≤10 | ≤15 |
| 認知的複雑度 | ≤15 | ≤25 |
| 最大ネスト深度 | ≤3 | ≤4 |
サイズ
| メトリクス | 良好 | 注意 |
|---|---|---|
| 実コード行数（SLOC） | ≤240 | ≤400 |
| 関数定義数 | ≤15 | ≤25 |
保守性
| メトリクス | 良好 | 注意 |
|---|---|---|
| 保守性指数 | ≥70 | ≥50 |
Git 更新情報（改善優先度・変更回数・最終コミット日時）
ファイル一覧タブでは、静的解析による品質メトリクスに加えて、ファイルごとの Git 更新履歴をもとにした3つの指標を確認できます。いずれも直近90日間のコミット履歴（マージコミットを除く）を対象に集計します。
改善優先度（Improvement Priority）
品質スコアの低さと直近90日間の変更頻度（変更回数）をもとに、リポジトリ内での改善の優先順位を0〜100 のパーセンタイルで表した指標です。100 に近いほど「品質が低く、かつ頻繁に変更されている」＝いま改善に着手する価値が高いファイルであることを示し、母集団の中で最も優先度が高いファイルが 100 になります。
- 母集団は同じリポジトリ内で直近90日間に変更のあったファイル（変更回数が 1 以上）のみです。直近90日間に変更のないファイルは対象外となり、値は空欄で表示されます。
- 値はリポジトリ内での相対順位のため、異なるリポジトリ間では直接比較できません。
パーセンタイル表示のため、1つの値だけでも母集団の中での優先度の高低を判断できます。頻繁に変更されている低品質なファイルほど値が高くなるため、日々手を入れているコードから優先的に改善したい場合の目印として活用できます。
変更回数（Change Count）
直近90日間に、そのファイルへ加えられたコミットの回数です。変更頻度の目安になります。
最終コミット日時（Last Commit Datetime）
直近90日間で、そのファイルが最後にコミットされた日時です。この期間に変更のないファイルは値がなく、空欄で表示されます。
注意事項
- これらの指標は、他の品質メトリクスと同様に1日1回のバッチで更新されます。反映は翌日以降になります。
- 集計対象は直近90日間のコミット履歴です。90日より前の変更は集計に含まれません。
- マージコミットは集計対象から除外します。
- 直近90日間に変更のないファイルは、変更回数が 0、最終コミット日時が空欄になり、改善優先度はパーセンタイルの母集団の対象外として空欄になります。
コード品質分析の読み解き方
品質スコアは絶対評価の基準ではなく、チーム内・リポジトリ間の相対比較と、時系列での変化の追跡に活用するのが効果的です。
改善対象を特定する
- リポジトリ一覧タブで平均品質スコアが低いリポジトリ、平均複雑度が高いリポジトリを特定します。
- 次にファイル一覧タブでスコアの低い順にソートし、特に改善効果が大きいと思われるファイルを抽出します。
- 認知的複雑度・最大ネスト深度が突出して大きいファイルは、リファクタリングの優先候補です。
- 改善優先度の降順にソートすると、「品質が低く、かつ頻繁に変更されている」ファイルが上位に来ます。限られた工数で効果を出したい場合の起点として有効です。
改善の効果を測定する
- リファクタリング後に対象ファイルの品質スコア・複雑度がどう変化したかを確認します。
- 継続的にスコアの推移を追うことで、改善活動が一過性で終わっていないか・新しく書かれているコードの品質が保たれているかを確認できます。
スコアだけで判断しないこと
品質スコアは静的解析に基づく機械的な指標であり、コードの意図やビジネス的な妥当性は反映しません。スコアが低くても合理的な理由があるコードは存在しますし、スコアが高くても設計上の問題を抱えているコードもあります。
スコアはあくまで「ここを見ると改善余地があるかもしれない」という会話のきっかけとして活用し、最終的な判断はチームでのコードレビューに委ねてください。
よくある質問
1. GitHub以外のGitサービスにも対応していますか？
現在はGitHub Cloudのみ対応しています。GitLab、Bitbucketなどの対応については、今後の検討課題です。
2. 解析結果がいつ反映されますか？
解析処理は1日1回のバッチで実行されます。設定変更・新しいコミットの解析結果は、翌日以降に画面へ反映されます。
3. コード品質分析にデータが表示されない場合は、以下の点をご確認ください。
- 解析処理は定期実行されるため、設定が正しいことを確認し翌日以降に画面を確認してください。
- 対応言語のソースファイルがリポジトリに含まれているかをご確認ください。
- アーカイブされたリポジトリは解析対象に含まれません。
4. 解析対象とならないファイルはありますか？
対応言語以外のファイルや、テストファイル・依存パッケージ・ビルド成果物などのディレクトリは解析対象から除外されます。詳細は「対応言語」のセクションをご参照ください。
5. 自動生成コードなど、特定のファイルを解析対象から除外できますか？
はい、リポジトリのルートに .teamplusignore ファイルを置くことで、任意のファイル・ディレクトリを解析対象から除外できます。詳細は「解析対象ファイルの除外設定（.teamplusignore）」のセクションをご参照ください。
6. 品質スコアの値は何を意味しますか？
ファイルの「複雑度」「サイズ」「保守性」の各カテゴリのサブスコアを重み付き合計した 0〜100 の整数値です。値が高いほど高品質であることを示します。詳細は「指標定義と解釈」の章をご参照ください。
7. ソースコードは保管されますか？
いいえ、解析処理のために一時的にリポジトリをクローンしますが、解析処理完了後すぐに削除されます。Findy Team+ 側に保管されるのは、解析結果のメトリクス値（スコア・複雑度・行数など）のみで、ソースコード本体は保持されません。
8. コード品質分析は無効化できますか？
Findy Team+ の管理者が設定画面からいつでもコード品質分析機能を無効化できます。無効化すると、関連するすべての処理が即時停止し、機能は利用できなくなります。
9. 「コーディングタスク分析β」とどう違うのですか？
- コーディングタスク分析β：マージされたプルリクエストの変更行を「新規」「手戻り」「メンテナンス」に分類し、開発活動のリソース配分・取り組みのバランスを可視化します。
- コード品質分析：デフォルトブランチの最新コミットのソースコードを静的解析し、コードベース自体の品質状態を循環的複雑度・保守性指数などの数値で可視化します。
両者は補完的な関係にあります。コーディングタスク分析βで「メンテナンスに割いている時間」を、コード品質分析で「メンテナンス対象となるコードの状態」を、それぞれ別の角度から把握できます。
10. 「改善優先度」「変更回数」「最終コミット日時」が表示されない、または空欄になっています。
- ファイル一覧では、Git 更新情報のうちデフォルトで表示されるのは改善優先度のみです。変更回数・最終コミット日時は、列の表示切り替えから表示に切り替えてください。
- 最終コミット日時が空欄のファイルは、直近90日間に変更がないことを意味します。あわせて変更回数は 0 になり、改善優先度はパーセンタイルの母集団の対象外として空欄になります。
- これらの指標は1日1回のバッチで更新されます。設定直後や解析対象に追加した直後は、翌日以降の反映をお待ちください。
コード品質分析についてご紹介します🙋
機能概要
コード品質分析は、エンジニアリングマネージャーやチームリーダーが、チームが保守しているコードベースの品質状況を定量的に把握し、改善の意思決定をするのに役立ちます。
ソースコードを静的解析し、複雑度・保守性・サイズなどの観点からファイル単位・リポジトリ単位の品質スコアを算出して可視化します。属人的になりがちな「このコードは読みづらい」「ここは将来怖い」といった感覚を、共通の数値指標として議論できるようにします。
以下は、コード品質分析がどのような課題に対して効果を発揮するかを整理した一覧です。
| 課題 | この機能がどう解決するか |
|---|---|
| コードの品質状況を客観的に把握できていない | 循環的複雑度・認知的複雑度・保守性指数などをファイル/リポジトリ単位で可視化し、共通の指標で議論できるようにします |
| 技術的負債が積み上がっているが、どこから手をつければよいか分からない | 品質スコアが低いファイル・複雑度が高いファイルを特定し、改善対象に優先順位を付けられます |
| コード品質の改善活動の効果を説明しにくい | 品質スコアの推移を継続的に追跡することで、リファクタリングや改善施策の成果を定量的に示せます |
| 新しくジョインしたメンバーがどのファイルが読みにくいか分からない | 認知的複雑度や保守性指数から、レビュー時に重点的に説明すべきファイルを事前に把握できます |
| プロダクトや経営層に対してリファクタリング工数の確保を説明しにくい | スコアの低いコードが多いリポジトリを示し、改善投資の必要性を客観的なデータで議論できるようになります |
注意事項
- 現在はβ版として提供しており、今後さらに機能改善・拡張を予定しています。
- 対応しているコード管理ツールは GitHub Cloud 版のみです。
- Personal Access Token（PAT）による接続は未対応です。
- 解析処理は1日1回のバッチで実行されます。設定変更や新しいコミットの反映は翌日以降になります。
- アーカイブされたリポジトリは解析対象に含まれません。
ご利用に必要な設定
- Findy Team+ の管理者ユーザーが「コード品質設定」画面から機能を有効化する必要があります。
- 詳細は下記の「必要な設定」のセクションをご参照ください。
対象プラン
以下のプランを対象に機能提供しています。
- Enterpriseプラン
- Advancedプラン
※今後、機能提供の方法を変更する可能性がございます。
対象ロール
以下のロールを対象に機能提供しています。
- 管理者
- マネージャー
- スタッフ
対応言語
以下の言語のソースファイルが解析対象です。
| 言語 | 拡張子 |
|---|---|
| TypeScript | .ts, .tsx |
| JavaScript | .js, .jsx |
| Ruby | .rb |
| Python | .py |
| Go | .go |
| Java | .java |
| C++ | .cpp, .cc, .cxx, .hpp, .hh, .hxx |
| PHP | .php, .phtml |
なお、以下のファイル・ディレクトリは自動的に解析対象から除外されます。
- テストファイル（
*.spec.*/*.test.*など） - テスト慣習ディレクトリ（
__tests__,__mocks__,__fixtures__,testdataのみ） - 依存パッケージ・ビルド成果物ディレクトリ（
node_modules,vendor,dist,build,coverageなど） - VCS / IDE 関連ディレクトリ（
.git,.idea,.vscodeなど）
これらに加えて、任意のファイル・ディレクトリを除外したい場合は、次の「解析対象ファイルの除外設定（.teamplusignore）」をご参照ください。
解析対象ファイルの除外設定（.teamplusignore）
自動生成されたコードや実験用のコードなど、品質改善の対象外としたいファイルを解析対象から除外できます。
解析対象リポジトリのルート（デフォルトブランチ）に .teamplusignore という名前のファイルを作成し、除外したいパスを .gitignore と同じ構文で記述してください。
# 自動生成コード
generated/
**/*.gen.ts
# 実験用コード
sandbox/
除外設定をコードと同じリポジトリで管理できるため、変更履歴も Git に残ります。
記述ルール
#から始まる行はコメントとして扱われます。- パターンはリポジトリのルートからの相対パスに対して評価されます。
- ファイルサイズの上限は 1MB です。上限を超えると、そのリポジトリの解析はエラーとなります。
注意事項
.teamplusignoreは「自動的に解析対象から除外されるファイル・ディレクトリ」への追加の除外としてのみ機能します。!による否定パターンは.teamplusignore内に記述した他のパターンの打ち消しにのみ使用でき、テストファイルやnode_modulesなどの自動除外を解析対象に戻すことはできません。- 除外に一致したディレクトリは配下がすべて解析対象外となるため、除外ディレクトリ配下の一部ファイルだけを否定パターンで解析対象に戻すことはできません。
.teamplusignoreの追加・変更・削除は、翌日のバッチ処理実行後に解析結果へ反映されます。パターンを削除（またはファイル自体を削除）した場合は、除外されていたファイルが再び解析対象に戻ります。
必要な設定
コード品質分析を利用するには、以下の2つのステップが必要です。
1. 設定画面から機能を有効化する
Findy Team+ の管理者ユーザーが、コード品質設定画面からコード品質分析機能を有効にする必要があります。
この機能ではソースコードに対して解析処理を行うため、管理者による明示的な確認が求められます。
※ ソースコードは保存されることはなく、処理完了後すぐに削除されます。データの取り扱いに関する詳細は、Findy Team+ のカスタマーサクセス担当までお問い合わせください。
2. 対象リポジトリを設定する
解析対象とするリポジトリを選択してください。
解析対象ブランチはカスタマイズできず、各リポジトリの GitHub 上のデフォルトブランチが対象になります。デフォルトブランチの最新コミット（HEAD）の状態に対して解析が行われます。
注意事項
- 解析対象リポジトリの変更内容は、翌日のバッチ処理実行後に解析結果へ反映されます。
- アーカイブされたリポジトリは解析対象に含まれません。
画面の見方
コード品質分析画面には2つのタブがあります。
リポジトリ一覧タブ
解析対象リポジトリ全体の品質サマリーを一覧表示します。
| カラム | 説明 |
|---|---|
| リポジトリ | リポジトリ名 |
| 平均品質スコア | リポジトリ内の各ファイルの品質スコアの平均（0〜100、高いほど高品質） |
| 最大ネスト深度 | リポジトリ内のファイルの最大ネスト深度のうち最も大きい値 |
| 平均保守性指数 | リポジトリ内の各ファイルの保守性指数の平均 |
| 平均認知的複雑度 | リポジトリ内の各ファイルの認知的複雑度の平均 |
| 平均循環的複雑度 | リポジトリ内の各ファイルの循環的複雑度の平均 |
リポジトリ単位で品質状況を俯瞰し、どのリポジトリから改善に取り組むかの優先順位付けに活用します。
ファイル一覧タブ
リポジトリを選択して、配下のファイル単位での品質メトリクスを一覧表示します。
| カラム | 説明 |
|---|---|
| ファイル | リポジトリルートからのファイルパス |
| 品質スコア | ファイル単位の総合品質スコア（0〜100、高いほど高品質） |
| 最大ネスト深度 | ファイル内の最大ネスト深度 |
| 保守性指数 | ファイルの保守性指数（0〜100、高いほど保守しやすい） |
| 認知的複雑度 | ファイル全体の認知的複雑度の合計 |
| 循環的複雑度 | ファイル全体の循環的複雑度の合計 |
| 実コード行数（SLOC） | コメント・空行を除いた実コード行数 |
| 関数定義数 | ファイル内の関数・メソッド定義数 |
| 改善優先度 | 品質スコアの低さと直近90日間の変更頻度をもとにした、リポジトリ内での改善の優先順位（0〜100 のパーセンタイル。100に近いほど優先度が高い。90日以上変更のないファイルは空欄） |
| 変更回数 | 直近90日間のコミット回数（変更頻度の目安） |
| 最終コミット日時 | 直近90日間で最後にコミットされた日時（90日以上変更のないファイルは空欄） |
改善優先度・変更回数・最終コミット日時は、ファイルの Git 更新履歴（直近90日間）をもとにした指標です。算出仕様は「指標定義と解釈」セクション内の「Git 更新情報」をご参照ください。
ファイル一覧では、表示する列を絞り込めます。Git 更新情報のうちデフォルトで表示されるのは改善優先度のみで、変更回数・最終コミット日時は列の表示切り替えから表示できます。
スコアが低いファイル・複雑度が高いファイル、または改善優先度が高いファイルにソートすることで、改善対象のファイルを効率的に特定できます。
指標定義と解釈
品質スコア（0〜100）
ファイルの各メトリクスを「複雑度」「サイズ」「保守性」の3カテゴリに分類し、各カテゴリのサブスコアを重み付き合計して算出する 0〜100 の整数値です。値が高いほど高品質を示します。
| カテゴリ | 構成メトリクス |
|---|---|
| 複雑度 | 循環的複雑度 / 認知的複雑度 / 最大ネスト深度 |
| サイズ | 実コード行数（SLOC） / 関数定義数 |
| 保守性 | 保守性指数 |
平均品質スコアのランク（Elite / High / Medium / Low）
平均品質スコアは、その値に応じて以下の4段階のランクに分類されます。
| ランク | スコア範囲 |
|---|---|
| Elite | 90以上 |
| High | 80〜89 |
| Medium | 65〜79 |
| Low | 65未満 |
循環的複雑度（Cyclomatic Complexity）
McCabe の循環的複雑度。ファイル内の条件分岐・ループ・例外処理の数に基づき、コード内の独立した実行パスの本数を数えた指標です。値が大きいほど、テストでカバーすべきパスが増え、バグの混入リスクや理解の難易度が上がります。
認知的複雑度（Cognitive Complexity）
SonarSource 方式の認知的複雑度。「人間がコードを読むときに、どれだけ脳に負荷がかかるか」を測る指標です。ネストの深さや制御フローの中断（早期 return、break、continue 等）を加味して算出されます。値が大きいほど、レビューや改修の際に理解しづらいコードであることを示します。
保守性指数（Maintainability Index）
Microsoft の保守性指数をベースにしています。実コード行数（SLOC）と循環的複雑度をもとに算出する 0〜100 の指標で、値が高いほど保守しやすいことを示します。実コード行数が多く、循環的複雑度が高いファイルほど値が低くなります。
最大ネスト深度（Max Nesting Depth）
ファイル内の制御構造（if / for / while / try など）が最も深くネストしている部分の深さ。深いネストは可読性を著しく下げるため、リファクタリングの目印になります。
関数定義数 / 実コード行数（SLOC）
- 関数定義数：ファイル内の関数・メソッド定義の数
- 実コード行数（SLOC）：コメント・空行を除いた実質的なコード行数
ファイルあたりの責務が大きすぎないかを判断する材料になります。
スコア算出の目安となる閾値
各メトリクスは以下の閾値を基準に正規化されます。値が閾値を下回る（保守性指数は上回る）ファイルは「良好」、それを超えるファイルから段階的にスコアが下がっていきます。
なお、行数系の指標は実コード行数（SLOC）のみで評価します。コメント・空行の行数はスコアに計上されません。
複雑度
| メトリクス | 良好 | 注意 |
|---|---|---|
| 循環的複雑度 | ≤10 | ≤15 |
| 認知的複雑度 | ≤15 | ≤25 |
| 最大ネスト深度 | ≤3 | ≤4 |
サイズ
| メトリクス | 良好 | 注意 |
|---|---|---|
| 実コード行数（SLOC） | ≤240 | ≤400 |
| 関数定義数 | ≤15 | ≤25 |
保守性
| メトリクス | 良好 | 注意 |
|---|---|---|
| 保守性指数 | ≥70 | ≥50 |
Git 更新情報（改善優先度・変更回数・最終コミット日時）
ファイル一覧タブでは、静的解析による品質メトリクスに加えて、ファイルごとの Git 更新履歴をもとにした3つの指標を確認できます。いずれも直近90日間のコミット履歴（マージコミットを除く）を対象に集計します。
改善優先度（Improvement Priority）
品質スコアの低さと直近90日間の変更頻度（変更回数）をもとに、リポジトリ内での改善の優先順位を0〜100 のパーセンタイルで表した指標です。100 に近いほど「品質が低く、かつ頻繁に変更されている」＝いま改善に着手する価値が高いファイルであることを示し、母集団の中で最も優先度が高いファイルが 100 になります。
- 母集団は同じリポジトリ内で直近90日間に変更のあったファイル（変更回数が 1 以上）のみです。直近90日間に変更のないファイルは対象外となり、値は空欄で表示されます。
- 値はリポジトリ内での相対順位のため、異なるリポジトリ間では直接比較できません。
パーセンタイル表示のため、1つの値だけでも母集団の中での優先度の高低を判断できます。頻繁に変更されている低品質なファイルほど値が高くなるため、日々手を入れているコードから優先的に改善したい場合の目印として活用できます。
変更回数（Change Count）
直近90日間に、そのファイルへ加えられたコミットの回数です。変更頻度の目安になります。
最終コミット日時（Last Commit Datetime）
直近90日間で、そのファイルが最後にコミットされた日時です。この期間に変更のないファイルは値がなく、空欄で表示されます。
注意事項
- これらの指標は、他の品質メトリクスと同様に1日1回のバッチで更新されます。反映は翌日以降になります。
- 集計対象は直近90日間のコミット履歴です。90日より前の変更は集計に含まれません。
- マージコミットは集計対象から除外します。
- 直近90日間に変更のないファイルは、変更回数が 0、最終コミット日時が空欄になり、改善優先度はパーセンタイルの母集団の対象外として空欄になります。
コード品質分析の読み解き方
品質スコアは絶対評価の基準ではなく、チーム内・リポジトリ間の相対比較と、時系列での変化の追跡に活用するのが効果的です。
改善対象を特定する
- リポジトリ一覧タブで平均品質スコアが低いリポジトリ、平均複雑度が高いリポジトリを特定します。
- 次にファイル一覧タブでスコアの低い順にソートし、特に改善効果が大きいと思われるファイルを抽出します。
- 認知的複雑度・最大ネスト深度が突出して大きいファイルは、リファクタリングの優先候補です。
- 改善優先度の降順にソートすると、「品質が低く、かつ頻繁に変更されている」ファイルが上位に来ます。限られた工数で効果を出したい場合の起点として有効です。
改善の効果を測定する
- リファクタリング後に対象ファイルの品質スコア・複雑度がどう変化したかを確認します。
- 継続的にスコアの推移を追うことで、改善活動が一過性で終わっていないか・新しく書かれているコードの品質が保たれているかを確認できます。
スコアだけで判断しないこと
品質スコアは静的解析に基づく機械的な指標であり、コードの意図やビジネス的な妥当性は反映しません。スコアが低くても合理的な理由があるコードは存在しますし、スコアが高くても設計上の問題を抱えているコードもあります。
スコアはあくまで「ここを見ると改善余地があるかもしれない」という会話のきっかけとして活用し、最終的な判断はチームでのコードレビューに委ねてください。
よくある質問
1. GitHub以外のGitサービスにも対応していますか？
現在はGitHub Cloudのみ対応しています。GitLab、Bitbucketなどの対応については、今後の検討課題です。
2. 解析結果がいつ反映されますか？
解析処理は1日1回のバッチで実行されます。設定変更・新しいコミットの解析結果は、翌日以降に画面へ反映されます。
3. コード品質分析にデータが表示されない場合は、以下の点をご確認ください。
- 解析処理は定期実行されるため、設定が正しいことを確認し翌日以降に画面を確認してください。
- 対応言語のソースファイルがリポジトリに含まれているかをご確認ください。
- アーカイブされたリポジトリは解析対象に含まれません。
4. 解析対象とならないファイルはありますか？
対応言語以外のファイルや、テストファイル・依存パッケージ・ビルド成果物などのディレクトリは解析対象から除外されます。詳細は「対応言語」のセクションをご参照ください。
5. 自動生成コードなど、特定のファイルを解析対象から除外できますか？
はい、リポジトリのルートに .teamplusignore ファイルを置くことで、任意のファイル・ディレクトリを解析対象から除外できます。詳細は「解析対象ファイルの除外設定（.teamplusignore）」のセクションをご参照ください。
6. 品質スコアの値は何を意味しますか？
ファイルの「複雑度」「サイズ」「保守性」の各カテゴリのサブスコアを重み付き合計した 0〜100 の整数値です。値が高いほど高品質であることを示します。詳細は「指標定義と解釈」の章をご参照ください。
7. ソースコードは保管されますか？
いいえ、解析処理のために一時的にリポジトリをクローンしますが、解析処理完了後すぐに削除されます。Findy Team+ 側に保管されるのは、解析結果のメトリクス値（スコア・複雑度・行数など）のみで、ソースコード本体は保持されません。
8. コード品質分析は無効化できますか？
Findy Team+ の管理者が設定画面からいつでもコード品質分析機能を無効化できます。無効化すると、関連するすべての処理が即時停止し、機能は利用できなくなります。
9. 「コーディングタスク分析β」とどう違うのですか？
- コーディングタスク分析β：マージされたプルリクエストの変更行を「新規」「手戻り」「メンテナンス」に分類し、開発活動のリソース配分・取り組みのバランスを可視化します。
- コード品質分析：デフォルトブランチの最新コミットのソースコードを静的解析し、コードベース自体の品質状態を循環的複雑度・保守性指数などの数値で可視化します。
両者は補完的な関係にあります。コーディングタスク分析βで「メンテナンスに割いている時間」を、コード品質分析で「メンテナンス対象となるコードの状態」を、それぞれ別の角度から把握できます。
10. 「改善優先度」「変更回数」「最終コミット日時」が表示されない、または空欄になっています。
- ファイル一覧では、Git 更新情報のうちデフォルトで表示されるのは改善優先度のみです。変更回数・最終コミット日時は、列の表示切り替えから表示に切り替えてください。
- 最終コミット日時が空欄のファイルは、直近90日間に変更がないことを意味します。あわせて変更回数は 0 になり、改善優先度はパーセンタイルの母集団の対象外として空欄になります。
- これらの指標は1日1回のバッチで更新されます。設定直後や解析対象に追加した直後は、翌日以降の反映をお待ちください。
