コードの品質を測定する方法が記載されてました。

https://codezine.jp/article/detail/18337

GitHub や Gitlab などの API のあるコード管理を使っているなら、 CI や、品質計測用の日次バッチで、自動計測できそうです。

変更のリードタイム: first commit から、その commit が本番にリリースされるまでの時間

ブランチのログから取得できます。 ついでに API で Issue の着手から Close までの時間、 PR の作成から、マージまでの時間なんかも計測できます。

手戻り数: プロジェクト管理システムにおいて、プロセスの前段に戻ってきたタスクの数

例えば、あるタスクを「完了」に移動したが、実際にはバグがあった場合、タスクは前段に戻され「手戻り」となる。

と記載されてましたが、なんらかのルールを設けないと、計測に抜け漏れが出そうです。

私は、これまで、完了にしたタスクを戻すことはしてなくて、新しいタスクを作っていました。 タスク（Issueチケット）の動かし方を分析して、仕様変更で手戻りが発生したケース、バグによる手戻りのケースなどで分類分けして、 Issue チケットのワークフローをルールで決めておかないと、正しく計測できない気がします。

次のタスクに取り掛かって、前のタスクのバグが見つかったとしても、前のタスクの状態を戻さずに作業することも、よくあるので、厳密な管理は難しいかもしれません。 参考程度の指標として使うのがよいかもです。

ルールが決まったら、 API で回収できるので、自動化できます。

手戻り率: プロジェクト管理システムにおいて、プロセスの前段に戻ってきたタスクの割合

タスクが戻った回数をB、タスクが進んだ回数をFとすると、手戻り率は (B / (F + B)) * 100 で表せる。

上記のとおり、「手戻り」の識別方法を、どこまで厳密化できるかが課題ですが、参考指標にはできそうです。

コード行数（LOC：Line Of Code）

昔の開発では、プロジェクトの終了時に、開発したコードの行数を数えてたな・・・と、懐かしいです。 記事の中でも、「取り扱いが難しい指標」と記載されています。

本当に手が早い人で、コードの行数が多い＝生産性が高いと評価できる人もいるかもしれないけど、コピペ君が書いたコードかもしれないです。 LOC を生産性の指標とするのは、やや問題がありそうです。

ただし、コード量が多いとメンテナンスにかかるコストが大きくなるのは、そのとおりなので、バグの数を LOC で割ったものを「バグ密度」と定義して、品質の指標には、使えると思います。
保守性を推し量る指標にもなるかもしれません。

行数のカウント方法には、LOC、NLOC、LLOC、CLOC など、やり方がいくつかあり、さらに「2つの命令が書かれた行は2行と数える」「括弧だけの行を除く」というルールを設ける場合もあるようです。そこまでやると、なかなか大変ですが、 AST を使ってコードをパースすれば、計測できなくはないです。

どこまでやるかは検討するとして、自動化できます。

循環的複雑度（Cyclomatic Complexity）

大雑把にいえばコード内のif／else、for、switch、whileなどの分岐やループの数を数え上げたもの

だそうです。

ツールがあるので、自動化可能です。

• OCLint: C言語向けの静的解析ツール
• GMetrics: Java向けのメトリクス分析ツール
• Lizard: コマンドラインの循環的複雑度計測ツール（たくさんの言語がサポートされている）

循環的複雑度とそのコードが編集された回数には密接な関係があるそうで、 複雑なコードは修正回数が多くなるというのは、頷けるところです。

私としては、オブジェクト指向の複雑度も計測してほしいです。
オブジェクト指向が進むと、条件分岐じゃなくて、汎化と具象化で機能を入れ替えますが、 他人が書いた複雑なオブジェクト指向な実装は、コードの理解とデバッグ難易度が高いので、 ちょうどよい塩梅の指標が欲しいです。

コードの重複（Code Duplication, Clone Code）

DRY 原則としても有名です。コピペはやめましょう。

これも、ツールがあるので、自動化可能です。

• Clone Detective
• Simian
• PMD
• SonarQube

検出した重複コードを使ってコード品質を測定するなら、 例えば、プロジェクトのコード行数に対する重複コード行数の割合、 つまり「重複率」を測定することができます。 この「重複率」をKPIとして利用しているチームも多いでしょう。

との記載もありました。

また、以下のようにも。

（「重複率」は）低い方がより良いだろう、ということは自明だと思いますが、 先に紹介した循環的複雑度とは異なり、実は重複度に関しては明確な基準値はありません。

重複度に関しては、その絶対値よりも値の時系列変化に着目した方が良いでしょう。 ある程度の期間の中で何か著しい増加が観測されたら、 チームを集めてその原因や対処方法について検討してみて下さい。

グラフ表示できるとよさそうです。

その他の指標

以下は、健全なプロジェクトであれば、すでに取り組んでいるでしょう。

• ユニットテストとカバレッジ
• コードレビュー頻度
• 性能プロファイリング

まとめ

このような計測データを、プロジェクト別に集計するだけではなくて、個人別に集計すると、これまで見えていなかった課題が、見える化されるかもしれません。みなさんも、品質指標の計測の自動化に取り組んでみては、いかがでしょうか？