ロジャーS.プレスマン, 実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識, 翻訳版（原本は第6版）の「第15章 成果物に関するソフトウェアメトリクス」に、私が学生にうまく伝えられなくてもやもやしていることが言語化されていたのでメモ。
困っていること
所属研究室では、新しいソフトウェアの開発を研究テーマにすることが多いのだけれども、そのとき開発したソフトウェアの有用性や有効性、実用性を説得力ある形で示さなければならない。説得するときには定性的な説明（メカニズムや特徴による説明）と定量的な説明（データを使った説明）の両方を使うことが多い。所属学部が工学部なので、定量的な説明を求められることが多い。
で、学生に「定量的に開発したソフトウェアの有用性や有効性、実用性を説明しなければいけない」と伝えるのだけど、そうすると学生はとりあえず実験やデモを用意して、説明しにくる。ところが「その実験結果やデモの結果を通して、何を主張したいの？」「有用性（あるいは有効性や実用性）をその実験結果やデモの結果からどうやって説明するの？」と尋ねるとうまく答えられないという事態にしょっちゅう直面してしまう。
処理速度向上とか、省メモリ化とかなどの「実験結果＝主張」となりやすいものだと良いのだけど、「使いやすくなった」「より簡単になった」というものになると、「実験結果＝主張」となりづらい。実験方法すら明確じゃない（明確な方法の場合、一研究室だと実験できない場合がある）
一生懸命に「まず、仮説を考えて、次にその仮説を裏付けるためにどういうものを測定するべきかを検討して、期待される測定結果とその解釈を考えて、云々」と説明しているのだけど、どうにもわかってもらえない。
ロジャーS.プレスマン, 実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識, 翻訳版（原本は第6版）の「第15章 成果物に関するソフトウェアメトリクス」に、私が学生にうまく伝えられないことを明確に書いてあった。
これは、ソフトウェアだけに限らず、直接測定できないことを定量的に評価しなければいけない場合に役に立つのと思う。もちろん、実験メインの分野では別の言葉や概念を使って教えられていることだろうと思う。
測定とは何か？
p. 307で引用されているフェントン（N. Fenton）のソフトウェアの世界における測定に関する言葉。
測定とは、明確に定義された基準に従うことなどによって、数や記号を現実の測定対象についての属性として割り当てる手順のことである。物理学や医学、経済学、最近では社会科学においても、従来測定できないと考えられてきた属性が測定できるようになってきた。当然これらは、多くの物理学的な測定ほどには洗練されていない。それでも測定は実際に行われており、測定した結果にもとづいて重要な決定が行われている。対象の理解を深めるために『測定できないものを測定できるように』しなくてはいけないという考えは、ソフトウェアエンジニアリングにおいても他の分野のように強くなってきていると感じられる。
ここで述べられているフェントンの定義に従えば、ある物事の属性を測定をするためには、「明確に定義された基準」が必要であり、基準に従って「数や記号を現実の測定対象についての属性として割り当て」られないといけない。では、「明確に定義された基準」や基準に従って「数や記号を現実の測定対象についての属性として割り当てる手順」がわからないとき、あるいは、無いときはどうするか？自分で目的に適した基準や数や記号への割り当て手順を探しだしたり、編み出したりしなければいけない。
測定値、メトリックス、指標
ある属性に関して品質が向上したり、低下したりするメカニズムがはっきりしていない場合や、その属性の品質の向上とはどういうものなのかが曖昧な場合や、さらには、その属性自体について多くの人に受け入れられる定義が明確でない場合は、その属性自体を直接測定できない
p. 310 にソフトウェアエンジニアリング（あるいは本書）における測定値、メトリックス、指標の定義が記載されている。
- 測定値（measure)とは、製品またはプロセスの属性の程度、分量、寸法、容量、大きさを示す定量的なデータを表す。測定値は、１つのソフトウェアコンポーネントで発見されたエラーの数といった1種類のデータを収集することで得られる。
- メトリクス（metrics）とは、システム、コンポーネント、プロセスにおける特定の属性の定量的な測定値。メトリクスは、複数の測定値から導出される。たとえば、開発しているソフトウェアのソフトウェアコンポーネントごとのエラーの数の平均など。
- 指標（indicator）とは、プロセス、プロジェクト、製品そのものの重要な性質や状況を示すメトリクスや、その組み合わせ。
ちなみにこの本の第15章では、この p. 310の定義のあと指標という言葉がでてこない。後ろに登場するのはメトリクスのみ。そして、メトリクスは「メトリクスを導出する方法およびメトリックスの評価尺度」という意味にも使われている。
閑話休題。この定義に従えば、我々が何かを定量的に評価したいときに得たいものは指標となる。そして、実験および調査で得られるのは、測定値やメトリクス。なので、多くの場合、単独の実験および調査だけでは、定量的に評価を行うことができない。ある事柄の重要な性質を定量的に調べたいときには、複数の実験や評価によって、得られた測定値からメトリクス導出し、それらのメトリクスを組み合わせて指標にする必要がある。
測定プロセス
「〜について定量的に評価したい」と思ったならば、何を測定するのか、測定値からどのようなメトリクスを得るのか、さらには、それらのメトリクスを組み合わせて、どのような指標を得たいのかを検討しなければいけない。
p. 311 にロシュ（Roche）が提案した、測定プロセスが記載されている。
- 定式化：対象とするソフトウェアを適切に表す尺度やメトリクスの導出
- 収集：定式化プロセスで導出されたメトリクスを得るために必要なデータ（測定値）の蓄積および機構の整備
- 解析：メトリクスの算出および数学的なツールの適用
- 解釈：メトリクスの評価および品質に与える影響への考察
- フィードバック：メトリクスの理解にもとづいた、ソフトウェア開発チームに対するアドバイスの作成
良いメトリクスの特徴
同じく p. 311に良いメトリクスの代表的特徴が記載されている。
- メトリクスは数学的特性をもつことが望ましい
- 妥当な性質の時は増加し、想定外の性質の時は減少するようなソフトウェア特性をメトリクスが表現しているならば、メトリクスの値は同じ方法で増減しなければならない。（例えば、「暑く感じる」という現象をメトリクスで表したいとき、「さっきよりも暑くなっている」という変化に対応するメトリクスが「メトリクスの値の減少」になっていてはいけない。「メトリクスの値の増加」に対応しているべきということ。）
- メトリクスを公開したり、決定する前に、経験的にさまざまな背景からそれが有効であることが立証されなければならない。
また、pp. 312-313 にエジオグ（L. Ejiogu）が提案した効果的なソフトウェアメトリクスの持つべき属性が述べられている。
- 単純で計算可能なこと
- 一貫性があり客観的であること
- 単位や次元が一貫した使い方をされていること
- プログラミング言語から独立していること
- 品質を改善するための効果的なメカニズムの提案に役に立つこと（注：本書では「品質を改善するための効果的なメカニズムがなくてはならない」と書いてあるけど、たぶん、こちらの意味だと思う）
4番目を「特定の製品や手法から独立していること」と置き換えれば、ソフトウェアだけでなく、各種測定が難しいものを定量的に評価したいときに使うメトリクスが持つべき属性になると思う。本書では、あるメトリクスがこれらの属性をすべて満たしていないとしても、無いよりもマシならば捨てるべきではないと述べている。
GQMパラダイム
これらの定義や説明をふまえた上で自然に思い浮かぶのは「じゃあ、どういう指標、メトリクスを用いれば良いのか？」ということ。それに対するうまい手はないけど、考えるためのフレームワークは提案されているみたい。 p. 312 で紹介されている。GQM (Goal/Question/Metric) パラダイムがそれ。
バジリ（Basili）とウェイス（Weiss）によるGQMパラダイムは、有用なメトリクスをソフトウェアプロセスのあらゆる段階で得るための技術として考案された。GQMは、(1) 特定のプロセスアクティビティや製品の特性を評価するための測定目標を確立する。(2)目標に到達するために答えなければならない質問を定義する。(3)これらの質問に答えるのに役立つメトリクスを特定する。という３つの点を重視したパラダイムである。
測定目標は、目標定義テンプレート（goal definition template）を用いて定義していく。テンプレートの形式は以下のとおり。
- 選定の対象：（測定したいアクティビティや属性の名前）
- 分析の目的：（分析全体の目的）
- 対象の側面：（測定したいアクティビティや属性の側面や特性）
- 利害関係者：（この測定を必要とする人々のもつ観点）
- 測定の背景：（測定が必要となった状況や環境）
（p. 312 より）
このGQMパラダイムをどのように使うかの例については、以下の記事が参考になる。
学生にどう説明すべきだったか
学生は、ロシュの測定プロセスのうち収集プロセスだけを考えており、測定プロセスの定式化プロセス、解析プロセス、解釈プロセスおよび、そもそものメトリクスの選択プロセスを考慮外に置いていた。このため、定量的説明を行うために、実験や調査がどういう位置づけにあるのかを説明できないようになっていた。
GQMパラダイムでいう測定目標をまず設定し、その上で適切なメトリクスを決定するべき。その上で、収集プロセスを実行するための実験および調査を設計し、測定値を収集しなければいけない。
追記（2013年1月12日）
こちらのエントリーもこの話にとても関係あると思う。
