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

2009年7月14日

本エントリは「［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）」の続きです。

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

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

欠陥を指摘するためのテクニック

新野　ソフトウェアインスペクション／コードレビューの現状の分析をパネリストにしていただいたところで、次は、明日から使えるソフトウェアインスペクション／コードレビューのテクニックを紹介してもらおうと思います。

そういえばこのあいだ細川さんの情報処理学会の論文を読ませていただきました。で、そこにインスペクションのテクニックには2つある、って書いてあったんです。1つは発見するテクニック。もう1つは指摘するテクニックだと。指摘するテクニックってそのとき始めて知ったので、その辺も含めて教えていただけませんか。

細川氏「レビューへの参加というのはキャリアアップの1つの技術だと思います」

細川　コードレビューしたら、めちゃくちゃたくさんの欠陥が、良くも悪くもでちゃいました、というときに、フィードバックの仕方とものの言いようによって、きれいに対処してくれたり、一個も直してくれなかったり、ということが結構あるんですね。正しいことを指摘したからといって必ずしもそれがソフトウェア品質に貢献しない場合があります。

こうしたときの指摘のテクニックのポイントというのは、まず事実をベースにしましょうと。私のチームにレポートを書かせるときには「～がある、～がない」という語尾で統一しなさいと、よくいいます。事実としてこのインスペクション対象がどうなっているか、をきちっと伝えてくださいと。

それを踏まえたうえで、ひとことで言うとこれの原因は何である、という風にまとめてあげる。レベルを1つあげてあげるんですね。欠陥の事実が100個あったとして、で、どうしたらいいの？という対処法がよく見えないリストをあげてもしょうがないんです。ですので、これらの欠陥を分類するとこうなります。原因としてなにが想定されるので、これを解決するようにしてください、という形にすると、クイックなコンサルテーションになると思います。つまり指摘のテクニックというより伝達のテクニックなんですね。

私はレビューへの参加というのはキャリアアップの1つの技術だと思います。私は仕事としてだいたい年に数百件レビューするんですね。ところが普通の開発者が1年間に数百件のプロジェクトを経験できますかっていうと絶対無理なんですよ。そう考えると、たくさんのプロジェクトを経験したり、たくさんの業務やアプリケーションに効率よく触れるという意味では、ぜひ若手にインスペクションやレビューの経験をたくさん与えてほしいと思います。

新野　続けて細川さんに聞きたいのですが、細川さんは仕事としてソフトウェアインスペクション／コードレビューをしていますよね。つまり、あるプロジェクトに呼ばれてポンと入って、そのプロジェクトの対象業務が何であるか、といったバックグラウンドの知識をほとんどなしに仕様書やプログラムを見て、なんらかの方法論を使って欠陥を指摘するじゃないですか。そういう方法論的な指摘のテクニックも教えてもらえませんか。

細川　みなさん、今日ワークショップとしてソースコードをレビューしましたよね。ソースコードの中に書いてあるバグというのは、直すのが比較的楽なんです。いちばん難しいのは、他人が作ったソースコードと、私が作ったソースコードのスキマに落ちるバグなんです。こういうのを不整合といったりします。

他人と私の理解の違いとか理解の矛盾、というのを見つけるのは非常に難しくて。これを見つけるのは、他人としゃべって確認する以外に、基本的には発見する方法がないんです。

なので、だまーって仕様書を書いているチームって絶対にバグが多いんですよ。わいわいやっているチームって、一見効率が悪いのですが、最終的にはバグの混入率が低くなっている場合が多いので、開発もわいわいやってもらいたい、検出もわいわいやっていただきたい。というのはトータルなテクニックだと思います。

ソフトウェアインスペクションをツールから学ぶ

越水氏「ツールの指摘を参考にしてソフトウェアインスペクションやコードレビューを学んでいくというのは、1つの方法としてあるかなと思います」

越水　仕事柄、ツールを使ってインスペクションしましょうという話をよくするのですが、ツールから学ぶ、ということがあるかなと思っています。言い方を変えれば、アンチパターンから学んでいく、と。要は分析した結果、それはツールが修正するわけではなく、分析した担当者やプログラマが、その内容を検討して判断してプログラムを修正していく、ということになるわけで、分析して修正することでアンチパターンを学んでいけるかなと。つまり、どういうプログラムがいけないのか、判断するのは難しいので、ツールの指摘を参考にしてソフトウェアインスペクションやコードレビューを学んでいくというのは、1つの方法としてあるかなと思います。

新入社員の教育の中で、ツールを使ってインスペクションをしていくというコースを組んで、こういうコードはいけなんだよ、ということを若いうちにすりこんでいく、という試みをしているお客様もいらっしゃいます。

細川　私のようなインスペクションを職業にしている人としては、（IBM Rationalの製品で）ソフトウェアアナライザーがありますが、あれに頼り切っているところがあります。簡単なバグはみんなあれでつぶしたあとで、セマンティックエラーの発見に特化したい、ということができます。

特に私が好きなツールは、設計のバグを取るツールと、ソースコードのメトリクス解析（量的解析）をするツールですね。静的解析ツールというとフリーなものも含めて世の中にはいいものたくさんありますが、メトリクスをしっかりとれるものはそれほどないんです。

メトリクスって、お医者さんの診断に結構近いんです。検査データがあって、これとこれの検査結果から見ると何病である、という診断ができる。大きいシステムのレビューでは絶対必要ですね。

越水　メトリクスを人手によって行うのはまず不可能ですから、そういうのをツールで試してもらえればと思います。

無料で使えるツールはどれがいい？

新野　アンケートでもツールを使っているという回答がありましたね。1つは「Wikiで関係者でインスペクションの結果を共有している」という回答。それから定番ツールかもしれませんが、「JUnit」それから「FindBugs」を使って分析している、という回答もありました。どちらもEclipseのプラグインとしてよく知られているツールです。

で、先ほど越水さんからはIBM Rationalの商用ツールを紹介いただきましたが、越水さんおすすめの、商用じゃないツールってありますか？（笑）

越水　IBMのサイトにはオープンソースを使ったソースコード分析の情報もでていました。そこで紹介されていたのは、FindBugs、PMD、CheckStyleですね。この3つを一緒に使うといいのでは、と紹介されていました。

参考：FindBugs第1回:コード品質を改善する - developerWorks

大事な部分だけを指摘する

新野　森崎さんからも、テクニックをぜひ教えてください。

森崎氏「技法を知っていただきたいなというのを強く感じています」

森崎　論文レビューとかでもよくあるんですが、細かい部分を気にしないように、ということです。例えば、ソースコードのタブの幅は4文字がいい、とか、try～catchは改行しないとだめとか、そういうことをいちいち指摘するとレビューやインスペクションが進まないですね。

もう1つは、技法を知っていただきたいなというのを強く感じています。いただいたアンケートの中に、ツールの実行結果を用いて、レビューする箇所を決めるというのがありましたが、こういう風にぜひツールを使っていただきたいのと、技法とか観点とか、今日のワークショップでガイデッドチェックリストとか使っていただいたのですが、いろいろ技法が存在しますので、ぜひ使っていただきたいなと思います。

例えばチェックリストはよく使われますが、使っていると数が多くて全部チェックするのいやだなあということで使われなくなってくるんです。でもチェックリストを優先順位順に並べていくと、上から順番に大事なところからできるわけで、それも技法の1つだと思うんです。

で、技法をどこかから学ぶというのも大事ですし、加えてこういう場でぜひ情報交換してもらいたいなと思います。

新野　今日の会場からの1つ目の発言でも、技法や材料があったから密度の高いレビューができた、という発言があったので、まさにそれに当てはまるかなと思います。

組織としてソフトウェアインスペクションを成功させるには？

新野「組織のなかでソフトウェアインスペクションを活用できるようなプロセスとかカルチャーになっていないと個人も能力を発揮できないと思います」

新野　さて、今日3つめのアジェンダが。「ソフトウェアインスペクション成功のヒント」です。ソフトウェアインスペクションやコードレビューは、個人が上達することは大事だし、全体の底上げも大事なんですが、組織のスキルという意味で、組織のなかでソフトウェアインスペクションを活用できるようなプロセスとかカルチャーになっていないと個人も能力を発揮できないと思います。そういう風にするにはどうしたらいいのでしょうか？

細川　コード書いている人と、コードと戦って検出している人、両方の人から見て、なんのためにインスペクションするのか。本質は、安心したいから、だと思うんですね。つまり、納得して進めたいんですよ。

ソフトウェアを、自信をもってリリースしたことのある人って少ないと思うんです。やることはやりきった、これでここまでやったんだから大丈夫だ、とか、現時点でできることはここまでだ、とか。こういう自信を持って、安心して次に進むためのインスペクション、というとらえかたをすると、けしてゼロディフェクト（無欠陥）を目指す必要はないんじゃないかなと思います。

4人でインスペクションをやるとするじゃないですか。私の作ったものをみんなにみてもらうと、私が担当した部分に対応できる人が3人いるということです。もしくは誰かの目に見てもらった安心感だったりもする。

インスペクションというのはそもそもべたべたな仕事で、そういうべたな仕事が安心感を生み出すんだ、というのは科学されていない部分だけれども重要だと思います。

ここまでやった、よし自信を持て、という雰囲気が組織の中でかもしだされれば、インスペクションというのはどんな形でやったとしても、どんな技法を使ってやったとしても、その組織では成功だと思います。

新野　さきほどの会場からも、お客さんにどうやってソフトウェアインスペクションの価値を認めさせればいいんでしょう。という質問がありましたよね。

細川さんのビジネスというのは、ソフトウェアインスペクションをサービスとして顧客に提供するビジネスですよね。それはどうやって価値を顧客に認めてもらっているのでしょう？

不安をコントロールする

細川　非常に単純で、黒スーツしてサングラスしたやつが現場に突入して、お客さんの前で（ソースコードを）ボコボコにする（会場やや笑い）。冗談のようですが本当です。

「5分で（バグが）100件見つかりましたから、もうここでやめておきましょう」って言ったりすることもあります。たたき出した100件ていうのは見えた病気なんですよね。

みなさんお医者さんに診てもらって、原因のわからない病気というのはいちばん怖いですよね。これと同じで、現象としてどんなバグが出るのかをたたき出したほうが、つまり、目の前でボコボコにしたほうが信頼を得られる、というビジネスなんですね。

新野　ツールと方法論が説得力を持つ世界、ということなのかもしれませんね。

細川　そうですね。「安心」というキーワード。もっというと不安をコントロールすること自体がビジネスになるのではないかと思います。

新野　越水さんにも、成功のヒントをお話ししていただこうと思います。

越水　今回、これほどの人数が集まったことにまずびっくりしてまして。インスペクションに対して興味を持つ方が多いんだなと思いました。一方で、アンケートの結果やはり78％の方はインスペクションが機能していないのだな、ということも分かりました。

なかなかうまくいかないのは、ソフトウェアインスペクション／コードレビューが難しいというのと、時間がなくてできないから、という現状があると思いますので、そこはぜひツールを使ってクリアしてもらいたいです。

ツールでインスペクションが100％自動化できる訳ではありませんが、30％でも50％でも自動化すればその部分は効率があがりまし、組織としても効率があがると思います。

テストでは見つからないバグをツールで見つける

新野　越水さんはソフトウェアインスペクションのツールを売る立場ですよね。ただ、一般にはIBM Rationalのツールって高いんじゃないの？と思われています。実際にツールの価値を顧客に認めてもらうために、どういう売り文句を使われているのでしょう？

というのも、今日この会場にいらっしゃる方はソフトウェアインスペクションのツールが導入されればうれしいですよね？早く帰れるかもしれないし、バグが減るかもしれない。だとすると、現場の人は上司にはなんと言って導入してもらえばいいのか。越水さんのビジネス上の色気が出てもいいと思うので（笑）、ぜひその辺の売り文句をさらっとここで言ってみてもらえませんか？

越水　IBMがいつも使うチャートで、上流から下流にいくにしたがって、修正コストが大幅に増えていきます。というのがあります。たとえば要件からコーディング、単体テスト、結合テスト、運用とあるときに、それぞれ修正コストが変わってきますと。そしてテストでコードを動かしてみて、そこで動かないバグは発見しやすいですが、発見しにくい問題もあります。メモリリークとか初期化忘れとかがそうです。

こういうバグがソースコードに含まれていても、一見普通に動くことが多いんです。しかし、ある日いきなり運用で落ちてしまう。でも表面化しにくいからテストでも見つけられない。そういうコーディングの中で作られる問題というのは、コードを読み合わせないと見つけられない可能性が高いんです。運用で発見されるのと、コードの完成フェーズでインスペクションして発見されるのでは明らかに修正コストが違っています。

そういう発見を何回か繰り返すことによって、例えばツールの費用としての何百万円というものはペイできるものだと思います。また、人を雇うつもりでツールを入れるということを考えても安いでしょう。細川さんを雇うよりずっと安いですよ。

細川　ぼくはずっとたたかれてますよ（笑）

新野　ありがとうございます。では、森崎さんにも成功法を。

同僚による評価が大事になる組織を

森崎　4つほどあげさせていただきます。

まず組織の中で、「だれだれさんのおかげで、このソフトウェアの品質はよくなったって」っていう、そういう文化がぜひほしいと思っています。そういう文化と技術があってはじめて組織の中でインスペクションレベルがあがっていくのかなと。

もう1つ。ソフトウェアインスペクション／コードレビューに対する事前合意ができていること。開発プロセスとしてあらかじめ「こういうチェックをしますよ、こういう指摘をしますよ」というのを最初に合意しておけるかどうかで、だいぶインスペクションの生産性が変わると思います。「こういうチェックをしますので、こうしておいてくださいね」というのがないと、「そんなことまでいうのかお前は」となってしまいやすいので、事前合意は大事だと思います。

それから、すぐには難しいと思うのですが、同僚からの評価を人事評価に組み込むというのも大事だと思います。「彼は僕をインスペクションで助けてくれた、見逃し欠陥を減らしてくれた」と。

というのも、どうしてもいまは上司が部下を評価するパターンがほとんどだと思うんですが、そうすると上司に見てくれがいい成果を部下が作りがちなんです。で、インスペクションやレビューというのはそういうの（上司が部下を評価すること）に向いていないと僕は思っていて、同僚の評価を取り入れられるといいのではないかと思っています。

最後4つめは、今日のワークショップのように組織の中とか、近くの人とぜひやっていただきたいなと思います。昼ごはんのときにパンを買ってきて会議室でやりましょう、ということもたぶんできると思います。で、技法なり何なり事前共有をしておかないといけないことはこういうことだ、といったソフトウェアインスペクションについてのディスカッションしてもらいたいなと思います。

新野　そろそろ終わりの時間も近づいてきました。パネリストの方に、何か言い残したことがあれば、ひとことずついただきたいと思います。

細川　インスペクションでつながる集団て珍しいですよね。こういうテーマで苦労されている横のつながりはすごく大事で、この出会いをちゃんととっておきたいなと思います。

それから、日本が品質について語るとき、世界はだまって耳を傾けてくれます。「うるさい、俺は品質の話をしているんだから」というと、とりあえず黙って聞いてくれるんですよね。日本は品質の国であり、品質の苦慮、工夫の話なら金払っても聞きたいという人はたくさんいるんです。ですのでこの中から世界へ情報発信していったり、世界へ向けて品質大国日本を築いていくメンバーが出てくれるとうれしいと思います。ぜひ一緒にこの世界を広げていきたいですね。

越水　インスペクションになかなか踏み込めないのは、専門的なスキルが必要だと考えている人が多いかもしれないと思っているので、もっと手軽にはじめてみて、そこから組織としてやるように発展していってもらえるといいかなと思います。

森崎　お忙しい時間をさいて参加していただいて、ワークショップも盛り上がって感謝しています。運営に携わったIBMの方々や当学の学生にも感謝しています。

細川　（会場に向かって）また別のテーマでやるといったら、また参加されますか？

（会場から拍手）

新野　みなさんありがとうございます。また次へつなげていけるといいですね。

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