インスペクション

前回は、ピアレビュー教育の概要を紹介し、教育の中でピアレビュー会議を実践することが効果的である、ということを説明しました。ピアレビュー会議のあ と、30分程度の時間を使い、ふりかえりを必ず実施するようにしています。

レビューは欠陥検出、関係者の認識共有と合意形成、効果的解決手段の検討促進、エンジニアの育成および開発全体の生産性向上などに有効な手段と言われて います。また、実機でのテストに比べて「1．欠陥を安価に検出できる」「2．機能や処理の抜けを検出できる」などの特徴を持ちます。

大規模ソフトウエアの保守・拡張開発で起こる問題の多くは、中小規模の開発でも存在します。しかし、中小規模では目をつむっていられるものでも、規模が 大きくなるにつれ、対処できないほどの問題になります。今回取り挙げる問題点は、大規模ソフトウエアを長期間保守・拡張していれば、どの開発でも遭遇する ものです。

ソフトウエア開発におけるレビューは、開発技術や管理技術の成果物に含まれる欠陥を早期に検出して取り除く活動として重要です。しかし、レビューの準備 段階から指摘に対する是正が完了するまでの活動に誤りがある場合は、効率よく欠陥を検出することができません。

レビューを組織やチームで定着させるためには、必要性を認識してもらったうえで、レビューの基本的なルールやうまく実施するためのポイントを理解する必 要があります。そのための方法として、組織単位でレビュー教育を実施することが効果的です。

今回は品質の定量測定について「定量測定はなぜ必要か」について考察してみましょう。品質定量測定の目的は、実にさまざまです。その理由は立場／ 役割（ロール）によって、品質を理解／把握したいと思う動機がさまざまだからです。

インスペクション／レビューにおける欠陥の指摘は自由度が高いため、本題である欠陥や矛盾の指摘から話がそれてしまうことがあります。例えば、質問ばか りで指摘が全くされない、品質向上につながらない指摘が多い、極端な場合にはインスペクション／レビュー対象のソフトウエアから離れてしまい、ベテランの 昔話を拝聴する場や愚痴を言い合う場になることもあります。

Red Hat Enterprise Linuxのトラブルの原因を調査する仕事をしていて大変に印象的なのは、「簡易なソースコード読解作業」に よって多くの問題の原因を突き止めるに至っている、ということです。「簡易なソースコード読解作業」とは、例えば次のようなものです。今、トラブルに対応すると考えられるログ出力を得たとします。トラブルの原因を究明し たいが、ログだけを見てもその意味がわかりません。ところがこのログ出力を行っているソースコード行を特定し、その行を囲うif文の条件式から、ログの意 味がわかり、まさにそのログがトラブルの原因を説明していたことが判明しました。

今回は、財団法人 日本科学技術連盟2007年度ソフトウェア品質管理研究会の第1分科会グループAとして活動した成果として、メトリクスを活用したソフトウエア品質を客観的に評価する手法について紹介したい。