仕様書をチェックしてソフトウェアの欠陥を予防する　――日本アイ・ビー・エム サービス事業 品質技術 細川宣啓氏に聞く

　日本アイ・ビー・エムでは，ソフトウェアの欠陥を検出するために，「Quality Inspection」と名づけた手法を（組み込み機器開発の部署も含めて）実践している．これは，仕様書を熟視して矛盾や不整合を見つけ出すことにより，ソフトウェアの欠陥を仕様書の段階で検出する方法である．「インスペクション」というとコード・インスペクションが有名だが，Quality Inspectionは，審査の対象がコードではなく仕様書である点，会議の形態をとらずに個々人が作業を分担して実施する点などが異なっている．ここでは，Quality Inspection担当部署である日本アイ・ビー・エム サービス事業 品質技術 プロジェクト品質技術担当の細川宣啓氏に話を聞いた（写真1）．

[写真1] 日本アイ・ビー・エム サービス事業 品質技術 プロジェクト品質技術担当の細川宣啓氏

――Quality Inspectionを始めたきっかけを教えてください．

細川氏　そもそも，ソフトウェアの欠陥除去コストを最小にするためには，完成したソフトウェアをテストするよりも，上流で欠陥の混入を予防したほうが効果的です．欠陥の除去にかかるコストは，一般に「コーディングの前なら100ドルですむものが，コーディング後になると1万ドルかかる」と言われています．コードになる前と後のコストは100倍くらい変わってきます．

　コード・インスペクションでは，そのソース・コード内のバグはよく見つかるのですが，プログラム間のインターフェースのバグを検出することは容易ではありません．Quality Inspectionなら，それをあぶりだすことができます．

　また，会議形態のインスペクションには，「審査する目の数が多い」，「お互いに触発されて検出効果が高まる」などのメリットがあるのですが，その一方で時間がかかり，また会議が長時間に及ぶので疲れる，というデメリットがあります．そして1件につき5～10日もかかってしまうので，ソフトウェアの開発コストが高くついてしまいます．

　インスペクションを実施すれば欠陥除去効果が上がることはわかっていたので，当時，これを社内のすべてのプロジェクトに適用するためにどうすればよいかを考えました．そのとき考えたのが，短期間のインスペクションを繰り返し適用するという手法です．時間を短縮するために会議の形態をとらず，個人個人に作業を分担させることにしたのです．

●欠陥を絞り込む事前検査を実施

――チェックする仕様書はかなりの量にのぼるのではないでしょうか？

細川氏　はい．だいたい1件あたりの仕様書は，1,000ページ前後から数Gバイトのものまであります．10Gバイトと言えば，28年分の新聞記事に相当します．仕様書の始めから終わりまでのすべてを熟読していては，いつまでたっても作業が終わりません．

　そこで，われわれのしごとのポイントは二つあります．一つはツールを利用することです．例えば，だれかが病院に行った場合に，いきなり手術したりはしません．いろいろと検査してから，処置を施します．それと同じように，プロジェクトから依頼された仕様書をツールにかけることによって，欠陥の傾向を予測し，それに基づいてQuality Inspectionを実施するのです．

　ツールでは，ファイルの作成日時や作成者などを機械的に抽出します．

――それらの項目から，どのようなことがわかるのですか？

細川氏　例えば，複数あるドキュメントのうち，違う人が作っているものや，作成日時が離れているものは，そこに矛盾がある可能性が高くなります．ほかにも，作成時間が深夜の場合にミスが生じやすいとか，いろいろと兆候が見つかるものです．そのあたりはノウハウなので，あまりお話しできないのですが...．

　そして，矛盾や不統一がありそうな箇所を，関連するものごとにまとめて，それぞれ担当者がチェックします．

●コストと品質のバランスを考えてテストを行う

細川氏　さて，ポイントの二つめは，サンプリング・レートを決めることです．プロジェクトに要求される質に応じて，仕様書の何％をサンプリングしてチェックするかを決める必要があります．

――サンプリングにもれた部分については，欠陥があっても検出できないのではないかと思いますが？

細川氏　もちろん，どの部分をサンプリングするかはとても重要です．それを，先ほどお話ししたツールで抽出するのです．また，Quality Inspectionのような仕様書のレビューの段階では，いちばん重要な欠陥，つまり致命的な欠陥だけをチェックできればよいのです．細かいところについては，その後にユニットごとのテストや結合テストがあるわけですから．

――それだけ絞り込んでも，やはりドキュメントはかなりの量だと思うのですが，それをどのように読むのでしょう？

細川氏　基本的に，「矛盾，不整合，不統一」．この三つが存在する箇所を見つければ，そこに欠陥があることが多いのです．Quality Inspectionの担当者には，他人が見逃すところを見つける洞察力や集中力などが必要です．ふつうの開発者が見つけられることしか見つけられないのなら，わざわざ専任担当者を使う必要はありませんから．

　また，担当者には体力や根気も要求されます．そのため，休憩や食事のとりかた，体力づくりなども考えていく必要があります．

●開発担当より高いスキルが求められる

――テスト担当は開発担当に比べて低く見られたり，テスト担当と開発担当が反発しあうなどの風潮が一般的にあるようですが．

細川氏　確かに，設計の欠陥を指摘するわれわれの部署は，憎まれ役の面もあります．プログラム開発者は，本当は顧客のためのプログラムを開発しているはずなのに，いつのまにか「自分たちのプロジェクト」，「自分のソース・コード」という意識が生まれてしまいます．このような意識を取り除くのはなかなか難しいのです．だから，どうしても「よけいなことを言いやがって」という目で見られてしまいがちです．しかし，プロジェクトが成功すると，とても感謝されます．これまでに，社内のプロジェクト・チームや顧客から，ずいぶん多くの感謝状をもらっています．

　また，われわれの部署は，開発者よりもつねに高いスキルが求められます．だから，若いメンバであっても，現場の第一線のプロジェクト・リーダと対等に話をしています．

●情報を共有し，教え合って向上する

――実践しているチーム・ビルディングについて教えてください．

細川氏　われわれの部署では，1日に30分「お茶会」の時間を設けています．みんなでコーヒーを飲みながら，作業を通して気づいたことや感じたことを話し合う場です．新人がわからないことがあれば，ベテランが説明します．また，対象となる業種ごとの事情や気を付ける点などについても話します．そのように技術を共有し，技術移転を図っています．

　また，ベル＝ランカスター法と言われる「助教法」を取り入れています．これは「教わる人が別の人に教えるために学習する，というサイクルを作ると，技術が定着する」というやりかたです．われわれの部署では，「教わった者は，それに自分のアイデアをプラス1して次の人に教えろ」と言ってあります．だから，みんな教わるときには必死でメモを取っています(笑)．そうやって，自ら学び，向上する風土ができています．

（本インタビューの詳細は，Design Wave Magazine 2004年9月号[8/10発売] に掲載されています）