基調講演は，日本アイ・ビー・エム GBS AIS エンタープライズ・アーキテクチャー&テクノロジー　クオリティ・エンジニアリングの細川宣啓氏より，「現場主導の実践的なソフトウェア・メトリクス測定のもたらす効用・効果 ─明日から使える実践的なメトリクス測定とIT産業の発展─」と題して行われました。

IT業界を成長する鍵は計測にあり

ソフトウェア開発において，定量的に品質を測定したい場面は少なくありません。ただ品質を測定するといっても，その目的はさまざまなものがあります。たとえばカットオーバーのタイミングなど，意志決定が必要な場面でその判断の拠り所とするためということもあるでしょう。また，設定したパフォーマンスが達成できているかどうかも，計測しなければ判断できないことだと言えます。さらに現場レベルでは，計測によって早期に問題を特定し，修正を行っていくといったことも考えられます。

日本アイ・ビー・エムの細川宣啓氏は，ソフトウェア開発における品質の定量測定（メトリクス測定）を，検査学という学問になっている医療の世界の対比し，その重要性を説明します。

細川氏は「70年代以降，二つのキーポイントによって医学が発展したと言われています。一つは投薬，二つ目は検査技術です」と語り，医学の世界における検査の重要性をまず指摘しました。

医療のサイクルでは，まず医師が問診によって病気の可能性を探り，そこで立てられた仮説を検証するための検査方法を決定します。次のステップでは，再現性や正確性，迅速性を重視して検査が行われます。最後にその結果を受けて病気を特定，見立てと処置が正しかったかを判断しながら，次のサイクルを回していくということになります。

こうして検査を行っていくフローは，ソフトウェア開発のテストでも同様だと細川氏は語ります。たとえば医療において初診の場面で問診から仮説を立てて検査方法を決定するように，ソフトウェア開発においても，まずテストの目的やテスト戦略があり，それに基づいてテスト技法を決定するべきだというわけです。さらに実際の検査においても，再現性や正確性，迅速性が重要であるのは，医療の検査でもテストでも同様でしょう。細川氏はこれらを踏まえ「IT業界にも測るという概念が浸透すれば，もっと伸びるのではないでしょうか」と述べ，メトリクス測定がソフトウェア開発におけるキーポイントになるとの認識を示しました。

目的指向の測定を実現するGQM法

では，メトリクス測定において具体的に何を測っていくべきなのでしょうか。こうした測定手法として以前から使われているものに，行数，そして複雑度があります。まず行数については「プログラム行数と欠陥発生率に，顕著な相関関係はないと否定されています」とのことで，指標として使うべきではないと述べます。

複雑度を指標として用いる場合は，一つのモジュール内での複雑度を測る「Intra-module complexity」と，モジュール同士の結びつきの複雑度である「Inter-module Complexity」の二つがあることに注意が必要とのこと。

「モジュール間の結びつきの複雑さを無視して，個々のモジュールの複雑度を軽減しましょうという考え方は危険です。モジュールの分割粒度が細かくなると，相互依存性や関連性が深くなるため，連結テストや結合テストが複雑になります」と語り，モジュール内の複雑度と連係部分での複雑度の両方を考える必要があると解説しました。

具体的に何を計測するのかを考える際に，テンプレートとして使える考え方として紹介されたのが「GQM法」です。これは，プロセスアクティビティや製品特性を評価するために測定目標を確立し（Goal），目標に達するために答えなければならない質問を定義（Question）した上で，質問に答えるためのメトリクスを特定する（Metrics）という手法です。この考え方を用いることで，目的を明確してメトリクス測定を実施することが可能になります。

このメトリクスを考える際に，細川氏が重要だと強調したのが「簡単に測れること」です。この具体的なメトリクスの1つとして，IEEE 982.1-1998として定義されている「ソフトウェア成熟度指標（Software Maturity Index）」が紹介されました。

これは現在リリースされている製品に含まれているモジュールから，変更されているモジュールや追加されたモジュール，削除されたモジュールを引いて得られる値で，これが1に近づけば安定していると判断できるというもの。いずれも単純な指標のため，容易に計算することができます。こうした分かりやすさも，メトリクス測定においては重要であると細川氏は述べます。

バインダーの端でプロジェクトの健全性が分かる

最後に容易に測定ができる指標や事柄を紹介し，それをどのように判定するのかが紹介されました。多くの来場者にインパクトを与えたのが「バインダーの端」。これでなぜ品質の判定ができるのか，プロジェクトの健全性が測れるのかというと，「バインダーの周辺の角がすり切れていれば，よく読まれていること，メンテナンスがされていることが分かります」とのこと。勢いだけで作っていたり，後から仕様書を作ったプロジェクトは，まったく汚れていなかったり，埃をかぶったりしているというわけで，仕様書の外観からも分かることはあるそうです。

また，仕様書作りなどで利用されることが多いワープロソフトや表計算ソフトでは，ファイル内のページ数やそれを編集した時間などがプロパティとして保持されています。こうした数値からも，プロジェクトの健全性が読み取れると細川氏は語ります。プレゼンテーションで示されたのは，316ページのドキュメントの編集時間がたった17分というもの。「17分で316ページということは，1ページあたり3.22秒で作成したことになります。ありえませんよね。明らかにほかのプロジェクトのものを流用した仕様書であるということが分かるわけです」と，些細なポイントからも仕様書の妥当性を見抜けると指摘します。

変数名の文字数の平均値から，開発に携わった人がどのような言語を経験してきたかが分かり，そこから何を重点的にチェックするべきかが分かるといったことも紹介されました。COBOLの経験者であれば8文字ネーミングに慣れているため，変数名の長さの平均値も8文字以下になるとのこと。またC／C＋＋言語経験者であればハンガリアンネーミングを用いている技術者が多いことから9文字以上12文字以下に，Java技術者はあまり変数名の長さを意識しないことから18文字以上になることが多いと言います。

こうして確認した開発者の背景がたとえばCOBOL技術者であれば，COBOLにはない例外処理の漏れを疑う，C／C＋＋ならNull Pointerのエラー類を疑う，そしてJava技術者の場合はリソースの解放忘れやnew演算子の多様を疑うといったように，それぞれの言語特性から混入するであろう欠陥を予測するというわけです。

最後に細川氏は，メトリクス測定において重要なのは洞察力であると説明します。こう聞くと自分にはできないと思われるかもしれませんが，細川氏は「ゆっくり見ているうちに，プロジェクトの特徴が確実に見えてきます。一般的によく言われることに惑わされず，自由な発想で計測したデータを使ってください」と述べて講演を締めくくりました。