品質保証業務（その７：中間品質検査）

中間品質検査は、
品質保証部門が設計での品質の作り込みが正しく行われているか確認するものであり、
中間品質検査時に設計の弱点が発見されたら、
設計に品質向上を要求する（フィードバック）だけでなく、
検査項目の強化（フィードフォワード）を同時に行うこと。
更に、
設計には品質マップ（一般的には、縦軸に機能を、横軸に品質に関する各種イベントを時系列的に表し品質に関する傾向を一目で見れるマトリックス）を作成し自ら品質に関する管理を図るよう指導することが望ましい。
また、ソフトウェア作業契約発注先の中間品質検査にも適用する。
なお、設計部門は下記、問題点管理票、プログラム変更書を作成すること。

■ 問題点管理票は、
プログラムの修正事項及び制限事項を管理し、
対策を漏れなく実施すると共に不良原因を明確にし、
不良分析に役立てることを目的に作成する。

■プログラム変更書は、
プログラムを変更する場合にその理由と内容を明確にし、
プログラムの変更を正しく管理すると共に、
プログラムの変更履歴を保存することを目的とする。

問題点管理票の作成は、
プログラムの変更時に不良が作り込まれることが多いため次の時点で作成する。
・社外事故対策と試送以降摘出の不良により、プログラムを変更する場合。
・既存製品に対する機能追加、仕様改善、及び試送までのそれらの修正と、
新規製品の机上デバッグ完了以降から試送までにプログラムを変更する場合。

プログラム変更書は、
単に変更履歴を残すための物ではなく、
修正内容が正しいことを関連者がレビューするために書くものである。
「デグレードや修正不十分」とならないよう入念なレビューを行うこと。

【デグレードと修正不十分】
修正と言う前向きな行為が後退（デグレード）したり、
停滞（修正不十分）したりしないように、Ｐ票レビューを入念に行う必要がある。
デグレードとは、修正を行った時に不良を作り込むことである。
また修正不十分とは類似の別の不良が発生することである。
プログラムの特性とし、このような「モグラ叩き」のような副作用は頻繁に発生する。
「プラスがあればマイナスがある」、「表があれば裏がある」ことを忘れずに、
常にデグレードの発生の可能性を考えておく必要がある。
思い込みや先入観がデグレードを発生させるので、単純なことでも確認を怠らないようにすべきである。

中間品質検査は、
品質に関する問題点を早期に把握し、品質向上を立てさせることが狙いであるため、
工程の完了宣言に伴い、設計が実行すべきことを着実に行っているか、
作業手順に誤りや抜けは無いかを工程ごとに、以下の観点で品質状況を確認し、
必要に応じて「中間品質検査報告書」を発行し対策・改善を図る。

（１）不良摘出の目標値と実績値から、異常値の原因を究明し設計に対策を立てさせる。
工程完了ごとに不良分析を行い（量だけでなく、内容を分析）その工程を完了して良いか判断し不十分であれば、作業内容や不良摘出観点を追加する。量の判断は、過去の実績等を参考とする。

（２）ＰＣＬ確認結果のサンプルチェックを各工程の完了時点で行う。
サンプルチェックは、検査で確認が困難な項目を選択するのが良い。
テスト困難なものほど、テスト不十分になり、結果の判断を誤ることが多い。
不良を社内工程で発見できなかった原因別に分類した的を絞った対策を講ずること。

（３）モジュール別品質評価
後工程で不良摘出が多いモジュールほど、また、不良摘出累計が多ければ多いほど品質が悪く、残存不良も多いと考えられる。
なぜならば、不良修正により別の不良を作り込んでいる可能性もあるからである。
初期品質が悪いものは、デバックでは完全な品質向上は不可能なので、
モジュール別不良摘出件数一覧を確認し、品質を評価する。
特に、不良摘出件数累計が多いモジュールは、中間工程で作り込み品質が悪いと判断し、
最初から作り直すことも考えさせる（設計に「リコーディング基準」を設定させるとよい）。

（４）プログラム不良／ドキュメント不良コードによる評価
■プログラム不良の分類による評価としては、
・ デグレードまたは重要度の高いの新規不良が多い場合は、
設計技術力が低く、品質が安定しないので、上位技術者によるレビューを要求する。
・ 新規不良が多い場合は、
製造技術力の問題が多くコーディングレベルの問題なのか否かを見極めること。
コーディングレベルの問題ではなく仕様がらみの場合は、要求仕様の段階のものか、
機能レベルの段階のものかと言った観点で根本原因を追求し対策を講ずる必要がある。
・ 潜在不良が多い場合は、
不良を作り込んだバージョンに遡りサポート仕様の範囲を限定し必要に応じて再検証する必要がある。
更に、重要度に応じて既存製品（バージョン毎）への事故対策も行う必要がある。
これらの不良発生状況も品質マップに反映させておくこと。

■ドキュメント不良の分類による評価は、
・ 記述漏れ、記述不足、記述誤り、仕様不足に関しては、
プログラム不良と同様重要な評価項目である。
これらの不良が多いと合否判定を誤ったり、製品の品質が安定しない。
プログラム不良と同様、コード分類し、根本原因を追求し対策を講ずる必要がある。
・ 誤字脱字等に関しては、基本的にドキュメントの電子化を図りワード等の校正機能を利用させ自動化を図ること。
全工程を通じて品質評価結果を記録しておき、
品質の推移をフォローしていくと、後工程や社外で問題が生じたとき、対策を立てやすい。
「機能別＆担当者別不良発生推移」を作成して記録に残すようにする。
これにより、時系列的な品質の安定度合い（成熟度）を知ることができる。

【ＰＣＬの必要性】補足
「自分のプログラムを自分でテストするな」とよく言われているがこの意味は、
自分で作成したプログラムは、どうしても“上手く動くこと”をテストしようとしてしまい、「エラーを見付ける」というテスト本来の目的を外してしまうからである。
自分でテストをすると、本来の目的に沿った姿勢に立てずに、どうしてもテストが甘くなってしまう。
しかしながら、現状では効率面や細かな仕様実現の確認の面では自分のプログラムを自分でテストし、基本動作の保証を行う方法がベターと言える。
このため、事前にテスト計画を立てテスト項目を作る必要がある。
そして、テストを実施する際には、そのＰＣＬに従って、感情や願いを入れずに、愚直に確認していく。

ＰＣＬは「要求仕様」に基づき作成する。つまり、
・ 要求の範囲を間違って理解していないか
・ 要求範囲が正しいとした場合、要求を実現する方法を間違えていないか
・ 実現方法が正しいとした場合、実現すべき要求を勘違いしていないか
・ 実現要求も正しいとした場合、要求を見落としていないかなどをテストする
これが出来るかどうかは、要求仕様書がうまく書かれているかどうかにかかっている。
個々の要求を明確に管理していかなければ、要求にあった効果的なＰＣＬを作ることは困難である。
要求仕様がキチンと出来ていれば「マトリックス」にすることが出来る。
先々の使い方まで良く考えた要求仕様書が、その後の設計作業やテスト作業をスムースに進める。
これをいい加減にして先に進んでも設計モレやテストモレによってリワークが発生するだけである。