［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）

「ソフトウェアインスペクション」あるいは「ソフトウェアレビュー」とは、一般にプログラムが動作する以前の段階から問題やバグを発見することをいいます。ソースコードの静的解析やコードレビューは、ソフトウェアインスペクションの中でもよく行われていることの1つといえるでしょう。また、コード以前の要件定義や仕様書などもソフトウェアインスペクションの対象となります。

7月2日に、このソフトウェアインスペクションをテーマにしたイベント「ソフトウェアインスペクション・ワークショップ 2009」が行われました。ソフトウェアレビューやインスペクションの経験者を前提として参加者に集まってもらい、Javaソースコードのインスペクションを実際に実施することを目的としたこのイベントは、地味なテーマ設定のためそれほど参加者が集まらないのではないか、と予想されていました。

しかし実際には約115名もの応募が寄せられ、定員で締め切ったために参加したくともできなかった方も出て、当日も90名以上の出席者が参加するイベントとなりました。多くの人が、ソフトウェアインスペクションという分野に実は興味をもっていたということがうかがえます。

イベント当日は講師によるセッションと、実際にJavaソースコードをレビューするワークショップなどが行われました。その模様は＠ITの記事「"レビュー"とは、責め合うものではなく、品質を高め合うもの－ ＠IT」に詳しく紹介されています。

このイベントの最後のセッションは、パネルディスカッション「明日からのソフトウェアインスペクション／コードレビューを成功させる方法」でした。そして、そのディスカッションのモデレータを僕が勤めさせていただきました。

僕自身、ソフトウェアインスペクションについての知識はそれほどあったわけではなく、事前に勉強したうえで望んだパネルディスカッションでしたが、非常に示唆に富む内容ばかりで充実したディスカッションになりました。

ここでは、そのディスカッションの内容を前後編の2つに分けて紹介したいと思います。また、エントリの最後にはソフトウェアインスペクションに興味を持たれた方のために参考になる記事へのリンクも用意しましたので、ぜひそれらにも目を通していただけると、より理解が深まると思います。

なお、イベントのテーマとして「ソフトウェアインスペクション」という言葉が使われ、また当日のワークショップとして「コードレビュー」が行われたため、ここでは「ソフトウェアインスペクション／コードレビュー」と並べて記述することがあります。両者を厳密に使い分けてはいませんので、ご了承ください。

パネルディスカッション

パネリスト（50音順）
越水喜之氏（日本IBM）
細川宣啓氏（日本IBM）
森崎修司氏（奈良先端科学技術大学院大学）

モデレータ
新野淳一（前＠IT発行人、現Publickey編集長）

新野　今日はアジェンダを3つ用意しています。1つ目は、ソフトウェアインスペクション／コードレビューの現状について、パネリストのみなさんに現状認識を語っていただき、2つ目に明日から使えるソフトウェアインスペクション／コードレビューのテクニックを紹介してもらおうと思っています。そして3つ目には、チームや組織としてどうすればソフトウェアインスペクション／コードレビューを成功できるのか、その方法についてのお話をしてもらおうと思っています。

その前に、会場の皆さんに答えていただいたアンケートをざっとまとめてみました。「みなさんの会社の中で、ソフトウェアインスペクション／コードレビューがうまく機能していますか？」という問いに「機能している」と答えられたのが22％。残りの大多数、78％の方は「うまく機能していない」と答えられています。

理由として、「レビューしても障害が出る」「時間がない」「トラブル対応としてしか機能しない」「レビューを受ける側にプレッシャーがある」といったことが書いてありました。コードレビューはうまくいっていない、と、みなさんなんとなく認識されていたと思いますが、それがあらためてアンケートによって数字になって表れた感じがします。

8割の参加者が「ソフトウェアインスペクションが機能していない」

（ここで会場から手が挙がる）あ、会場からの発言ですね。ぜひ。

参加者　○社の△です。我々のチームで、今日のワークショップでいつもより多くのコードレビューができたのは、ただ単に短い時間に凝縮してやったからだけでなく、チェックリストや技法などレビューのための事前資料が用意されたうえでできたので、いつもより多くこなせた、という意味の回答でした。

新野　なるほど。ワークショップを主催された森崎さん、コメントを。

森崎　そうですね。実はワークショップで恐れていたのは「こんなのコードが長すぎてやる気が出ない」ということだったので、そういっていただけるとありがたいです。フラウンホーファー（ワークショップの結果を共同研究するドイツの研究機関）にも伝えておきます。

新野　ほかのパネリストの方でコメントがあれば。

越水　私が昔開発をしていたときはウォークスルー、つまりソースコードの読みあわせをやっていたんですね。でも、読み合わせをするにもスキルが必要ですし、そこで指摘される項目というのは、いままでのプログラミングやコードレビューの経験で得られてきたことが反映されます。そのレベルを底上げするためには、ツールを使うのが有効かなと思っています。ツールを使えば、一定のルールをもってソースコードを分析し結果がでますし、それを基に使う方すべてが同じレベルでレビューできますから、ソフトウェアインスペクション／コードレビューのレベルの底上げが可能になるかなと思います。

ソフトウェアインスペクションの価値をどう説明するか

新野　もう1つ会場から発言ですね。どうぞ。

参加者　×社の□です。インスペクションをすると時間や工数はかかりますが品質はあがる、というところをお客様に納得してもらうのに、いつも苦慮しています。というのも、お客様はどうしてもコストに目が向いてしまいますので工数の増加についてなかなか理解してもらえません。ソフトウェアインスペクションの効果をお客様にどう納得してもらえばいいのか、なにか答えがあれば教えてもらいたいです。

細川　インスペクションのスピードをあげる方法、時間を短縮する方法として、ディテクションとリペアを分けるという考え方があります。まず直し方を議論しないこと。バグであると検出したときには直し方まで考えず、バグであると報告してしまう。直し方には何通りもあり、どれがメリット、デメリットという話をしていると長くなる。だからバグと認定、次、とやっているとどんどんバグがでてくる。

そしてさっきのアンケートでも、レビューしても結局バグが出る、というコメントがありましたが、同じバグを二度と出さない工夫というのをするべきだと思います。これは現象を捕まえるだけでなく、原因に踏み込んでいく。原因を除去しないと現象が再発します。原因は何だろう、例えば教育が足りなかったからか、開発前の説明が甘かったからとか、そういう組織的なバグであれば、まんべんなく成果物に表れるはずですし、開発者のスキルや経験に依存するものならその人が担当したところに局所的に出ると思います。

こうやって原因にひとつひとつに踏み込んでいくと、最初のうちはコードレビューに時間がかかるのですが、だんだん短くなっていく可能性が高まります。これは単なるレビュー慣れでは実現できなくて、観点を絞り込み、かつ再発防止に勤める。目指すレベルは高いですが、意識を持って2～3回レビューをやっていくだけでも段違いに生産性が高まっていくと思います。

森崎　学術論文などでは、ソフトウェアインスペクション／コードレビューのコスト対効果などを取り上げると厳しくその点を論文の審査員から追究されるので、まさにご質問の点はしっかり考えなければならない点だったりします。

例えば、ウォーターフォールなどを前提にしたときに、設計時やコード作成時のソフトウェアインスペクション／コードレビューでバグを発見できたときの修正コストと、それを見逃しそのあとのテスト工程などでバグを発見し修正したときの修正コストを、比較します。当然、早い段階で、つまりソフトウェアインスペクションで発見したほうがコストが安く済むはずです。

両者にほとんど差がなかった、ということがもしもあったとしても、後工程で見つけることでリスクを増やしたいですか、それとも早くみつけてリスクを小さくしたいですか、と考えます。そう考えると、やはり早い段階でソフトウェアインスペクション／コードレビューを行うのはいい、そういう説明をしています。

具体的な話は機密があってできませんが、複数件で（ソフトウェアインスペクションの効果を）実験した結果として、修正コストに激しく差がありました、というインタビュー結果を得るのは難しいでしょう。実際には効果があっても、見逃していないバグの修正コストを予測すること自体が難しいことを示しているともいえます。いずれにせよ、早期のソフトウェアインスペクション／コードレビューでリスクが小さくできるということに関して異論はほとんどなくて、説得されるにはそういう説明を使えばいいのではないかと思います。

なぜソフトウェアインスペクションは現場で機能しないことがあるのか？

新野　ではそろそろ本来のアジェンダに入りたいと思います。先ほどのアンケート結果にも表れているように78％の人がご自身の組織の中でもソフトウェアインスペクション／コードレビューがうまくいっていない、とお答えです。

実際のところ、多くのソフトウェア開発の現場ではコードレビューは形式的にはやることになっていると思います。コードレビューで上司にハンコをもらわないと顧客に納品できない、といったところは多いはずです。

今日1つめのアジェンダは、こうした現状について。なぜ組織の中でソフトウェアインスペクション／コードレビューがうまくいっていないか、について発言をいただこうかなと思っています。

細川　いまの例で挙げられたように、「形式上やらなくてはいけない」とされているのが、まず現場としてはイヤかもしれませんね。出荷したあとでお客さんからクレームもらうくらいなら、同僚にレビューしてもらって指摘されたほうがまだましと自然に思えればいいのですが、「制度上コードレビューをやらなくてはならない、誰かにレビューされなければならない」というのでは気分いいわけないんです。この心理的なものがすごく邪魔すると思います。

もう1つは、偉そうなレビューアやインスペクターにバグを指摘されるとむかつく、というのもありますよね。こういった感情からすると、自分が作ったコードが完璧であるわけはないんだけど、でもバグは隠したいという心理が働くのは否定できないと思います。

でも、私自身は品質保障していない工業品は犯罪に近いと思っています。ですから、たとえば隣の人に見てもらうとか、カジュアルに「ちょっと見ておいて」といったスタンスをコードレビューに導入できるといいのではないかと思っています。

新野　アンケートでも「レビューを受ける側のプレッシャーが気になる」という回答があったので、まさに心理的なものがバリヤーになっているのかもしれないですね。

プレッシャー、時間がない、自分の評価につながらない

越水　ソフトウェア開発の現場の忙しさも問題ですね。プロジェクトが佳境に入ったときに周りの人をインスペクションに巻き込むのは難しいだろうなと思います。ですから現状では、コードの完了時にある程度品質が担保できるよう、プログラマーが自分の責任でインスペクションされている例が多いと思います。

しかしこれからは、組織としてどういう風にインスペクションしなければいけないのか、それをやる仕組みが重要だと思います。

森崎　私も5年ほどソフトの開発にたずさわっていた時期がありまして、レビュー、インスペクションはやるほうもしんどいし、指摘されるとプライドが傷ついている様子を見ました（笑）。また、そういう話をよく聞きます。

これは私のいた組織のことではありませんが、組織上の問題として、他人の成果物をレビューしてあげたところで、自分の成果に結びつかないから、そういうことからなるべく逃げる。こういうのが結構あったりします。誰かの支援をしても、それが自分の人事評価につながらない。

細川　レビューアが報われない、という話ですね。

森崎　そうです。レビューでいい指摘をしても評価にならないんです。

もう1つ。レビューはほかに比べるとエビデンスが求められない。テストはちゃんとテスト計画を立てて、あんまりいいかげんにやると、これやった？ って突っ込まれることがある。でもレビューは、欠陥指摘リストとか欠陥密度といったエビデンスが求められますが、エビデンスとしては必ずしも十分ではない。たとえば1K行あたり10件の欠陥をみつけなさい、といった指標では、3つバグを見つけると、まずそれを2つに割って6つにして、さらに6つのうち大きめのやつ4つをさらに2つずつに割って、合計10にして終わりと。だから、レビュー、インスペクションではエビデンスの求められ方がちょっと洗練されてないのも原因かなと思います。

（後編につづく）

（撮影：奈良先端科学技術大学院大学 保田 裕一朗氏）

参考記事 on the Web

• Software Inspection Workshop Japan 2009
• "レビュー"とは、責め合うものではなく、品質を高め合うもの－ ＠IT
• コードレビューの道具、使っていますか？
• "確実な記録"こそが、品質・コストに貢献する－ ＠IT情報マネジメント
• 全関係者の"納得"が、レビュー成功の大前提 － ＠IT情報マネジメント
• 森崎修司の「どうやってはかるの？」 > ソフトウェアインスペクション／レビューをテーマに11人の執筆陣で21記事の特集『インスペクションの世界』ThinkITで : ITmedia オルタナティブ・ブログ
• 某開発者の独り言: ソフトウェアインスペクション・ワークショップ 2009に行って来た
• ＠IT自分戦略研究所の「おすすめエンジニアライフ」: インスペクターよ、誇りを抱け
• ソフトウェアインスペクション・ワークショップ 2009に行ってきた - 自分の仕事を憎むには人生は余りにも短い
• WACATE以外のワークショップに行ってきました♪ - WACATEブログ