ソフトウェアの品質を数値化して確かめる：初めてのソフトウェアメトリクス（前編）

[長瀬嘉秀, 新船弘之，テクノロジックアート]

ソフトウェアメトリクスとは

　ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。

ソフトウェアにとっての品質

　 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背景となってきたわけです。

　しかし、このようなことを改善していかないと、作る側には、モノ作りの喜びもなくなり、ただ、コードを作成して、動けばよいだけとなってしまいます。頼む側にとっては、やっつけで作ったコードは保守性が悪く、いつもバグを直す作業が発生してしまいます。双方ともに不幸です。

　そもそも、ソフトウェアの品質を示す項目にはどのようなものがあるのでしょうか。

• 性能
• 信頼性
• 保守性
• 可用性
• 安全性
• 全体としての顧客満足度

　このように品質という言葉は多岐にわたっていますが、開発現場で主に取り上げられるのは、次のような点です。

• バグの少なさ
• 機能修正や追加のしやすさ

　開発工程の後半になってもバグが収束せず納期が遅延したり、要件変更に合わせて迅速に機能修正できずデグレードを引き起こしてしまった、という経験は多くの人が持っているのではないでしょうか。

　バグは存在しないことに越したことはありませんが、機能追加は可能な限り安価かつ迅速に行うべきです。しかし、限られた予算と時間の中では、十分なテストによってバグが存在しないことを示すのは大変です。そして、要件変更に迅速に応えられるような柔軟な設計を十分に行うことも困難です。

　それでは、一体どこまでテストを実施すれば良いのでしょうか。どこまで設計に時間をかければ良いのでしょうか。これらの問いに対して明確な線引きが存在しなければ、顧客や開発者は直感的に判断するしかありません。経験に基づいた直感はとても重要ですが、適切に判断を行えない場合には多くのトラブルを引き起こします。このような場合に定量的な方法を導入することができれば、たとえ完全ではないにせよ、直感だけに頼らない明確な線引きが可能になります。これが開発現場でソフトウェアメトリクスが必要とされる理由の1つなのです。

実践に役立つソフトウェアメトリクスとは

　基本的なメトリクスである規模と結合度を例に取って考えてみましょう。規模とは、文字通りソフトウェアの規模を表しています。規模が大き過ぎると、理解するために多くの労力が必要となるため、提供できる機能や性能などが変わらないのであれば、規模は小さい方が良いはずです。また、結合度とは、モジュール間の結び付きや依存の強さを表します。結合度が低いほど、各モジュールの独立性が高く、モジュールの変更を行いやすいといえます。従って、結合度は低いほど良いはずです。これらは、統治方法として有名な「分割して統治せよ」という言葉を、ソフトウェアに当てはめたものといってもいいかもしれません。

　結合度は高い方が良くないのですが、高いということはモジュール間の依存度が大きくなることです。結合度が高いと、あるモジュールに修正を加えると修正の影響が結合しているモジュールにも出てしまいます。このことにより、修正作業が困難になってしまいます。もちろん、開発中の修正作業だけではなく、システムが稼働した後の保守作業も難しくなります。

　規模と結合度は、経験的にも直感的にもよく理解できるメトリクスです。そのため、これらを定量的に測定することができれば、ソフトウェアの状態を感覚的かつ客観的に認識できます。もし、意味がすぐに理解できないようなメトリクスだったとすれば、それを測定したところで、結果を現場の開発へフィードバックすることはできません。

　上記の例では、規模と結合度という2つの側面だけを取り上げていますが、実際の開発でソフトウェアの問題個所を的確に認識するためには、さらにほかのメトリクスを測定して多角的に判断する必要があります。しかし、測定には多くの時間がかかります。ソフトウェアの規模が大きくなり、許される時間にも限りがある実際の開発では、人手で測定を行うことはまず不可能です。そのため、メトリクスを自動測定できるツールの存在が不可欠となります。

メトリクス測定ツール

　ツールに求められる機能としては、ソースコードを解析し、前述したようなメトリクスを測定できることが最低限必要です。ただし、操作性の高さが大きなポイントとなります。操作性が悪い場合は測定することが大きな負担となってしまい、とても使おうとは思わなくなるでしょう。また、測定結果の出力方法も重要です。単に測定結果が数値化されて列挙されているだけでは、プログラムのどの個所に問題がありそうか、全体から見て注意しなくてはならない個所がどの部分なのかを即座に判断することは困難です。そのため、グラフ表示などの直感的な出力方法が求められます。

　プロジェクトでメトリクス測定ツールを導入する場合、測定担当者や測定タイミングを工夫することでも効果を得ることはできますが、IDEに統合されているような開発者自身が気軽に測定できるものの方が、より素早くフィードバックを得られ、生産性も大きく向上します。

　以上の点から、メトリクスツールに求められる機能として、以下が挙げられます。

• 操作性が良いこと
• 処理時間が短いこと
• 出力結果が分かりやすいこと

ツールの比較

　現在利用可能なツールを以下の表にまとめてみました。

ツール名	提供元	ライセンス	プログラム言語	メトリクスの種類	機能
Resorce Standard Metrics for C、C++、Java	XLSOFT	商用	C、C++、Java	約120種類	・HTML、CSV、テキストでのレポート出力 ・VisualStudioと統合 ・Kawa Java IDEと統合
Java Source Code Metrics	Semantic Designs, Inc.	商用	Java、C#、VBScript	約10種類	・XMLによるレポート出力
Krakatau Professional for Java	Power Software	商用	C/C++、Java	約70種類	・HTMLでのレポート出力 ・Visual Studio のプロジェクトをインポート可能 ・CDFへエクスポート可能
RESORT	Soft4Soft	商用	Cobol、C、C++、Java	約100種類	・チャートやグラフによる表示 ・ISO/IEC 9126の Maintainability、 System Level Metrics 提供 ・IDEとの統合なし
CodePro Studio	Instantiations, Inc.	商用（非営利目的用の非商用ライセンスあり）	Java	約50種類	・チャートやグラフによる表示 ・HTML, XMLによるレポート出力 ・Eclipseのプラグインとして提供
Eclipse Metrics Plugin	TEAM IN A BOX, Ltd.	フリー	Java	約10種類	・表形式、棒グラフによる表示 ・HTML、CSVによるレポート出力 ・Eclipseのプラグインとして提供
Eclipse Metrics Plugin	Frank Sauer	フリー	Java	約20種類	・ツリー形式による表示 ・各計測値をツリー表示 ・パッケージ間依存度をグラフ表示可能 ・Eclipseのプラグインとして提供

※ 上記に挙げたツールは、無作為にピックアップしています
※ 使用ライセンスについては、各ベンダ、開発元にお問い合わせください

　どのツールも複数のメトリクスをサポートしていますが、ほとんどのツールは次のような基本となるメトリクスに対応しています。

キーワード	概要
LOC（Line of Code）	コード行数
LCOM（Lack Of Cohesion Of Methods）	メソッドの凝集度の欠落
Complexity	複雑度
Couplings	結合度

　上記ツールの比較対応表を見ていただくと、IDEへの統合、サポートしているメトリクス、対応プログラミング言語、結果出力形式など、さまざまなものがあるのが分かります。どのツールも、メトリクスを測定して結果を出力するという基本的な機能が備わっていますが、得られた出力結果をどのように生かすのかは、あくまでも開発チームに委ねられています。メトリクスそのものが与えてくれるものは、あいまいだったソフトウェア品質というものを、定量的に明確化するためのきっかけにすぎません。

　次回は、代表的なソフトウェアメトリクスとその測定方法について、詳しく解説します。

「初めてのソフトウェアメトリクス」バックナンバー

• 凝集度と結合度：このコードのどこが悪いのか？
• ソフトウェアの品質を数値化して確かめる