ソフトウェアの品質保証

作成日:2000-12-29
最終更新日:

ISO 9000 とソフトウェアとの相性

ISO 9000(1994 年度版)は、率直にいってソフトウェアとの相性はよくない (以下、このページでは、断わりがない限り ISO 9000 といえば 1994 年版を指すものとする)。 もっといってしまえば、ISO 9000 は製造業向きの規格であり、その他の業種には向かないようだ。 そのくせ、製造業といっても、大きく分けて素材産業型と組立産業型というのがあり、 その両者でもまた異なるようだ。 生産管理の観点から見れば、標準品(カタログ品)を生産するタイプと、 特注品(受注生産)のタイプがあり、これまた仕組をどのようにするかは頭の痛い問題である。

とにかく、ソフトウェアはソフトウェアなりの難しさがある。一例を挙げよう。 ごく小規模なソフトであれば、(そして小規模なソフトから入る人が多いのだが) 設計とコーディングとテストが渾然一体となっていて、いちいち工程を区別することができない、 というものである。ところが、ISO では、設計はこうしなさいとか、工程を管理しなさいとか、 テストが通るまでは次に進めないよとか、けっこう大変なことをいってくる。 これでは、ソフトウェア実務に携わる方はたまったものではない(と思う)。 もちろん、私が ISO 推進の事務局となったときから陽に陰に言われ続けてきた。 またこんなこともあった。徹マンの最中、隣の雀卓から「今度俺の会社 ISO 取るって いうんだけれど、管理者の自己満足だよ」という声が聞こえてきて(この雀士もソフト業界の人)、 急に酔いが覚めたこともあった。

さて、どのように反論すべきなのだろうか。 これはどこかで書かれていたのだが、 ソフトウェアといってもソースコードの行が○○行をこえると、そのソフトウェアは ハードウェアとしてと変わりない、というソフト技術者の方がいた。 今の所はこれだけにしておこう。

あてはめと齟齬

ソフトウェアで ISO 9000 をとろうとするときには、 2つのアプローチがあるとはよく言われることである。 ここでいうアプローチとは、 ソフトウェアの各工程と ISO で要求されている事項の各項をどのように対応付けるか、ということである。

一つのアプローチ(a)は、ソフトウェアの設計からプログラミング、デバッグ、テストまでをすべて、 ISO の設計管理で位置付けることである。この場合、工程管理は単に媒体やネットワーク上に プログラムを格納することとなる。 そして、ISO の検査・試験とは、媒体やネットワークが正常に動作することを確認するだけの事になる。

もう一つのアプローチ(b)は、ソフトウェアの設計のみをISO の設計管理と位置付け、 プログラミングをISO の工程管理で、デバッグ、テストを ISO の検査・試験で行なうことになる。

字面だけからの対応では、b のアプローチがよさそうに思える。 しかし、これではテストの管理が大変である。実際にソフトは、テストとデバッグに多大な工数を要する。 厳密に ISO の各条項を満たしつつ、 実態に即した品質マニュアルを記述するのは一大事である。

そこで、実際の審査を受ける組織は a のアプローチが多い。また、巷のソフトウェア ISO 9000 本も このアプローチを勧めている。

ところが、私の勤務している部署では、bのアプローチをとった。 a のアプローチでは、工程管理以降が有名無実になってしまうのである。 ISO を推進している部署の経営者は、 ソフトウェアは工場のハードウェア組立品と同じように清算されるべき、という信念を持っていた。 そのため、b の方法を採用した。

じゃあ、お前のところの品質マニュアルはどうなのか、ということになると、 厳密に ISO の要求事項を満たしているかという観点からみると、怪しいところがあるかもしれない。 しかし、運用できればいいのである。ISO は品質マネジメントシステムであるから、 厳密に要求事項を満足しているかなどということは気にしない。 利用者はISOのために仕事をしているのではない。そして、利用者は学者ではない。

審査員は、ソフトウェアでこういうタイプをとる方々は珍しいと口々にいっていたが、 だからといってこの対応付けによって審査の観点がおかしくなるということはなかった。 (他の点でおかしいということはあるが、これはソフトウェアの分野に限らず、どこにもあること)。 それに、b タイプも徐々に巷で見るようになってきた。こちらのほうが、 工程の始めと終わりをきちんととらえることができる。b タイプを勧める。

ISO 9000-3

この ISO 9000-3 とは、ISO 9001 をソフトウェア分野に適用する際の 「ガイドライン」であった。ソフトウェアに特化した規格だけあって、 ソフトウェアの保守や、構成管理などに多くの点が割かれている。 TickIt などを取らない限りこちらはきちんと読み込む必要はないだろうが、 ソフトウェアの業務管理という観点からは参考になるだろう。

現在では、ソフトウェア開発においては CMMI を、 保守については ITIL なども参照できるだろう。

まりんきょ学問所品質の部屋 > ソフトウェアの品質保証


MARUYAMA Satosi