SQiP2010 D3-2 組込みソフトウェア開発におけるピアレビューの導入と定着化 Introduction and establishment of peer review in embedded software development ○永田 剛志1) ○Tsuyoshi Nagata1) （株）日立メディコ Hitachi Medical Corporation 阿部 賢一1) 中村 隆1) 矢沢澄仁2) Kenichi Abe 1) Takashi Nakamura1) Sumito Yazawa2) Abstract : Analyzing bugs detected in software development shows that most of bugs were made in design process. That means it is necessary that design verification should be carried out more in upper process. To review documents more efficiently and effectively, we decided to introduce peer review to software development process. But it is actually necessary to get the agreement with developers in design department to introduce it in software development process. Even if the introduction is accepted, it is difficult to apply peer review officially soon because many problems should be detected in the early step of introduction. This paper shows the points of effort and innovation for peer review introduced for the purpose of reduction of production rework and efficient development of high-quality software. 1. はじめに 近年顧客要求の多様化・高度化によりソフトウェアは膨大かつ複雑になり、さらに高品質の製品開 発が強く求められている。この要求に応えるためには設計・製造・検証の各フェーズにおいて継続し たプロセス改善と見える化が必須である。これを実現するため当社ではレビューの強化、コーディン グ基準と構文チェッカーによるソースコード品質の向上、テストプロセスの見直しによる効率のよい 効果的な検証等による改善を進めている。 本論文では、レビュー強化(レビュー品質向上)のために導入した技術的観点を重要視するピアレビ ューに関して、その導入から現在の活動である定着化推進までの過程と苦労した点や工夫した点につ いて述べる。 2. ピアレビューとは ピアレビュー(peer review)[1]とは、対象成果物(ドキュメント、ソースコード等)の欠陥除去を目的 とし、技術的な観点から問題点を発見するためのレビュー技法の一つである。ピア(peer)とは同僚と いう意味であり、レビュー参加者が対等な立場で自由に発言することができるよう、話しやすい雰囲 気を作ることが重要であるといわれている。 当社においては、このピアレビューを効果的に実施しやすくするため、以下のような取り決めを行 ってピアレビューを実施している。 • 少人数でも実施する。その際、 「司会役」 「読み手」 「作成者」等の役割を一人の参加者が兼務して もよい。 • 事前レビュー(以降、 「机上レビュー」と呼ぶ)を必ず実施する。ミーティングの前に対象成果物の 内容を理解することで効率のよいレビューミーティングができ、指摘を多く出すことができる。 • レビュー中、作成者に質問してもよいが、責めてはいけない。 • 指摘が多く出たことをほめ、決して対象成果物の質をレビューミーティングの場では議論しない。 上記の内容はピアレビューを実施する際に一般的に言われていることであるが、この中でいかなる レビューのときでも必ず対象成果物を事前配布して机上レビューを行うことが我々の特徴であると考 えている。 1) 株式会社 日立メディコ 共通ソフト開発センタ Hitachi Medical Corporation, Software Engineering Center 〒277-0804 千葉県柏市新十余二 2-1 2-1, Shintoyofuta, Kashiwa-shi, Chiba-ken, 277-0804 Japan 2) 日立ソフトウェアエンジニアリング株式会社 エンベデッドシステム事業部 Hitachi Software Engineering Co.,Ltd., Embedded Systems Group 〒244-0801 横浜市戸塚区品濃町 549-6 549-6, Shinano-cho, Totsuka-ku, Yokohama, 244-0801 Japan SQiP2010 D3-2 3. ピアレビューの推進 ソフトウェア開発におけるピアレビューの実施は、品質の向上や全体の開発期間の短縮などの効果 が期待できる。しかし設計工数が増加するため、設計工程の時間をより多く確保する必要がある。そ こで、ピアレビューを推進するためには、レビューを行う開発者や部課長、および会社幹部にピアレ ビューの重要性を理解してもらうと同時に、設計工数が増えることも認識してもらう必要がある。以 上のことから、次に示すステップでピアレビューの導入を図ってきた。 ① 開発者がピアレビューを実施できるようにするため、教育を行うと共にガイドラインを作成し、 レビュープロセスを明確にした。 ② レビュープロセスに従って試行し、発生した問題を抽出・解決するなど、全展開へ向けて活動 した。 ③ 試行で得られたノウハウを基に本格的な定着へ向けて各部署でピアレビューを実施する。 ここでは①を「導入期」(2008 年 2 月～2008 年 7 月)、②を「試行期」(2008 年 8 月～2009 年 6 月)、 ③を「定着期」(2009 年 7 月～至現在)と呼ぶことにする。 3.1 導入期(2008 年 2 月～2008 年 7 月) (1) 目的 ピアレビューの導入を決定し、試行するために必要な準備を行う。 (2) 実施内容および検討事項 ピアレビューを円滑に導入するためには各部署の理解を得ることが必要で、各部署の開発者から構 成されるワーキンググループを中心にピアレビューの導入準備を推進した。さらにコンサルタントや、 組込みソフト開発をサポートする日立製作所の事業部の協力も得て進めた。 この体制の下、会社幹部には設計工数の増加はあるが、品質を向上させる重要性の理解を得るため、 少人数での face to face meeting を設定した。各部署の部課長に対して、ピアレビューは「技術的な レビュー」であり、審査・承認レビューなどとは性格が異なり、不具合を多く摘出することが大事で ある、即ち、不具合を摘出することは “ほめる”ことであり”叱る”ことではない、との主旨を徹底 させるための説明会を開催した。またピアレビューを行う開発者には、ピアレビュー教育として講義 と演習を実施した。このような教育活動と並行しピアレビューをどのように展開するかを検討し、下 記に示す準備を行った。 ① ピアレビュー実施ガイドライン ピアレビューの意義・目的・実施手順・実施後のフォローなど、実施する際に必要な事項を記載し た。また、以下に示すツールやテンプレートの使用方法およびレビュースタイルの説明なども含め ている。 【ピアレビュー実施計画書兼報告書】 ピアレビューの実施計画の記入と実施結果の集計を行う。プロジェクト毎に準備し、そのプロジ ェクトで計画・実施したピアレビューはすべて登録する。登録したレビューデータを基に「ピア レビューログ」の自動生成や、ピアレビューログに記載されたデータの自動集計などを行う。 【ピアレビューログ】 ピアレビュー１回毎の実施結果を記入する。レビュー参加者の氏名や全ての指摘、対策方法等を 記載する。記入した内容から、レビュー参加人数や指摘項目数などを自動集計する。 【チェックリスト】 ピアレビューを実施するときの観点を記述したもの。これによりピアレビュー実施時のレビュー 項目の抜け・漏れを軽減する。 【レビュースタイル】 ピアレビューのスタイルとして、以下の３種類を採用した。いずれのレビュースタイルにおいて も、必ずドキュメントを事前配布して机上レビューをするようにした。 • フェイガンインスペクション 一般的にはインスペクション[2][3]といわれている。システムの重要部分、後工程への影響が大 きいドキュメントに対し、特に念入りに検証する。効率よく指摘を出すことが目的であるため、 対応策については議論しない。 • 簡易インスペクション 影響が中程度のドキュメントに適用する。指摘に対する対応策を議論してもよい。 • ウォークスルー 影響が少ないドキュメントやコードレビューに適用する。手軽に実施できる。 ② 社内規程 ピアレビューの実施に適度な強制力をもたせることが重要と考え、多忙な開発者に少なくとも実施 すべき範囲を明示した社内規程(案)を作成した。なお、この規程(案)は、ピアレビューの試行結果 から見直しを行い、規程化することとした。 SQiP2010 D3-2 3.2 試行期(2008 年 8 月～2009 年 6 月) (1) 目的 ピアレビューを試行した際の問題点を抽出し、解決する。 (2) 実施内容 ワーキンググループのメンバーが各部署でパイロットプロジェクトを選出し、ピアレビューの試行 を計画・実施した。各部署におけるパイロットプロジェクトの試行に関しては、２週間に１回定期報 告を実施し、ワーキンググループのメンバーが互いに状況を確認できるようにした。 試行した結果、ピアレビュー実施ガイドラインに関しては「チェックリスト」と、 「ピアレビュー実 施計画書兼報告書」および「ピアレビューログ」などのツールに対して見直しを行い、更新した。ま たピアレビューの社内規程化も実施した。 (3) 課題 • 部署によって実施件数および指摘件数が大きくばらつく結果となった。最大で実施件数・指摘件数 ともに約 10 倍の差があった。実施件数の少ない部署はピアレビューに対して積極的でなく、その理 由として「忙しい」 「時間がない」といったことを挙げていた。一方多く実施した部署はマネージャ ーの意識が高く、指示がしっかりなされていたということが分かった。 • ピアレビューの結果は指摘件数や対策工数など様々な形で記録するが、個々の指摘項目に対しては 重要度というものを定義し、３段階で分類している。その重要度の定義が曖昧であるため、部署に よって差異があり、正しい分析・フィードバックができないということが分かった。 (4) 対応策 各部署で試行の取り組みに対する温度差が発生したことに対し、強制力でピアレビューの取り組み を推進する必要があると考え、社内規程に記載しているピアレビューの実施方法について、機能仕様 書等の重要なドキュメントに対しては、「実施することを推奨」から「必ず実施」ということにした。 また、指摘重要度があいまいな点に関しては、正しい分析・フィードバックができるように、重要 度の再定義を行った。 その他、定着を推進するための仕組み作りも検討した。詳細は次節に示す。 3.3 定着期(2009 年 7 月～至現在) (1) 目的 ピアレビューの定着を推進し、上流工程で不良を摘出することによりソフトウェアの品質を向上さ せる。 (2) 実施内容および検討事項 ピアレビューの定着を推進するため、 「ピアレビュー評価会」を組織し、評価会と各部署の部長・ソ フト開発責任者で、図 1 に示す体制を整えた。 【活動内容】 • ピアレビュー評価会は評価会で得ら れた情報を基に、その実施状況を各 部署の部長に報告する。 • 部長はソフト開発責任者に対して、 実施件数や指摘数の増加などの良い 点は評価し、問題点は是正するよう 指示する。 • ソフト開発責任者(主任技師)はピア レビュー実施状況の定期的な部長報 告と、ソフト開発チームに対するピ アレビュー実施の推進を行う。 部長 部長 定期的な 進捗報告 レビュー状況の 報告を求める 月1回レビュー状況の 報告と指示・指導の お願い ほめる フォローアップ ソフト開発責任者 ソフト開発責任者 （主任技師） （主任技師） ソフト開発 ソフト開発 チーム チーム 評価会 評価会 レビューログ 分析結果、効果の 報告、教育の提供、 改善要望の対応 各部署において全てのプロジェクト 図 1. ピアレビュー定着へ向けた推進体制 を対象とし、ピアレビューを開始した。 定着を推進するために、 「ピアレビュー評価会」を月に２回開催し、各設計部におけるピアレビューの 実施状況を分析・評価した。なおピアレビュー評価会はワーキンググループのメンバーに加え、開発 者が多いグループから複数人のメンバーを追加で迎え入れ、きめ細かい分析・評価ができる構成とし た。 ピアレビュー評価会のメンバーは、所属部署におけるピアレビューの実施状況を把握し、開発者か ら問題点を拾い上げ、評価会で報告・提案する。ピアレビュー評価会では「レビュー速度」(１時間に レビューするページ数)や、「指摘密度」(１ページあたりの指摘数)などの数値も報告してレビューの 質向上を目指している。 SQiP2010 D3-2 レビュー速度 [ページ／時間] 図 2 は 2009 年度下期に行ったレビ 部署Ａ ューの散布図で、縦軸をレビュー速度、大 部署Ｂ 横軸を指摘密度として示している。こ 部署Ｃ の図から、レビュー速度が速いと指摘 部署Ｄ 部署Ｅ 密度が下がり、レビュー速度が遅いと 推奨範囲 近似曲線(部署Ａ) 指摘密度が上がる傾向にあるといえ を設定した 近似曲線(部署Ｂ) 近似曲線(部署Ｃ) る。レビュー速度が速いと指摘を見逃 近似曲線(部署Ｄ) す恐れがあり、逆に指摘密度を上げる 近似曲線(部署Ｅ) ためにレビュー速度を遅くして時間 がかかりすぎると非効率である。限ら れた時間で効率良く指摘を出すため には適切な範囲があると考え、それを 推奨範囲とすることにした。(図 2 の 楕円領域)ただしサイズや位置につい ては適宜見直していく予定である。図 大 指摘密度 [件／ページ] 2 の左下部にあるレビューを推奨範 図 2. レビュー速度－指摘密度 散布図 囲に近づけるのが望ましい。 定着期の重要な課題は、ピアレビューのさらなる定着とレビューの質の向上である。ピアレビュー の実施に関しては着実に件数が増加してきているが、実施率という観点からはまだまだ推進する必要 がある。また、レビューの質の向上には、評価会で議論したレビューの分析結果や改善案を各部署に 正しくフィードバックすることも必要である。 (3) 対応策 定着と質の向上を目指し、下記各項目を実施している。 • ピアレビュー実施率：ピアレビューの定着をさらに推進するために、「ピアレビュー実施率」 を毎月の部長報告で各部署に提示した。これによりピアレビュー実施の強化が必要であるこ とを認識してもらい、実施率の向上を図っている。 • 交流会：ピアレビューの実施に際して困っていることや改善提案を抽出するために、各部署 から数名のピアレビュー推進者を集めて「交流会」を実施した。参加者から積極的な発言が あり、その代表的な意見を以下に示す。 ¾ ウォークスルーを主に行っていたが、影響が大きいもののレビューにインスペクションを 取り入れてみようと思う。 ¾ 机上レビューを必ず実施しようと思った。 ¾ ピアレビュー後の確認はやはり曖昧さが残っており、確認を行って１つのプロセスが完結 するような仕組みについて検討すべきと思う。 ここで得られた意見を基にピアレビュー実施の改善を図っている。 • 勉強会：ピアレビュー推進のために、各部署において何が問題であるかを開発者自身が認識 し、改善することができるようにするため、評価会メンバーが主体となり、部署単位で「勉 強会」を実施している。これにより問題点の改善と、さらなる定着の推進を行っていく。 • 質の向上：図 2 に示すような数値や分析結果が出てきたので、ある程度標準的な数値がつか めてきた。しかし逆に数値目標を設定するとピアレビューの形骸化につながる恐れがある。 それを防止するために、評価会事務局が各部署のレビューに立ち合い、目で見て現状を把握 し、問題点や改善点を発見することにより、レビューの質の維持および向上に努めている。 • 部長報告：評価会で議論した分析結果や改善提案を各部署に円滑にフィードバックするため、 各部長へ報告(1 回/月)を行っている。その結果、ピアレビューの現状と問題点をはっきり認 識してもらい、部内での改善推進をお願いしている。 • アンケート：ピアレビューの効果を定量的に示すのは難しいが、ピアレビューを実際に行っ ている開発者が効果を実感できていることを示すことで、さらに定着が進むと考え、社内の ソフトウェア開発者(協力会社含)を対象に、アンケートを実施した。その結果約 90％の開発 者から品質面で効果を実感したという回答が得られた。(4.3 参照) 4. 効果の結果と考察 ピアレビューの効果は製品出荷後のソフト品質で評価すべきであるが、改善施策を実施してから実 際にその効果を得るまでにはある程度時間の経過が必要であり、まだ実質的な効果を得られる段階に は至っていない。現在までに本活動を通じて得られた全般的な効果について報告する。 SQiP2010 D3-2 2009年度上期に対する2009年度下期の件数比率 4.1 ピアレビューの実施状況 ピアレビューの実施件数、実施ページ数および指摘件数は、2009 年度上期の実績に対して 2009 年度 下期は全体的に約２倍に増加した。そのうち実施件数と実施ページ数はすべての部署で増加し、それ に伴い指摘件数も増加した。2009 年度上期に対する 2009 年度下期のピアレビュー実施件数、実施ペー ジ数、および指摘件数の比率を以下図 3 に示す。 グラフ上の数値は、2009 年度上期の件数を 1 とした場合の 2009 年度下期の件数比率を示す。 すべての数値が 1 以上であるこ 6 とから、ピアレビューの実施は拡大 実施件数比率 しているといえる。部署Ｂでは、実 5.2 実施ページ数比率 5 施ページ数の伸びに対して指摘件 指摘件数比率 数の伸びが少ない。一方部署Ｄでは （2009年度上期を1とする) 実施ページ数の伸びよりも指摘件 4 3.7 数の伸びの方が大きい。これは図 2 からも分かるように、部署Ｂにおけ 3.1 3 るレビューでは、レビュー速度が速 2.8 く指摘密度が低い傾向にある。これ 2.4 2.4 に対し部署Ｄにおけるレビューで 2.02.0 2.0 2 1.8 1.71.8 は、指摘密度は高いがレビュー速度 1.4 1.4 1.4 1.3 は遅い傾向にある。 1.2 1.0 1 以上より、ピアレビューの実施は いずれの部署においても拡大した が、レビュー速度や指摘密度といっ 0 た観点で見ると部署毎に異なった 部署A 部署B 部署C 部署D 部署E 全体 特色があり、単に実施が増えたとい 図 3. 2009 年度上期に対する 2009 年度下期の うだけではなく、十分指摘が出て、 ピアレビュー実施状況の伸び かつ効率のよいレビューが実施さ れているかどうかを注視していくこ とが重要である。 4.2 低減工数 ピアレビューを実施し、設計段階で不良を発見して対策することにより、実際にそれを見逃した場 合のソフトウェア対策にかかる工数を定量的に示すことで、低減効果の「見える化」を行った。この 結果を各設計部署にフィードバックすることにより、ピアレビュー実施の効果に対する理解を得るこ とができたと考える。低減工数を正確に求めるには、同一プロジェクトに対して、ピアレビューを実 施した場合の開発工数としなかった場合の開発工数をそれぞれ算出し、その差分を示せばよいが、そ のようなことは現実的にはできないため、低減工数の算出は次のように行った。 ピアレビュー低減工数[人時] = 不具合対策工数[人時] － ピアレビュー工数[人時] 不具合対策工数 ：ピアレビューで指摘した項目を見逃した場合に、ソフトウェアの 対策にかかる工数。 ピアレビュー工数：机上レビュー、ミーティング、および仕様書修正にかかる工数。 図 4. ピアレビュー実施による低減効果の算出方法 上記の「不具合対策工数」は、認定試験で発見される不具合に対して、過去のデータをもとに不具合 １件あたりの平均対策工数を部署毎に算出した。それに実際のピアレビューでの指摘件数を掛けて出 した対策工数を、全部署で合計し、「不具合対策工数」とした。 図 4 の計算方法に基づいて、各部署の低減工数を算出した結果、2009 年度上期に対して 2009 年度下期 の低減工数は約 2.7 倍に増加した。これは、ピアレビューの実施において指摘件数を倍増したことに より、ソフトウェアの開発工数に対する低減効果がより向上したといえる。 SQiP2010 D3-2 4.3 アンケートの実施 当社および協力会社のソフトウェア開発者を対象に、ピアレビュー実施に関するアンケート調査を 行った。このアンケートにより、約 90%の人が効果を実感できたと回答した(図 5)。品質で示した定量 的な数値ではないが、実際にピアレビューを実施している開発者自身が効果を実感することは非常に 重要である。 ピアレビューの実施による品質面の効果を実感できた理由として「漏れ・抜け・矛盾を防止できた」 「気付き・多面的な見方ができた」 「手戻りを防止することができた」という意見が多くあり、ピアレ ビューの実施でより完成度の高い仕様書を作成できたことや、レビュー参加者自身の視野が広がった というような効果を得られた。 ピアレビューで重要な指摘を出すために必要な事に関しては、 「机上レビュー・理解してからレビュ ーに参加」「多角的視点・チェックリスト・観点明確化」「机上レビューのための時間確保」などが上 位を占めており、いずれも机上レビューが重要であり、内容をしっかりと理解した上でレビューミー ティングに臨むことが、重要な指摘を出すためには必要であるということが分かった。 ピアレビューによって品質面の効果を実感できますか？ 「はい」：具体的にどういった点で品質面の効果を 実感していますか？ その他 21% 曖昧さ排除・ 理解性向上 13% 漏れ・抜け・矛盾 を防止できた 29% ピアレビューで重要な指摘を出すために必要な事は 何だと思いますか？ その他 27% 机上レビュー・理解 してからレビュー参加 26% 事前の準備・意識 あわせ・目的意識 5% 技術力・経験 が必要 7% 手戻り防止 することができた 16% 気付き・多面的 な見方ができた 21% 人選・適正人数 でレビュー開催 8% 時間確保 （机上レビュー） 12% 多角的視点・ チェックリスト・ 観点明確化 15% 図 5. ピアレビュー実態アンケートの結果 5 今後の課題 • 各部署においてピアレビューの実施件数は増加しているが、今後も定着を推進する施策が必 要である。特に重要なソフト仕様書やテスト手順書に対しては、100%の実施を目指した推進 策を検討する。 • ピアレビューの実施状況を様々な数値で示しているが、逆にそれらの数値を目標とし、レビ ューが形骸化しないよう注視していく。 • ピアレビューの品質面での効果を判定するために、不良分析の結果等を用いて製品出荷後の ソフト品質を定量的に評価する方法を検討していく。 6 参考文献 [1]小室 睦「ソフトウェア開発への統計的プロセス制御の適用」, 日立評論, Vol.89, No.3, pp.82-92,2007 [2]森崎 修司 「ソフトウェアインスペクションの動向」, 情報処理, vol.50, no.5, pp.377-384, 2009 [3]Karl E. Wiegers 著, 大久保 雅一 監訳「ピアレビュー－高品質ソフトウェア開発のために」, 日 経 BP ソフトプレス, 2004
© Copyright 2024 Paperzz
