品質保証業務（その１１：合否判定）

合否判定は、
品質保証部門の最大の責務であり、この判断を誤ってはならない。

合否判定基準は次の通り。
・検査項目が全て合格となっていなければ、不合格とする。
・検査ドキュメントが全て検査合格となっていなければ、不合格とする。

【特別採用】
製品検査の結果、不合格となった製品を特定の顧客に出荷することを品質保証部長が決裁し、特別に許可することを言う。
特別採用は、次の項目を満足しなければならない。
・当該顧客に対し、当面は実用上の支障が無いこと。
・不合格項目の解決時期が明確であること。

【品質保証担当役員決裁】
特別採用にも当てはまらない品質内容であっても顧客からの強い要望で形式的に出荷する場合がある。
この場合は、社内的には品質保証担当役員決裁と言う形をとり緊急事態であるということの徹底が重要である。
その後の手続き等は特別採用と同じであるが、
当該顧客に対し、実用上の支障がある点は、
たとえ形式的な出荷であっても明確に周知徹底しなければならない。

品質保証業務（その１０：プログラム検査）

試送
「試送」とは、「合格となるかどうかを試す為に品質保証部門に送る」と言う意味である。

プログラムのコーディングが完了すると、誰でもが直ぐに実行したくなるものである。
これと同じように、設計者は検査合格となるかどうかを安易に試したくなる。
しかし、試送品質が低いと不良による検査実施不可項目数が多くなるので、
試送を繰り返すことになり、結果として工程が遅れることになる。
安易に試送をさせない為に、設計には「後工程はお客様」であることを認識させることが重要である。
つまり「品質保証部門は最初のお客様」であると言うこと。
このため、不合格が発生したときのペナルティーを決めておき、
試送後も設計部署での品質向上を続けさせる必要がある。

プログラム検査
プログラム検査とは、製品をコンピュータで実行し、
検査項目に従って製品が正しく動作することを確認することである。

【品質保証部門は現実主義に徹する】
設計の要求に妥協して納期を優先し、未完成品や代用物で検査をしてはならない。
品質保証部門は、顧客に提供するものと同じ物で、かつ同じ環境で実施するべきものである。
完成品以外の物を、「提供物と同じはず」であるとして検査してはならない。
同じであるはずの物が、往々にして同じでないことが多い。
現物、現場、実物、実機主義を貫く必要がある。

・プログラム検査中に摘出した問題点は、「問題点一覧」に記入し設計に連絡する。
「疑わしきは不合格」の考えで、少しでも疑いがある場合は全て問題点として報告する。
連絡が遅れると設計での調査が遅れ、結果的に工程遅延につながる。
また、折角不良を発見しても、設計部署が口頭で確認して不良ではないと言われて、
社外事故を発生させた事例もある。
判定に迷ったら、上長に相談し、判断してもらうこと。

・全ての検査項目の確認が完了したときにプログラム検査終了とする。
プログラムの不良のために、確認不可項目があれば、判定不可の項目数とする。

・不合格と判定した場合（ドキュメント不良や原因不明を含む）は、
検査見解、設計要求事項を記述した「検査結果の報告書」を作成し設計に差し戻す。
この時、品質向上目標値（設計での不良摘出件数）を設定し品質向上を促す。

・不合格の検査項目が無くなり、その他の検査合格基準を達成したら合格とする。

不合格内容の確認
検査作業で発生した問題は、全て問題点一覧にあげる／あがるような環境にすること。

○プログラム不良：
１件１件、何故設計で摘出できなかったかを５Ｗhy方式で追及し、抜本対策を立てさせること。
デグレードまたは重要度Ａの新規不良が多い場合は、
設計技術力が低く、品質が安定しないので、上位技術者によるレビューを要求する。
新規不良が多い場合は、
製造技術力の問題が多くコーディングレベルの問題なのか否かを見極めること。
コーディングレベルの問題ではなく仕様がらみの場合は、要求仕様の段階のものか、
機能レベルの段階のものかと言った観点で根本原因を追求し対策を講ずる必要がある。
潜在不良が多い場合は、
不良を作り込んだバージョンに遡りサポート仕様の範囲を限定し必要に応じて再検証する必要がある。
更に、重要度に応じて既存製品（バージョン毎）への事故対策の発行要否を検討し、既納製品へのフィードバックを図る必要がある。

○仕様不良：
仕様改善のレビューの実施、ＰＣＬの追加等初期段階からの品質強化を図ること。
プログラム不良より重要な問題であると言うこと認識すること。

○仕様：
マニュアル記述不十分でないか検討し、マニュアルへの反映を図ること。

○ハード不良：
１件１件、設計からハード不良調査依頼表を発行させ、そのフォローを行うこと。

○原因不明：
原因が判明しない限り工完の対象としないことを事前にＰＲし、徹底的に究明に当たること。

○検査ミス：
ユーザミスしやすい原因を究明し、マニュアルをよくするように働きかけること。

【テスト（検査を含む）漏れ】
一言で「テスト漏れ」といっても、実際は、テストケースとして設定されるのが漏れたということ。
限界値テストなどでテストケースが漏れるだけではなく、
その機能が使われる「環境」の想定が漏れることがある。
これはテスト者のスキルもあるが、
テスト仕様としての記述が省かれていることが、「環境」の想定を困難にしている。
このようなケースでは、市場に出てからバグが見つかることになる。
一般に、設計者の立場では「機能」を明らかにするところに重点が置かれ、
熟練したテスト者は、その機能が使われる「環境」に注目する。
設計者も考えないわけではないが、どうしても一つの「環境」の中で機能を考えてしまう傾向があるため、違った環境でテストされると、途端にエラーとなってしまう。
ここに、熟練したテスト者の存在意義があるし、
設計作業を終了する前に、テスト仕様書が書かれていることの意義がある。
テスト仕様書が完成していなくても、出来るだけ早い段階で、
テスト項目を設計者に見せることで、品質を織り込むことができ、同時に、テスト内容の検証も可能となる。

品質保証業務（その９：受入検査）

社外に発注した製品（外部へ委託開発／購入品／導入製品等）が納入されたとき、
その良否を判定するために受入検査を行う必要がある。
納品されたソフトウェアの受入検査は、ドキュメント及びプログラムに対して実施する。

具体的には，
・ドキュメント受入検査；発注条件書に規定された機能を包含しているかどうかについて行う。
・プログラム受入検査 ；発注条件書に規定された機能について行う。
（ただし、取引実績の成績が優れている協力会社の場合は、
協力会社で作成した品質評価報告書で評価を代行するなど協力会社との間で取り決めればよい。ようは品質を如何に確保するかである。）
なお、上記は要求元が受入検査を行う場合で、要求元と品質保証部門とが合同で行う場合も同様である。
要求元とは別に品質保証部門にて独自に受入検査を行う方法もあるが、
企業によって部門の役割が異なるのでどの方法がよいとは言えない。
ただし、本工程は最終工程（顧客に代わって対応していると言う意識）であることを認識し、品質保証部門が受入検査を実施する／しないにかかわらず、ルールに基づいて品質評価を実施すること。
受入検査で不良が摘出された場合は「問題点一覧」を発行し、問題点ごとに、分析し評価すること。

【工程の評価】
受け入れ検査以前に、現在どの工程にいるのかと言った進捗状況を見、
かつその時点の品質状況を把握し評価することが望ましい。
更に、ツールによる評価を行うのも一つの方法で最終工程の綜合評価として効果的である。
例えば、ソースコード検証サービスツールで最終の評価として検証し仕上がり具合を総合評価するなど。

品質保証業務（その８：作業監査）

品質保証部門は、設計部門が規格、内規、作業基準書等に従って、
その生産物及び現場で真にその通り実行されているかを確認する（作業監査）。
これを、ＣＭＭＩの普及に伴い、プロセスＱＡと呼んでいる。

プロセスＱＡとは、対象とする組織やプロジェクトが、
決められたプロセスを守って作業を行うことを保証することである。

【プロセスの考え方】
決められたプロセスと言うのは、組織やプロジェクトが、より良い製品やサービスを提供するために、活動状況を定めた基準や規格のことを言う。
具体的には、開発手順、管理手順、レビュー基準、コーデイング基準、テスト基準等がこれに当たる。
これらの基準は、各プロジェクトで定めているもので、これが「決められたプロセス」に当たる。
プロセスＱＡでは、物作りをする時に、これらの決められたプロセスに沿って作業が進められるかを確認する。
これは、良いプロセスから良い製品が生まれる。
すなわち、良いプロセスに沿って仕事をすれば、良い製品が完成する。と言う考えに基づいている。

■プロセスＱＡの手順と実施時の注意点
プロセスＱＡでは、プロジェクトで定めたプロセス（各種基準、規格）を、
エンジニアリングプロセス（業務プロセス）ごとにチェックする。
また、管理プロセス（要件管理、進捗管理等）もチェックし、
決められたプロセスを守って作業しているかも判断する。
プロセスＱＡは、これまでの品質保証部門による検査（プロダクトＱＡ）とは性質の異なる物で、チェックを行う時には、次の点を注意すること。

■ 現場の実態確認が大切
例えば、進捗報告書の確認や、記入済みチェックリストのような、「成果物」の確認ではプロセスＱＡにはならない。
あくまでも、定められたプロセスが、現場で真にその通り実行されていることを確認することが大切である。

■ 規定されたプロセスが良い物であることが前提
プロセスＱＡは、プロセスそのものの良し悪しを判定する物ではないので、
規定されたプロセスそのものが良いプロセスでないと、プロセスＱＡを行っても効果がない。各プロジェクトに適した良いプロセスが定義されていることが前提となる。

■ 問題点の重要度
定められたプロセス通りに作業しているかどうかを確認すると、
規定はされているが本質的にプロジェクトの成否とはあまり関係ないような、
細かい相違についても指摘があがる事が多々ある。
このような場合、指摘事項がプロジェクトの遂行や製品の品質にどのような影響を及ぼすか、ということを分析して、問題点の重要度をランク付け（Ａ，Ｂ，Ｃクラス等）して整理することが望ましい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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