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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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