IBM細川さんに、レビューのサンプリング技を学ぶ #infotalk

　産業技術大学院大学が主催している、Infotalk というイベントがあります。Webサイトによると、

ICT関連の熱い技術，面白い活用等を取り上げ，いろいろと議論したりする場（勉強会&交流会）

だそうです。
　その第38回は、日本IBMの細川宣啓さんによる「ソフトウェア品質検査技術と静的解析～インスペクション技術を中心に」というテーマ。ソフトウェア品質技術者たまねぎ戦士のわたしとしては外せないイベントです。

　このエントリーでは、その内容を一部、お伝えしたいと思います。
　なお発表のスライドは（まだ）公開されていませんが、内容の一部は細川さんの別の講演でも紹介されているので、そのスライドをご参照ください。たとえば、コチラ（PDF)です。わたしの記事には文章しかないので、わかりづらいと思います。

サンプリングの重要性

　大きなテーマがいくつかありましたが、わたしが特に気になったのは2つ。ドキュメントのレビューとコードインスペクション、それぞれの対象の選び方です。
　レビュー自体の能力ももちろん重要ですが、その能力を最大限生かすためには、対象を効率よくサンプリングする能力が必要なのですね。

　V字モデルで開発している組織は多いと思いますが、その実態は、設計のある段階からテストのある段階までを外注する、つまりV字の下の部分を自分たちでは行わない「洗面器モデル」。
　その洗面器に入れる「発注時のドキュメント」と、洗面器から出てくる「納品時のプログラム」の品質の見極めが大事であり、そのためにはそれぞれを適切にサンプリングする方法が必要だというお話です。

ドキュメントのサンプリング

　まずはドキュメント。膨大なドキュメントからどう、品質的なリスクの高いものをサンプリングするか。

　設計工程で得られるデータといえば、見積もり規模、ドキュメントの枚数、レビュー工数、レビュー指摘件数などでしょうか。
　これらを組み合わせて、何がしかのメトリクスを作ることはできます。伝統的な指標については、たとえば『定量的品質予測のススメ』にたくさん載っています。

定量的品質予測のススメ―ITシステム開発における品質予測の実践的アプローチ (SEC BOOKS)

続 定量的品質予測のススメ(SEC BOOKS)

　ですが細川さんの提示された散布図は、これらをなぎ倒すものです。
　この散布図、ドキュメントの最終更新日時の「日付」横軸に、「時刻」を縦軸に持っています。そこにはどんなパターンが現れるでしょう。

　たとえば、縦に現れる強い筋。縦ということは同じ日に多くのドキュメントを更新しまくっているということで、つまりは納品直前だったりします。
　さらにその納品日直後に、台形を左に倒したような形（右に長い辺、左に短い辺）。これは、「納品日は早上がりして、酒を飲みにいく。翌日以降は一時的に、出勤時刻が遅く、退勤時刻が早くなるが、納品後のお客様指摘への対応のために徐々に労働時間が長く・・・」ということを意味するとのこと（笑）。 　「最終更新日時」なんていう普段は気にもしない属性が、プロジェクトの様子を如実に表していますね。

　このように、グラフが示すパターンから事実を読み取ることを「グラフマイニング」と呼んでいました。特徴的な欠陥パターンの例として、以下のものがあるそうです。

Overnight Work

　午前3時にプロットがある。おつかれさま・・・。でも、そんな時間帯に一人で更新すると、すり合わせ不足による矛盾・不統一の欠陥が多いかも知れない。

2-cluster

　外部設計書と内部設計書、それぞれの納品日直前の黒い筋。この間隔に全然プロットがないということは、内部設計書を書き始めてから、外部設計書をほとんど更新していないということ。仕様追跡性の欠如が疑われる。

　身につまされるお話。。。
　IBMでは、成果物の品質のリスクになるパターンを10数個に整理しているそうです。それらのパターンをもったあたりを狙い撃ちすることで、危ないところから潰していけるということですね。

コードのサンプリング

　まず、細川さん謹製の「欠陥の魚群探知機」という散布図。
　上から下が、基底クラスから派生クラス。左から右が、重い欠陥から軽いバグとしてプロットしています。
　たとえば横に強い筋があれば、広くたくさん誤っているということで、人を次ぎ込む必要がある。縦に強い筋が現れていれば、標準化をミスっているため、みんなで間違っているのかも知れない。こんなことが読み取れると言います。

　さらに、すべてのソースファイルをスキャンして、「診断」に必要なパラメタを抽出します。行数、コメント率、IFの数、try~catchの数・・・。
　これらのパラメタを組み合わせてメトリクスにして、「2万行のクラス」「コメント率が100%」「ifが数100個なのにelseがほとんどない」といったリスクの高い箇所を絞り込み、サンプリングの対象とします。

コードインスペクション LIVE★

　そのうえで、さあいよいよコードのロジックを・・・見ない。まず、ファイルを開いてコードをソートする。！ ？
　ソートにより、デッドコピーが1か所に集まってきたり、深すぎるネストの多さが可視化されたりするのです。これだけでも、ざっくり傾向がつかめるというのです。ダイナミック過ぎてすごい。

　さらに今度は、書かれた言葉を検索する。「TODO」「TBD」「調整」など・・・。中国の開発においては、「XXX」という隠語が使われることもあるとのこと。
　これらのコメントは、仕様がギリギリまで固まっていないとか、とりあえずの実装をしているといったリスクをはらむ。最悪のコメントして、「// 苦肉の策」なんてものまで紹介されました。

　もちろんこれは、下準備。この後に本来のインスペクションがあるわけですが、その前段階としてできることがある、ということです。

　なお、この言葉拾いは、わたし自身もドキュメントチェックの際にやっています。当初は、「以上/以下」「こともある」みたいな、間違えにつながりやすい言葉を拾っていましたが、そのうちより人間行動に着目しｗ、そっち系のキーワードを集めました。
　わたしの場合「XX」と「**」をチェックしていますが、細川さんの観点とはちょっと違って、「XXX参照」「＊＊＊に記載」のようにとりあえず書いたまま参照先のネタを作り忘れるということがあるためです。

その他にももっともっと

　欠陥マスターDBについての話がありました。これは細川さんが以前から進めていた研究の一つで、欠陥の現象や原因を一般化し、その定義、発生の兆候、検出方法、除去方法、副作用などを整理したものです。
　これらの特性を数値化し、それを「Shape of Defects」として可視化したり、欠陥同士の関連性を見つけたりという欠陥エンジニアリングの研究を進めているそうです。

　このようなトピックは、来週開催されるJaSST'12 Tokyoでもお話されるとのこと。JaSST参加予定の方は、ぜひ聞いてみることをオススメいたします。

　細川さんはプレゼンの最後に、「日本のソフトウェア開発でもっとも不足しているのは、品質エンジニアだ！」と力説されていました。
　品質とは本当に難しい分野だと思いますが、わたしもその一端を担えるようがんばりたいです。という、小学生の日記のような終わり方ですいません。