品質保証に関する提言（その１：概要）

ユ－ザがソフトウェアの品質を判断する手がかりは、価格、ブランド、マスコミ情報などの「間接的手段」によっている。
日本ではこの手段が全てといっても過言ではない。

米国においては、1980年代から第三者によるソフトウェアテスト（ｅｘ，ＩＢＳＴ社.）が実施され評価されてきた。

1990年代においては、オ－プンなシステムに対して、米国においてPOSIX検定、日本においてもCTRON検定、及びINTAPの適合性試験など標準化に対する各種の試みがなされてきた。

その後、ソフトウェア開発のあり方そのものが各種の開発技法によって大きく変わりつつあり、ますます第三者によるソフトウェアテストの必要性が高まってくるのではないだろうか。

かなり前のことになるが、品質に関するニュースで顧客の意見の中に、製品保証書（テレビ等の保証書相当）を発行し責任を持たせる提案があったことを記憶しているが、現状はそれ以前の問題が多く、先ずは基本的なテスト仕様が作成されていなければ保証書の発行に結び付かない。

従って、ここでは広い意味でのソフトウェアの品質保証に関する課題を中心に提言する。

なお、ここで言うテストとは、「システムに要求されていることが、正しく組み込まれていることを確認するための行為であり」広い意味での検査も含めている。

【追記】
ソフトウェアの世界では、まず、オ－プンなシステムに対して認定証相当のものが発行されてきている。
このため、オ－プンシステムの普及、ＰＬ／ＰＳの強化等により、保証書相当のものがユ－ザ意識として一般化し、要求されるようになってくると思われる。
このためにも、オ－プンでない独自製品に対してもテスト仕様をキチンとしておかなければならない。
なお、現状のテストに関する個人的な感想は2000年当時と一向に変わっていないと言える。
あえて言うならば1970年当時と比較してもそれほど変わっていないと言っても過言ではない。

品質保証技術（その９：変更管理システムの徹底）

変更（バージョン／リビジョン）管理

本件は、製品の生まれから成長過程をキチンと管理することで開発段階から出荷後のトラブル対応までキチンと対応できハードウェアと同様に基本動作の一つである。
バージョン／リビジョン管理の徹底による無駄なテストの防止を図ることが重要である。

品質の早期見極めの為にシステム未完成の状況からテストを開始すると言っても、ある程度機能がまとまっていなければテストにならないので、被テストシステムのバージョン／リビジョン管理をキチンとする必要がある。

せっかく新機能を追加しても関係モジュール全体に対して、整合がとれた状態で追加修正が行われないとテストは無駄な工数を食うだけである。

被テストライブラリが整然とラインアップし、更新されているためには、厳密な変更管理システムの整備と変更管理責任者が任命されていなければならない。

ここでベースとなる「モジュールの大きさ」について、
開発言語等によっていろいろな考え方があるが基本は次のように考えるとよい。

「２～３時間で机上デバッグが完了する程度の大きさが望ましい。
とは言っても、
入り口は原則一ヶ所、
他モジュールを参照せずに開発・保守ができること、
他モジュールをリコンパイルせずに、
当該モジュールだけで修正・変更ができる等の原則論は守らねばならない。」

品質保証技術（その８：製品検査設備／ツール（治工具））

検査環境は、
ユーザ環境に近い環境を作ることが基本である。

この環境設備の良否が作業効率や不良摘出に大きく影響するので、
早い段階から設備に関する計画を推進しなければならない。

・ 技術は、個人個人の技術力が向上しただけでは、それが、蓄積、伝承されるとは言い難い。
ツールや技術資料の形で具体化されてはじめて蓄積、伝承されたことになる。

・ ツールは、テスト手法、テスト環境等を記載し、
ノウハウを個人からチーム（my program → our program）のものにすることが必要である。

・ ツールは、他部門にも活用できるよう公開し、共通の財産としていく仕組みとする必要がある。

特に、デグレード事故（デグレード防止策）の多くは技術の蓄積や伝承の欠如が深く関係している。

○テスト効率向上のために

・ 大規模テストには過去に蓄積されたシミュレータ等の冶工具を総動員しよう。
・ 市販の冶工具を探してみよう。
・ 新テスト技法への絶えざる挑戦をしよう。

品質保証技術（その７：規格／規則／基準／規定／内規）

品質保証に関する下記規則等の整備をし、
品質保証作業の標準化を推進しなければならない。

また、これらの規格等は社会の変化や製品の進化に伴い、
常に改定や改善を行っていかなければならない。

・ 規格（判断の基準となる標準、作業の標準）

・ 規則（行為や手続きなどを行う際の標準、きまり）

・ 基準（物事の判断の基礎となる標準、チェックリスト等）

・ 規定／規程（物事のありさまややり方をある形に定めること、各種技術資料、ツール等）

・ 内規（部内の規定、部門内の作業の標準化）

・ 教育資料等

品質保証技術（その６： プロジェクトの崩壊（逆発想））

１．失敗の原因

○どうすれば、プロジェクトを失敗させられるか！
・ 納期遅延を起こし、開発費オ－バ－
・ 品質が悪くバグだらけ、期待とおりに動かない
・ 性能が出ず、メモリも大幅超過

○失敗の原因の多くは、次の要因である
・ 量の変化は、質の変化をもたらす、という基本原則を理解していない
・ 大きいものは、「分割」して「制御」するという「構造設計の基本哲学」に従っていない
・ よく分かっていない人が何となく作る
・ 仕様が不明確で複雑．．．主任／サブリ－ダが仕様を正確に把握せよ
・ 仕様変更多発、仕様が決まらない．．．仕様は「変わる」という前提で仕事をせよ
・ 性能無視．．．基本としてディスクアクセス回数をキチンとおさえよ
・ 異常ケ－ス無視、最大値／最小値無視・ 論理拙劣、論理過大．．．テ－ブル化を図れ
・ 工程切迫の手抜き．．．結局高価になる、線表を強烈に守れ

２．混乱の要因

○開発体制の不備
・ 主設計者が不明確。全体の技術的責任者は誰なのか。
・ 全体としての意志統一不足。
・ 人員投入の遅れと場当たり的な人員投入。

○基本動作の欠落
・ ドキュメントの更新サボリ。
・ レビュ－のサボリ。
・ ＤＤをサボリ、工程遅延の調整に使用する。

○性能設計の欠落
・ オブジェクト性能の偏重
・ コンパイル性能（コンパイル時間、使用メモリ等）が欠落
・ 管理者の見通し力と決断力の欠如。”何とかなりそう”程度の見通しで、何とかなったためしがない。頑張ることは大切だが、具体的施策の裏付け要。
・ 結果として、一年かけて五月雨式改善とあいなる。