品質保証業務（その６：検査項目作成）

検査項目作成は、
製品検査作業の「質」「量」を左右する最も基本的な作業の一つである。

検査項目は、
ユーザの観点から設定（入力条件、結果確認項目等）するのが基本であるが、
それだけでは不良を見逃す確立が高い。
特に、ハードウェアに密着した部分ではハードウェアとのインタフェースまで立ち入って項目を作成する必要がある。

【検査項目】
・ 製品の品質評価や合否判定をするための基準である。
・ 対象とする製品のもつ機能、性能、及び操作性等に関する項目のうちで、
検査の対象とする項目等の各種外部仕様を具体的に記述したもの。

【検査項目の性格】
・合否判定の最小単位である。
・ 品質評価の基準である。

（１） 検査項目は、次のドキュメントに記述されていることを基準に作成する。
要求仕様書、機能仕様書、マニュアル、取扱説明書等

（２） 検査項目作成前に、「検査計画書」で検査項目作成方針、検査項目作成目標件数を立案する。
・ 検査項目の着眼点、重要事故防止項目、デグレード防止項目等の作成方針を明確にする。
・ 確認方法を明確にする（特に治工具やシミュレータ使用の場合）。
・ 検査項目数を。

（３） 注意すべき事項
・ 設計のデバッグ／テストで摘出した不良の分析を行い類似項目の追加をする。
これは、デバッグ／テスト時に不良が多かったモジュールや機能はそれだけ残存不良が多いし、修正時にデグレード／修正不十分である可能性があるため。
・ 製品検査で見逃して、他部署や社外事故で発生した不要も必ず検査項目に反映する。

【検査項目設定基準】：前提として、設計作成のＰＣＬレビューを実施していること。
下記の数値は、あくまでも参考まで、設計の目標値や品質保証部門の指標を参考に設定すること。
・ 検査項目の量的設定基準は、生産ｋｓ当たり約１０件程度を目安とする。
・ 質的設定基準は、正常：４０％、異常：４０％、境界・限界等：２０％を目安とする。
・ 重要機能に関しては、基本機能の２～３倍程度の検査項目を目安とする。
・ 潜在不良摘出のため、事故分析を行い既存機能の項目設定を考慮する。
・ デグレード防止確認項目は上記以外に上積みする。

品質保証業務（その５：ドキュメントレビュー・検査）

品質保証部門は、
設計ドキュメントのレビュー（デザインレビュー、設計検討会等）に積極的に参加すると共に、ドキュメント検査により品質の作り込みを行うことが重要である。

■ドキュメント検査の着眼点は次の通りである。

（１）仕様の良否を判定する。
・機能の整合性や統一性をチェックする。
・処理方式の妥当性をチェックする。

（２）記述品質の良否を判定する。
・正確性（要求仕様と機能の対応が正しく記述されていること）
・明確性（スティタスマトリックスや状態遷移図を使用する）
・記述範囲の十分性（性能、信頼性等について記述されていること）
・理解容易性（操作性等について記述されていること）
・統一性（用語、形式）
・ドキュメント間の整合性
・ドキュメント体系

（３）提供情報の十分性、適時性を評価する。
・マニュアル体系の十分性
・関連するＰＲ資料等の発行するタイミングは良いか

（４）留意事項について
・性能に関しては、メモリー容量、Ｉ／Ｏ回数については当然のこと、処理時間、応答時間についても記載され、且つその裏付けを与える内容が記述されていること。
更に、性能目標値（顧客要求値、前提条件、必要資源等）が明確になっていること。
・信頼性に関して、障害に対する回復機能やトラブルシュート機能が記載されていること。
更に、エラー処理や特殊条件の処理（限界・境界）及び、
データの流れの変曲点処理（バッファ／データのオーバーフロー処理等）が記述されていること。

■マニュアル検査について

マニュアルは、顧客の立場を考慮して、読み易さ、使い易さの他に、
製品安全及び製造物責任の観点から記述内容及び表現を検査する。

（１）タスクオリエンテッド（作業主導）に記述すること。
・一つの作業をする時には、必要事項は一冊のマニュアルで完全に網羅されていること。
他のマニュアル参照の度合いが少ない方が良い。
このため、マニュアル体系を考えるときには、作業単位に分類して考える必要がある。
作業者は一人でも、プログラマでありシステム操作員でもある場合がある。
・「ｘｘｘ機能は○○○である」ではなく、「△△△の作業をする時にはｘｘｘ機能を○○○のように使用する」と書く。

（２）図表や実例を使用して説明する。
・文章だけでは理解が困難な物は、文章と図の組み合わせで記述する。
・文章よりも図のほうが直感的で理解できるし、記憶に残り易い。
・複雑な文章を多く書くよりも、表にまとめると理解しやすい。
・使用者は、実例と同じに実行して、理解を深める（練習用の例題）。
・図表の使用は１ページに１個程度あると、読む気にさせる。

（３）文章は、理解が容易であること。
・難解な専門用語は使用しないこと。

（４）留意事項について
・統一性／整合性；
必要事項が記述されていて、一つのドキュメント内で矛盾がなくかつ複数のドキュメント間に矛盾がないこと。
更にボリュームが適切であること（少ないほど良い）。
・理解の容易性；
誤りがなく、読み易く理解しやすいこと（文章や用語理解の容易性）。
ドキュメントの全体体系が明確であること。
・トレーサビリティ；
仕様の展開が上流から下流まで理解しやすいこと。
更に検索しやすいこと（索引の良否）。
・その他；使いやすさ、保守のしやすさ、性能について明確になっていること。
更に見栄えが良いこと（カラー、イラスト）等。

（５）ＰＬ（Product　Liability）との関係
買い手が、製品に期待していた安全性が期待と異なっていた、
あるいは意図した使用目的に合致していなかった、
ということでその製品を欠陥とする基準（消費者期待基準）が使われる。
次のような取扱説明書の不備により製造物の責任を追及されることがある。
・あいまいな用語の使用
・注意事項が記述されていない
・使用誤りについての警告が無い。
絶対やってはいけないことは、目立つように大きな文字等で工夫する。
・誤使用などに関する予見可能性の限界についての警告が無い（誤使用をすると、予見できない結果が発生する）。
・不実表示。「機密保護は完全である」、「信頼性１００％」などの記述は事実に反する。

■不合格内容の確認
・記述漏れ、記述不足、記述誤り、仕様不足に関しては、プログラム不良と同様重要な評価項目である。
これらの不良が多いと合否判定を誤ったり、製品の品質が安定しない。
プログラム不良と同様、コード分類し、根本原因を追求し対策を講ずる必要がある。
・誤字脱字等に関しては、基本的にドキュメントの電子化を図り、ワード等の校正機能を利用させ自動化を図ること。

【製造物責任ＰＬ：Product Liabilityについて】

ＰＬとは、
製品の欠陥等により使用者又は第三者が生命、
身体または財産に損害を被った場合に製造業者や販売業者等が負うべき賠償責任をいい、
1995年7月1日に立法化がなされた。
日本におけるＰＬ法制定は、総合製品安全対策の施策の一部として位置付けられており、
製品によって生じる事故のない安全な社会をめざすことが目標である。

ＰＬ対応には、
・ＰＬ事故発生の防止（製品安全ＰＳ：Product Safety）と、
・万一事故が発生したときの迅速で誠意ある対応（ＰＬＤ：Product Liability Defense）がある。

【ＰＳの十戒】
（１）安全は全てに優先
（２）常識としてかたづけるな
（３）顧客からのクレームは神の啓示
（４）まさかと思う事故発生
（５）公的基準は最低限の基準
（６）安全装置に頼り切るな
（６）人間工学、心理学の面でのムリは大怪我のもと
（８）安全に老朽化は許されぬ
（９）安全を確立のみで割り切るな
（１０）顧客に期待するな

【ＰＬ法に対する考え方】
ＰＬ法の対象とする製造物の範囲や欠陥については、
時代と共に変わっていくので常に最新の情報で対応すること。
現状では、ソフトウェアに関しては下記の通りである。
・ＰＰ：Program Product。ＵＰ：User Program。
ソフトウェアを組み込んだ製品（ハード・ソフト一体型）は対象となる。ソフト単独では対象外。
・ＡＰＰ：Application Program Product。対象となりうる。
・ＳＩ：System Integration。サービスであるため対象外。

【マニュアル検査のあり方】

いろいろな方法が採用されているが、現実的には、
「マニュアル検査について」の留意事項に的を絞った形式的な観点からのチェック方法が多い。
できれば上記に加え、スペシャリスト（ｅｘ、ネットワーク、ＤＢ等）による的を絞ったチェックが効果的である。
なお、スペシャリストは品質保証部門だけでなく広く適任者を募り全社的な運動として品質活動を推進するとよい。

【観　点】
・読み手について知る（平均的な読者層を念頭に置く）
・読み手は関連知識をもたないと想定せよ（冗長度をやや高めにおく）
・専門用語の使い方に注意せよ（専門用語が理解できるように記述する）
・読み手の不安感を取り除け（親切に書く）
・読み手に正しいイメージを与えよ（全体の枠組を与える）
・「例え」を活用せよ（全体のイメージをつかませる）
・「わかる」ことを目指せ。操作の理解や記憶も促進されるし、満足感も得られる（単なる使い方「how　to」だけでなく、なぜ「why」も記述する）
・マニュアルの読み方を示せ
・設計思想を語れ（操作の共通点をまとめる）
・因果関係を示せ（禁止事項をやったらどうなるかを書く）など。

品質保証業務（その４：検査計画）

検査計画

品質保証の基本は、
すべての作業の実施前に計画書を作成し、着実に実行することである。
また、計画が良いかどうかをレビューし、関係者の知恵を結集することが大切である。
さらに、計画書は作成したら、工程の途中で予定通りに実行されているかをフォローする必要がある。
計画書（検査計画書）は、次の観点を明確にし、上長の承認後、設計、他関連する部署に知らせる。

検査概要は、
顧客名、開発規模、マシン使用時間などを明確にし、
不合格摘出目標は各設計部の品質目標値を参考に部方針に従って設定する。

開発概要は、
製品の目的、概要を簡潔かつ明確に記入する。
開発形態に関しては、新規の場合は類似製品の調査を行い必要に応じて参考にすること。
改造品に関しては、母体製品の調査を行いどのような品質であったか生い立ちを調べて参考にすること。

検査方針は、
・ドキュメント検査：対象ドキュメントのレビュー状況の品質を確認する。
・検査項目作成：質、量の両面から配慮すること。
・検査環境：
早期の手配が必要であり当該プロジェクトの開発計画段階から配慮すること。
それと、顧客使用環境との相違点を明確にしておくこと。
・プログラム検査：これを一般的には製品検査と呼んでいることが多い。実機による確認。
プログラム検査方針を明確にする。試送条件、品質向上要求基準について明確にする。
・品質管理方針：
工程完了判定基準を明確にする。
中間品質検査の方針を明確にする。
特に性能、信頼性に関しては早期に対応しなければならない。
・受入検査方針：受入検査基準を明確にする。

検査工程は、
検査計画から工完までの全体工程を線表で作成する。
工完日から日程を考えたり、明らかに期間が短すぎる、長すぎるなどの計画とならないようにする。

品質保証業務（その３：製品検査の流れ）

製品検査の流れ

品質保証部門は開発工程からアフターサービスまでの一貫した品質保証活動を推進する。

【製品検査とは】

製品を何らかの方法で調べた結果を判定基準と比較して、製品の合格、不合格を判定することである。

【検査とは】

JIS　Z8101によると、品物を何らかの方法で試験した結果を、品質判定基準と比較して、個々の品物の良品・不良品の判定を下すこと。

【製品検査に関する業務】

[見積り審査会レビュー参加]：見積調書、見積取纏め表、リスク管理シート、その他関連文書の審査

[プロジェクト診断会議レビュー参加]： プロジェクト開始報告書、プロジェクト計画書、アローダイヤグラム、リスク管理シート、その他関連文書の審査

[デザインレビュー]： 製品の開発方針や製品仕様の良否をレビュー

検査計画： 品質管理基準や方針及び製品検査作業の計画、作業量、日程などを立案

[ドキュメントレビュー]： 設計ドキュメントの良否をレビュー

ドキュメント検査： ドキュメントの良否を検査

マニュアル検査： 顧客に提供するマニュアルを検査

検査項目作成： 製品の合否判定基準を、ドキュメントを基にして作成

検査ジョブ作成：検査項目を確認するためのプログラム、操作手順書などを作成

[中間品質検査]：設計品質の中間段階での品質を評価

作業監査：設計工程全般の作業の監査

[受入れ検査]：外部へ委託開発／購入品／導入製品等の受け入れ評価

[サンプリング検査]：検査項目の一部をサンプリングし品質の評価

製品検査：実機マシンを使用して製品が判定基準を満足しているかを確認し合否を判定

[システムテスト]：個別の顧客対応の現地テスト等

工完・入庫：製品の作番完了処理

出荷検査：顧客に提供する出荷物が要求とおりに出荷されるかを確認

[　]：必要に応じて実施。

【アフターサービス業務】

（１）社外事故処理：

顧客からのクレームの受付や障害発生時の受付・対策を行う。

事故速報、社外事故週報などで上長に速やかに報告し推進・対策を行う。

（２）予防保守／再発防止策：

製品の稼動実績フォローや事故分析を行い同件事故の未然防止の推進／再発防止対策の推進を行う。

（３）品質維持向上活動：

広く国内外における品質に関する情報を関連部門にフィードバックする。

【品質に関する諸活動業務】

（１）品質目標値設定：

各品質指標の基準値は、予算編成方針及び過去の実績に基づき、品質保証部門が設定する。

品質保証部門は、品質指標及び基準値を明確にし、部方針の設定指示と同期して品質目標値の設定を各部門に指示する。

（２）品質会議：

品質会議は、主に社外事故状況、主要製品の品質向上策を継続フォローして、製品品質の維持と改善を図るために実施する。

（３）品質反省会：

全社レベルで品質に関するT.Tを図り、問題が指摘された場合は指摘事項を是正するために必要な是正処置・予防処置を行い品質記録として保管する。

（４）品質月報の発行：

関連部門に品質データを連絡しT.Tを図る。

【試験に関して】

製品検査のなかの試験に関しては、次のような物がある。

・サイクル試験：

相互に関連のあるプログラム（データの受け渡しなど）を連続して実行する。

実運用を考慮したデータの繰り返し使用（年回し、月回し、週回し）や資源の共用／繰り返し使用など。

・多重オペレーション試験：

複数種類のオペレーションを組み合わせる。

複数端末からのオペレーションや、メッセージの出力／応答の同時入力。

・境界条件試験：

ボリューム数、ファイル数、データ数などの最大値、最小値、特異値を設定し、実行する。

・障害試験：

プログラム実行中にハードウェア障害などを発生させる。

シミュレータなどを用いて入出力障害等を発生させるとより効果的な試験となる。

・多端末試験：

多数の端末を用いて、同時にデータの送受信を行う。

人海戦術では到底実際の顧客と同じ数の端末数の試験は実施できない場合が多いので、

多端末シミュレータなどを用いる。

・性能試験：

性能検査は実測値と目標値との比較を行う。

また、性能上の問題を検査工程で指摘しても、対策に十分な時間が確保できないので、

試送前に設計で性能評価を行うよう要求しなければならない。

設計に性能目標値を設定（性能設計書等の作成）させ、目標値、評価基準、評価手段等の良否をレビューする。

実行性能の評価と、資源の使用効率の両方を評価する。

性能評価尺度としては、

レスポンスタイム（送信キーを押した時点から最初の動作（印字・表示）まで）、

対話処理（単位時間あたりのトランザクション処理件数）、ファイル使用量など。

品質保証業務（その２：テストとは）

テストとは

システムに要求されていることが、正しく組み込まれていることを確認するための行為である。

新規／エンハンス／保守と言った何れの開発であろうと、開発作業の動機は「要求」である。

その要求を、どのように実現しているか、そこにテストの真価が問われる。
従って、「テストはエラーを見付ける」ことにその意義がある。
しかしながら現実には、そこまでテストされないことが多く、その理由は、テストの目的を勘違いしているからである。

「正しく動くことを確認する」という姿勢からは、効果的なテストケースが想定されない。
その結果、表面的な機能テストでは「ＯＫ」となるかも知れないが、限界・境界値や発生しうる特異データを試した途端に、実現の不十分さが露呈することになる。

そこで、事前にチェックリスト（PCL：Program Check List）を作成し、愚直に実施することが重要となる。

【テストと品質】
「テストで品質の向上を図る」という考え方の人がいるが、テストは、
プログラムが要求仕様を実現しているかどうかを確認する行為に過ぎない。
したがって、テストは仕様の確認行為であって、ここには品質を作り込む機会はない。

品質は、あくまでも仕様策定や、その仕様を実現すべく適切なデータ構造などの設計や、実装の作業の中で「作り込まれる」ものである。

実際に、データ構造の選択を間違えると品質を満たさない事が起きる。

その状態を発見することがテストであって、その時点では、品質は既に作り込まれている。

【テストの作業分析】
テストは、現実問題として省くことは出来ない。
設計の問題を含めて、テストのあり方を考えるのに、テストのどの作業に時間がかかっているか測ってみる。

現実のテスト作業を調べて、作業を定義すれば、時間などを記入するシートが作れる。

テストそのものに時間がかかっているとすれば、
・ それはテストの量が多いからか
・ 個々のテストに時間がかかっているからか。あるいは
・ エラーの修正作業に時間がかかっているのか

原因が、テスト仕様そのものが用意されていないことにあるとすれば、全く論外である。

【テスト者の心理】
設計者がそのテストを“簡単で、容易で、また自明”だと考えた瞬間から、
警戒心が薄れ、品質意識が軽視され、そして、多くのケースでテストが誤って行なわれるようになる。

これは、誤ったテストという形か、または考えもしなかった副作用という形で、結果が現れる。

特に厳しい状況では、“簡単だと思いたい”心理に陥り、厄介な問題なのである。