最適なレビュー実施と現場が喜ぶメトリクスの研究
Research of metrics with which the best Review execution and site are pleased
主査 三浦 邦彦 矢崎総業（株） 副主査 藤巻 昇 （株）東芝 リーダー 中野 誠 ＴＩＳ（株） 小澤 廣晃 （株）エスシーシー 吉田 直美 （株）日立製作所 伊藤 秀樹 アビームシステムズ（株） 有田 亮一 沖通信システム（株）1.
研
研
研
研究概要
究概要
究概要
究概要
近年、ソフトウェア製品市場では顧客ニーズの多様化が進んでいる。その為、開発 者側では今まで以上の生産性の向上と安定した高品質の確保が求められている。一般 的な対応として、開発上流工程において成果物の不具合を摘出し対応を実施する事が 考えられる。その一手段として活用されている活動にはレビューがある。 しかし、レビューをただ実施するだけではなく、これまで以上の品質確保の考慮お よび即時に対応を実施する事が必要となっている。そこで、本研究ではレビュー実施 とその結果から即対応が出来るレビュー品質の評価を定量化する方式を検討しパイロ ットを実施した。Abstract
Recently, the diversification of the customer needs is advanced in the software product market. Therefore, securing an improvement of productivity more than before and a steady high quality is requested on the developer side. It is possible to execute correspondence by the removal of the trouble of the product in the developmental style process as general correspondence. There is a Review in the activity that has been used as the one means.
However, the review is not enough by itself. More than ever, it is necessary to consider securing the level of quality and actions must be taken quickly based on the results of the review. We have created a method to quantify the evaluation of the quality of the review itself and allow for actions to be taken immediately; this method has been examined, and a pilot has been executed.
第
第
第
2.
テーマ
テーマ
テーマ
テーマ 選定
選定
選定
選定の
の 理由
の
の
理由
理由
理由と
と
と 背景
と
背景
背景
背景
近年、プログラムが高度化、複雑化、大容量化されるに従ってソフトウェア製品の 品質見極めも複雑化しつつある。特にテスト工程でのバグは、バグ原因が上流工程（仕 様／設計）段階の場合は、手戻り工数が発生し、結果として予算の超過や、納期遅延 となる場合がある。そのために、いかに上流工程で品質を作り込むか、上流工程で品 質を見極められるかが重要である。一方、現場では上流工程での品質確保を図るべく、 設計レビュー時のレビューア、レビュー時間の確保をするものの、時間の効率化、指 摘事項の質向上といった、常に生産性を意識した行動を求められる。本グループメン バーは、開発部門が半数以上と現場に近い部門で構成された。そこで、これらの問題 を解決するために、レビューにおける成果物の品質評価を定量化することによって、 現場自らが判断を行い適切な処置が行えること、つまり「現場が喜ぶメトリクス」を 目的に以下の段階でのメトリクスについて研究を行った。 ・レビュー実施時の指摘事項の整理（指摘と原因分類） ・レビュー実施後の評価（レビュー成果物の品質評価）3.
活動目標
活動目標
活動目標
活動目標
「現場が喜ぶメトリクス」を目的に、次のことを本グループの目標とした。 １） 現場が喜ぶレビュー指摘と原因分類の定義 ２） 設計成果物の品質評価の精度向上 ３） レビュー評価結果からのフォロー、安心感の提供4.
活動内容
活動内容
活動内容
活動内容
この一年の活動内容を「表 1:活動経過」に示す。 表１:活動経過 日程 日程日程 日程 活動内容活動内容 活動内容活動内容 2008/04/18 • 研究会メンバー自己紹介と検討課題洗い出し。グループ分 け 2008/05/22 臨時会開催 • 各社の現状課題の意識あわせ実施 • 工程の区分と測定指標（メトリクス）の雛形を検討し併せ て各社の課題について意見交換 2008/06/08 • 各社課題から絞り込み、スコープを検討（レビュー実施と 終了判断）2008/07/10～11 • 計 画 段 階 か ら の レ ビ ュ ー 実 施 手 順 と レ ビ ュ ー 実 施 後 の 終 了判断、及び、 工程終了判断のメトリクスの検討 • 併せて現場に役立つセルフメトリクス評価方法の検討 2008/09/16 • 試行に向けての準備（測定データ、データ区分の検討） 2008/11/14 • 測定データの試行および評価 • 試行結果の検討、課題の整理と方向性を審議① • 論文骨子の検討 2008/12/19 • 試行結果の検討、課題の整理と方向性を審議② • 論文骨子の検討 2009/01/09 • 試行結果の検討、課題の整理と方向性を審議③ • 論文骨子の検討 2009/01/09 ～ 02/01 • 報告書作成 • 報告書レビュー 2009/02/02 • 報告書提出
5.
研究成果
研究成果
研究成果
研究成果および
および
および考察
および
考察
考察
考察
本分科会ではＶ字型開発モデルにおけるソフトウェア開発での上流工程・外部設計 成果物の品質を確保する方法について研究を行った。研究のスコープは成果物レビュ ーで取得し得るメトリクスの活用とした。5.1
成果物品質
成果物品質
成果物品質
成果物品質を
を
を
を 評価
評価
評価
評価する
する
する上
する
上での
上
上
での
でのメトリクス
での
メトリクス
メトリクス
メトリクス の
の見直
の
の
見直
見直
見直 し
し
し
し
5.1.1 レビューレビュー 指摘分類レビューレビュー指摘分類指摘分類指摘分類 レビュー結果の評価を行う上で、設計本質にかかわる指摘なのか、単に表記上の誤 りで本質にかかわるものではないものを分別して成果物品質の評価の精度を向上させ る目的として、レビュー指摘分類を下表の５パターンとした。 その観点は次の２点である。 • 設計成果物に対する指摘としてその設計内容については「漏れ」「相違」「あい まい（冗長）」で分類できると考えたこと • 「ケアレスミス」や「記載に当たっての標準化ルールに沿っていない」といっ た設計書表記上による指摘を分別したかったこと 表 2：レビュー指摘分類 レビュー レビューレビュー レビュー 指摘指摘指摘指摘 分類名分類名分類名分類名 定義定義 定義定義 記述漏れ 設計成果物に記載されるべき事項が書かれていない 記述相違 設計成果物に記載されている事項が正しくない
記載あいまい 設 計成 果 物 に 記載 さ れ て いる 内 容 が 冗長 で 複 数 の解 釈 ができる パンチミス 誤字脱字や表記上の誤りで、設計内容に問題はないと判 断されるもの 標準化違反 プロジェクトでの記述ルールに沿っていないもの 指摘分類を行うに当たっては、その内容が‘誤字脱字’や‘コピーペーストによる 誤りのコピー増幅’についてはパンチミスに含まれるとしてカウントした。 5.1.2 レビューレビュー 指摘原因分類レビューレビュー指摘原因分類指摘原因分類指摘原因分類 指摘の原因区分をより細かく分類して不備を発生させた傾向を具体的に捉えやすく することを目的として、見直し前の４パターンから８パターンとした。その観点は次 の２点である。 • 上流工程成果物が原因と考えられる場合、自工程での設計担当者に問題がある ケース、上流工程成果物に問題があるケースを分別することによってレビュー 対象成果物の品質評価の質が高まると考えたこと • 方式面や環境面での知識不足／理解不足が原因となる指摘は、業務要件に対す る理解不足に比べて指摘内容の影響が大きいと考えたこと 表 3：レビュー指摘原因分類 レビュー レビュー レビュー レビュー 指摘指摘指摘 原因指摘原因原因分類名原因分類名分類名 分類名 定義定義定義定義 上流工程成果物の誤り イ ン プ ッ ト と な る 上 流 工 程 の 成 果 物 に 誤 り があったことが原因 上流工程成果物の内容理解不足 上流工程の成果物に対する理解不足が原因 上流工程成果物の内容誤解 上 流 工 程 の 成 果 物 内 容 を 正 し く 理 解 で き な かったことが原因 環境理解不足 開発環境を理解できていないことが原因 実装方式スキル不足 開 発 方 式 に 対 す る ス キ ル が 不 足 し て い る こ とが原因 業務要件理解不足 業務要件を理解できていないことが原因 仕様漏れ 顧 客 か ら の 業 務 要 件 仕 様 に 漏 れ が あ っ た こ とが原因 ケアレスミス 不注意による表記ミス
5.1.3 レビューレビュー 指摘密度レビューレビュー指摘密度指摘密度指摘密度（（（（ 件件／件件／／／10 ページページページページ ））） ） 指摘事項の発生割合のメトリクスである「レビュー指摘密度」は、指摘件数を１０ ページあたりの発生件数に換算したものとした。
5.2
試行
試行
試行
試行結果
結果
結果
結果
前項記載にしたがって見直したメトリクスを活用して、実際の開発プロジェクトで の上流設計工程成果物レビューに適用し施行とした。 ＜ ＜ ＜ ＜参考参考参考参考：：：：施行対象施行対象施行対象施行対象ののプロジェクトののプロジェクトプロジェクト内容プロジェクト内容内容内容＞＞＞＞ ・ システム形態 クライアント／サーバー型 ・ 開発規模 １２０人月 ・ 業務 金融・営業支援系（同規模の６サブシステムから構成） ・ 開発形態 Ｖ字型開発 5.2.1 指摘分類指摘分類 の指摘分類指摘分類ののの 見直見直 しの見直見直しのしのしの 実施実施実施実施 従来指摘の内容を「漏れ」「誤り」「あいまい」という点から分類していた結果に対 して、一次精査として明らかな‘誤字脱字’や表記のケアレスミスを分別することに より、指摘分類・原因をより設計内容に絞っての分析が可能となった。表 4 に、分別 による件数の分布を示す。 表 4：指摘分類見直し この結果、評価分析としては見直し後の「記載漏れ」「記載誤り」「記載あいまい」 に分類されたものを対象とした。６６件（２４％）は評価分析対象外となった。 ※この６６件は「漏れ」「誤り」「あいまい」との指摘になっていたが、内容の再監 にて誤字脱字等のパンチミス・標準化違反であることが明らかであるため設計内容の 不備から分別した。その上で設計者にミスの傾向が見られれば改善指導を個々実施し た。5.2.2 レビューレビュー 指摘原因分類レビューレビュー指摘原因分類指摘原因分類指摘原因分類によるによるによるによる 見直見直見直 し見直し 及しし及及及 びびびび再監者再監者 による再監者再監者によるによるによる 精査結果精査結果精査結果精査結果 原因区分の見直しとあわせて、一次評価者と再監者との見直しを行った。区分の見 直しによる原因の細分化と再監による見直し結果は以下のとおりである。 表 5：指摘分類見直し結果 分類と再監により、４項目の原因区分からは傾向が捉えにくかった状況から以下の 傾向を掴むことが可能となった。 • 一 次 評 価 の 際 に は 上 流 設 計 成 果 物 の 不 備 に 起 因 す る 件 数 が 多 か っ た が 再 監 の 結果、自工程設計作業に原因がある件数のほうが多く上流設計成果物の品質に は大きな問題はないと判断 • シ ス テ ム 実 装 方 式 や 環 境 面 に 対 す る 知 識 ／ ス キ ル 不 足 に よ る 件 数 は 割 合 と し て大きなものではないのでこの面での懸念は小さいこと また、上流工程成果物の理解不足や誤解については、再監者を固定化することによ り全レビュー記録に対してサブシステム間を横断して同一観点で再監することが可能 となり、評価判断が統一化されるとともに各担当者の傾向も見ることもできて個別指 導を行う効果も確認された。 5.2.3 レビューレビュー 指摘密度レビューレビュー指摘密度指摘密度指摘密度のののの サブシステムサブシステム 間相対評価サブシステムサブシステム間相対評価間相対評価の間相対評価ののの 実施実施実施実施 指摘件数・指摘率をサブシステム間で比較評価し、他システムと乖離している値と なったものについては、差異が出たことの原因を精査して定性評価を行った。図 1 に 表記されたデータ中にある、３と４は他サブシステム（１，２，５）と比べて指摘率 が低く、レビュー・プロセスに問題があった可能性があるため、指摘の内容と開発機 能の難易度についての考察を行った。その結果指摘率が低くなった原因としては以下 の２点によるものであり、品質上の大きな問題はないと判断をした。 • 既存サブシステムの類似機能開発であるため、過去の開発資産が活用できた事 • 帳票出力が主機能で開発難易度が他サブシステムに比べて低かった事 パンチミス・標準化違反を除いたサブシステム別 指摘率 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 1 2 3 4 5 サブシステム １ ０ ペ ー ジ 当 た り 件 数 図 1：指摘率
5.3
考察
考察
考察
考察
総括として、レビュー指摘分類、指摘原因区分を再定義することは、 ① 指摘が設計内容の本質にかかわるものか（表記上の不備などの）本質にはかか わらないものかの分別の明確化 ② 原 因 区 分 の 細 分 化 に よ り 設 計 担 当 者 へ の フ ィ ー ド バ ッ ク を よ り 具 体 的 に 実 施 することが可能 等の効果があり、成果物品質に対する評価の精度を上げるための方法として有効であ ったと考える。以下詳細を記述する。 5.3.1 誤記誤記 ・誤記誤記・・・ 標準化標準化標準化標準化 ルールルールルールルール 違反違反 を違反違反ををを 除外除外除外 することの除外することのすることの 効果することの効果効果効果 ・ 評価の対象を設計内容に合わせることが可能となり客観的な評価が可能 5.3.2 レビューレビュー 結果再監レビューレビュー結果再監結果再監結果再監によるによる レビューによるによるレビューレビューレビュー 結果結果結果 精度向上結果精度向上精度向上精度向上 ・ 複数人からなる一次評価に対して、同一視点での評価をプロジェクト・リーダ が実施することにより評価のばらつきを抑えて平準化することを実現 ・ 一次 評価 との 差異 が出 た場 合に は評 価者 との 評価 方法 の差 異是 正に より 精度 の向上とプロジェクト内での評価方針の統一化を実現 5.3.3 原因区分 の原因区分原因区分原因区分のの 細分化の細分化細分化細分化・・プロジェクト・・プロジェクトプロジェクト 特性プロジェクト特性特性 に特性ににに則則 した則則したしたした 内容内容内容内容 へのへのへのへの 変更変更 による変更変更によるによるレビューによるレビューレビューレビュー 結果精結果精結果精結果精 度向上 度向上度向上 度向上 ・ 標準的な区分を細分化し、また選択肢としてプロジェクト特性へのテーラリン グを行うことにより指摘の原因がわかりやすくなり、またお仕着せでない具体 的な原因の特定化を行うことが容易 ・ 「その他」を原因区分として原則使用禁止としたことにより具体的な原因追求 を実施 5.3.4 相対的評価相対的評価 による相対的評価相対的評価によるによるによる特異特異特異特異なななな 結果結果 からの結果結果からのからの 問題からの問題問題問題サブシステムサブシステム のサブシステムサブシステムののの 検知検知検知検知 ・ サブシステム間で指摘率について突出傾向が見られる場合は、基準値との乖離 とは別に突出傾向の原因分析を行うことにより問題傾向の把握が可能 5.3.5 指摘結果指摘結果 の指摘結果指摘結果ののの フィードバックフィードバックフィードバックフィードバック によるによる 設計者によるによる設計者設計者との設計者とのとのとの情報共有化拡大情報共有化拡大情報共有化拡大情報共有化拡大 ・ レビ ュー 結果 は設 計者 及び プロ ジェ クト チー ム内 への 評価 報告 によ る設 計書 品質の情報共有化を実現 最後に補足するならば、これまでの品質評価活動を通じてレビュー結果の評価は定 量評価の数値が一人歩きする傾向を感じていたが、今回その結果に加えて定性評価を 行い、その結果をチーム全体に連携することにより、より設計成果物の品質に対する 理解･問題点の理解が全体として深まり、次工程での留意事項として活用されることにつながった、と感じる。指摘の原因を細分化してその背景を定性評価し、その内容の 共有化はチームの弱点やプロジェクトの留意点を明らかにすることにつながり、弱点 対策の立案に対しても効果があったと感じる。
