読者です 読者をやめる 読者になる 読者になる

職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

未開の地でもメトリクス

パソコン・インターネット

この文中におけるメトリクスとは、ソフトウェア製品の定量的な(数値化した)評価(software metrics)を指します。「メトリクス計測」という言い方もするようですが、これは「ネットワーク網」のような二重表現のような気もします(ここでは問題視はしませんが)。数値化して評価した結果はソフトウェア製品の品質向上などのために活用されます。
数値化した後に評価するには「○○点以上なら合格」といった何らかの閾値・指標を設ける必要がありますが、この閾値の適切な値はソフトウェア製品の開発手法や言語などによって大きく左右されます。メジャーな開発環境における妥当な値というものは様々な論文や記事などから伺い知ることができますが、総人口の少ないマイナーな開発環境における事例は存在しない/公開されていないことが多いです。もちろん数値化する手法についても同様です。

この記事では、マイナーな開発環境において計測を実施するための作業

  • 数値化する項目の選定
  • 閾値(合格点)の設定
  • 上記2点の妥当性の検証&改善

を進めていくにあたって、どのような点に気を付ければ良いのかを検討していきます。あまりにも壮大なテーマですので、後日改訂したり続編を書いたりするかもしれません。
本当は具体例を挙げながら進めたいところではありますが、筆者が取り上げたい具体例そのものが極めてマイナー(実際は単なるプロプライエタリな環境)であり、例示する価値がほとんど無いので控えておきます。

はじめに:本来の目的を見失わないように(兼・筆者自身への戒め)

計測の本来の目的は、ソフトウェア製品の品質向上です(ここで「品質とは何ぞや」とか言い出すと話が終わらなくなるのでパス)。計測の結果として出力された数値は絶対のものではありません。

お前、この数値はどういうことじゃ!コード修正してこい!!

という上司の指示は極めて危険だと思います。何故なら、計測の数値が適正値になることを目指した修正をしてしまい、品質向上につながる可能性は低いからです。品質向上のためには

このプログラムは何か潜んでそうだな。A君を交えてコードレビューをやろう。

という取り組みが重要になるでしょう。

アンチパターン:よく聞く悪い話

SIerとして仕事をしていると時々聞こえてくるのが「Javaで作ってるソフトウェア製品なのにCOBOL向けの指標を適用されて大変だった」といった話です。もちろん何も計測しないよりはマシですし、その開発チームがそのプラットフォームを始めて経験するというのであれば当然の流れです。しかしながら大規模な開発チームを抱えており、そのプラットフォームにおける経験が豊富であるにも関わらずこのような状態が続くのであれば、その開発チームは検証&改善のループを回す事のできない、死んだ組織であると言っても過言ではないでしょう。これでは計測の価値はありません。このようにならないように気を付けて環境整備していきたいものであります。

数値化する項目

メジャーなプラットフォーム向けに提供されているメトリクス製品の中には数百種類(?)もの計測項目を謳っているものもあるそうですが、さすがに最初からそんな多数の項目を用意しても準備に時間を取られ過ぎて失敗しそうです。そこで、有名どころをここで列挙しておきましょう。

1. Cohesion(凝集度)
2. Coupling(結合度)

これら2項目については、この@ITの記事が有効でしょう。URLが「matrix」になっているのが若干気になりますが…(笑) @IT:初めてのソフトウェアメトリクス(中編)

3. Cyclomatic complexity(循環的複雑度)

文字通り複雑さを測るための指標の一つなのですが、図示せずに説明するのが辛くて辛くて…(泣)。このサイトがきっと良いこと教えてくれます。 循環的複雑度 - Wikipedia

4. 行数

簡単なプログラムの割りにソースコードがやたら長い…そんなときは中身に大きな誤りを秘めていることがあります。そう、行数も立派な計測項目です。

番外編:バグ率

よくあるのは「ソースコード100行あたりバグ検出率」といったものでしょうか。100行ではなく1000行だったりしますが。これはソースコードを記述するスタイルや、「何を以てバグと数えるか」といった、計測の根本を覆しかねない要因がいくつかあるので、しっかりと定義をした上で使いたい項目です。ソースコードの機械的な処理による測定は不可能で、開発チームを管理するようなツールでのデータを使って計測することになります。また、プログラムの部品によって数値の高低は変化してきますから尚更厄介です。例えば、変数をカプセル化しているだけのクラスでは、著しく低いバグ率が弾き出されるでしょう。

もちろん、ここに挙げた以外にも多くの項目があるので探してみると良いでしょう。各プラットフォームに即した、新しい項目を自分達で作り上げるのも良いですね。

採用/不採用について

さて、これらの項目を採用するかどうかですが、各項目について次のような評価を下していく事で採用/不採用を決定すると良いでしょう。

  • 機械的な作業で数値化することができるかどうか。 … そもそもこれができないと、話は始まらないですよね。場合によってはコンパイラ的な動作をさせないといけない事もあるでしょう。
  • 作りの良し悪しによって、数値の高低に有意の差が生じるかどうか。 … この差が無いと「評価」することができないですね。

閾値(合格点)

過去の複数のソフトウェア製品を引っ張り出して来て、採用する各項目について

  • 数値化したときの評価
  • そのプラットフォームの熟練者による主観的評価(五段階評価など)

とを見比べた上で、閾値を設けていくと手っ取り早いでしょう。
もちろん、初めて取り組むプラットフォームでは熟練者は居ないでしょうから手探りにはなりますね。
え?過去の製品が存在するにも関わらず熟練者が居ない? そんなことを言われる会社さんは早々にそのプラットフォームから撤退することをお勧め致します。もしもそのプラットフォームが魅力的なのであれば、どこかから熟練者をヘッドハンティングして来て下さい。

複合的な評価

ソフトウェアではなく工業製品における品質管理には「QC7つ道具」というものがあります。7つの道具を使って品質を測定し、異常を早期発見しようという取り組みです。この道具の一つに「散布図」というものがあります。2種類の適当な測定項目を選択し、その値を使って座標平面に打点していき、その2項目の相関を知る、という道具です。ソフトウェアメトリクスでも同じような分析をするときっと面白いはず、と筆者は予想しています(が、結構面倒臭い作業なので、余程ヒマな時じゃないと難しいでしょう)。例えば「行数」と他の項目との相関関係を見ると、いろいろ見えてきそうですよね?

PDCA

アンチパターンでも挙げたように、一旦設定した項目や閾値もプラットフォームが変われば変わります。それと同様に、求められる仕様や品質など様々な要因によって「何が適切か」は変化していきますので、製品を1つリリースする度には見直し&再設定を繰り返していきたいところです。

最後に

筆者もこれからメトリクスの話を展開していこうとしている身分ではありますが、皆さんも未開の地でのメトリクス、ぜひお試し下さい。