インスペクタはこんなところをみている

仕様記述中の句読点の数

　今回は通常のインスペクターの視点に加えて、インスペクションにメトリクスデータを活用するいくつかの事例を紹介します。

　仕様書の文書中に読点（「、」ですね）が何度も出てきて長い文章を記述している場合は、注意深く観察すると欠陥が含まれていることが少なくありません。

　これはテキストマイニングの専門家の方にアドバイスをもらったことがあるのですが、自信のない文章やよく理解していない文章は叙述的になりがちであり、句読点で多くの文章を記述することが多いそうです。

　記述の中に矛盾や2～3種類のメッセージを盛り込んでしまうことは要件や設計内容が理解されていない、または確定していない内容を可能な限り「表現しておこう」「記述しておこう」という思惑の表れではないかと考えます。

　実際に「全文書中の句点（「。」ですね）で文章を改行し、1文中の句読点の数を数えると、直接の文そのものでないものも含めて高確率で欠陥を検出できる場合があるのです。特に論理矛盾・記述内容の不整合、および一意性欠如といった仕様書の典型的な例が多数検出されます。

　実はかくいう筆者の文章も修飾語が多く、1文で多くのメッセージを伝えている場合が多いと部下のインスペクターに指摘されることがあります。筆者が締め切りに間に合わないと焦りながらも、少しでも多くのことを（よく推敲（すいこう）せずに）何とか形にしようとして、必死に「もがく」姿が文章に表れているのだと思います。

プログラム中の変数名の長さ

　次はプログラムコード内の品質のムラについては、こんな例もあります。

　まず各ソースコード1本1本の中で変数名の長さ（これを平均変数名長：Average Identifier Lengthと言います）を計測します。1本あたり1つの値が出ます。これをグラフ上に描画すると群（クラスター）が見えることがあります（図1）。

　この図のクラスターを以下の判定条件式にしたがって評価し、開発者の言語経験を推定します。

IF　　平均変数名長≦8 THEN COBOL言語経験者
IF 9≦平均変数名長≦12 THEN C/C++言語経験者
IF　　平均変数名長≧18 THEN JAVA言語のみの経験者

　確かに、汎用機の経験者は8文字ネーミングに慣れている場合が多く、またC言語／C++の経験者はハンガリアンネーミングを用いている方も多いでしょう。では、開発者の過去に経験したことのある言語を知って、何がわかるのでしょうか。

　実は「言語に依存した癖」というものが存在するのです。これは各種開発言語の持つ特性そのものと言ってもいいでしょう。例えば、今回プロジェクトで使った言語がJavaであれば、Java言語と先に判定した過去経験言語を照合し混入欠陥を予測することができるのです。典型的な例で言えば、以下のようなものがあります。

・今回利用言語が「Java」で、過去経験言語がCOBOLなら、「例外処理の漏れ／try-catch」を疑う
・今回利用言語が「Java」で、過去経験言語がC・C++なら、「Null Pointer エラー類」を疑う
・今回利用言語が「Java」で、過去経験言語がJavaなら、「リソース解放忘れ／new多用」を疑う

　なぜこのようなことが可能なのでしょうか。通常プログラムソースコードは多くの予約語と変数で構成されていますが、普段何気なく命名している変数名の癖などは、典型的なプログラマーの経験を映し出すメトリクスの一例として有効なのです。

　もちろん、筆者はこの方法がすべてのプロジェクト、あらゆる言語に有効だと主張するつもりは毛頭ありません。反例を挙げれば、一般のプログラミング書籍に掲載された処理やアルゴリズムは、その処理内容をわかりやすく伝達する目的で変数名を1～2文字といった極端に短い長さで記載する場合が多いのです。しかしそのような場合は、平均変数名長という欠陥推測方法がまったく通用しない例の1つです。

　ここで強調したい点は、インスペクターはおおよそ考えつく限りのあらゆる測定可能項目を集計し、どんな欠陥と相関があるか常に考えている「欠陥と計測のプロ」であるということです。より早くより正確に欠陥へたどり着くために有効な「微細な兆候」を恒常的に探し続けているのです。