プロジェクトマネージャを支える新たなコードメトリクス：プロジェクトの品質を高めろ！（2/2 ページ）

[潮英夫, 渡部修平, 辻克己（NTTコムウェア），ITmedia]

想定する利用シーン

　今回のコードメトリクス技術は、以下の用途に活用できると考えています。

• 単体試験／結合試験で利用し、高リスク箇所を重点的に試験することによる、バグヒット率向上
• 試験の優先順位付けにより、限られたリソースの有効活用
• 複雑度から見た、開発工数の妥当性評価
• 他組織が開発したシステムを、引き取る際のリスク管理

　以下では、具体的な内容について説明していきます。

適合率が高い組み合わせをパターン化

　システムのソースコードには、大小さまざまなクラス（モジュール）が存在します。クラスが複雑であればあるほど、その箇所のリスクが増大すると考えています。

　「クラスが複雑」とは、

• クラス間の参照が多い
• クラス内部の参照が多い
• 実装メソッド数が多い
• クラス内の通過経路数が多い
• 条件文のネストが深い
• 複雑なライブラリを活用している

といった条件を満たすクラスを指します。

　今回のコードメトリクス技術の開発時には、まず、各システムの担当者に依頼し、有識者の経験から、クラスごとに複雑さを判断してもらいました。

　次に、既存のメトリクスを調査し、コードの複雑性に関するメトリクスを選定しました。それらのメトリクスを精査し、お互いに干渉せずに独立しているものを抽出し、今回活用するメトリクスの候補としました。

　それらのメトリクスの視点から、システムのソースコードを解析し、メトリクスごとの値（コードメトリクス値）を算出しました。汎用的なコードメトリクス値の算出には「Understand（※1）」を活用していますが、これに加えて独自のメトリクスを定義し、係数を掛けて演算した結果から、複雑度を求めました。

　この算出した複雑度と、有識者判断値を比較し、適合率が高い組み合わせをパターン化しました。

　そのパターンによる出力結果を改めて有識者に確認してもらい、実際のプロジェクトのリスク判断と乖離している部分を調査し、新しい指標や組み合わせ方の重み付けなどを調整し、パターンにフィードバックします。これを繰り返すことで、有識者の曖昧な感覚を分析ロジックに反映し、適合率を高めました。

　複雑度はクラスごとに算出されます。大規模なシステムのコードともなれば、多数のクラスを含んでいるため、表示方法にも工夫が必要となります。コードメトリクスで適用可能な、複数のチャートや表示方法を比較検討した結果、ロジックツリーを採用することにしました。

コードメトリクスのロジックツリー

　コードメトリクスでは、クラスの情報をアイコンで表現したロジックツリーで表示することで、システムを俯瞰しやすくしています。一例を挙げると、

• クラスの種類…アイコンの形
• クラスの規模…大きさ
• クラスの複雑度…色

などです。

　このように表示することで、直感的に判断を行えるようにしました。一般的なロジックツリーのデメリットとして、全体の見通しの悪さがあります。そこでメイン画面に加え、全体構成と解析位置を示す縮尺図を実装することで、全体を見やすくしました。

図1

　上記の図1は、ソースコードをメトリクス利用手法により解析し、クラスごとの規模、種類、複雑度をロジックツリーで表示したものです。アイコンの色が赤ければ赤いほど、複雑度が高い（複雑である）ことになります。システムのどの部分がどの程度複雑であるかが一目で分かります。

　出力されるクラスごとの複雑度をグラフにすることで、さまざまな傾向を把握することもできます。図2は、横軸をコード量（ライン数）、クラスの名前、縦軸を複雑度とし、クラスごとの複雑度を表した棒グラフです。複雑度が極端なクラスを把握できるため、そのクラスに対して機能分割する、試験密度を高める、といった対策を立てることができます。

図2

　図3は、横軸をコード量（ライン数）、縦軸を複雑度とし、クラスをプロットした散布図です。灰色の楕円が示す通り、通常、コード量が増えるにつれ、複雑度も上昇していきます。しかし赤色の楕円が示すグループは、コード量と複雑度の相関が見られません。これは、赤色の楕円のグループは、宣言文が多いため、コード量に対して内部処理は複雑でないためです。

　この散布図を用いれば、赤色の楕円のグループにかかる試験リソースを減らし、その分、灰色の楕円グループ内の平均より複雑度が高いクラスを重点的に試験する、といった判断の一助となります。

図3

　実在のシステムを例に、算出した複雑度とリスクの関係について見てみましょう。合計8428クラスのシステムを、コードメトリクス技術により解析したところ、1％（81クラス）が高複雑度と判定されました。後工程でのバグ発生率を調査したところ、高複雑度と判定されたクラスに、発生したバグの25％が集中していました。高複雑度と中複雑度を合わせると、システムの19％のクラスに、バグの69％が存在していました。ソースコードのライン数と比較したところ、当社が算出した複雑度のほうが、バグ発生率の相関が高いことを確認しております。

　プロジェクトマネージャはこのロジックツリーを利用することで、システム細部の知識がなくとも、リスク箇所を容易に把握することが可能となりました。

　今回ご紹介したこの新しい技術は、自社のプロジェクト管理におけるリスクヘッジが目的であり、製品としてリリースする予定はありませんが、このような汎用的な技術でも、組み合わせや利用法によってはシステムの品質管理に役に立つということを広く読者の方々に知っていただければ幸いです。

（※1）「Understand」は、製造元：米Scientific Toolworks Inc. 販売元：テクマトリックス株式会社の製品 「Understand」は、Scientific Toolworks Inc.の商標または登録商標です。