■第12回ホットセッション  
「ソフトウェアメトリクスの最新動向と活用について」■

• 「Intl' Software Metrics Symposium (Metrics2004)の紹介+α」
  　　　　　　　　　　　　　　　　　　　東洋大学　野中　誠　氏
  
  　最初に、IEEE Computer Society主催の国際シンポジウムである Metrics2004の概要、及び、発表の中で興味深かった５テーマの研究内容を ご紹介いただいた。
  　�@ペアプログラミングの生産性とペアの満足感の関係　 �A工数見積り誤差　�Bレビュー方法による効率性・有効性の違い �C工数見積もりを他社データを使って行なった結果　�Dテスト・ファーストと テスト・ラストの生産性・品質の違い
  　理論的な研究は意外に少なく、測定による手法評価が多かったとのこと。
  　次に、野中氏が某企業の新人ソフトウェア技術者研修で実施した実験を ご紹介いただいた。設計レビューとソースコードレビューを、TCBR(Test Case Based Reading)とCBR(Checklist Based Reading) の２つの手法で実施し、 結果を比較した。実験の範囲では、TCBRの方が効率的・効果的であることが 確認された。
  　最後に、地道なメトリクス計測の努力をして結果をS-open等で共有するように 提案されて、講演を締めくくられた。
  
  Ｑ：ＴＳＰ（チーム・ソフトウェア・プロセス）の良い資料はないか？
  Ａ：日本語の本があったが、多分、絶版になっていると思う。
  　　ＳＥＩのホームページが参照可能。
  　　なおカスタム主催のＴＳＰ講演（３月）を引受ける見込みである。
  
  Ｑ：コードレビューでTCBRの方が効果的だったのは何故か？
  Ａ：とくにモジュール間インタフェースに関する欠陥が多く指摘
  　　されたためではないか。なお、実際には設計レビューについて評価
  　　したかったのだが、分析可能な程の数のバグが指摘されなかった。
  　　
  Ｑ：シナリオベースとチェックリストでは、チェックしている対象が違うのでは？
  Ａ：実際には、状況に応じて手法を組み合わせて使う方がよい。
  
  Ｑ：テストケースを作成する過程でも、バグは見つかったのでは？
  Ａ：実験では、テストケースは事前に野中氏が用意しており、実験参加者はケース作成に関わっていなかった。
  
  
• 「ソフトウェア・メトリクス盛衰記」　日立ソフトウェアエンジニアリング株式会社　山浦 恒央 氏
  
  　ソフトウェアメトリクスの世界的な歴史を５つの時期に分類し、 おのおのの特徴を説明していただいた。1968年から�@混乱期、�A胎動期、 �B活動期、�C反抗期を経て、現在は、�D成熟・定着期であると位置づけ られた。この変遷で、メトリクスの目的や意義は組織に定着したが、 メトリクスは、結局、�@や�Aの時期に提案されたソースコード行数 （ＬＯＣ）と発生バグ数を軸とすることに戻った感があるとのこと。
  　日立ソフトさんでは、全社的に、予測バグ数と予定テストケースを もとに管理曲線を描き、実績を追記することで、品質と進捗の管理を 行っているそうである。時期は、コンパイルエラー・フリー後。
  
  Ｑ：管理曲線の予定値は、実績がすすんだ後、誰が是正するのか？
  Ａ：工数との兼ね合いで、なかなかできない。
  　　しかし、乖離度合いを見ることが主な目的なので、品質管理、工程管理
  　　には、大変役立っている。
  
  Ｑ：メトリクスが使われるための条件の一つに客観性をあげているが、
  　　顧客満足度のような客観性がないものも使えるのでは？
  Ａ：それらは、扱いにくい項目ですね。　　
  
  Ｑ：日立ソフトさんで、設計工程でのメトリクスの事例はないか？
  Ａ：先進的なプロジェクトでは、モジュール数、データ数等の計測事例がある。
  
  Ｑ：設計工程で、テスト工程のように予定バグ数を曲線で描き、管理する例はないか？
  Ａ：全社的に実施するということはまだない。
  
  
• 「エンタプライズ系の見積もりについて」　独立行政法人情報処理推進機構　石谷 靖 氏
  
  　ＩＰＡソフトウェアエンジニアリングセンター（ＳＥＣ）における プロジェクトの見積もりの研究についてご講演いただいた。ＳＥＣでは プロジェクト目標としての見積もりをターゲットに研究を進めている。 そのカテゴリは、大きく分けて、「成果物から規模の見積もり」と 「規模から工数の見積もり」になる。いずれの場合でもプロジェクトの 特性に合わせて見積もり結果を補正するための要因を特定し、数値化 すうことが重要である。
  　ＳＥＣでは、以下の２つの方法を使い、実際の企業のプロジェクトと 協力して、要因の特定と数値化に取り組んでいる。
  ・プロジェクトデータが多い場合 ＯＳＲ法
  　データマイニングにより、要因を導き出す方法。
  ・プロジェクトデータが少ない場合 ＣｏＢＲＡ法。
  　データをあまり持たない場合でも専門家の頭の中にある知識を 数値化/形式値化して組織で活用できるようにする。専門家に要因を ヒアリングして、そのポイントに限って分析をして形式化する。
  
  （参考） IPA URL：http://www.ipa.go.jp/
  
  Ｑ：ＬＯＣベースの見積もりが中心であるが、Ｗｅｂ開発などコンポー ネントベースの開発が増えており変える必要があると感じている。
  何かよいアプローチがあるか？
  Ａ：現時点で、あまり良い手法はないと認識している。ただし、 コンポーネントベースでも同じ手法は使えると考えている。
  ＳＥＣでもコンポーネントベース開発についても、将来、研究対象と する予定である。
  
  Ｑ：シリーズ製品などの繰り返し開発で使える良い見積もり手法はないか？
  Ａ：改造もとのソフトウェアなどが大きな要因になると思っている。
  現在、ＳＥＣでも議論を重ねている最中である。
  
  Ｑ：ＳＥＣから来年度にどのくらいのアウトプットがでてくるか？
  Ａ：分析結果をＷｅｂで公開していく予定である。
  
  Ｑ：ＯＳＲ法の結果について、ツールを使った場合と使っていない場合で 大きく異なるが、本当か？
  Ａ：欧州の宇宙開発プロジェクトの分析結果である。正しいと認識している。
  
  
• 「メトリック・何でも測っちゃおう」　株式会社東陽テクニカ　二上 貴夫 氏
  
  　１０年間Ｃ言語の解析をした実績からいろいろなことがわかってきた。 バグの下限値、潜在結果の多さ、ユニットテストの実施状況、複雑度の 範囲などがわかってきた内容である。
  　ソフトウェア工学だけでなく、一般工学の観点からもわかりやすく メトリックは重要性を解説いただいた。ミクロな視点では、「ヒューマン エラー」、「加工精度」などが重要なポイントである。マクロな視点では、 「大きくなると危なくなる」、「見かけの数字にだまされない」ことが 重要なポイントなる。これらの考えをソフトウェアに当てはめても同じ ことが言える。
  　まとめとして、メトリックを計測する上では、しぶとさが大切である と強調された。
  
  Ｑ：手戻り工数の定義についてよい案はないか？
  Ａ：手戻り工数は、ばらつきが大きい項目だと認識している。
  私のところではとらないデータの一つにしています。
  
  Ｑ：関数分布というメトリクスはどういうメトリクスか？
  Ａ：ドメインごとの関数がどのフォルダに入っているかというメトリクス
  
  Ｑ：メトリクスのタブー（欠点が協調して見える）で解決する方法はあるか？
  Ａ：まず、本人に教えてあげる。これにより、不具合は修正されるという メリット面が見えてくる。それから、全体として取りまとめて報告する。