ファイル TEF東海メトリクス勉強会 Summary3 1 3 5

1

第３章　測定の基礎

らち

測定とは、現実の世界における実体の属性へ

と数字や記号を割り当てるプロセスである。

このプロセスは、明確に定義された規則に従

って実体の属性を表現する形で行われる。

フェントン、フリーガー

マー

ク ^意味

いい感じ、ハッピー _{普通、ぼちぼち}

やな感じ、どんより、

こんな感じ記号って

？

2

３．１　測定の最初の課題

/* strncat()は、文字列 src から coutn 数の文字を文字列 dest に付加し、さら に終端に null 文字を付加する。重なるオブジェクト間でコピーする場合の 動作は未定義である　 */

char *strncat (char, *dest, const char *src, size_t count) {

char *temp = dest; if (count) {

while (*dest)

dest++;

while ( (*dest++ = *src++)) { if (--count == 0) {

*dest = ‘\0’; break; }

} }

return temp; }

ソフト生産性（ LOC/H ）を調べるとき、この関数の行数はいくつと数えますか？

コメント行も数えますか？　｝ だけの行は１行として数えますか？　改行だけの行 は？・・・

こういう場合は、「規則」を明示しましょう。

規則により、みんな同じ答えに到達するようになります。

測定の基礎

3

３．２　測定が取り組むべき課題

つまり、ソフトウェアの測定は、難しいんです。

抽象的であり、視覚化したり感触を確かめたりするのが難しい。 プログラムの複

雑性は、どう測 る？

そもそも複雑 性の定義って

？ ^{２時間で１００行のプ} ログラムを作り、その 中に５つのバグがあり

ました。

同じ機能のものを１ 時間で１行のプログ

ラムを作り、その 中に１つバグがあ

りました。

興味本位ですが、「生産性（ＬＯＣ／Ｈ）は？」と聞かれ ると、

測定の基礎

4

３．３　測定モデル

「測定不可能なものを測定可能にする」ためには、モデルが重要である。 モデルとは

抽象化されたもの

不要な要素を取り除いて実体や概念を特定の観点からとらえる。 モデルを使うと

重要な点に焦点を当てて、 無関係なものを無視し、

実体について仮説を立てて論理的に考えることができる。 モデルがあれば

測定が可能になる。 モデルには

テキスト　　　　ダイヤグラム　　　　アルゴリズム ことば　　　　　　　絵　　　　　　　数字 　　　　の３種類がある

上４行目「モデルとは抽象化されたもの」とは？ 下４行目でいうダイアグラム（絵）は、抽象的だ が、テキストやアルゴリズムは、具体的だと思う んだが・・・

一言ずつが重い

測定の基礎

5

３．３．１　テキストモデル（１

テキストモデルは、たいてい

／２）

最も効果が小さいが、最も一般的である。

しかし、複雑な状況や法則を言葉だけで適切に表現するのは難しい。 例： 工数 ：　製品の開発に必要な時間

　　　一般に、規模の関数であり、コストを決定。 フィーチャ ：　開発対象製品への要求

規模 ：　開発対象製品の規模。

　　　一般に、規模はフィーチャの関数である。 欠陥 ：　製品の不完全性

　　　一般に、欠陥は　規模　と　スケジュール　の関数である。 スケジュール：開発時間全体。主要マイルストーンの達成にかかる時間。

　　　一般に、スケジュールは　工数　と　リソース　の関数である。

利点： 各項目は明確に定義され　わかりやすい 欠点： 項目間の関係を視覚化するのが　難しい

効果が小さいとは 思えない何と比べ て小さいの？

スケジュールは、 時間というより日 数の方がしっくり する。でないと工数との 区別がない気がす る

上記の関係は、２ページ後の３．３．２　ダイアグラムモデル参照

測定の基礎 　測定モデル

6

３．３．１　テキストモデル（２

また、

／２）

　テキストモデルは、「ソフトウェア開発」という抽象概念に構造を与えている

。

ソフトウェア開発を取り巻く法則性を洞察する際、メタファや経験則が頻繁に使 われる。※ メタファー（ metaphor ）は、隠喩（いんゆ）、暗喩（あんゆ）ともいい、伝統的には修辞技法のひとつとさ

れ、比喩の一種で、たとえであることを明示する形式（直喩。例えば「～のようだ」のような形式をとるもの）で はないものを指す。

例：人生はドラマだ。　　　　出典： Wikipedia

これがうまくいくのは、メタファと関連づける意味に幅を持たせられるからであ る。

ソフトウェア開発のテキストモデルとしての 　□メタファの例：

　　　・ワイルド・ワイルド・ウェスト　（無法ではあるが、開発に勢いがあ る状況の比喩）

　　　・アジャイル開発

　　　・デスマーチ　（プロジェクトが混乱した状態） 　　　・ソフトウェアファクトリ

　□経験則の例

　　　・「遅れているプロジェクトで開発要員を増やしても、さらに遅れるだけ だ」ブルックス

　　　・「プロトタイピングにより、システム開発工数を４０％削減できる」 バーンスタイン

測定の基礎 　測定モデル

7

３．３．２　ダイアグラムモデル

ダイアグラムモデルは、きわめて強力。

　例：ワインバーグ：システム洞察法　センゲ：最強組織の法則 実体や、実体間の関係、および法則性をモデル化できる。

フィーチャ

規模

工数

スケジュール 欠陥

リソース コスト

それぞれの関係を図で表す方が効果的な場合もあるが、適切な言葉を使うこと が最善の場合もある。

測定の基礎 　測定モデル

8

おまけ

ワインバーグ：システム洞察法

    内容は、自分自身や相手の心を理解するための観察プロセスをいくつかのステップに分 ける単純なモデルを採用し、これに沿って述べられている。このモデルの観察プロセスは

「取り込み」、「意味づけ」、「意義づけ」、「反応」の 4 つの主要な部分に分けられて いる。

1 章　「取り込み」では、「正確さ」をキーワードに、具体的な観察方法を述べている。 貧弱な観察が原因で起きる失敗例を取り上げ、なぜ失敗が起きるか、その理由を解説して いる。　 2 章「意味づけ」でも「正確さ」をキーワードに、取り込んだデータに対し、その意味 づけプロセスのさまざまな側面を検討している。いくつかの事例を紹介し、ささいに見え るデータからどれほど多くの意味が抽出できるかを述べているのは大変興味深い。

　 3 章「意義づけ」では、「関連性」をキーワードに意義づけの抽出について、

　 4 章「反応」では、「有用性」をキーワードに、適合的反応――思考から行動への翻訳 がどのようにモデル化されるか――について述べている。

　そして最後の 5 章では、高品質ソフトウェアの品質管理をはじめる際の必要最小限のス テップを記述している。品質管理の改善に興味のある管理者におすすめしたい。

（大塚佳樹） http://www.amazon.co.jp/dp/4320027078

センゲ：最強組織の法則

音を立てて崩れ去る日本の「経営神話」。終身雇用制も崩れつつある中、チームの問い直 しに迫られる日本企業の道は、自らが学習機能を持った「ラーニング・オーガニゼーショ ン」となる他にはない

第 1 部 最強組織の条件―ラーニング・オーガニゼーションとは何か

第 2 部 システム思考革命―ラーニング・オーガニゼーションの中核ディシプリン 第 3 部 ラーニング・オーガニゼーションの構築

第 4 部 創造への課題

第 5 部 組織学習の新しいテクノロジー 　 http://www.amazon.co.jp/dp/419860309X

9

３．３．３　アルゴリズムモデル

パラメータモデルとも呼ばれる。 実体間の関係を明確に表現できる。

例： 工数　＝　スケジュール　＊　リソース

１つのテストサイクル内で発見される欠陥数　＝　製品に残存してる欠陥 の３０％工数　＝　Ａ　＊　（プログラム規模^Ｂ）　＋　Ｃ

Ａ，Ｂ，Ｃはすべて実績データから導出された定数

測定の基礎 　測定モデル

10

３．３．４　モデルの例：応答時

テキスト、ダイアグラム、アルゴリズムの３つのモデルは、状況に応じて組合わせ

間

たり、単独で使用したりできる。

【例】○ テキスト：応答時間（ＲＴ）はエンターキーを押してから画面上に応答が現れる までの 時間を測定する。メトリクスは、標準時間内のＲＴの平均となる。

○ ダイアグラム：

○ アルゴリズム：ＲＴ＝標準時間内における　（応答開始ー入力終了）　の平均

（１）モデルは、すべての測定対象に存在しなければならない。

（２）モデルがあれば、システム内の実体および相互作用を一定の方法で文書化で

（３）基礎となるモデルを参照せずに、データを解釈したりシステムに対する理由きる。 づけを行ったりできない。

（４）モデルを使用することで、戦略の改善を検討し、期待される結果を予測する ことができる。

平均入力プロセス 平均表示プロセス

時間

ＲＴ

上５行目：「メト リクスは・・・平 均となる」意味不

明。

（１）すべての測定対象は、モデル内に存在しなければならない　の間違い

（２）は何を言いたいのか不明

（３）データの勝手な解釈はダメと言うことかもしれないが、モデルもある意味勝手な解釈から始 まっている。何かおかしい。

測定の基礎 　測定モデル

11

３．３．５　汎用メトリクスパラダイム：あらゆるもの

の測定方法

汎用メトリクスパラダイムは、 単純な手段であり、

実世界に存在するすべてのものについて

純粋に視覚的で定量的なモデルを生み出す。

作成方法１．モデル化の対象について、定義によって求められる最小限まで削減する。 すべての余計な情報を取り除く。

２．紙上または頭の中でこれを視覚化する。

３．実際に作業するか、または想像の中で、これを均等に分割する。 ４．これを測定する　（たとえば、分割したものを数える）

これによってできたモデルを操作、推論、実験、発展させることができる。

作成方法の１は難しい。「定義 によって」の定義を間違えれば

、都合の良いデータだけを取る ことになる。

測定の基礎 　測定モデル

12

３．４　メトリクスのためのメタ

抽象的な概念を実証的な測定によって表すモデルは、別の方法でも作成できる。

モデル

－カンのメタモデル－

１．概念を抽象化して定義し

２．その後　運用上の定義を作成し ３．現実世界の測定を特定する。

□ 「抽象的な～作成できる」何が言いたのかわから ない。別の方法で作成できて何がうれしいの？

□ ２・３の意味が良くわからない。

運用上の定義は○○だけど、実際の測定は○○で 行うということ？

□ 直接・間接メトリクスは、メタモデルの中での言 葉の定義？　それとも一般的？　なんでこの章で 説明しているのか、意図が読めない。

概念 定義

運用上の定義 現実世界での測定 抽象

実証的 世界

応答時間

システムが入力に応答するまでの時間量の平均

（応答表示の開始時刻－エンターキーを押した時刻）の平均

標準時間内における（送信時間＋サーバ内の経過時間＋表示時間）の平均

※ メタモデル（ Metamodel ）とは、所定の問題領域でのモデリングに適用可能で有益なフレーム / 規則 / 制限 / モデル / 理論を意味する。 (Wiki)

直接メトリクス：直接定義して測定可能なソフトウェア属性

例：システム内のモジュール数、プロジェクトに割り当てられた開発要員数 間接メトリクス：計算によって求められるもの

例：１０００コード行あたりの欠陥数、週小言に作成される平均コード行数 平均

測定の基礎

13

３．５　測定の効力

一般に、測定を実施すると、良い測定結果がでるようにがんばったり、細工をしま うことがある。

なぜなら測定とは、評価の対象を明確に表現したものであり、人より良く見せたい と思うのが人間のサガだからである。

また、最善の結果を得ようとしても、メトリクスが誤っていれば、非生産性な行動 が簡単に引き起こされてしまう。

－例－　１．「照明を明るくすると生産性が上がる」と考え、実験した。結果、生産性は 上がった。

　２．別の要因を変え、結果を測定した。生産性は改善した。 　３．要因を元に戻し、結果を測定した。生産性は改善した。

　つまり、注目して測定したことが違いをもたらした。この結果は「ホーソン効 果」と呼ばれる。

教訓：　測定効果の価値を認めるとともに、測定によって行動が変わることも覚えておく 必要がある。

測定の基礎

14

おまけ

ソフトウェア工学の祖の一人である、トム・デマルコが、最近 IEEE Software 誌に、 過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。

「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。 http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

1982 年に、デマルコは有名な「計測できないものは制御できない」という一文から 始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著 を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むし ろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコ ントロールし、人間の役に立てることをその定義としており、そこでは測定を元にし たコントロールという概念はその中核にあるものだ。だから、「計測による制御」と いう概念を疑うことは、「ソフトウェア工学」というものの存在、あるいは、意味を 大きく問う問題でもある。

15

おまけ

では、計測しないで制御する、という方法があるというのだろうか？

この記事のなかで、例えば、 GoogleEarch や Wikipedia といったソフトウェアが、果 たして計測と制御という管理で作られただろうか、と問うている。そして、２つの種類 のプロジェクトを例にし、

Project A: 100 万ドルのコストを使って 110 万ドルの価値を作る。

Project B: 100 万ドルのコストを使って 5,000 万ドル以上の価値を作る。

「計測と制御」は、 Project A の世界では有効だが、 Project B の世界ではほとんど意 味をなさない、と指摘している。これは、

ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含ま れており、その中では、「工学」の概念は「ポイントを外している」

ということだ。

デマルコは、冒頭に上げた本を書いた自分を「若かったころ」という言い方をして、メ トリクス賛美を実際に悔いているように思われる。

16

おまけ

ちょっと衝撃的な記事だが、実際には、「ソフトウェア工学は誤りだった」、という よりも、「ポイントを外しつつある」というのが正しい。ソフトウェア開発にもっと も大切なのは、そこには無かったのだ。現実のソフトウェア開発は、「計測と制御」 で語れる部分の「外側」に徐々にフォーカスを移動しつつある。

デマルコの最後の結論の部分を引用する。

Software development is and always will be somewhat experimental.

The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought

to have been.

ソフトウェア開発は、いつも、ある種「実験的」である。実際にソフトウェアを構 築する行為は必ずしも実験的ではないが、ソフトウェアの構想を作る行為は必ず実 験的である。そして、それこそ我々が焦点をあてるべきところであり、ずっと焦点 をあてるべきところであったのだ。

「測定できないものでも制御できる」 と言っているように受け取れます。 」　 (biac さん )

17

おしまい

ご清聴いただき、

ありがとうござい

ます。

静岡ホビーフェ ３／２７までア

（出店もあるで よぉ）