パッケージソフトウェア品質認証制度申請者ガイドブック

パッケージソフトウェア品質認証制度
申請者ガイドブック

一般社団法人コンピュータソフトウェア協会
平成 24 年度パッケージソフトウェア品質基準委員会

i

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

ii

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

Chapter 1 パッケージソフトウェア品質認証制度発足にあたって

1

1 パッケージソフトウェア品質認証制度概要

2

1.1

パッケージソフトウェア品質認証制度とは

2

1.2

PSQ認証制度の目的と効果

3

1.2.1 ソフトウェア製品の品質認証制度の必要性

3

1.2.2 PSQ認証制度のもたらす効果

3

PSQ認証制度と関係する規格

4

1.3.1 ISO/IEC25000（SQuaRE）シリーズ

4

1.3.2 JISX0129

51.4

PSQ認証制度の対象となるソフトウェア

61.5

国際規格委員会との連携

7

1.5.1 国際標準規格委員会（JTC1）

7

1.3

2 PSQ認証制度設立の背景と経緯

8

2.1

パッケージソフトウェア品質の現状

82.2

PSQ認証制度設立に至った背景と経過

8

2.2.1 CSAJがPSQ認証制度策定に向け活動を開始するまで

8

2.2.2 JISX25051を選定するまで

9

2.2.3 制度に対する要望をヒアリング

92.2.4 活動経過10

ソフトウェア品質監査制度（仮称）11

2.3.1 ソフトウェア品質監査制度（仮称）の枠組み

11

2.3

3 パッケージソフトウェア認証制度の枠組み

12

3.1

認証と各種文書との関連について

12

3.2

認定機関／認証機関の関係図

13

iii

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4 本書の編纂目的

14

Chapter 2 パッケージソフトウェア品質認証取得手続き
1 認証制度の対象

15
16

1.1

認証制度の申請者

16

1.2

認証制度の対象ソフトのカテゴリと範囲

16

1.3

認証制度はどのように品質を認証するか

17

2 認証の流れと提出書類
2.1

2.2

18

認証フロー図182.1.1 仮申請フロー

18

2.1.2 本申請フロー

19

2.1.3 最終審査フロー

20

提出書類

20

3 認証の更新と変更
3.1

21

認証の更新

21

3.1.1 認証の有効期限

21

3.1.2 有効なバージョン

21

3.1.3 提供事業者の変更

21

3.2

更新申請の方法

21

3.3

更新フロー図22

3.4

サポート終了時

22

3.5

認証取り消し22

Chapter 3 申請者用の手引き＜審査基準＞

23

1 製品説明（製品カタログなど）の審査基準

24

1.1

製品説明とは24

1.2

製品説明の審査基準の概要

26

1.3

製品説明の文書としての審査基準

27

1.3.1 製品説明の可用性

27

1.3.2 製品説明の記載内容

27

1.3.3 製品説明の識別情報および表示方法

28

製品説明の記載内容に対する審査基準

31

1.4.1 機能性

31

1.4.2 信頼性

34

1.4.3 使用性35

1.4.4 効率性

39

1.4.5 保守性

40

1.4.6 移植性に関する審査基準

42

1.4.7 利用時の品質

44

1.4

2 利用者用文書（ユーザマニュアルなど）の審査基準

iv

46

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.1

利用者用文書とは何か

46

2.2

利用者用文書の審査基準の概要

47

2.3

利用者用文書に記載する内容および附帯物

48

2.3.1 利用者用文書に記載する内容

48

2.3.2 利用者用文書の附帯物

50

利用者用文書の審査基準の詳細解説

50

2.4.1 完全性

50

2.4.2 正確性

52

2.4.3 一貫性

52

2.4.4 理解性

53

2.4.5 習得性

53

2.4.6 運用操作性

54

3 試験文書の審査基準

55

2.4

3.1

3.2

3.3

3.4

3.5

試験文書の概要

55

3.1.1 審査における試験文書の位置付け

55

3.1.2 試験文書を構成する３種類の文書概要

56

試験文書全体の概要と審査基準

58

3.2.1 試験文書の目的

58

3.2.2 試験文書の一貫性

58

3.2.3 試験文書全体に共通する文書管理用の項目

59

試験計画に対する審査基準

60

3.3.1 試験計画に含まれる内容

60

3.3.2 パッケージソフトウェアの試験における合否判定基準

63

3.3.3 試験を実施するための環境

63

3.3.4 試験活動の管理項目

64

試験説明に対する審査基準

65

3.4.1 試験項目

65

3.4.2 試験手順

67

3.4.3 再試験

68

試験結果に対する審査基準

69

3.5.1 試験実施報告

69

3.5.2 不具合報告

70

3.5.3 再試験

72

3.5.4 試験結果の総合評価

73

4 ソフトウェア品質に関する具体例
4.1

4.2

74

ソフトウェアの品質

74

4.1.1 ソフトウェアの品質特性について

74

4.1.2 審査におけるソフトウェア品質の位置付け

74

ソフトウェア品質の例

75

4.2.1 ソフトウェアの機能性の例

754.2.2 ソフトウェアの信頼性の例

76

4.2.3 ソフトウェアの使用性の例

77v

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4.2.4 ソフトウェアの効率性の例

79

4.2.5 ソフトウェアの保守性の例

80

4.2.6 ソフトウェアの移植性の例

80

4.2.7 ソフトウェアの利用時の品質の例

81

Chapter 4 用語解説

83

1 ソフトウェア品質特性

84

1.1

ソフトウェア品質特性とは

84

1.2

内部品質と外部品質

86

1.3

ソフトウェア品質特性の階層構造

87

1.4

機能性の品質副特性

881.5

信頼性の品質副特性

891.6

使用性の品質副特性

901.7

効率性の品質副特性

91

1.8

保守性の品質副特性

921.9

移植性の品質副特性

95

1.10

利用時の品質と利用時の品質の特性

94

2 用語説明96

vi

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1 パッケージソフトウェア品質認証制度とは

1パッケージソフトウェア
品質認証制度発足にあたって1

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1

パッケージソフトウェア品質認証制度概要
ここではパッケージソフトウェア品質認証制度の概要および関係する規格について説明します。

1.1 パッケージソフトウェア品質認証制度とはパッケージソフトウェア品質認証制度（略称：PSQ認証制度

以下PSQ認証制度と記載）とは、パッケー

ジソフトウェア製品の品質について第三者機関が認証を行う制度です。これはソフトウェア製品の品質要求に関するJIS標準JISX25051（ISO/IEC25051）「ソフトウェア製品の品質要求および評価－商用既製（COTS）ソフトウェア製品に対する品質要求事項及び試験に対する指示」を基に制度化されています。

第三者が検証・妥当性確認を行う意義
従来ソフトウェア製品では製造者（供給者）側に品質責任者がいました。同じ組織内に製造部門と品質管理部門があり、これらが一体となり品質を保証してきました。そのために利用者はその製造者もしくは提供企業に対する信頼感の強さから、安心して製品を購入することができました。
しかし、アメリカをはじめ諸外国では、自社の製品を自社で「大丈夫」と保証するだけでは十分な信頼が得られない場合があります。例えば会計監査で考えてみましょう。会計監査制度が存在するのは社内の会計処理だけでは妥当性・公平性・信頼性が保てず、ひいては投資家の利益を守れないからです。会計監査制度があることにより、投資家が安心してその会社に投資が行え、金融機関や顧客も安心して取引できるようになります。
ソフトウェア製品の信頼性についてはどうでしょうか。ソフトウェア製品の製造者が製品の品質や性能に関する情報を提供していたとしても、現実には購入者がそれらを詳細にわたり検証し、評価することは困難です。まして個人レベルでは専門知識も乏しく、費用の面でも時間の面でも不可能です。
そこで製造者でもなく、購入者でもない、第三者が検証・妥当性確認を行う必要性があるのです。
なおIPAが検討しているソフトウェア品質監査制度（仮称）の中間報告でも「利用者から中身の見えないソフトウェアの安全性・信頼性に関わる品質について、専門的知見に基づき、第三者の立場で「開発事業者」の技術ドキュメントや開発エビデンスを評価し、技術の専門知識がない「利用者」に理解できる形で提供すること」と示されています。ソフトウェアの品質は第三者が評価すべきという趣旨
で共通の認識を示しています。

2

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.2 PSQ認証制度の目的と効果
1.2.1 ソフトウェア製品の品質認証制度の必要性
日本工業規格JISX25051（ISO／IEC25051）「ソフトウェア製品の品質要求及び評価－商用既製（COTS）
ソフトウェア製品に対する品質要求事項及び試験に対する指示」の序文に、ソフトウェア製品の情報提供に関する説明があるので引用します。
幅広い様々な業務分野で、商用既製(COTS)ソフトウェア製品の使用が増加している。そのため多くの場合、商用既製ソフト
ウェア製品の正しい運用操作が、ビジネス用途・安全性用途及び個人用途にとって極めて重要となる。COTSソフトウェア製品は、その製品の特質及びその他の品質に何の影響も及ぼさない取得者に対して既製品として販売されている。典型的にはソフトウェアは、利用者用文書と一緒に梱包されて販売される。外装表示に提供されている情報は、製造者又はマーケティ
ング組織が、取得者及び利用者に情報を伝えることができる唯一の手段であることが多い。それゆえ、そのCOTSソフトウェア
製品の品質が取得者のニーズに合っていることを評価できるように、絶対必要な情報を取得者に提供することが重要である。

ソフトウェア製品の利用者が購入前に得られる情報は、製造者または販売者が提供するカタログや外装表
示、あるいはWebサイトに掲載された情報や広告に限られています。それゆえ、製造者は利用者に対して品質を含め重要な情報を適切に提供する必要があると当該規格は指摘しています。言い換えれば、利用者が自身のニーズに合う高品質なソフトウェア製品を選択できるよう、適切な情報提供がなされることが重要だと説いています。
その解決策、つまり信頼ある情報を提供する方法として、「第三者評価または第三者認証」を提案しています。ソフトウェア製品の利用者の中にはビジネスや安全性における重大なリスクに対する保証を必要としている人もいます。実際に利用者がソフトウェア製品購入後に何らかのリスクに直面することもあるかもしれません。こうした利用者が直面するリスクなどを踏まえ、当該規格ではソフトウェア製品に対して最低限の安全性またはビジネス上の重要な品質要求事項に関して（特定するまでの意図はないまでも）参考となる手引きを提供しています。
視点を変えれば、このように国が商用ソフトウェア製品のJIS基準を定めた意義は大きいと言えます。現状
ではソフトウェアに関して品質や安心を保証するための認証制度はまだ存在していません。そこで(一社)コンピュータソフトウェア協会(CSAJ)は国内外の企業や個人が安心して利用できるように、またそれだけではなく世界に通用するソフトウェア製品の開発･販売のためにも、JISX25051の認知に努め、その認証制度を運用し普及させることが必要だと考えています。

1.2.2 PSQ認証制度のもたらす効果
PSQ認証制度が目指すものと、それによりもたらされる効果は上記以外にも下記のようなものも見込まれています。
 パッケージソフトウェア製品に関する利用者や市場への品質説明力強化

技術知識の不足した利用者にもわかりやすいように、製品の品質についての認証を第三者機関が行うことで利用者が製品を安心して購買できるようにする。
 効果⇒利用者の安心感の向上

3

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 国際市場における日本製品の品質に関する正当な評価の確立

第三者による正当な製品評価制度を確立することにより、国際市場における競争力の維持・強化を図ります。特に新成長分野や国際社会での利用と購入が増加し、国際優位性の確保につながると期待できます。
 効果⇒国際競争力の維持・強化
 効果⇒国際優位性の確保
 利用者の潜在的なリスク低減

ソフトウェア製品は日々高度化しています。これらソフトウェア製品が品質要求事項（機能性、信頼性、使用性、効率性、保守性、移植性、利用時の品質）を満たしていることを品質認証制度が提供できれば、利用者のリスクを低減することが可能となり、ひいては利用者の利益につながります。
 効果⇒利用者の快適性・利便性の向上
 ソフトウェア製品の本質的な品質向上

第三者がソフトウェア製品の妥当性を検証することで、本質的な品質向上が図れます。これにより利用者
および国民生活の安全性の確保を図れると期待できます。
 効果⇒利用者生活の安全性の確保（参考文献：『ソフトウェアの品質説明力強化のための制度フレームワークに関する提案（中間報告案）』,独
立行政法人情報処理推進機構技術本部 ソフトウェア・エンジニアリング・センター, 2011 年
http://sec.ipa.go.jp/reports/20110930.html）

1.3 PSQ認証制度と関係する規格
PSQ認証制度は日本工業規格JISX25051「ソフトウェア製品の品質要求及び評価－商用既製（COTS）
ソフトウェア製品に対する品質要求事項及び試験に対する指示」を基に、技術的内容を変更することなく策定しました。このJISX25051はソフトウェア製品の品質要求・評価に関して定めた国際標準規格
ISO/IEC25051を元に作成された国内規格です。ここでJISX25051と関係のある規格を紹介します。

1.3.1 ISO/IEC25000（SQuaRE）シリーズ
ISO/IEC25051を包含するものとしてISO/IEC25000（SQuaRE）シリーズがあります。
従来ソフトウェア製品の評価では、ISO/IEC9126シリーズおよびISO/IEC14598シリーズが広く認知されていましたが、2000年５月のプレナリ会議でISO/IEC25000（SQuaRE）シリーズとして再編され、承認が行われました。現在はこのISO/IEC25000（SQuaRE）シリーズがソフトウェア製品の評価に用いられています。

 ISO/IEC25000（SQuaRE）シリーズでは対象を「商用既製（COTS）ソフトウェア製品」と規定していますが、いわゆるパッケージソフトウェア製品と解釈することに問題はありません。

ISO/IEC25000（SQuaRE）シリーズではパッケージソフトウェア製品に対して以下の事項が規定され
ています。
 ①

製品説明に対する要求事項

 ②

利用者用文書に対する要求事項

 ③

ソフトウェアに対する品質要求事項

 ④

試験文書への要求事項

 ⑤

適合性評価のための指示

4

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

また骨子は以下の3点です。
 ①

製品説明、利用者用文書に記述されている内容とソフトウェア機能が一致していること。

 ②

ソフトウェアの機能、性能が試験文書で証明されること。

 ③

第三者が適合性評価をする場合の手順。

1.3.2 JISX0129
JISX25051と関係がある規格にはJISX0129（ISO/IEC9126）があります。この規格における品質要求事項は下図の品質特性モデルのそれぞれについて最低限備えるべき要求条件を規定しています。これに対し、JISX25051はより具体的な要求と指示を示しています。

<品質特性モデル>

5

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.4 PSQ認証制度の対象となるソフトウェア
PSQ認証制度の対象範囲はJISX25051「ソフトウェア製品の品質要求及び評価－商用既製（COTS）ソフトウェア製品に対する品質要求事項及び試験に対する指示」の適用範囲（後述）に準じると考えていま
すが、当面は単独の製品としてパッケージ化されているソフトウェア製品に限定して運用を行います（組込み系のソフトウェアに関しては、適用範囲が難しく今後の検討事項とします）。
またJISX25051では「商用既製（COTS）ソフトウェア製品が提案され、納入されたとおりに機能するという信頼を利用者に与えること」のみを扱っていますので、本制度は供給者の開発プロセスに関しては審査対象としません。

 JISX25051にある「商用既製（COTS）ソフトウェア製品」について、当協会ではいわゆるパッケージソフトウェア製品と解釈しています。

以下、参考情報です。JISX25051における「ソフトウェア製品に対する品質要求事項および試験に対する指示」の適用範囲は、以下の通りです。
 JISX25051 「1.適用範囲」より引用

テキストプロセッサ，表計算，データベース管理ソフトウェア，グラフィックスパッケージ，技術用，科学用又は実時間組込み機
能用のソフトウェア（例えば，実時間オペレーティングシステム又は航空機用・通信用ローカルエリアネットワーク），現金自動支払機，両替機，人材管理ソフトウェア，販売管理，及びウェブサイト・ウェブページを生成するウェブソフトウェア

 JISX25051 「附属書B 「ビジネス又は安全性に関して重大な業務に適用する場合の手引き」

より引用‐一部省略
適用範囲として、航空用途、医療用途、薬及び調剤、宇宙及び探査、電気通信建設、エレベータ、鉄道、防衛システム等１件の障害でも重大な影響を及ぼすシステムに関しては特定用途向け集積回路（ＡＳＩＣ）、電子プログラマブル理論装置（EPLD）などのハードウェアに実装されてもよいとされている。重大な業務に関する製品の適用評価する場合、両方を考慮することが望ましいとされている。

6

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.5 国際規格委員会との連携
JISX25051（ISO／IEC25051）が策定された2006年当時、ソフトウェア製品の販売者はシステム媒体と取扱説明書を同梱して提供するのが一般的でした。そのため本規格では昨今普及したインターネットを介したWEBサービス、ASP、SaaS、IaaSはまだ想定していません。現在、国際標準規格委員会（JTC1）において改訂の検討が行われているところです。日本からは日本工業調査会（JISC）が窓口になり、実際は情報処理学会の情報規格調査会のメンバが参加しています。
国内のJTC1への対応組織は、情報処理学会のWebサイトに記載された組織図をご覧ください※。
当認証制度委員会も委員を派遣し、その改訂に積極的に関わりを持っています。現在検討が行われている
改訂の主眼は製品品質(Product Quality)の追加・変更に伴うものと、利用時品質(Quality in Use)の変更に伴うものとなっているものの、提供、利用形態に合わせた改訂も行われると想定しています。なお規格の原則に大きく手を加えることはないでしょう。
※一般社団法人

情報処理学会

情報規格調査会「JTC1概要」

http://www.itscj.ipsj.or.jp/outlineJTC1_100406.pdf

1.5.1 国際標準規格委員会（JTC1）
JTC1はISOとIECが情報技術（IT)分野の標準化を推進することを目的として、1987年に合同で設立しました。メンバはプライマリーメンバが43カ国、オブザーバーメンバが45カ国（※あるいは「世界98カ国」にまとめる）、外部リエゾンにはECMA、ITU、ECがあります。傘下には18のSubcommittee（SC）と2つのWGがあります。詳細は情報処理学会のWebサイトに記載された「JTC1概要」中の第2図「JTC1の組織」をご覧ください※※一般社団法人 情報処理学会 情報規格調査会 「JTC1概要」
http://www.itscj.ipsj.or.jp/outlineJTC1_100406.pdf

7Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2 PSQ認証制度設立の背景と経緯
ここではPSQ認証制度設立に至る背景と経緯を説明します。

2.1 パッケージソフトウェア品質の現状
日本国内のパッケージソフトウェア製品は、作り手側の品質への意識が高いこともあり、高品質であることが多いです。この背景には「品質が悪ければ売れない」という市場の事情もありますが、顧客の信頼に応えるため、ひいては会社の信用を落とさないためといった前向きな取り組み姿勢もまた品質の維持に寄与していると言えるでしょう。機能性の面においても、特定の業界や業務ごとにアプリケーションを提供しているケースが多く、特定用途向けに特化し十分な機能を提供しています。

2.2 PSQ認証制度設立に至った背景と経過
2.2.1 CSAJがPSQ認証制度策定に向け活動を開始するまで日本製品の品質の良さは国内外ともに評価が高く、世界中で販売されています。しかし2009年、アメリカで発生した事故から、日本の大手自動車メーカーのブレーキ制御系ブログラムが問題視される事態にまで発展しました。この事件のように、最終的には「安全で問題が無い」と判定されたものの、第三者機関の「お墨付き」がなかったばかりに、原因究明と品質証明に多くの時間と費用がかかるというリスクが顕在化しました。
これまで日本では「高品質は当たり前」という共通認識のもと、必死に良い製品を作り出すことに注力してきましたが、それだけでは不十分となってきました。グローバル化が進む昨今では「見える化」が重視され、どの品質基準に従い、どのように製品化し、誰が品質を確認したのか説明するように求められています。またビジネスの競争力強化の観点からも、規格に準じた標準化、品質の見える化、品質説明力強化が必須となってきています。
近年国内ではすでにいくつかの業界で品質認証制度が運用を開始しています。例えば食品なら「特保マーク」、自転車なら「BAAマーク」などです。また2011年度からは国土交通省が優良な中古住宅販売業者を対象にした認証制度も導入されました。ソフトウェア業界も世界に向け、ISO／IEC基準に則った「安心・安全・高品質」を証明するための認証制度を設立し、それぞれの品質を客観的に利用者に提示できるようにする必要があります。
こうした社会的要求に応じるため、(一社)コンピュータソフトウェア協会(CSAJ)は2009年から本制度の実現に向けて活動を開始しました。

8

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.2.2 JISX25051を選定するまで
当初は経済産業省の非機能要求グレード評価委員会が作成した「実証報告書」及びソフトウェアメトリク
ス高度化プロジェクトの「システム及びソフトウェアの品質の見える化、確保及び向上のためのガイド」と付録「定量的マネジメントのための公開データ利用ガイド」などをベースに品質基準を検討しました。
これらは品質基準を検討する上で大いに役立ちましたが、大型の個別開発案件（スクラッチ開発案件）の品
質に重点がおかれており、パッケージソフトウェア製品の品質評価とは視点が異なることが判明しました。
その後、ISO/IEC25000（SQuaRE）シリーズのソフトウェア品質評価技術標準化に関する調査研究委
員会／ソフトウェア製品の品質評価委員会幹事である日本電気株式会社の込山俊博氏に講演とオブザーバ
ー参加を呼びかけ、協力を得ながらさまざまな検討を重ねてきました。その中で25000シリーズの拡張部
門 と な る 25051 の 日 本 語 版 リ リ ー ス の 情 報 を 入 手 し 、 内 容 を 精 査 し た 結 果 、 JISX25051（ISO/IEC25051

2006翻訳版）を本制度の基準規格と定めることにしました。また、その後発足した

IPAのソフトウェア品質監査制度（仮称）との連携についても検討し、その制度のフレームワークに準拠する制度として検討を進めています。

2.2.3 制度に対する要望をヒアリング
PSQ認証制度を設計する段階で、関係機関や検討会議に参加した企業からの要望をヒアリングしました。
またIPAソフトウェア監査制度検討委員会の資料を検討し、その対応方針もまとめました。その結果および対応方針用紙を下記に記載します 購入者・消費者から

 製品やサービス内容がカタログや WEB 情報で開示され、専門家でなくても理解できること
 障害に対して適切な対応がされること
 製品のクレームに関して情報が公開されること⇒対応方針

認証マークを付与する
障害情報の公開と対応方法を公開させること
クレーム情報はその内容を精査し、認証の取消や情報公開を行う

 業界からの要望

 認証制度としてコストバランスが取れること
 製品の機密性が保てること
 国内だけでなく国際的にも認知される制度であること
 取得メリットが明らかであること⇒対応方針

書類審査による認証制度とし、申請者の負担を可能な限り軽微に抑える
適合性認証機関として日本工業標準調査会（ＪＩＳＣ）の制定した規格及びガイドとその作業プログラムに準拠した運用を行う（製品認証機関に対する一般要求事項JISQ0065（ISO/IEC Guide 65））
将来的にIPAのソフトウェア品質監査制度（仮称）と連携する認証取得メリットを開示（下のコラム参照）

9

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 申請者の負担を可能な限り軽微に抑えるという方向性は特に重視しています

パッケージソフトウェア提供側が得られる認証取得メリット
本制度は利用者だけではなく、パッケージソフトウェア提供側にもメリットがあります。パッケージ
ソフトウェアの品質を可視化することで、下記のように製品やサービスの差別化、ブランド力、付加価値を強化し、競争力を強化することが期待できます。
1.購入者が製品を安心して選択できる基準
2.開発時の品質基準となり、無駄なテスト工数が削減できる
3.販売代理店に対し、品質基準を明確にできる
4.損害賠償時に品質基準を示せる
5.OEM供給時の品質基準を示せる
6.保険料の割引対象となる
7.企業・公官庁の入札時の品質基準を示せる
8.国際市場で品質基準を示せる

2.2.4 活動経過
これまでの活動経過を以下に記述しました。2010年度は延べ7回の研究会を開催し、認証基準の策定と制度設計を行いました。2011年度からは組織を研究会から委員会へと変更し、より具体的な制度策定へと活動を進めてきました。
2009年10月

パッケージソフトウェアの品質評価の必要性が提案され、検討を開始

2010年4月

CSAJのソフトウェア技術委員会内に「パッケージソフトウェア品質基準(PSQ)
研究部会」が発足

2010年6月

韓国における「ＧＯＯＤ

ＳＯＦＴＷＡＲＥ」ＧＳ認証を参考制度として研究を開始
2011年1月20日

ソフトウェア製品のパッケージソフトウェアの品質要求事項・試験・検証方法について標準化が行われ、開発および使用の合理化、品質の向上を目的としたJIS
規格が制定

2011年2月18日

JISX25051（ISO/IEC25051

韓 国 TTA(Telecommunications

2006翻訳版）

Technology

Association)

SoftwareQuality Evaluation CenterよりDr. Shin Seok-Kyoo(Director General)を招
聘して韓国のソフトウェア品質への取組-GS認証制度-」の講演会をCSAJで開催
2011年4月

ＪＩＳX25051を基準と決定。内容の解読、コンメンタール作業を行う。

2011年9月

制度設計の概要作成
ISO/IEC

25000シリーズの改訂に伴い、情報処理学会 情報規格調査会JTC1

SC7/WG6へ委員が参加
2011年10月

ＩＰＡソフトウェア品質監査制度委員会参加

実証評価ＷＧに参加し本制度との整合性を確認しながら活動

10

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.3 ソフトウェア品質監査制度（仮称）PSQ認証制度とは別に、IPAが検討しているソフトウェア品質監査制度（仮称）があります。PSQ認証制
度と共通の趣旨を持つことから、PSQ認証制度の委員がWGに参加するなどして、制度間の整合性を確認しながら活動しています。

2.3.1 ソフトウェア品質監査制度（仮称）の枠組み
ソフトウェア品質監査制度（仮称）では、制度に「公認審査員（監査人）」を導入する予定です。また審査
基準策定機関は業界単位に設定する計画です。

<ソフトウェア品質監査制度（仮称）の枠組み案>

出典：独立行政法人情報処理推進機構

技術本部 ソフトウェア・エンジニアリング・センター,「ソフトウェアの品質説明力強化のための制度フレームワークに関する提案（中間報告案）」
http://sec.ipa.go.jp/reports/20110930.html

11

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3 パッケージソフトウェア認証制度の枠組み
ここではPSQ認証制度のおおまかな枠組みを説明します。

3.1 認証と各種文書との関連について
PSQ認証制度では、「製品説明（カタログなど）と利用者文書（マニュアルなど）とソフトウェアの機能が一致していることを確認できること」が要件となります。品質ライフサイクルの観点では企画から廃棄までの範囲で品質を考えることもありますが、本制度では組織能力や管理プロセスは審査対象ではありません。
本制度の概念図を以下に示します。

〈パッケージソフトウェア品質認証制度と各種文書の関係図〉

12

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.2 認定機関／認証機関の関係図
本制度の認証機関および認定機関の関連性をあらわした概要図を下に示します。
IPAのソフトウェア品質監査制度と本制度との大きな差は体制の違いです。

<パッケージソフトウェア品質認証制度の枠組み認定機関／認証機関の関係図>

13

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4 本書の編纂目的
本書はソフトウェア製品の企画・開発および品質管理に携わる技術者および経営者を読者として編纂しています。これまでの日本のパッケージソフトウェアベンダーは、独自の品質基準を設定し、独自の方法で品質を担保してきました。こうした社内での品質管理には、製品の発売前に社外に情報が漏洩したり、その技術が流出したりするのを防止する目的がありました。
「それが当然」と誰もが考え、異論を唱える技術者はいませんでした。
しかし、国際基準では早くから品質に関する要求事項を整理し、第三者機関による適合性評価を定めて規格化しています。昨今のソフトウェア製品は機能が増加し、プログラムソースの肥大化はますます進んでいます。こうしたソフトウェア製品の品質を維持することはベンダーの宿命であり喫緊の課題となっています。それならば、国際基準に準拠した開発プロセスで開発を行い、品質要求事項に準拠した試験を実施
し、第三者による適合性評価を取得しておくべきと言えるでしょう。
今後、利用者の立場がますます強くなり、提供者の責任は重くなります。万が一、重大な過失と指摘される事態が発生しても、しっかりとした規格に基づく開発や試験を行っていたと証明できれば、第三者からの評価もおのずと適正なものとなります。結果として商品コストの削減、信頼性の向上にもつながると確信しています。
本来工業規格書を入手して、その内容を熟読すればいいことですが、残念ながらこのような文書は六法全書のように専門家でなければ解読が困難です。そこでパッケージソフトウェア品質基準委員会（奥付参照）
では開発技術者および経営者が容易に理解できる実務書として本書を作成しました。コンメンタール形式
で実務に即戦力となるよう工夫を重ね、現場の手引書として活用していただけることを目指しました。

14

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2 パッケージソフトウェア品質認証取得
手続き

2

パッケージソフトウェア
品質認証取得手続き

15

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1 認証制度の対象
ここでは「パッケージソフトウェア品質認証制度（略称：PSQ認証）」を申請するにあたり、事前準備や申請手順について概要を説明します。

1.1 PSQ認証制度の申請者
本認証制度に申請できるのは、特定または不特定の利用者にパッケージソフトウェアを提供する事業者です。

1.2 PSQ認証制度の対象ソフトのカテゴリと範囲
本認証制度では以下のソフトウェアカテゴリを対象としています。なお、すでに提供を開始しているものに限ります。
 ソフトウェアのカテゴリ

企業向け業務パッケージソフトウェア
例：テキストプロセッサ、表計算、データベース管理ソフトウェア、グラフィックスパッケージ、人材管
理ソフトウェア、販売管理、Webページを生成するソフトウェア
 製品の範囲

ソフトウェア製品を構成するソフトウェアモジュール一式です。
提供形態、規模は問いません。他ソフトウェア（オープンソースソフトウェアも含みます）製品を組み込んでいる製品も対象とします。またSaaSなどサービスとして提供するものも対象とします。

 サブシステムについてパッケージソフトウェアが機能するために必要な、当該事業者以外が開発している、モジュールやミドルウェア、データベースシステムなどをバンドルしている場合、当該パッケージソフトウェアが機能する上で必要となる範囲において、要求事項に適合しているか、また、十分な試験を行われているかを審査します。

16

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.3 PSQ認証制度はどのように品質を認証するか
本認証制度はJISX25051（ISO/IEC 25051）に基づき規定されています。
本認証制度では認証対象ソフトウェアの製品品質を「製品説明※１参照」、「利用者用文書※2」、「製品機能」が要求事項に適合し、一致しているかで評価します。また製品機能の品質については、
「試験文書

※

３」を適正に作成し、試験を実施しているかで評価します。

 ※1 製品カタログなど：「Chapter3 申請者用の手引き ＜製品説明の審査基準＞」参照
 ※2 ユーザマニュアルなど：「Chapter3 申請者用の手引き ＜利用者用文書の審査基準＞」参照
 ※3 ソフトウェア機能を示す試験文書「Chapter3 申請者用の手引き ＜試験文書の審査基準＞」参照<製品説明・利用者用文書・製品機能・試験文書の関係>

17

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2 認証の流れと提出書類
ここでは認証の申請から取得までの流れを説明します。それぞれの段階で必要な提出書類、関連する規程などについても説明します。

2.1 認証フロー図
認証の流れを以下に記します。

2.1.1 仮申請フロー
仮申請の流れを以下に記します。仮申請を行う際、必要書類を提出していただき、審査費用の見積を行います。

<仮申請フロー>18

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.1.2 本申請フロー
本申請の流れを以下に記します。正式申請受理後、外部試験機関にて審査作業を行います。必要に応じて、現地審査を実施します。

<本申請フロー>19

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.1.3 最終審査フロー
最終審査の流れを以下に記します。外部試験機関の審査結果をもとに、最終認証審査を行います。

<最終審査フロー> 審査基準の詳細については、「Chapter3 申請者用の手引き＜審査基準＞」にて紹介しています。

2.2 提出書類
申請時には以下の書類を提出する必要があります。
 パッケージソフトウェア（PSQ）品質認証（仮）申請書
 秘密保持契約書
 その他添付資料


製品説明（カタログなど）



利用者用文書（ユーザマニュアルなど）



試験文書

 パッケージソフトウェア（PSQ）品質認証申請書

20

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3 認証の更新と変更
ここではPSQ認証取得後に、更新を申請するときの流れを説明します。

3.1 認証の更新
3.1.1 認証の有効期限
本認証制度で取得した認証は、5年間（5年後の、認証取得月の月末まで）有効です。
認証期間を超える場合は更新申請が必要となります。

3.1.2 有効なバージョン
認証は取得時の製品バージョンでのみ有効です。以下の場合は更新申請が必要となります。
 製品名変更
 メジャーバージョンアップ

本認証制度では、メジャーバージョンが変更となる場合をメジャーバージョンアップとします。

Ver. ××．××．××
メジャー

マイナー

 製品名やバージョンなどが明示的に表示されない製品であっても、ソフトウェアの機能に利用者への告知が必要となるような大きな追加や変更などがあった場合でも更新申請が必要になります

3.1.3 提供事業者の変更
当該ソフトウェア製品の提供事業者が合併、分割もしくは相続などの理由により、変更があった場合には更新申請が必要になります。

3.2 更新申請の方法
認証の更新を申請する場合は、認証の有効期間満了日の 90 日前から 60 日前までに手続を行い、更新審査を受ける必要があります。
 上記の期間内に更新の申請をしたとき、認証の効力は、有効期間後も更新を決定するまでの間継続します。
 更新の審査は、新規申請時点から変更のあった項目を対象とします。

変更のあった項目については、新規申請時の記述内容と変更後の内容を併記してください。
 更新申請の際には「更新申請書」を提出する必要があります。

21

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.3 更新フロー図
更新時の流れを以下に記します。

<更新フロー>

3.4 サポート終了時
認証期間内に当該認証パッケージソフトのサポートを終了したときは、指定する様式により、遅滞なく届出を行ってください。その際には、認証証も同時に返納していただきます。届出にあたっては、費用はかかりません。

3.5 認証取り消し
認証パッケージソフトウェアを提供する事業者が、次のいずれかに該当する場合には、その認証を取り消すことがあります。
 審査基準に適合しなくなったと認められるとき
 不正な手段により認証を受けたことが明らかになったとき
 正当な理由なく、認証機関が求める調査に応じない場合、または当該調査に虚偽の説明又は資料の提出をしたとき
 正当な理由なく、改善の要請に従わないとき
 不法行為及び法令違反行為を行ったとき
 認証対象商品以外にマークなどを利用したとき
 認証パッケージソフトウェアを提供する事業者の倒産、合併、分割もしくは相続などにより、認証パッケージソ

フトウェアのサポートなどの維持継続に疑義が生じたとき

22

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3 申請者用の手引き＜審査基準＞

3
申請者用の手引き＜審査基準＞

23

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1 製品説明（製品カタログなど）の審査基準
本節では、パッケージソフトウェア品質認証制度(Package Software Quality Certification 以下、PSQ
認証制度と記載)を取得しようとするパッケージソフトウェア製品の製品説明（製品カタログなど）に関する審査基準について解説します（「製品説明」の詳細については本節1.1を参照）。

1.1 製品説明とは製品説明とは、当該製品の購入を考えている購入予定者や利用予定者に対して、当該製品の特徴、機能の概要、制約、使用する上での要求事項（ハードウェア環境、他に必要になるソフトウェアなど）を伝える文書の総称です。

 JISX25051では「購入予定者」のことを「潜在取得者」、「利用予定者」のことを「潜在利用者」と呼んでいます。取得者の定義に関してはChapter4の該当箇所を参照してください。

<製品説明と他の文書との相関関係>

製品説明は、購入予定者や利用予定者が製品の比較や選定をする際に参考とするため、製品の記述について利用者用文書や試験文書と整合がとれている必要があります。

24

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 製品説明に該当するもの

製品説明は購入予定者が製品購入前に当該製品が自分たちの用途に適しているか、購入に値するかどうかを判断するための資料です。以下のものが該当します。
 製品のカタログや製品の紹介資料。当該ソフトウェア製品のみを紹介する紙 1 枚程度のもの（リーフレット、フライヤーなどと呼ばれます）や、製品販売会社が取り扱う製品全体を紹介する冊子を含みます 製品外箱の説明文
 製品販売会社の Web サイトでの紹介文
 前述のカタログよりは詳細な製品紹介資料

PSQ認証の取得に必要な記述量はパッケージソフトウェア製品の特性や規模に応じて異なります。一般的な目安は以下の表のようになります。

機能が限定された製品やA4 1枚両面程度の記述量で、審査基準を満たすことができる

小規模な製品大規模で多機能な製品

A4 1枚両面程度の記述量では、審査基準を満たすことができない

 原文

4.5
製品説明（product description）
ソフトウェアの特徴を記述した文書。この文書の主な目的は，潜在取得者がソフトウェアを購入する前に，そのソフトウェアが自分たちに適しているかどうかを評価するのを支援することである。

25

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.2 製品説明の審査基準の概要
製品説明に要求される審査基準は、大きく次の2つに分類することができます。
 製品説明の文書としての審査基準（製品説明自体に適用されます）
 製品説明の記載内容に対する審査基準<製品説明に要求される2つの審査基準>

1.3 製品説明の

製品説明自体に求められる審査基準

文書としての審査基準
1.3.1 製品説明の可用性

製品説明の入手・参照のしやすさ、利用のしやすさ

1.3.2 製品説明の記載内容

当該製品が購入予定者や利用予定者に十分な品質を備えていることが伝わる内容であること

1.3.3 製品説明の識別情報および表示方法
1.4 製品説明の記載内容に対する審査基準

どの製品に対する説明なのか、製品に複数の版（バージョン）がある場合はどの版についての説明なのか、明確に識別できること
製品説明の記載事項詳細に求められる審査基準「購入予定者や利用予定者に対し、製品の品質を正確に伝えることを意識しているかどうか」が審査の基準となります。

1.4.1 製品の機能性製品が提供する機能そのものに関わる特性

1.4.2 製品の信頼性

故障の生じにくさ、故障や誤操作・誤入力への耐性など

1.4.3 製品の使用性

利用者にとっての使いやすさ（憶えやすさ、理解しやすさを含む）

1.4.4 製品の効率性

処理速度や応答時間（いわゆる性能）

1.4.5 製品の保守性

資源効率など故障の原因調査や修正箇所の特定のしやすさ

1.4.6 製品の移植性変更作業のしやすさ複数の環境・構成への適応のしやすさ、インストールのしやすさ

1.4.7 利用時の品質

利用者視点から見た品質

26

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.3 製品説明の文書としての審査基準
製品説明の文書としての審査基準には、次の3つが挙げられます。
 製品説明の可用性
 製品説明の記載内容
 識別情報および表示方法

これらの審査基準について以下に解説します。

1.3.1 製品説明の可用性
製品説明は、購入予定者や利用予定者が当該製品の購入を検討する際に参照する文書なので、入手および参照がしやすくなければなりません。
 審査基準 購入予定者や利用予定者が必要な時に入手・参照できること。
 紙媒体の場合、販売店で入手可能であること、あるいは販売会社から取り寄せができること。
 Web ページの場合、URL から参照可能であること。
 電子媒体の場合、Web の URL から参照可能か、ダウンロードが可能であること。
 電子媒体の場合、当該媒体を参照する手段が利用可能であるか（文書閲覧ソフトなど）、一般的な Web ブラ

ウザで参照可能であること。
 製品説明の利用に当たって、購入予定者や利用予定者が不便を強いられないこと。
 原文

5.1.1.1
製品説明は，製品の潜在取得者及び潜在利用者が使用可能でなければならない。

1.3.2 製品説明の記載内容
製品説明の記載内容は、以下のようであることが求められます。
 当該製品が自分の要望を満たすに足るものかどうか、購入予定者や利用予定者がその記載内容に基づいて評価できること
 当該製品が購入予定者や利用者にとって十分な品質を備えていることが伝わる内容であること（品質として取り上げられる事項については 1.4 以降で詳述します）

例えば、会社での使用に適したパッケージソフトウェア製品の購入を検討している購入予定者がいるとします。その会社ではコンピュータに不慣れな従業員がおり、購入予定者は彼らに対するトレーニングの手間をかけたくないと考えています。この場合、購入予定者は製品の機能もさることながら、初心者でも使いやすそうな製品を選定しようとするでしょう。この購入予定者の要望に応えるためには、製品説明において、その製品がどのような点で使用性（使いやすさ）に優れていると言えるのか、明瞭に書かれている
必要があります。

27

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

製品説明は購入予定者に真実を矛盾なく伝える必要があります。実際の製品の振舞いと異なること、矛盾することが書かれていてはいけません。また製品説明に記載してある内容は、評価版やデモ環境、導入後のテストなどで検証可能でなければなりません。ただし、必ずしも「定量的な評価が可能でなければならない」というわけではありません。PSQ認証制度では購入者や利用者が実際に利用した時に、製品説明の記載に相違ないかどうか判断できることが求められます。
 審査基準 特に強調したい品質について、購入予定者や利用予定者に伝わる形で明記されていること。また、購入予定

者や利用予定者が、自分の要望を満たすに足るものかどうか評価できる形で明記されていること（具体的には、本節 1.4 以降を参照してください）。
 評価版やデモ環境、あるいは製品導入後に、記載内容が事実であることを検証できること（検証の仕方は、テストによって結果を確認するのでもよいですし、製品説明のスクリーンショットやサンプル画像と照合するのでもかまいません）。
 事例

以下は、製品説明の記載内容の一例です。
事例1
当製品では、Windows標準のユーザインタフェースに準拠した操作性を提供しています。このため、Windowsパソコンを使っている人なら誰でも判りやすく、特別なトレーニングを必要とせずに使うことができます。
事例2
当製品は、最近のWebアプリケーションで一般的となっている以下の要素を各画面に配置しています。
・画面上部に、その画面までのページのリンク（ナビゲーションバー）・画面左部に、当製品の主要機能を直接呼び出せるメニュー（サイドバー）
これらナビゲーションバーやサイドバーを使うことにより、必要な時に必要な機能を呼び出したり、元の画面に戻ったりすることが容易にできるようになっています。

 原文

5.1.2.1 製品説明は，潜在取得者が自分たちのニーズにソフトウェアが適合していることを評価するために必要な情報を含んでいなければならない。
5.1.2.2 製品説明は，内容に矛盾があってはならない。
5.1.2.3 製品説明で記述されたことは，試験可能又は検証可能でなければならない。

1.3.3 製品説明の識別情報および表示方法
製品説明の識別情報および表示方法の各項目について解説します。

製品説明の識別

製品説明には、ほかの製品説明と区別できるよう、一意の識別子を明記しなければなりません。当該製品に複数の版（バージョン）がある場合はどの版についての説明なのかがわかるよう、対象となる製品の版、日付を記載します。

製品の識別

製品説明には、どの製品に対する説明なのかわかるように、以下を明記しなければなりません。
 製品の名称 当該製品の版（バージョン）、リリース日付

複数の版がある場合はどの版についてのなのか識別できるようにする

28

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

開発元や販売元の記載

製品説明には開発元と販売元の記載がなければなりません。
 製品の開発元の社名および住所（所在地住所またはWebのドメイン） 製品の販売元の社名および住所（所在地住所またはWebのドメイン）

販売元は、開発元と異なる場合にのみ必要となります。販売元を記載する場合、販売会社または販売代理店のうち、1社について記載されていれば十分です。
製品が提供するサービスの記載

製品説明には、当該パッケージソフトウェア製品が提供するサービスの記載がなくてはなりません。
 この製品を使用することで何ができるか どのような作業に役立つか

環境要件の記載

製品説明には、当該製品が稼働するために必要なハードウェア、ソフト
ウェアを記載しなければなりません。記載例として、以下の項目があります。
 ソフトウェア製品の名称、版
 オペレーティングシステムの名称、版
 ハードウェアの名称
 オペレーティングシステムの標準構成以外に必要となるソフトウェア（必要である理由も明記）
外部要件の記載

下記のような外部の要求事項に準拠することが必要となる場合、または準拠していることが製品の特徴となる場合、該当する外部要件を明示しなければなりません。
 法律上の要求に準拠
 国内規格、国際規格に準拠
 業界標準に準拠

動作条件の記載

複数利用者による使用の可否を含めた記載が求められます。
 複数の利用者が同一のソフトウェア製品を使用できるかどうか 使用できる場合、複数の利用者が同時並行で使用できるかどうか

複数利用者による使用が可能な場合は、以下の記載も必要となります。
 製品説明に記載している動作環境や性能の範囲内で、最大何人までの利用者が同時並行的に使用できるか
外部インタフェースの記載

外部ソフトウェアとの通信やデータ交換が可能な場合には、以下の記載が必要となります。
 データ交換で利用可能なデータ形式
 通信を行なう製品であれば、通信プロトコルを含めたインタフェース
 直接通信対象とする外部ソフトウェアが明らかであれば、そのソフト

ウェア名称
サポートや保守サービスの識別取得者や利用者が当該製品を運用する際に、開発元ないし販売元がサポートを提供できるかどうかを明記する必要があります。
保守サービスを提供する場合は概要を明記する必要があります29

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 審査基準

製品説明に先の表に挙げられている事項が記載されていれば、本項目を満たしていると判断されます。
 製品説明の識別ができる
 製品の識別情報が記載されている
 開発元や販売元が記載されている
 製品が提供するサービスが記載されている
 環境に関する要件が記載されている
 外部要件が記載されている
 動作条件が記載されている
 外部インタフェースが記載されている
 サポートや保守サービスに関する事項が記載されている

 原文

5.1.3.1
製品説明は，一意の識別子を表示しなければならない。
5.1.3.5
COTS ソフトウェア製品に適用する要求事項が法律又は規制機関によって定義されている場合で，かつ，供給者がこれらの該当する要求文書に適合していることを主張したい場合，製品説明は，これらの要求文書を明記しなければならない。
5.1.3.2 COTS ソフトウェア製品は，名称，版及び日付で指定できなければならない。
5.1.3.3 製品説明は，次を記載しなければならない。
a) 供給者の社名及び住所（郵便宛先又はWEB のアドレス）b) （該当する場合は）販売会社，電子商取引販売会社又は販売代理店の中の少なくとも1社の社名及び住所（郵便宛先又はWEB のアドレス）
5.1.3.4 製品説明は，そのソフトウェアによって実行可能な，意図した課業及びサービスを明確にしなければならない。
5.1.3.5 COTSソフトウェア製品に適用する要求事項が法律又は規制機関によって定義されている場合で，かつ，供給者がこれらの該当する要求文書に適合していることを主張したい場合，製品説明は，これらの要求文書を明記しなければならない。
5.1.3.6 製品説明は，COTS ソフトウェア製品が単一のシステム上でエンドユーザが複数同時並行使用できるかどうか，又は単一のシステム上で単一エンドユーザだけを対象としているかどうかを明示しなければならない。また，要求されたシス
テム上で，記述している性能のレベルで，最大何人のエンドユーザが同時使用できるかを記述しなければならない。
5.1.3.7 製品説明において，利用者が呼び出すことのできる，既知の他ソフトウェアへのインタフェースに言及する場合，
これらのインタフェース又はソフトウェアの身元を明らかにしなければならない。
5.1.3.8 製品説明は，そのCOTS ソフトウェア製品が，どのような点で特定ソフトウェア及び／又はハードウェアに依存するかを適切な参考情報と併せて指示しなければならない。
例 参考情報としては，次のようなものがある。
－ ソフトウェア及び／又はハードウェアの名称－ 版－ 特定のオペレーティングシステム
5.1.3.9 製品説明は，COTS ソフトウェア製品の運用操作に対して，サポート提供の有無を記述しなければならない。
5.1.3.10 製品説明は，保守サービスの提供の有無を記述しなければならない。保守サービスが提供される場合は，その保守サービスについて記述しなければならない。

30

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.4 製品説明の記載内容に対する審査基準
製品説明の記載内容に関しては、「1.2 製品説明の審査基準の概要」で示した6つの品質特性である機能性、信頼性、使用性、効率性、保守性、移植性、および利用時の品質という基準で審査します。以下、順に解説します。

1.4.1 機能性
製品説明では、その製品が実現・提供する機能について、購入予定者や利用予定者に必要な情報を示さなければなりません。機能に関する記載には以下のものがあります。詳しくは順次解説します。
 エンドユーザが呼び出すことのできる、製品機能の概要
 安全性、もしくはビジネスリスクに影響を及ぼしうる機能

ソフトウェア品質特性のうち「機能性」に該当する事項を記載する場合、ソフトウェア品質特性に準じた記載にする必要があります。この場合、次のことを考慮しなくてはなりません。（後述「品質特性の考慮」
を参照）
 機能性の品質副特性を考慮していること
 “検証可能な適合の証拠を示せる”という形で書かれていること

その他、特に記載しなければならない場合・事項には以下のものがあります。
 ソフトウェア製品や、ソフトウェア製品が作成・管理するデータに対する不正アクセスを防止する機能を備えている場合
 利用者に影響を与える制限事項がある場合
 ソフトウェア製品の構成要素に選択肢がある場合
 製品の機能の概要

製品説明には、エンドユーザがその製品で利用可能な機能の概要を記載しなければなりません。記述の詳細さについては特に基準を設けません。大規模・多機能な製品になるにつれて、機能の概要として記載する事項は大まかなものになることがあるでしょう。以下に記載例を挙げます。

製品の規模

記載例

小規模な製品本ソフトウェア製品では、電子メールの受信・転送・返信、新規メールの作（電子メールクライアントを例として）

成・送信ができます。
複数のアカウントを作成し、それぞれのアカウントでのメール受信、全アカ
ウントの一括受信も可能です。

大規模な製品

本製品では以下の機能がご利用になれます。

（オフィスソフトを例として）

・文書作成（ワードプロセッシング）
・表計算
・プレゼンテーション資料作成
・スケジュール管理（スケジュール情報の共有も可能）

 類似製品との差異を強調したい場合は、製品規模の大小を問わず詳細な記述をすることもあります。

31

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 品質特性の考慮

ソフトウェア品質特性の「機能性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形で記載する必要があります。記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません。
（各項目については「Chapter 4.1ソフトウェア品質特性」を参照してく
ださい）。
 合目的性 正確性
 相互運用性 セキュリティ
 機能性標準適合性

 こうした品質特性に関連する記載では、機能の単なる主張ではなく、「製品説明の記載通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

副特性の記載例：合目的性
副特性「合目的性」を例に記載内容を解説します。業務用のパッケージソフトウェア製品では、その製品が提供する機能ないしサービスが利用者の具体的な要望や目標を満たすことの明示が求められます。例えば、税務申告用パッケージソフトウェア製品が提供する各種機能は、税務申告業務を軽減
ないし自動化する、必要な書式を容易かつ確実に作成する、などといった利用者の具体的な目標を達成する上で適切なものでなければなりません。同時に製品説明でも、扱える法令書式の種類を明記するなど、利用者の要望する機能を提供できるかどうか、明確に述べる必要があります。

 安全性、もしくはビジネスリスクに影響のある機能

以下に挙げるような特定の分野や特定の業務で利用される可能性のあるパッケージソフトウェア製品の場
合、安全性やビジネスリスクに影響を及ぼしうる機能があれば、それについて言及する必要があります。
 航空および鉄道、自動車など輸送業務
 医療機器、薬の調剤
 電気通信 建築
 会計
 その他、社会基盤（インフラ）での利用、

例えば、会計ソフトでは、税率の計算や報告書に記載する数値など、数値の扱いの正確性はビジネスリス
クに影響があると言えます。また、建築分野では、構造計算を行なうソフトウェア製品などで、数値計算の正確性が安全性に影響を及ぼすと考えられます。このような場合は、想定される影響範囲を明記する必要があります。
 許可のないアクセスの防止

近年のソフトウェア製品は、製品自体や、製品が作成・管理するデータなどに対する不正なアクセスを防止する機能を備えることが多くなってきました（不正なアクセスとは、意図的か偶然かを問いません）。
パッケージソフトウェア製品でも同様の傾向にありますが、製品がこうした機能を備えている場合は、そのことを明記する必要があります（不正アクセスの防止は、機能性に含まれる副特性の「セキュリティ」
副特性に該当します）。

32

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 利用者に影響を与える制限事項

機能の実行やサービスの提供をする上で制限がある場合は、それらを全て記載する必要があります。
制限事項には以下のようなものがあります。
 入力データ（または取り扱えるデータ）の最大値、最小値
 検索に用いるキーの長さ
 レコード数の最大値
 検索条件数の最大値
 ソフトウェア構成要素の選択

当該製品の購入にあたって、構成要素のうち選択可能なものがある場合、あるいは構成要素のうち複数の版が存在する場合は、選択可能なものや版を明記しなければなりません。例えば、利用者がデータベースのソフトを選択できるようにしている場合、以下のような情報を明示する必要があります。
 利用可能なデータベースソフトの名称（製品名）
 適用可能な版（バージョン）
 審査基準

製品説明に本節で説明された事項が記載されていれば、本項目を満たしていると判断されます（該当しな
い事項についての記載はなくても問題ありません）。
 エンドユーザが呼び出すことができる製品機能の概要が記載されている。
 安全性、もしくはビジネスリスクに影響のある機能がある場合、それが記載されている。
 品質特性のうち「機能性」に該当する事項がある場合、各副特性も考慮して記載されている。
 許可のないアクセスを防止する機能を備えている場合、それが記載されている。
 利用者に影響を与える制限事項がある場合、それが明記されている。
 ソフトウェアを構成する要素が選択可能な場合、それが明記されている。

 原文

5.1.4.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，機能性に関する記述を含まなければならな
い。機能性という特性には，合目的性，正確性，相互運用性，セキュリティ及び機能性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
5.1.4.2 製品説明は，エンドユーザが呼び出すことのできる製品の機能の概要を記述しなければならない。
5.1.4.3 製品説明は，全ての重大な機能を記述しなければならない。
注記 詳細情報は，附属書B 及びJIS X 0134 を参照する。
5.1.4.4 ソフトウェア構成要素に選択肢及び版がある場合は，それらを記述しなければならない。
5.1.4.5 利用者に影響のある機能性に対する既知の制限事項は，全て記述しなければならない。
例 制限事項には，次のものがあってもよい。
製品説明は、そのソフトウェアによって実行可能な、意図した課行及びサービスを明確にしなければならない。
COTSソフトウェア製品に適用する要求事項が法律または規制機関によって規定されている場合で、かつ、供給者がこれらの該当する要求文書に適合していることを主張したい場合、製品説明は、これらの要求文書を明記しなければならい。
－ 最小値又は最大値－ キーの長さ－ ファイル中の最大レコード数－ 検索基準の最大数。
－ 標本の最小サイズ
5.1.4.6 ソフトウェアに対する許可のないアクセス（偶然のものも，意図的なものも）を防止する機能を備えている場合，製品説明は，この情報を含まなければならない。

33

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.4.2 信頼性
製品説明では、当該製品の信頼性について、購入予定者や利用予定者に必要な情報を示さなければなりません。信頼性に関する記載には以下のものがあります。詳しくは順次解説します。
 品質特性の考慮


信頼性の品質副特性を考慮していること。

“検証可能な適合の証拠を示せる”という形で書かれていること。

 エラー発生時の運用・操作の継続性
 データの退避と復元の手順

 当該品質を特徴として記載する場合は、製品を提供する側としても十分な検証が望まれます。購入者や利用者に対し具体的に示せない場合は、信頼性に関する記載は控えるのがよいでしょう。
 品質特性の考慮

ソフトウェア品質特性の「信頼性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形での記載が必要になります。
記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません（各項目については「Chapter4.1ソフトウェア品質特性」を参照してください）。
 成熟性
 障害許容性
 回復性
 信頼性標準適合性

 こうした品質特性に関連した記載をする場合は、「実際に製品説明の記載通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。
 エラー発生時の運用・操作の継続性

製品説明には、当該製品が以下のようなエラーが生じた場合に継続して運用・操作できるかどうかを記載しなければなりません。
 ユーザインタフェースエラー システム資源またはネットワーク資源に起因するエラー
 アプリケーション自体の不具合
 データの退避と復元

製品説明には、データの退避手順・復元手順に関する情報を記載しなければなりません。
退避や復元の手順の詳細は不要ですが、以下のようなことを記載する必要があります。
 エンドユーザが退避や復元を行なえるかどうか。
 退避や復元の実行のために必要なコンピュータ、または当該製品のアクセス権限
 退避の自動実行が可能かどうか。
 退避や復元のために必要な事項
ハードディスクの空き容量、外部記憶装置、ネットワークなど

 退避や復元にかかる時間（概算） データの退避をオペレーティングシステムの提供する機能を用いて実行してもよい場合はその旨の記述でかまい
ません。

34

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

副特性の記載例：信頼性
副特性「回復性」を例に記載内容を解説します。常時稼働することを前提としたパッケージソフトウ
ェア製品では、故障発生時の停止時間を最小に留め、かつ、データの復旧が確実にできることが求められる場合があり得ます。この場合、システム復旧にかかる時間（平均復旧時間）や復元可能なデー
タの種類などを具体的に示して回復性の記載とできます。

 審査基準

製品説明に本節で説明された事項が記載されていれば、本項目を満たしていると判断されます（該当しな
い事項についての記載はなくても問題ありません）。
 エラー発生時の運用・操作の継続性が記載されている。
 データの退避手順、復元手順が記載されている。
 品質特性のうち「信頼性」に該当する事項がある場合、各副特性を考慮して記載されている。
 原文

JIS-X-25051：5.1.5、信頼性に関する記述（5.1.5.1－5.1.5.3）
5.1.5.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，信頼性に関する記述を含まなければならない。信頼性という特性には，成熟性，障害許容性，回復性及び信頼性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
注記 開発者が運用中のデータ又は他の検証可能なデータで主張を具体化していない場合は，信頼性を主張する記述はしないことが望ましい。
5.1.5.2 製品説明は，ユーザインタフェースエラー，アプリケーション自体の論理エラー又はシステム資源若しくはネットワ
ーク資源の可用性によるエラーが発生したときに，ソフトウェアが継続して運用操作できるかどうか（すなわち，使用可能であること）について記述しなければならない。
5.1.5.3 製品説明は，データの退避手順及び復元手順に関する情報を含まなければならない。
注記 データのバックアップがオペレーティングシステムの機能によって実行されてもよいということを認める指示は，許容できる。

1.4.3 使用性
製品説明では、その製品の使用性について、購入予定者や利用予定者に必要な情報を示さなければなりません。使用性に関する記載には以下のものがあります。詳しくは順次解説します。
 ソフトウェア品質特性のうち「使用性」に該当する事項を記載する場合、ソフトウェア品質特性に準じた記載。

この場合、次のことを考慮する必要があります（後述「品質特性の考慮」を参照）。


使用性の品質副特性を考慮していること。

“検証可能な適合の証拠を示せる”という形で書かれていること。

 ユーザインタフェースの種別 アクセス容易性
 使用および運用操作に必要な知識
 利用者が当該製品の設定を変更したり、当該製品をカスタマイズしたりできる場合、そのためのツールまたは

手順のほか、ツールや手順を使用できる条件
 著作権の保護に関する記載

35

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 品質特性の考慮

ソフトウェア品質特性の「使用性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形での記載が必要になります。
記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません（各項目については「Chapter 4.1ソフトウェア品質特性」を参照してください）
。
 理解性
 習得性
 運用性
 魅力性
 使用性標準適合性

 こうした品質特性に関連した記載をする場合は、「実際に製品説明の記載通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

副特性の記載例：習得性
副特性「習得性」を例に記載内容を解説します。機能が豊富なソフトウェア製品ほど、機能の習得のための補助や、利用者が使っていて分からなかったり困ったりした時の参考情報が求められるかもしれません。その場合は、オンラインマニュアルやチュートリアルの存在、またそれらを容易に呼び出せることなどをもって習得性とできます。

 ユーザインタフェースの種別

製品説明には、その製品がどのようなユーザインタフェースを提供するか、その種別を記す必要があります。ユーザインタフェースにはさまざまなものがあり得ますが、以下のいずれかを記載すれば十分です。
 GUI／テキスト型／CLI の種別


GUI ……グラフィカルな表示で、ウィンドウ、メニュー、マウス操作、キーボードショートカットを用いるインタ
フェース



テキスト型 ……テキストベースの表示で、ウィンドウ、メニューなどを提供するインタフェース



CLI ……キャラクタ入力のコマンドを用いるインタフェース

 OS のユーザインタフェース標準への準拠度合
 Web ブラウザから閲覧、または Web 上のアプリケーションである場合は「Web ブラウザ」としてよい ヘルプ機能の有無（オンラインマニュアル、問合せ、チュートリアルなど）

 アクセス容易性

アクセス容易性を考慮した製品の場合、製品説明でもアクセス容易性について記載しなければなりません。
特に下記に該当する利用者への配慮が、購入予定者や利用予定者にわかるように記されていることが重要です。
 心身に障害のある利用者
 言語の異なる利用者

 上記は「ソフトウェア製品が心身に障害のある利用者や言語の異なる利用者にも使いやすいものでなければならない」と定めるものではありません。こうした利用者へのアクセス容易性を記載するということが重要です（そうした利用者にも使いやすい方が望ましいとは言えます）。

36

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 使用および運用操作に必要な知識

製品説明には、当該製品を使用したり運用・操作したりする上で必要な知識を明記する必要があります。
以下に例示します。特定の知識を必要としないのであれば、その旨を明記してください。
 使用するデータベースの知識（RDB の一般的な知識、SQL の知識など）
 プロトコルの知識（通信プロところなど）
 オペレーティングシステムの知識
 プログラミング言語やスクリプト言語の知識
 当該製品が前提としている技術分野の知識 当該製品が前提としている業務分野の知識

 設定の変更やカスタマイズ

利用者が当該製品の設定を変更したり、当該製品をカスタマイズしたりできる場合、製品説明に以下を記載しなければなりません。
 設定変更やカスタマイズのためのツール、または実行手順
 ツールや手順を使用できる条件

 著作権の保護

当該製品が著作権の侵害に対する技術的な保護を実装しており、それが使用性を損ねる場合は、製品説明にこの保護について記載する必要があります。以下のものが考えられます。
 事前に設定されている使用期限
 コピーに対する課金について、ダイアログボックスなどによる注意喚起
 使用する際のダイアログボックスなどによる承諾の確認
 審査基準

製品説明に本節で説明された事項の記載がある場合、本項目を満たしていると判断されます（該当しない
事項については記載しなくても問題ありません）。
 ユーザインタフェースの種別が記載されている。
 アクセス容易性を考慮した製品の場合、アクセス容易性について記載されている。
 使用および運用操作に必要な知識が明記されている。
 設定の変更やカスタマイズができる場合、その手順や使用するツールについて記載されている。
 著作権の保護が施されており、それが使用性を損ねる場合は、著作権保護に関する事項が記載されている。
 品質特性のうち「使用性」に該当する事項がある場合、各副特性を考慮して記載されている。

37

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文JIS-X-25051：5.1.6、使用性に関する記述（5.1.6.1－5.1.6.6）
5.1.6.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，使用性に関する記述を含まなければならない。使用性という特性には，理解性，習得性，運用操作性，魅力性及び使用性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
5.1.6.2 製品説明は，ユーザインタフェースの種別を明記しなければならない。
例 これらのインタフェースには，次のものがあってもよい。
－ コマンドライン－ メニュー－ ウィンドウ－ WEB ブラウザ－ ファンクションキー－ ヘルプ機能
5.1.6.3 製品説明は，ソフトウェアの使用及び運用操作に必要な特定の知識を明記しなければならない。
例 知識には，次のものがある。
－ 使用するデータベースの呼出しの知識及びプロトコルの知識－ 技術分野の知識－ オペレーティングシステムの知識－ 特別な訓練によって得られる知識－ 製品説明で使われている言語以外の言語知識
5.1.6.4 利用者がそのソフトウェアを適合させることができる場合，適合のためのツール又は手順及びこれらを使用するための条件を識別しなければならない。
例 条件には，次のものがある。
－ パラメタの変更－ 計算アルゴリズムの変更－ インタフェースのカスタマイズ－ ファンクションキーへの割当て
5.1.6.5 著作権侵害に対する技術的保護が使用性を損なう場合，この保護を記述しなければならない。
例 これらの保護には，次のものがあってもよい。
－ 事前に設定されている使用期限－ 複写に対する課金についての対話型の注意喚起
5.1.6.6 ソフトウェアは，アクセス容易性，特に障害のある利用者及び言語の違う利用者に対してのアクセス容易性を含まなければならない。

38

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.4.4 効率性
製品説明では、その製品の効率性について、購入予定者や利用予定者に必要な情報を示さなければなりま
せん。効率性に関する記述には以下のものがあります。詳しくは順次解説します。
 ソフトウェア品質特性のうち「効率性」に該当する事項を記載する場合、ソフトウェア品質特性を考慮した記載


効率性の品質副特性を考慮していること。

“検証可能な適合の証拠を示せる”という形で書かれていること。

 品質特性の考慮

ソフトウェア品質特性の「効率性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形での記載が必要になります。
記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません（各項目については「Chapter 4.1ソフトウェア品質特性」を参照してください）。
 時間効率性
 資源効率性
 効率性標準適合性

 こうした品質特性に関連した記述をする場合は、「実際に製品説明の記述通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

副特性の記載例：資源効率性
副特性「資源効率性」を例に記載内容を解説します。製品によっては、必要とする資源量が少ない（動作させるためのメモリやディスク容量が少ない）ことを特徴とする場合があり得ます。逆に、利用者の目標を達するために、あるいは快適に使えるために、できる限り最新のハードウェアを必要とする場合もありえます。こうした場合に、それぞれを具体的に明記することが求められます。記載事項には以下のものがあります。
 システムの構成
 効率的に動作するために必要な CPU やチップセットの最低条件
 効率的に動作するために必要なハードディスク容量、RAM 容量 効率的に動作するために必要なビデオカード、ネットワークインタフェース、外部バスなどの種類

 審査基準

製品説明に本節で説明された事項の記載がある場合、本項目を満たしていると判断されます（該当しない
事項については記載しなくても問題ありません）。
 品質特性のうち「効率性」に該当する事項がある場合、各副特性を考慮して記載されている。

39

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文JIS-X-25051：5.1.7、効率性に関する記述（5.1.7.1）
5.1.7.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，効率性に関する記述を含まなければならな
い。効率性という特性には，時間効率性，資源効率性及び効率性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
例 記述される条件には，次のものがあってもよい。
－ システムの構成－ COTS ソフトウェア製品が効率的に稼動するために必要な資源，例えば，ハードディスク容量，RAM，ビデオカード，
無線インタネットカードなど

1.4.5 保守性
製品説明では、その製品の保守性について、購入予定者や利用予定者に必要な情報を示さなければなりません。保守性に関する記述には以下のものがあります。詳しくは順次解説します。
 ソフトウェア品質特性のうち「保守性」に該当する事項を記載したい場合、ソフトウェア品質特性に準じた記載。

この場合、次のことを考慮する必要があります（後述「品質特性の考慮」を参照）。


保守性の品質副特性を考慮していること。

“検証可能な適合の証拠を示せる”という形で書かれていること。

 運用時・利用時の保守に関する情報

 品質特性の考慮

ソフトウェア品質特性の「保守性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形での記載が必要になります。
記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません（各項目については「Chapter 4.1ソフトウェア品質特性」を参照してください）
。
 解析性
 変更性
 安定性
 試験性
 保守性標準適合性

 こうした品質特性に関連した記載をする場合は、「実際に製品説明の記載通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

副特性の記載例：解析性
副特性「解析性」を例に記載内容を解説します。故障発生時の追跡調査を補助するために、内部のログを採取する機能があります。利用者がそれらを用いてある程度の原因調査ができるようにする、あるいは、利用者がソフトウェア製造者/提供者に不具合を報告するときにログの内容を含められるよ
うにするのであれば、ログ採取の機能について具体的に記述することが求められます。
 ログ採取の有効／無効の設定
 採取したログの確認／取得方法
 不具合報告への含め方 など

40

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 運用時・利用時の保守に関する情報

製品説明には、当該製品の運用時・利用時の保守に関する情報を記述しなければなりません。もし動作中にソフトウェアの振る舞い、ソフトウェア自身やOS、エンドユーザによる操作、外部とのデータの入出力などを監視している場合には、その旨も記述しなければなりません。他に例として以下のものが挙げられます。
 処理速度、応答速度などの監視
 予想外の故障や、動作に影響を及ぼす重大な条件の監視 ログ、警告表示などの運用操作中の指標の監視
 業務によって使われるローカルデータの監視 審査基準

製品説明に本節で説明された事項の記載がある場合、本項目を満たしていると判断されます（該当しない
事項については記載しなくても問題ありません）。
 運用時・利用時の保守に関する情報が記載されている（監視項目など）。
 品質特性のうち「保守性」に該当する事項がある場合、各副特性を考慮して記載されている。

 原文

JIS-X-25051：5.1.8、保守性に関する記述（5.1.8.1－5.1.8.2）
5.1.8.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，保守性に関する記述を含まなければならない。保守性という特性には，解析性，変更性，安定性，試験性及び保守性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
5.1.8.2 製品説明は，利用者に対して，保守に関する情報を含まなければならない。
例 情報には，次のものがあってもよい。
－ 業務実行中の動的性能の監視－ 予想外の故障及び重大な条件の監視－ ログ，警告表示などの運用操作中の指標の監視－ 業務によって使われるローカルデータの監視41

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.4.6 移植性に関する審査基準
製品説明では、その製品の移植性について、購入予定者や利用予定者に必要な情報を示さなければなりません。移植性に関する記述には以下のものがあります。詳しくは順次解説します。
 ソフトウェア品質特性のうち「移植性」に該当する事項を記載したい場合、ソフトウェア品質特性に準じた記載。

この場合、次のことを考慮する必要があります（後述「品質特性の考慮」を参照）。


移植性の品質副特性を考慮していること。

“検証可能な適合の証拠を示せる”という形で書かれていること。

 製品を動作させるための構成、使用可能な構成（ハードウェア、ソフトウェアとも） インストール手順に関する情報
 品質特性の考慮

ソフトウェア品質特性の「移植性」に該当する事項を当該製品の特徴として記載する場合は、ソフトウェ
ア品質特性に準じた形での記載が必要になります。
記載する上では、以下の副特性を考慮し、該当する特徴を記載しなければなりません（各項目については「Chapter 4.1ソフトウェア品質特性」を参照してください）。
 環境適応性
 設置性
 共存性
 置換性
 移植性標準適合性

 こうした品質特性に関連した記述をする場合は、「実際に製品説明の記述通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

副特性の記載例：環境適応性
副特性「環境適応性」を例に記載内容を解説します。ハードウェア環境・ソフトウェア環境は、利用者の好みや事情（組織のITポリシーなど）により多種多様です。そうした背景からくる要望が環境適応性です。例えば、パッケージソフトウェア製品であれば、ソースコードの変更なしにそのまま多様な環境に対応できることは特に重要な特性です。あるいは利用状況の変化に合わせてデータベースのサイズ上限を調整できるといった特性も環境適応性に含まれます。このように多様な環境への適応性
や、状況の変化に合わせた調整手段をあらかじめ提供されていれば、利用者にとって有益です。
この副特性の場合、ソフトウェアの構成情報の修正手段などを具体的に記すことで環境適応性の主張とすることができます。例えば、構成情報を構成ファイル(いわゆるINIファイルやレジストリ）に記録する場合、構成ファイルの名称や所在、項目名称と解説、修正方法などを記すことが一例として考えられます。

42

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 製品を動作させるための構成、使用可能な構成

製品説明には、当該製品を稼働させるために必要なハードウェア、ソフトウェアの構成が記述されてなけ
ればなりません。このハードウェア・ソフトウェア構成は一通りである必要はなく、目的や用途ごとにふさわしい構成を複数挙げることは問題ありません。構成要素としては以下のものがあります。
 オペレーティングシステムとそのエディション
 CPU とクロック周波数、チップセット
 補助プロセッサを含む演算処理装置
 メインメモリの大きさ
 周辺記憶装置の種別及び容量
 拡張カード 入力装置（スキャナなど）
 出力装置（プリンタなど）
 ネットワーク環境
 システムソフトウェア、および他のソフトウェア
 インストール手順に関する情報

製品説明には、当該製品のインストール手順に関する記載がなければなりません。
インストール手順の詳細は不要ですが、以下のようなことを記載する必要があります。
 エンドユーザがインストールを実行できるかどうか。
 インストールに必要なコンピュータ、または当該製品のアクセス権限
 インストールのために必要な準備

ハードウェア、先立ってインストールしておくべきソフトウェア、マスタデータなど

 インストールにかかる時間（概算） 審査基準

製品説明に本節で説明された事項の記載がある場合、審査基準を満たしていると判断されます（該当しな
い事項については記載しなくても問題ありません）。
 製品を動作させるための構成や、使用可能な構成が記載されている
 インストール手順に関する情報が記載されている
 品質特性のうち「移植性」に該当する事項がある場合、各副特性を考慮して記載されている

43

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文JIS-X-25051：5.1.9、保守性に関する記述（5.1.9.1－5.1.9.3）
5.1.9.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，移植性に関する記述を含まなければならない。移植性という特性には，環境適応性，設置性，置換性，共存性及び移植性標準適合性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
5.1.9.2 製品説明は，ソフトウェアを稼動するための様々な構成又は使用可能な構成（ハードウェア，ソフトウェアなど）を記述しなければならない。
注記 例えば，異なる課業，異なる境界値又は異なる効率性要求のために，異なる構成を規定してもよい。
例 これらのシステムには，次のものがあってもよい。
－ オペレーティングシステム－ 補助プロセッサを含む演算処理装置－ メインメモリの大きさ－ 周辺記憶装置の種別及び容量－ 拡張カード－ 入出力装置－ ネットワーク環境－ システムソフトウェア及び他のソフトウェア
5.1.9.3 製品説明は，インストール手順に関する情報を記述しなければならない。

1.4.7 利用時の品質パッケージソフトウェア製品のなかには、開発時に設定し、試験で確認・評価した品質レベル（注）だけ
ではなく、実際に利用者が自分の環境で使用した際の品質レベルを考慮したものもあります。そうした品
質を製品の特徴として訴えたい場合は、製品説明で本節の記載事項を踏まえた記述がなされている必要があります。

 注：「開発時に設定し、試験で確認・評価した品質レベル」とは、具体的には、以下を指します。
－製品の仕様や設計が十分検証されている（仕様や設計が試験され、故障が生じないことを確認している－前節までの製品の品質（1.4.1から1.4.6までの各節で言及している事項）が達成できていることが確認されている

ここで言及している「開発時の品質」とは、あくまでも製品の開発元が想定した利用者に対し、「これが達成できていればよいと考える」品質レベルです。これとは違い、実際の利用者の視点から「目的を達成できているかどうか、満足できるかどうか」といった、「利用者にとっての品質」も考えられます。これを「利用時の品質」といいます。利用時の品質は、開発元が考える品質だけとは限らないので注意すべきです。

 利用時の品質

利用時の品質とは、JIS X 0129「ソフトウェア製品の品質」によれば、ソフトウェア製品が「特定の環境および特定の利用状況で利用される時の、利用者の視点でのソフトウェア製品の品質」であり、前節までで取り上げたさまざまなソフトウェア品質特性の利用者に対する複合効果と考えられます。利用時の品質の概要に関しては「Chapter4.1ソフトウェア品質特性」で解説しています。

 利用時の品質の詳細は、JIS X 0129「ソフトウェア製品の品質」を参照してください。

44

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 利用時の品質の記述に関する重要事項

利用時の品質を記載する際には、以下の事項を含めることができます。
 製品に対する監査の結果


安全性の評価結果など

 製品の開発中に、開発元が把握している未解決の問題の概要
 利用者調査結果


実際の利用者の満足度など

 製品の基本的なサービスレベルとその実績
「（以下に規定する）環境下で稼働率 98 パーセントを維持」など

利用時の品質は、利用者や利用状況に大きく依存します。したがって、想定される利用者を全て取り上げようとするのではなく、典型的な利用者や、典型的な使われ方を想定して記述することが望ましいです。

 品質特性に関連した記述では、「実際に製品説明の記述通りであることはこのようにして確認できる」といったように、必要に応じて証拠を示せることも記す必要があります。

 試験報告への参照

製品説明に、当該製品の利用時の品質について記述する場合、試験報告への参照を記述しなければなりません。試験報告については「Chapter3.3試験文書の審査基準」を参照してください。

 審査基準

製品説明に本節で説明された事項の記載がある場合、本項目を満たしていると判断されます（該当しない
事項については記載しなくても問題ありません）。

 利用時の品質について、具体的な利用状況などを考慮して記載されている
 試験報告への参照が記載されている
 原文

JIS-X-25051：5.1.10、利用時の品質に関する記述（5.1.10.1－5.1.10.2）
5.1.10.1 製品説明は，該当する場合，JIS X 0129-1:2003 に基づいて，利用時の品質に関する記述を含まなければならない。利用時の品質という特性には，規定の利用状況における有効性，生産性，安全性及び満足度を考慮しなければな
らず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
注記 利用時の品質に関する記述は，利用状況に強く依存する。COTS ソフトウェア製品の見込まれる利用者を全て考慮す
ることは不可能である。予期された典型的な利用者及びその意図した使用について記述することが望ましい。
例 利用時の品質の記述には，次のものがあってもよい。
－ 監査された製品の割合－ COTS ソフトウェア製品の開発プロセスでの未解決問題報告又は観察結果の数－ 修正済み又は未修正の利用者調査結果
試験効率性，有効性及び満足度に関する情報については，ISO/IEC 25062 を参照する。
5.1.10.2 試験報告書への参照を記述しなければならない。
注記 試験報告書の様式は，TS X 0111-4 に示している。

45

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2 利用者用文書（ユーザマニュアルなど）の審査基準
ここでは、パッケージソフトウェア製品の利用者用文書（ユーザマニュアルなど）に含まれるもの、および利用者文書に対する審査基準について説明します。利用者用文書は申請の際に提出する必要があります。

2.1 利用者用文書とは何か
利用者用文書とは、エンドユーザが当該製品を使用し運用する上で、必要な情報を提供する文書などを指します。

<利用者用文書と他の文書との相関関係>

利用者用文書はいわゆる「ユーザマニュアル」などと呼ばれ、エンドユーザが当該製品を使用する上で必要な情報を提供します。機能の記述について製品説明や試験文書と整合性がとれている必要があります。
 利用者用文書に該当するもの

 操作マニュアル 運用マニュアル インストールマニュアル オンラインヘルプや練習用教材などがあれば、それらも利用者用文書に該当します。
 開発者用の利用者用文書

マクロなどの機能により利用者が独自に開発できる製品の場合は、それを利用する開発者も利用者に含まれます。したがって、開発用のインタフェース仕様書や注意事項、制限事項などを案内した文書も利用者
用文書に含まれます。
 利用者用文書の形態

利用者用文書は、当該製品を購入した場合には、全て利用できるようになっている必要があります。印刷
物を製品へ同梱する場合や、PDFやHTMLなどの電子ファイルでの同梱も含みます。またWebサイトなどで公開しているものがあれば、それも対象となります。

46

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文JIS-X-25051：附属書A
A.16 利用者用文書（user documentation）
利用者がソフトウェアを使用するに当たり，利用者を支援するために供給される情報。

2.2 利用者用文書の審査基準の概要
ソフトウェアの導入方法や利用方法を記載した利用者用文書（ユーザマニュアルなど）において、情報提供の内容や形態（2.3利用者用文書に記載する内容および附帯物の詳細解説を参照）が、完全性、正確性、一貫性、理解性、習得性、運用操作性の6つの審査基準（2.4利用者用文書の審査基準の詳細解説を参照）
を満たしているかどうかを審査します（下図参照）。
また、ソフトウェアの導入方法など利用者用文書に記載する内容についても、必須項目がそろっているか、
その他の項目についても適宜備わっているかどうかを審査します。

<利用者用文書の記載内容と審査基準>

 利用者用文書に対する審査基準 完全性

利用する上で必要な情報が記載されているか

 正確性記載された情報が正確か

 一貫性マニュアルや製品説明との間に矛盾や食い違いが無いか 理解性

想定している利用者にとって理解しやすいか 習得性

利用者が使用方法を学ぶための情報の記載や工夫がされているか

 運用操作性

全ての文書の利用方法を示してあるか47

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 それぞれの基準の内容に関しては、「JIS X0151流通ソフトウェアパッケージの利用者用文書及び外装表示」に基づいて審査します。

 各基準については、「2.4利用者用文書の審査基準の詳細解説」で、詳述していきます。

2.3 利用者用文書に記載する内容および附帯物
利用者用文書へ記載する内容は、重要度に応じて必須項目、条件付き項目、任意項目の3つに分類することができます。必須項目はソフトウェアの目的や機能の種類や分野にかかわらず必須とする事項、条件付
き項目は製品の内容によって必要とする事項、任意項目は提供者側の判断による事項（任意項目）です。
また、利用者用文書には、トレーニングプログラム（練習用教材）などの附帯物も同梱されることがあります。これらも上記3つの重要度に応じて分類することができます。
ここでは、1.利用者用文書に記載する内容、および2.利用者用文書の附帯物の順に解説を行います。

2.3.1 利用者用文書に記載する内容
利用者用文書に記載する内容および利用者用文書に含まれる付属物、つまり利用者用文書を構成する要素には、以下の表に示したような項目があります。 表中では、重要度（必須項目、条件付き項目、任意項目）を付したうえで、それぞれの項目について解説します。
また、それぞれの項目をさらに分類して詳細項目を作成した場合には、その詳細項目ごとに重要度も異なってきます。項目の重要度がその中に含まれる詳細項目にも一律に適用されるわけではありません。例えば、「パッケージの識別情報」は必須項目ですが、そのなかの「検索時のキーワード」に関しては任意項目となる場合などが該当します。
利用者用文書が複数の印刷物や電子ファイルなどで構成されている場合は、それら全体で、記載すべき内容を満たしている必要があります。

 参照 JIS X0151-1989 流通ソフトウェアパッケージの利用者用文書及び外装表示
Chapter1 利用者用文書

パッケージの識別情報（必須項目）

パッケージの名称とモデルなどの傍系の情報、製品のコード、バージョン



文書の版、文書の初版日、現行版の発行日



製造者または発売元の情報当該製品の特徴や、索引、検索などで利用しやすい言葉（キーワード）、言語

パッケージの構成品目

（必須項目）

CDや製本物、書類など、パッケージに含まれる物理的な構成品の一覧と数量

印刷用の専用紙など、パッケージには同梱されないが、関連するものの入手方法など

ソフトウェアの機能・仕様説明



目的と適用分野、機能範囲（必須項目）



複数の機能（メール機能と掲示板機能など）で構成されている場合は、それぞれについて記載する



必要なハード、ソフトウェア、通信などの環境



性能特性としての性能データ



計算精度などの定量的情報。ファイルサイズ、処理速度など

ソフトウェアの機能範囲などに関する制限事項

48

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

プログラムやデータへの不正アクセス防止に関するに保護機能、監査
機能、データバックアップ機能

ソフトウェアの導入方法

（必須項目）

ハードウェアの準備と設定、ソフトウェアのインストール、マスタデータなどの設定や、正常動作のテスト方法



ソフトウェアのバックアップコピーの作成方法



インストールしたソフトウェアを利用者の利用環境や用途に合わせてカスタマイズする場合の手順、調整可能な内容、方法など

ソフトウェアの利用方法



利用するためのソフトウェアの起動やロードの手順（必須項目）



全ての操作や命令の形式や機能の明確な説明

ソフトウェアの操作などの制限事項



操作や実行結果により出力されるメッセージの一覧と、それぞれの意
味、利用者がとるべき処置

入力するデータの内容、構造や形式など、項目や要素の意味、データ
の準備方法



表示や印字など出力するデータの内容と形式



中間データや補助的に必要となるデータについての説明



数値の大きさや、最大桁数、各データの扱える最大件数などのデータ
に関する制約

利用する上で必要となるファイルやレコードの形式と、他ソフトウェアでの利用の可否など

データの入力、加工、出力などの具体的な操作と、データがどのように処理されるかの簡単な機能説明

ソフトウェアの技術情報

入力操作のミスや入力データのミスなど、全ての誤りと障害となる条件



全ての誤りと障害に関するメッセージの内容と回復のための操作

ソフトウェアが採用している技術計算のアルゴリズムなど、利用者にと（条件付き項目）って必要になる、ソフトウェアに関する技術的な情報


開発ツールやエディタなどの場合、対象とする言語に関する情報

特定の機能やプログラム構造に関連する理論や問題の解法、アルゴリ
ズムなどと関連する参考文献などの情報

ソフトウェアのプログラム、モジュールなどの構成単位に関する構造

ソフトウェアの利用開始あるいは正常動作を確認するための試験方法

保証、支援（サポート）、規格

ソフトウェアそのものの保証や著作権に関する条件や約定と保証者（必須項目）



製造業者の購入者に対する、操作指導、欠陥の修正、品質保証、ソー試験方法（任意項目）

スコードの利用用語

準拠する規格と準拠しない部分の内容



利用者にとって分かりにくい専門的な用語に関する用語集と解説



文書で使用した主要な用語の索引



操作方法や誤りについてのメッセージなどの要約を、小冊子などに印（条件付き項目）
索引（条件付き項目）
早見表（クイックリファレンス）49

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック（任意項目）

刷したもの、あるいはメニューやヘルプ機能

2.3.2 利用者用文書の附帯物
アンケート用紙



文書の正確さや使い勝手に関する意見を受け付けるはがきなど

ユーザインタフェースを習得するための利用者向けの練習用教材（任意項目）
練習用教材（任意項目）
 原文

JIS-X-25051：5.2利用者用文書に対する要求事項（5.2）
注記 利用者用文書を作成するためにJIS X 0151 を使用することができる。

2.4 利用者用文書の審査基準の詳細解説
利用者用文書に対しては、「2.3利用者用文書に記載する内容および附帯物」で示した各項目を以下の6つの基準で審査します。以下、6つの審査基準をそれぞれ解説していきます。
 完全性

利用する上で必要な情報が記載されているか

 正確性記載された情報が正確か

 一貫性マニュアルや製品説明との間に矛盾や食い違いがないか 理解性

想定している利用者にとって理解しやすいか 習得性

利用者が使用方法を学ぶための情報の記載や工夫がされているか

 運用操作性

全ての文書の利用方法を示してあるか

2.4.1 完全性
利用者用文書における「完全性」に関しては、前述の「2.3.1利用者用文書に記載する内容」で取り上げた事項について全ての項目が適切に記載されていること、また条件付き項目や任意項目については、当該製品の内容に照らし合わせて適切に記載されていることを基準に審査します。

 利用者用文書の内容に関する要件の詳細は、「JIS-X-0151流通ソフトウェアパッケージの利用者用文書及び外装表示」の「第１章利用者用文書（必要）」を参考にしてください。
 完全性に関する重要事項

利用者用文書の「完全性」について、特に重要な事項を以下にあげます 当該製品の製品説明に記載してある機能について、また利用者が呼び出せる機能について、全て記載しな

ければなりません。
 信頼性に関して、不正な入力データの制御機能やメッセージ、操作誤りや何らかの障害によるデータ喪失、

データ量の許容件数や処理時間などの性能値、また障害発生時の対処方法などの障害許容性や回復性について記載しなければなりません。
 信頼性に関する内容のうち、ソフトウェアに存在する障害と発生頻度などの成熟性や、標準適合性について記載する場合は、その内容を具体的に記載しなければなりません。

50

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 ソフトウェアを利用する上で、業務の継続に影響を及ぼすような致命的なエラーや障害が発生したときに表示するメッセージや症状について、エラーメッセージ一覧などで利用者が速やかに対処できるようにしなければなりません。
 例えばファイルの保存など特定の操作をしないと利用者がデータを喪失するというような、利用者に致命的な状況が起こりうる場面があれば、障害やエラーでなくとも起こりうる状況としてあらかじめ記載しておかなければなりません。
 利用者の操作や運用上のミス、ハードなどの障害発生時も含め、データを保全するために、バックアップと復元の手順を具体的に記載しなければなりません。ただし、ハードや OS などのソフトウェア以外による障害発生などで、利用者独自の復旧が困難な場合を想定した支援体制などがあれば、それについても記載しなけ
ればなりません。
 例えば一般的な事務処理、会計の計算処理や給与計算、対外的な金銭上の問題を引き起こす請求業務など、重要なロジックを含むプログラム処理については不足なく、かつ正確で理解できるように操作方法や対処方法を記載しなければなりません。

 審査基準

利用者用文書の審査では下記の事項がもれなく記載されているかどうかを判断します。
 「2.3 利用者用文書に記載する内容および附帯物」中の必須項目を全て記載してあること。
 製品説明に記載してある全ての機能について記載してあること。
 製品説明に記載してある全ての制限事項について記載してあること。
 利用者が呼び出せる全ての機能について記載してあること。
 信頼性の特性と内容、および障害発生時の対処法について記載してあること。
 ソフトウェアの故障や停止を引き起こすようなエラーと故障の一覧が記載されていること。
 操作や処理業務の終了時にデータが消失するような条件について記載してあること。
 データのバックアップと復元手順について記載してあること。
 重要な機能について、操作方法はじめ全ての必要な情報について記載してあること。
 ソフトウェアのインストールに必要なディスク容量の最小値と最大値を記述してあること。
 ソフトウェアの管理機能についても、利用者が実行できるように、注意事項なども含めて必要な操作方法などが記載してあること。
 利用者がソフトウェアの管理機能を実行したさい、正常終了したことを確認するための手順や方法を記載してあること。
 利用者用文書の全ての分冊の構成と、それぞれの文書の関係や用途について、いずれかの文書に記載して

あること。
 原文

JIS-X-25051：5.2.1完全性（5.2.1.1-5.2.1.11）
5.2.1 完全性
5.2.1.1 利用者用文書は，ソフトウェアを使用するために必要な情報を含まなければならない。
5.2.1.2 利用者用文書は，製品説明に記述された全機能及び利用者が呼び出せる全機能を記述しなければならない。
5.2.1.3 利用者用文書は，信頼性の特質及びその運用操作を記述しなければならない。
5.2.1.4 利用者用文書は，業務の故障又は停止を引き起こす処理対象のエラー及び故障の一覧を記述しなければならない。特に，業務を終了するときにデータがなくなる終了条件を記述しなければならない。
5.2.1.5 利用者用文書は，必要なデータのバックアップ及び復元の手引を記述しなければならない。
5.2.1.6 利用者用文書は，重大なソフトウェア機能（その故障が安全性に影響を及ぼすことがあるソフトウェア又は大規模な金銭上の損失若しくは社会的損失を起こすことがあるソフトウェア）の全てについて完全な指示情報及び参照情報を提供しなければならない。注記 詳細情報は，附属書B を参照。
5.2.1.7 利用者用文書は，製品説明に記述している全ての制限事項を記述しなければならない。
5.2.1.8 利用者用文書は，インストールに必要なディスク容量の最小値及び最大値を記述しなければならない。
5.2.1.9 利用者用文書は，利用者が業務管理機能を実行するために必要な全情報を含まなければならない。

51

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

5.2.1.10 利用者が業務管理機能を実行するための情報には，業務管理機能が成功裏に終わったことを利用者が検証できる情報を含まなければならない。
5.2.1.11 利用者用文書が複数の分冊に分かれて提供される場合，そのセットのうち少なくとも一つに全体の構成を記述
しておかなければならない。

2.4.2 正確性
利用者用文書における正確性に関しては、内容が正しいこと、また説明や表現が具体的であることを基準に審査します。以下のような点に注意してください。
 利用者用文書に記載した全ての情報は、正確な情報源をもとに記載されていることが望ましいです。
 正確な情報源とは、ソフトウェアを検査した結果の記録や、検査に使用した仕様書や設計書など、あるいは税額の計算方法などで公示された情報など、情報源が外部にあるものであれば、その情報の所有者、記載者またその日付などの出典が具体的に確認できることを意味します。
 文章表現や数値などの記載について、曖昧さがあってはなりません。
 審査基準 利用者用文書の記載内容と、検査完了後のプログラム動作や表示、操作方法などが一致していること。
 外部の情報を記載した場合には、出典が具体的かつ正確であり、出典をたどることができること。
 文章表現のうえで、「～かもしれません」「～なるでしょう」などの、あいまいな表現がないこと。
 数値の記載については、「大きい」「少ない」「大量」などの漠然とした言葉の表現でなく、数字を使用した表現であること。
 原文

JIS-X-25051：5.2.2正確性（5.2.2.1-5.2.2.2）
5.2.2 正確性
5.2.2.1 利用者用文書の全情報は，正確でなければならない。
注記 利用者用文書の全情報は，正確性を保証するための信頼できる情報源をたどれることが望ましい。
5.2.2.2 利用者用文書は，情報に曖昧さがあってはならない。

2.4.3 一貫性
利用者用文書における「一貫性」に関しては、文書を構成する各マニュアルの記載や製品説明も含めて、それぞれの説明文書の間で矛盾がないことを基準に審査します。
ここではソフトウェアとの一貫性は含まず、製品説明も含め、利用者用文書を構成する各種のマニュアルや電子化したファイル、オンラインヘルプなどの記載内容が一貫したものであり、矛盾が無いことを審査します。
 審査基準 製品説明に記載した内容と、利用者用文書の記載内容が一致していること。
 利用者用文書を構成する各印刷物や、電子ファイル、オンラインヘルプなどで記載内容が一致していること。
 原文

JIS-X-25051：5.2.3 一貫性（5.2.3.1）
5.2.3.1 利用者用文書の文書は，それ自体の内容，利用者用文書間，製品説明間で矛盾があってはならない。
注記 ソフトウェアとの一貫性については，5.3.1.5 で取り扱う。

52

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.4.4 理解性
利用者用文書における理解性に関しては、利用者用文書の内容や構成が、当該製品を利用するエンドユー
ザにとって理解しやすいものであることを基準に審査します。
利用者用文書を構成している全ての文書について、当該製品が主に対象とするエンドユーザにとって、理解できる用語や表現でなければなりません。 また文書を構成するそれぞれの印刷物などの使い方についても、明確で具体的に説明しなければなりません。
 審査基準 当該製品を利用すると想定されるエンドユーザが理解できる用語や表現で記載していること。
 用語に複数の意味がある場合や意味する範囲が一般と異なる場合は、用語の一覧などで当該製品での意

味合いを説明していること。
 例えば建築家を対象とする製品など、特定の専門家がエンドユーザとなる場合は、その専門家たちが理解できる用語や表現を使っていること。
 利用者用文書を構成するそれぞれの文書の一覧を作成したうえで、それを使う場面、使い方、目的を利用者にわかりやすいように説明していること。
 原文

JIS-X-25051：5.2.4 理解性（5.2.4.1-5.2.4.2）
5.2.4.1 利用者用文書は，COTS ソフトウェア製品が主な対象としているエンドユーザ集団が理解できなければならない。
そのために，専門分野の人たちが理解できる専門用語及び様式を使用する。
例 建築家を対象にしているCOTS ソフトウェア製品
5.2.4.2 利用者用文書の理解性を，系統だった文書一覧によって容易にしなければならない。

2.4.5 習得性
利用者用文書の「習得性」に関しては、エンドユーザが製品を十分利用できるようにするための説明内容
であるか、あるいは教材が用意され利用できるようになっているかを基準として審査します。
利用者用文書には自習用などの教材も含みます。教材がない場合でも、具体的な操作方法をマニュアルに記載したり、操作しながら理解できるようにソフトウェア画面で図示したりするなど、利用者がソフトウ
ェアの利用方法を習得しやすく作られている必要があります。
 審査基準 エンドユーザがソフトウェアの使用方法を習得できるように説明されていること、あるいは、ソフトウェアの使用方法を習得できるような教材が用意されていること。
 エンドユーザが習得しやすいように、マニュアルや教材の利用方法が説明されていること。
 エンドユーザが習得する上で必要となる用語が説明されていること。
 他のマニュアルや教材などの参照箇所などを記載することで、使用方法を習得しやすいように考慮されてい

ること。
 原文

JIS-X-25051：5.2.5 習得性（5.2.5.1）
5.2.5.1 利用者用文書は，ソフトウェアの使用方法を学ぶために必要な情報を提供しなければならない。
注記 利用者用文書は，COTS ソフトウェア製品自体又は教育訓練用の補助教材に含まれている追加情報を参照してもよい。

53

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2.4.6 運用操作性
利用者用文書の「運用操作性」に関しては、マニュアルなどの利用方法が明確で、なおかつ確実に利用できるように構成、提供されていることを基準に審査します。
例えばマニュアルを電子ファイルで提供する場合は、電子ファイルの閲覧に必要なソフトウェアを明示する必要があります。利用者が印刷できる形式で提供する場合は、印刷する方法を説明する必要があります。
一般的でない用語や略語については、用語集などでの説明が必要です。
 審査基準 マニュアルを PDF などの電子ファイルで提供するような場合には、印刷ができるかどうかを記載していること、また印刷できる形式になっている場合は、印刷するための手順などを記載していること。
 印刷方法を記載すること。印刷に必要なソフトがあれば同梱するか、入手方法を記載してあること。
 カード形式や早見表（クイックリファイレンス）などの形態になっていない文書であれば、目次や索引、項目一覧などを付記してあること。
 エンドユーザになじみのないコンピュータ用語や専門用語など、一般的ではない用語については用語解説を提供していること。
 用語を略して記載している場合は、略語の定義を記載してあること。
 原文JIS-X-25051：5.2.6 運用操作性（5.2.6.1-5.2.6.3）
5.2.6.1 利用者用文書が印刷物でない場合，文書が印刷可能かどうかを示さなければならない。印刷可能な場合には，印刷物を手に入れる方法を示さなければならない。
5.2.6.2 カード形式及びクィックリファレンスガイド以外の利用者用文書は，目次又は項目一覧，及び索引を付けなければならない。
5.2.6.3 利用者用文書は，一般に使われていない用語及び略語を定義しなければならない。

54

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3

試験文書の審査基準
本節では、パッケージソフトウェア品質認証 (Package Software Quality Certification：以降PSQ認証と記載)を取得しようとするパッケージソフトウェア製品の試験文書に関する審査基準について説明します。試験文書は申請の際に提出する必要があります。

3.1 試験文書の概要
試験文書とは、ソフトウェア開発の一環で、ソフトウェアが正しく実装されているかどうかを確認する試
験で使用される文書を指します。主に試験計画、試験説明、試験報告から構成されます 。

ソフトウェア品質向上に欠かせないソフトウェア試験
一般的にパッケージソフトウェアの開発過程には試験の行程も含まれます。この試験は通常プログラム実装後に実施し、ソフトウェアが要求事項通りに機能するかどうかなどを検証するものです。試験はいくつかのレベルに分けて実施し、不具合を発見すれば修正を行います。これを重ねることでソフ
トウェアの品質を向上させていきます。多くは開発者が試験を実施しますが、開発者以外の人が担当する場合もあります。本章では試験を実施する担当者を「試験実施者」と表記します。

3.1.1 審査における試験文書の位置付け
試験文書は、製品説明や利用者用文書に記載されたソフトウェアの機能が正しく実装されていることを証
明し、同時にソフトウェアの機能が品質要求に関する各審査基準（Chapter 4を参照）を満たしているかどうかを担保するためにあります。
そのため、審査では試験文書内だけではなく製品説明、利用者用文書とも内容が合致している必要があります。また、試験文書の記載内容は、ソフトウェアの仕様書や設計書と漏れなく正確に対応しており、また試験を実施した結果や合否判定が具体的かつ正確に記録されている必要があります。以上が審査を受ける上で最低限満たさなければならない基準です。

＜試験文書とソフトウェアとの整合性＞

55

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.1.2 試験文書を構成する３種類の文書概要
PSQ認証制度では、製品説明や利用者用文書に記載されている内容の正確性について、および品質要求事項に対し適切に試験が行われたかについて、試験文書を通して審査します。
試験文書は大別して、試験計画、試験説明、試験報告から構成されます。下記の表で概要を説明します。

試験計画

パッケージソフトウェア製品の試験に先立ち計画したこと、つまり試験する
対象や範囲、試験工程、試験結果の合否判定方法、そして試験を実施す
る試験環境などについて記載します。

試験説明

試験を行う際の技術的な実施方法を記載します。試験の対象となる機能や性質、条件の組み合わせ、試験を進めるための手順、期待される試験結果などです。

試験結果

試験計画と試験説明に沿って実施した試験の結果報告、試験で発見した不具合の内容、およびその不具合修正に関して記載します。細かく分類すると以下の３つの事項からなります。ただしこれらは独立した形式である必要はなく、試験実施報告に不具合報告や試験結果の総合評価を含めひとまとまりにしてもよいものとします。

試験実施報告 試験実施者が試験結果を記録し、報告するための事項です。各試験の結果と、それらを集約したものとなります。
不具合報告

 試験実施者が不具合を発見した際、不具合の詳細を開発者に伝えるための事項です。試験実施者がパッケージソフトウェアの不具合を発見した際に作成し、開発者がこれを見て不具合の解析を行い、必要に応じてソフトウェアに修正を行います。
試験結果の総合評価

 試験全体あるいは各々の品質要求に応じた試験について、品質要求への適合性の評価について記載した事項を指します 試験文書の名称に規定はないので、必ずしも上記の文書名を冠する必要はありません。
試験文書を構成する文書の一覧を作成し、各文書がどれに相当するか明記してください。

 単体テスト、システムテストなど試験レベルが複数に渡る場合、各試験レベルで試験文書が作成されることがあります。この場合、システムの概要、機能一覧など試験レベルに依存しない情報については、共通した内容が記載されていても問題はありません。

56

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック<試験文書を構成する各文書の関係図>

 試験文書の形式

試験文書は本節で述べられている審査基準に適合する文書であれば、形式は問いません。また文書はひとまとまりにする必要はありません。試験文書として要求されている事項が全て網羅されていれば、複数の文書で作成されていてもよいものとします。下記に形式を例示します。
一般文書

 Microsoft Word などの文書作成ソフトウェアで作成された文書
 Microsoft PowerPoint などのプレゼンテーション資料作成ソフトウェアで作成された文書
データベース 不具合管理ツールで表示される不具合リスト

図表 Microsoft Excel などの表計算ソフトウェアで作成された図表、マトリクス
 Microsoft Visio などのフロー作成ソフトウェアで作成されたフローチャート

 試験文書はIEEEで定義された形式(IEEE829-2008)などがありますが、必ずしもその形式に従って作成する必要はありません。

 審査基準 試験文書として、下記 4 点が提出されていること。


試験文書を構成する文書の一覧



試験計画



試験説明



試験結果

 上記以外の文書は、提出の必要はありません。

57

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.2 試験文書全体の概要と審査基準
ここでは試験文書全体の審査基準について記載します。試験文書全体を通した審査基準には、以下の3つがあります。それぞれの詳細については順に解説していきます。
 試験文書の目的

製品説明や利用者用文書、ソフトウェアの品質要求事項に関する項目の全てが試験対象に含まれていること。
 試験文書の一貫性

試験文書自体で一貫性がとれていること、および仕様書や利用者用文書（マニュアルなど）とも矛盾がなく一貫性がとれていること。
 試験文書全体に共通する文書管理用の項目

試験文書全体に共通して記載すべき文書管理のための項目があること。

3.2.1 試験文書の目的
試験文書の目的とは、必要な試験項目が正しく試験されたかどうかを証明することにあります。試験計画
で試験の目的が定義され、その目的に基づいて試験説明で項目を列挙し、試験結果で各試験項目の結果を報告します。
 審査基準 試験文書を通し、製品説明や利用者用文書に記載されている内容や、品質要求事項に含まれる事項が全て確認されたかを実証できること。
 原文JIS-X-25051：6.1一般的な要求事項
6.1.1 目的
6.1.1.1 試験文書の目的は，ソフトウェアが5.3 で規定した要求事項に適合していることを明らかにすることである。5.3
は，この実証を可能にするための全ての要素を含んでいる。

3.2.2 試験文書の一貫性
PSQ認証制度では文書の一貫性を重視します。試験活動を通じて作成された文書、およびその文書を参照
する文書など、あらゆる文書間で矛盾がないこと、また実施した試験結果がそれに対応する製品説明や利用者用文書上の記載内容とも矛盾がないように作成されていなければなりません。
 審査基準 試験文書の記載内容に偽りや誤りがなく、正確性が確保されていること。
 試験設計の根拠や文書の参照関係などを参考にして各文書の一貫性を検証できること。
 試験文書の記載内容、関連する製品説明や利用者用文書、仕様書との間で一貫性が確保されていること。
 原文

6.1.2 一貫性
6.1.2.1 試験文書の各文書に含まれている情報は，検証可能で，かつ，正しくなければならない。
6.1.2.2 試験文書の各文書は，それ自体で矛盾があってはならない。また，製品説明及び利用者用文書と矛盾があってはならない。

58

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.2.3 試験文書全体に共通する文書管理用の項目
試験活動中は多くの文書を作成します。また、文書間で相互に参照先を指定しあうものもあります。このように文書の量が増加した場合、文書そのもの、あるいは文書間の参照関係を管理するために、何らかの文書管理体系が必要になります。PSQ認証制度では提出された書類を以下の事項で審査します。

 文書の識別子と一覧表

文書それぞれに識別のための識別子を付与しておく必要があります。同時に試験文書に該当する文書の一
覧表を作成する必要があります。
 共通して記載すべき文書管理用項目

試験計画書、試験説明、試験計画書全てに記載すべき項目と審査基準を下表にまとめます。
文書名

 同じ名前の文書が二つ以上存在することのないようにユニークな文書

名にしなければなりません。ただし名称のつけ方に規定はありません。
識別子

 各文書には参照すべき文書、管理番号、版番号、発行日を明記して、他の文書と識別できるようにしなければなりません。
 認証を受けるために特別な版番号、発行日などを割り当てる必要はな

く、通常行うバージョン管理の範囲で識別子が付与されていれば問題ありません。
改版履歴

 文書が修正された日付や内容、修正した作業者などを元に関連文書との一貫性や整合性を確認できるようにする必要があります。
試験文書内で参照している文書の識別子

 試験文書内で他の文書を参照している場合は、参照先の文書を具体的に指し示すための識別子が必要です。審査では必要に応じて参照先の文書を確認し、一貫性や整合性などを確認します。

文書の作成者、作業実施者

 試験文書の作成者、実際に試験を実施する担当者に関する情報を記載する必要があります。
文書の目次あるいはその内容について簡潔に示した記述

 文書の全体構成を表したものや、文書が果たすべき目的などを含む文書の概要が必要です。原則として、目次が記載されていればよいものとします。

（任意）用語集

 試験文書で専門用語が使用されていれば、用語集が必要です。製品

説明やその他の文書内に記載しているなら、そちらを参照してもよい
ものとします。参照する場合は、参照先を明記する必要があります。
企業内でのみ通用する特殊な用語は社外の人の理解を助けるよう、注釈をつけるなど補足する必要があります。

59

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 審査基準 提出が必要な試験文書にはそれぞれ下記項目が明記されていること。


文書名



識別子



改版履歴



試験文書内で参照している文書の識別子



文書の作成者、作業実施者

（任意項目）用語集

 各項目の解説は上記を参照してください。
 原文

6.1.3 内容に対する要求事項
6.1.3.1 試験文書は，次を含まなければならない。
a) 試験計画書b) 試験説明c) 試験結果
6.1.3.2 試験文書は，試験文書を構成する全ての文書について，文書名及び識別子付きの一覧を含まなければならな
い。
6.1.3.3 試験文書の各文書は，次を含まなければならない。
－文書名－ただ一つの識別子（参照，版番号，発行日など）－改良履歴，又は文書の変更履歴を記述した他の要素－目次又は内容の説明－文書の本文で参照されている文書の識別子－作成者及び検査者に関する情報－用語集
6.1.3.4 試験文書は，一冊以上の文書から構成されてもよい。

3.3 試験計画に対する審査基準
提出が必要な試験文書のうち、ここでは試験計画に関して説明します。試験計画は試験活動の全体を説明する文書であり、試験対象や範囲、試験工程、試験結果の合否判定方法、そして試験環境などが記載されている必要があります。

3.3.1 試験計画に含まれる内容
ソフトウェア開発活動の一環で行われる試験には多くの手法や技法が存在するため、PSQ認証制度では特定の試験手法や試験方法を推奨することはありません。また試験のスケジュール、作業工数、要員などの管理項目は審査対象としません。あくまで製品説明や利用者用文書に記載されている項目、およびソフト
ウェアが仕様に基づいて実装すべき項目が満遍なく試験されているかどうかが審査の対象となります。試験計画には下記の事項を含める必要があります。
 試験の目的

試験の目的とは、ソフトウェアが設計された内容に基づいて正しく実装されているかどうかを確認することです。
 製品説明やソフトウェアに対する品質要求事項で挙げた品質要求事項、または利用者用文書に記載された各機能は、少なくともそれぞれがひとつの試験の目的として設定されます。

60

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 試験の対象

試験の対象には、製品説明、利用者用文書、または機能仕様書などに記載された機能などの事項や、ソフ
トウェアが持つ品質特性で記載された項目などが挙げられます。
 ソフトウェアを表す文書に記載された事項
 ソフトウェアが持つ品質特性に記載された項目試験環境では準備できない本番環境など、試験対象にできない品質特性があれば、その理由を記載する必要があります。

 試験の対象に関する網羅性には、特に基準はありません
利用者用文書に記載された内容で、主要な機能ではないもの、例えばパッケージソフトウェアが運用される環境に関する事項なども試験の対象とする必要があります。下記が該当します。
 インストール 運用操作時の制限事項
 同時使用人数が限定されている場合やネットワーク帯域の制限、データベース連携の制限など運用時に制限事項がある場合など。
 入力構文違反
 利用者用文書に例示されている事項

 利用者の使用例や使用上のコツと言ったTipsが例示されている場合は、それらも試験対象とみなされます。

 試験の項目

試験項目を設計する際、例えば機能に着目して機能分割していく方法があります。どのような方法を採用するにしても、試験項目を設計した根拠を明示する必要があります。もし特定のテスト設計技法を使用した場合には、そのテスト技法の提示が必要です。
試験の項目は、少なくとも製品説明や利用者用文書に記述されている項目と、ソフトウェアに対する品質要求事項で挙げた品質要求事項を網羅している必要があります。
 利用者用文書に記載されている機能一覧は全て、試験項目に含める必要があります 利用者用文書から試験の項目を細分化する場合は、製品説明や JISX25051 の 5.3 ソフトウェアに対する品質要求事項のどれに基づいているか明示する必要があります。

 各試験項目の期待値は、利用者用文書に記載されている通りのもの、または利用者用文書に記載されている内容に基づいた記述である必要があります。条件により利用者用文書に記述されないケースが発生する場合があれば、その内容を利用者用文書に記載する必要があるケースも考えられます。

 製品説明の中にソフトウェアが満たすべき事項、規制に関する組み合わせというような要求事項を含んでいる場合
は、それらも試験対象とする必要があります。
 機能分割の水準

機能分割の水準とは、試験設計時に試験項目を切り分ける粒度です。機能分割から項目設計を行うなら、どのような水準で機能を切り分けたのかを記述する必要があります。機能の種類によって分割の水準が不均一になることが考えられますが、全体で一定の水準を保つ方がよいでしょう。水準の目安となる例としては下記のようなものが挙げられます。


利用者用文書で記述されている段落



シェルのコマンド

ユーザインタフェースのボタン

言語コマンド61

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 試験の目的に対する審査基準


製品説明やソフトウェアに対する品質要求事項で挙げた品質要求事項、または利用者用文書に記載された各機能が、少なくともひとつの試験の対象や目的として設定されていること。



ソフトウェアに対する品質要求事項で挙げた品質要求事項のいずれかが何らかの理由により適用できな
い場合は、その理由が明示されていること。



利用者用文書から参照されてテストの目的が設定された場合、パッケージソフトウェア製品が利用者用文書の記述に適合していること。

 試験項目に対する審査基準


試験項目の設計方法が明示されていること。

達成しなければならない業務を代表する機能の組合せだけでなく，利用者用文書に記述されている全ての機能が試験項目の対象とされていること。



製品説明に要求文書が記述されている場合は、それが試験項目の対象に含まれていること。



機能分割を行った場合、その水準が明記されていること。



運用時にインストール作業が必要な場合、それが試験項目の対象に含まれていること。



製品説明や利用者用文書に運用操作上の制限事項が記載されている場合は、それが試験項目の対象に含まれていること。



明らかな入力構文違反が含まれる場合、それが試験項目の対象に含まれていること。



利用者用文書に例示されている事例があれば、それが試験項目の対象に含まれていること。

 原文

6.2.1 進め方
注記特定の推奨する試験手法又は試験方法はない。
6.2.1.1 製品説明及び5.3 で記述した全ての品質特性は，試験項目の対象としなければならない。
6.2.1.2 製品説明及び5.3 で記述した各品質特性は，少なくとも一つの試験項目の目的としなければならない。
注記試験計画書は，その他のどんな文書（その文書と利用者用文書とが関連がある場合には）も参照できる。
6.2.1.3 達成しなければならない業務を代表する機能の組合せだけでなく，利用者用文書に記述されている全ての機能を
試験項目の対象としなければならない。
6.2.1.4 利用者用文書に記述されている各機能は，少なくとも一つの試験項目の目的としなければならない。
6.2.1.5 試験項目は，ソフトウェアが利用者用文書の記述に適合していることを実証しなければならない。
6.2.1.6 試験説明に要求文書が記述されている場合、これらは、試験項目の対象としなければならない。
6.2.1.7 試験項目の設計の根拠として選択された機能分割の水準を示さなければならない。
例機能は，次のように分割できる。
－利用者用文書の段落－シェルのコマンド－ユーザインタフェースのボタン－言語コマンド
6.2.1.8 試験項目の設計方法を示さなければならない。
例使用可能な設計方法には，次のものがある。
－境界値分析
－チェックリスト－データフロー分析－障害の埋め込み－量的試験
6.2.1.9 全てのインストール手順は、試験項目の対象としなければならない。
6.2.1.10 製品説明および利用者用文書に示されているすべての運用操作上の制限は、試験項目の対象としなければならない。
6.2.1.11 明らかな入力構文違反は、試験項目の対象としなければならない。
6.2.1.12 利用者用文書に例が示されている場合、その例は試験項目として使用されなければならない。ただし、全体試
験は、これらの例だけに限定してはならない。
6.2.1.13 5.3の品質要求事項のどれかが適用できない場合、理由を記述しなければならない。

62

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.3.2 パッケージソフトウェアの試験における合否判定基準
合否判定は原則として、製品説明、利用者用文書に記載されている項目の全てが試験項目として定義され、試験を通し全てが正しく実装されている事が確認された場合、合格とします。
この合否判定には基準が必要です。ソフトウェアが製品説明や利用者用文書に適合しているかどうかを判定するため、試験結果に対して何らかの合否基準を設ける必要があるということです。要求に適合した実装がなされているかどうか、試験結果を評価する客観的な基準を設けるべきです。

 合否判定基準は、根拠の提示を求める場合もあります。
 審査基準

 合否判定基準には、客観的な基準を明記すること。
 製品説明や利用者用文書、品質要求事項などの参照先があればそれらについても同様に明記すること。
 原文

6.2.2 合否判定基準
6.2.2.1 試験結果が製品説明及び利用者用文書へのソフトウェアの適合を実証しているかどうかを決定するために，使用する基準を示さなければならない。

3.3.3 試験を実施するための環境試験計画書には、試験を実行したハードウェア、ソフトウェアの構成を明示する必要があります。
試験実施者は、製品説明に記述されているパッケージソフトウェアの利用可能な環境構成に対し、全構成
および各コンポーネントの組み合わせを試験する必要があります。例えばパッケージソフトウェアが複数のOSに対応している時など、互換性に対して明示されている場合があり、その場合は全ての環境で試験を実施しなければいけません。
試験で適切な結果を得るため、試験対象となる環境は正確な試験結果を出力できるようにする必要があります。もし出力するコンポーネントが対象の試験環境に含まれていないとしても、出力結果を確認するた
めのモニタリング装置を必要とする場合もあります。

 例：クライアント-サーバ対応のパッケージソフトウェアで、クライアントPCで自動入力されたデータがバッチ処理によって変換され、所定のDB内に格納される場合。データがどのように変換されたのかを試験する場合は、モニタリ
ングツールを使用してデータの変換タイミング、状況を確認する必要があります。
 審査基準 試験を実施するためのハードウェア、ソフトウェアの構成が明示されていること。
 試験説明に記述されている環境要件に対し、環境の全構成を試験するよう計画されていること。
 試験ツールを導入して実施する場合は、使用するツールを明記すること。

 対応するOSが明記されているような場合は、全てのOSに対して試験を実施するように計画する必要があります。
前バージョンや派生バージョンのアーキテクチャを利用し作成しているという理由で試験する必要がないような場
合は、それに関連する文書の提出が必要となることもあります。

 製品説明に大規模なネットワークの対応が記載されていれば、試験用ツールなどを使用して実際に同じ環境でも問題なく使用することができるかどうかを確認する必要があります。

63

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文

6.2.3.1 試験計画書は，試験を実行するハードウェア及びソフトウェアの構成を明示しなければならない。
6.2.3.2 製品説明に記述されている適用の全構成に対してソフトウェアを試験しなければならない。
注記構成が同等である実証は，使用することができる。
6.2.3.3 試験計画書は，試験項目の実行に必要なツールを識別しなければならない。

3.3.4 試験活動の管理項目
試験活動の管理項目は直接的な審査の対象とはなりませんが、試験を実施した裏付けとなります。試験計
画に含めるべき必須項目と任意項目を下表にまとめます。
必須項目

 日程

マイルストン
任意項目

 コスト

作業工程
 資源

人的資源
物的資源
 審査基準 試験活動の計画に対する上記表の項目が記載されていること。

 試験活動の工程やマイルストンの粒度については特に定められていません。しかし、一般的な試験工程を想定した場合、マイルストンについては下記のように記載されていることが望ましいと言えます。
-製品の発売日に関するもの
バージョンのリリース日（ソフトウェア開発完了日、パッケージ製造開始日、発売日）-試験活動に関するもの(試験がレベル付けされている場合は、それぞれの試験活動に関するものを記載する)-開始日、完了日が記載されるべきもの
テスト計画
テスト設計
テスト実行
-開発の活動に関するもの
開始日、完了日が記載されるべきもの
要件定義
開発設計

 原文

6.2.4 日程
6.2.4.1 試験計画書は，各試験活動及び試験のマイルストンの日程を明記しなければならない。

64

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.4 試験説明に対する審査基準
提出が必要な試験文書のうち、ここでは試験説明に関しての説明を行います。以下、試験説明に記載する
項目を解説します。

3.4.1 試験項目
試験説明に記載する試験項目には以下のようなものが考えられます。
 試験項目の識別

試験項目を細分化したら、試験項目の最小単位ごとに一意の識別子を付与する必要があります。識別子は一連の試験活動で継続的に使用され、関連する不具合が発生した場合や試験実施報告を行う場合に、行った項目名を報告する際など、さまざまな箇所で使われます。
 試験項目の目的

製品説明や利用者用文書の記載項目、および品質要求事項の各項目が、試験計画書にある各試験項目の目
的となります。試験の目的と関連する試験の観点についても並行して記載することにより、試験の方向性を明確に示すことが可能になります。
 一意の識別子

各試験項目を正しく識別するため、他の項目と重複しないようにユニークな識別子を付与する必要があり
ます。
機能テスト












機能A-1-1
機能A-1-2
機能A-1-3
機能A-1-2
機能A-2-1
機能A-2-2
機能A-3-1
機能A-4-1
機能A-4-2
機能B
機能C

 試験における、入力データおよび試験の範囲や境界試験で使用する試験手順に関連する試験で入力データや入力条件などを定義します。これらは複数の試験項目で使用されることもあるので、試験項目と入力データは１対１ではなく、１対多であってもよいものとします。試験の境界を明示することで入力データに制限が生まれ、それによりテストの範囲が明確になります。試験の観点を考えた場合、正常系や異常系など、どのような観点を主眼に置いた試験を実施する
かによって試験の境界に変化が生まれ、試験の目的に相応しい入力条件の設計を行うことができます。

 テキストボックスへの入力を試験する場合、実際に入力する文字などを入力条件として定義します。
 試験結果を得るために必要な、一つひとつの試験手順

試験を実行し、予期された結果を得るための詳細な手順が定義されます。使用するデータを入力するための適切な手順や前提条件に即した入力など、適切に定義されている必要があります（詳しくは3.4.2で説明
します）
。

65

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 期待される出力結果

試験実施者が手順通りに試験を進めた結果、システムがどのような出力を行うかを定義します。試験計画書において、製品説明や品質特性に記載された内容を目的として定義しますので、それらに適した結果を定義する必要があります。3.3.3で説明した通り、正確な出力を行うためにはモニタリング装置などを使用
して試験結果を確認する事が必要な場合もあります。
 結果を解釈するための基準、結果が良いか悪いかを判断するための基準

各試験項目の終了基準、結果を比較する場合の指針、結果を解釈するための方法、得られた結果の合否など、試験実施者が明確に判断できるような客観的な基準がなければいけません。もし試験結果の評価で属人的な判断が必要となる場合は、試験結果を解釈するための基準を設ける必要があります。試験計画に基づき、他の環境や試験の条件などが比較対象になります。必要があれば、他の試験項目に関する情報を記載する方がよいでしょう。

確実に試験を実施するために試験説明では、試験実施者が確実に試験を実施できるように配慮しましょう。
例えば継続的な作業が発生する状況で試験を実施しなくてはならない場合、試験実施者はいつからい
つまでの期間で試験を実施すべきか判断に迷うかもしれません。そこで試験実行管理者は試験実施者
がどういった期間で試験を行うべきか、試験実施者に明示しておく必要があります。
別の例を挙げます。例えば出力画面の色合いを確認するなど、定量的な判断の基準がなく、合否判断が難しい試験があるとします。このような場合、試験結果の良い場合と悪い場合の見本をあらかじめ提示しておくのも1つの方法です。
このように試験説明では、試験実施者が客観的な評価ができるように、可能な限り客観的な試験項目の合否判定基準を定義しておきましょう。

 審査基準 試験説明で下記の項目が記載されていること。


一意の識別子

試験項目の目的

試験に対する入力データおよび試験の境界

試験実行のための詳細な実行手順

期待結果となる出力



結果を解釈するための基準、結果が良いか悪いかを判断するための基準(任意項目)必要に応じ、試験計画に対する追加情報が記載されていること。

 原文

6.3.1 試験項目説明
6.3.1.1 個々の試験項目の記述は，次を含まなければならない。
a) 試験の目的b) 一意の識別子c) 試験に対する，入力データ及び試験の境界d) 実行のための詳細手順e) 予期されたシステムの振る舞いf) 試験項目からの予期された出力g) 結果を解釈するための基準h) 試験項目の結果がよいか悪いかを決めるための基準

66

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

6.3.1.2.試験計画書に示されている環境および他の試験条件に比較して、追加情報を提示することが必要な場合、環境及び他の試験条件（詳細な構成及び準備作業）を記述することが望ましい。

3.4.2 試験手順
試験手順には、必ず下記の項目を含める必要があります。これらが満足に準備されてはじめて、試験の開始が可能になります。試験手順では正確な結果を得るための手順が記載されている必要があります。
 試験の事前準備

試験の事前準備には、ソフトウェアをどのような状態にすれば試験開始が可能になるかを明記します。誰が見てもわかるよう、客観的な判断基準が必要です。例えばパッケージソフトウェアのテストを行う場合
なら、準備すべき環境構成を明記する、「パッケージソフトウェアを起動して画面Aを開いておく」と指示するなど、試験開始前にどのような状態にしておかなければいけないのかを明記する必要があります。
 試験の開始と実行手順

試験実施者が試験を開始し、予期された期待結果を得るためにはどのような手順で試験を進めていけばよ
いかを説明します。まず反復性や再現性を確実にするために、誰が見ても同じ手順で試験を進められるよう客観的に明記する必要があります。例えば試験実施者が試験対象を熟知していたため、試験手順をアウ
トラインしか作成せずに試験に臨んでしまったとします。試験手順で詳細な記述を疎かにしてしまったがゆえに、正確な試験結果が得られなかったといったことも起こりえます。なお試験手順には前提条件や期待される結果も含まれます。
 試験結果の取得と記録

試験実施者は試験手順で明記した期待結果と比較し、試験結果が正しいかどうかを判断した後、その結果を記録します。この一連の作業で必要な手順を明記します。
例：結果が表示された画面のスクリーンショットを保存する方法や、試験手順を進めたデータログを保存する方法 中止・再開条件

意図せぬ環境不備などにより試験の継続が不可能になってしまった場合を想定し、試験を中止する基準と再開できる基準、およびその手順を明記します。
不具合により試験を中止し、不具合の修正後に再試験を行う場合、通常の試験とは違い、関連する機能の試験なども併せて行うこともあります。中止後の再試験など通常と手順が変わる場合には、その手順も明記する必要があります。
試験実行をツールなどで自動化して行う場合もあります。その際、試験手順は自然言語ではなくスクリプ
トを使用することがあります。
例：中止となる基準 - 試験項目1〜30までで、重要度の高い不具合が20件以上発見された場合再開できる基準 - 20件以上発見された不具合が全て修正された場合

 審査基準 個々の試験手順に下記が含まれていること。


試験の事前準備

試験の開始と実行手順



試験結果の取得と記録

67

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文

6.3.2.1 試験手順は，次を含まなければならない。
a) 試験準備b) 試験を開始し，実行するために必要な行為c) 試験結果を記録するために必要な行為d) 試験を中止し，その後再開するための，条件及び行為

3.4.3 再試験
再試験について詳しく説明します。再試験については本節の「3.5.3再試験」も参照してください。
 試験手順の反復性試験によっては何回も繰り返されるものもあり、試験実施者が変更になる場合もあります。担当者が変わっても同じ手順で試験が行えるように、試験の手順は詳細に記述しなければいけません。また試験を実施している最中に不具合が発生した場合、同じ不具合を再現させることができるように、不具合を再現するために必要な試験手順を明記しておく必要があります。
 不具合修正後の確認試験で発見された不具合が開発者によって修正されたら、試験実施者は不具合が再現するかどうか試すことで、不具合が正しく修正されているかを確認します。その際、関連する機能に関してどのように試験手順を進めていけばよいか、あらかじめ関連機能の再試験手順を用意しなければなりません。
 審査基準 試験手順は再現性、反復性を考慮し、十分詳細に記載すること。
 不具合修正後に、関連する機能について再試験を行う手順が記載されていること。
 原文

6.3.2.2 試験手順は，試験の反復性及び再現性に備えるために十分詳細でなければならない。
6.3.2.3 修正に続いて，関係する機能及び関連する機能を再試験する手順がなければならない。
注記試験手順を記述するために，擬似言語又はコマンド言語を使用してもよい。

68

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

3.5 試験結果に対する審査基準
提出が必要な試験文書のうち、ここでは試験結果に関しての説明を行います。試験結果は試験計画に基づいて作成された試験項目に対し、どのような結果が得られたのかを確認するための文書です。順にそれぞれの文書について解説します。
試験結果は3種類の事項で構成されます。
 試験実施報告
 不具合報告 総合評価3.5.1 試験実施報告
ここでは試験実施報告について説明します。試験実施報告はその名前の通り、試験活動の実施内容を報告するための事項で、下記の項目が含まれています。
 全体として必要とされる項目

全体概要

試験実施報告書には、試験で実施した項目の全体概要を含める必要があります。原則としては試験計画に試験対象となる項目が明記されているので、実施して得られた結果を忠実に明記し報告書として作成する必要があります。

 個々の試験項目に対して記述が必要とされる項目

認証を得るためには、試験計画で定義された試験対象に対し、個々の試験項目でどのような結果を得られたかが重要な要素となります。個々の試験項目に対し、下記の項目を記載し、試験結果として報告する必要があります。

試験項目の識別子

試験説明の中で定義された、試験項目の識別子を正しく明記します。

試験実施日

試験を実施した日付を明記します。試験実施中にパッケージソフトウェアがバージョンアップされた場合、試験実施者が試験した日付を基に試験で使われたパッケージソフトウェアのバージョンを特定することもあります。

試験を実行した人の氏名

試験実施者の氏名を明記します。それにより試験実施の責任が生まれ、問および職務題が発生した際の状況確認などを行うことができます。

発見された不具合の一覧

不具合が発見された場合、該当する不具合の識別子を明記します。

個々の不具合について、発見された不具合と、該当する不具合報告書の統合管理を行います

対応する不具合報告書への参照

69

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 審査基準 試験実施報告書には、全体概要が含まれていること。
 試験実施報告書には、全ての試験項目が試験計画書に従って実行されたことが実証されていること。
 個々の試験項目に対し、下記が含まれていること。


試験項目の識別子



試験実施日



試験実施者



発見された不具合の一覧と、対応する不具合報告書への参照項目

 原文

6.4.1 試験実施報告書
6.4.1.1 試験実施報告書は，試験項目の結果の全体概要を含まなければならない。
6.4.1.2 試験実施報告書は，全ての試験項目が試験計画書に従って実行されたことを実証しなければならない。
6.4.1.3 個々の試験項目に対して，試験実施報告書は，次を含まなければならない。
a) 試験項目の識別子b) 試験実施日c) 試験を実行した人の氏名及び職務d) 発見された不具合の一覧e) 個々の不具合について，対応する不具合報告書への参照

3.5.2 不具合報告
試験実施者が不具合を発見した場合、試験説明の不備や試験実施の人為的不備でないかを確認した後に不具合報告を作成します。不具合報告は不具合に対して1件ずつ作成される事項です。
 不具合報告書に含まれるもの

全体概要

不具合のタイトルに当たります。開発者や他の試験実施者などこの不具合に関係する作業者にとって容易に理解できるよう、簡潔な概要にすることが望ましいです。

 個々の不具合報告に対して記述が必要とされる項目

不具合の識別子

不具合の番号を明記します。不具合管理ツールによっては自動的に付与されることもあります。

不具合の記述不具合の詳細項目を記載します。関連する試験項目があれば、そこで記述されている内容と整合化を図る必要があります。
 環境
 条件
 手順
 詳細な不具合の状況
 本来取得すべき期待結果

不具合が発生した試験項目の箇所

該当する試験項目が存在する場合は、その該当識別子を明記します。

70

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

不具合の性質一般的に下記のような性質評価があります。
発見された不具合がソフトウェアに対し相対的にどの程度の重要性があったかを測るための指標です。
例）（任意項目）優先度

重要度が高い– Critical,

重要度が中程度– Major

重要度が低い– Minor

発見された不具合のソフトウェア開発に対する優先度です。
不具合によっては試験を中止しなければいけない場合など、作業を優先す
るものは優先度を高く設定する場合があります。

不具合の修正内容

開発者が不具合を修正した場合、不具合報告に基づいて修正を行ったことを実証する必要があります。修正に関する記述を行うためには、下記のような項目が含まれている必要があります。

修正の識別子どの修正であったかを識別するための識別子を明記します。

修正日

不具合が修正された日を明記します。

修正者の名前

修正者の名前を明記することにより、役割と責任を明確にすることができます。

修正に対する改良の識別子

修正したことにより製品仕様を改良した場合は、その改良した内容を正しく紐付けるために、改良に関する識別子を明記します。

予想される修正の影響修正したことにより、他の機能などへの影響が考えられる場合は、その内容を明記します。内容によっては追加となる試験の発生なども考えられます。

修正者の記述しうるコメント

修正した内容や必要事項、備考をコメントします。

 審査基準 不具合報告は全体概要が含まれており、必要に応じて修正内容、再試験時の結果が含まれていること。
 個々の不具合報告に対し、下記が含まれていること。


不具合の識別子

ソフトウェアの識別子



不具合の記述

不具合が発生した試験項目の箇所



不具合の性質

不具合の修正内容

71

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 原文

6.4.2 不具合報告書
6.4.2.1 不具合報告書は，発見された不具合の全体概要並びに，もしあるならば，修正及び再試験による検証を含まなければならない。
6.4.2.2 不具合報告書の説明部分は，各不具合について次を含まなければならない。
a) 不具合の識別子b) ソフトウェアの識別子c) 不具合の記述
d) 不具合が発生した試験項目の箇所
e) 不具合の性質
例この性質には，“中断”，“重大”，“軽微”などがあってもよい。
6.4.2.3 不具合報告書の修正記述部分は，発見された全ての不具合が修正されたことを実証しなければならない。
6.4.2.4 不具合報告書の修正記述部分は，各修正について次を含まなければならない。
a) 修正の識別子b) 修正日c) 修正者の氏名d) 修正に対応する改良の識別子e) 予想される修正の影響
f) 修正者の記述し得るコメント

3.5.3 再試験
試験実施者は不具合が修正された後に、不具合修正確認のための再試験を行う必要があります。これにより不具合が修正され、ソフトウェアの品質が向上されたことが証明されます。試験実施者は再試験で、修正された機能が製品説明や利用者用文書で定義された通りの動きをするということを確認します。再試験の試験結果には、下記の項目を含める必要があります。

検証の識別子試験実施者が再試験を行う際、検証活動をユニークなものにするために識別子を付与します。

検証日

試験実施者が検証した日を明記します。
これにより検証したバージョンに関する情報を合わせて取得することができます。

検証者の氏名

再試験を行った試験実施者の氏名を明記することにより、役割と責任が発生します。

検証に使用された試験項目

試験実施者が再試験を行う際、試験説明で定義された試験項目を使用した場合は、その試験項目の識別子、使用したデータなど、試験項目に関する情報を明記します。

検証結果

試験実施者が再試験を行った結果を明記します。意図した通りに不具合の修正がなされていない場合は再度開発者へ連絡し、対処を検討します。

72

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 審査基準 不具合に対し再試験が行われた場合は、試験結果に下記の事項が含まれていること。


検証の識別子

検証日

検証者の氏名

検証に使用された試験項目



検証結果

 原文

6.4.2.5 不具合報告書の再試験による検証の部分は，修正された全機能が利用者用文書に定義された振る舞いをすることを実証しなければならない。
6.4.2.6 不具合報告書の再試験による検証の部分は，各検証について次を含まなければならない。
a) 検証の識別子b) 検証日c) 検証者の氏名d) 検証に使用された試験項目e) 検証結果

3.5.4 試験結果の総合評価
試験実施者または責任者は、試験実施報告と不具合報告から試験結果の総合評価を実施します。3.3.2で説明した通り、ソフトウェアが利用者用文書や製品説明、品質要求事項に記載されている範囲で正しく動作すると判断された場合、ソフトウェアが利用者用文書や製品説明に記載された内容に適合していると決定されます。
 審査基準 試験実施報告書、不具合報告書から試験結果の総合評価が実施され、パッケージソフトウェアの適合性が評価されていること。
 原文

6.4.3 試験結果の総合評価
6.4.3.1 実施報告書及び不具合報告書の総合評価は，試験結果がソフトウェアの適合性を示すかどうかを決定するために使用される基準の範囲内で，全ての予期された振る舞いが得られたことを実証しなければならない。

73

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4 ソフトウェア品質に関する具体例
4.1 ソフトウェアの品質
本節では、ソフトウェアの品質特性ごとに実施すべき試験およびソフトウェアの利用時の品質について実施すべき試験について、具体例をあげて説明します。

4.1.1 ソフトウェアの品質特性について
ソフトウェアの品質は、以下の6つの品質特性に分類することができます。
 機能性
 信頼性
 使用性
 効率性
 保守性
 移植性

 ソフトウェアの品質特性についての詳細は、「Chapter4.1ソフトウェア品質特性」を参照してください。

4.1.2 審査におけるソフトウェア品質の位置付け
パッケージソフトウェア品質認証制度（Package Software Quality Certification 以下、PSQ認証制度と表記）では、ソフトウェアそのものは審査の対象としません。ソフトウェアの品質については、主に試験文書の審査、および製品説明・利用者用文書と試験文書間の整合性を確認することによって推定します。

<ソフトウェアの品質と試験文書の関連性>

74

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4.2 ソフトウェア品質の例
4.2.1 ソフトウェアの機能性の例
以下、ソフトウェアの機能性について具体例で説明します。
 インストール後にソフトウェアの動作確認ができること

利用者環境へのソフトウェアインストール完了後、正しく動作するかどうかを利用者が確認する手段が提供されている必要があります。
例： インストール後、動作確認用試験項目の実行
 上記試験項目に相当する、ソフトウェアの自己診断 利用者によるその他の試験の実行
インストール後の動作確認および自己診断の試験事例[インストールマニュアル上の記載]
本製品のインストール終了後、続いてインストール結果の自己診断が開始されます。
・自己診断が正常に終了した場合、「インストールが正常に終了しました」とのメッセージを表示します。
・自己診断で問題が確認された場合、「インストールが失敗しました」とのメッセージを表示します。
[試験での検証]
インストール後の自己診断について、製品説明に記載の手順でインストールを行い、自己診断が行われ、所定のメッセージが表示されることを目視で確認する。

 利用者用文書の内容はすべて実行できること

利用者用文書に記述されている機能は、与えられた制限の下で、すべて実行可能でなければなりません。

 「与えられえた制限の下ですべて実行可能でなければなりません」とは、利用者用文書に記載した機能実行に制限事項がある場合、その制限が明記されており、かつ、その制限の範囲内では実行に問題がないことを意味します。これらは、原則として開発中の試験で検証してあることが必要です。

制限事項の例・ファイル名に次の文字が使われている場合は、メールの添付ファイルとして利用できません。
¥ / : * ? < > | & ‘ % ソフトウェアが利用者用文書の記載通りに使えること

ソフトウェアの機能は、すべて利用者用文書の記述通りに実行可能でなければなりません。
利用者用文書には、規制機関による要求事項を含む場合があります。その場合、ソフトウェアは、製品説
明に記載している機能の検証だけでなく、当該要求事項への適合性の検証もされている必要があります。
規制機関による要求事項の例
・会計ソフトなどの会計に関する法律による制限
・給与計算における保険料率改定など

75

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 機能の正確性を検証していること

ソフトウェアが提供する機能は同じ環境下、同じ条件下では常に同じ結果を返す必要があります。
また、製品説明と利用者用文書間で記述内容に不整合があると、どちらが正しい動作なのか判断がつかな
くなります。
 機能の一貫性を検証していること

利用者用文書で記述した利用者の操作制御と、実際のソフトウェアの振る舞いは一致している必要があり
ます。
 原文

JIS-X-25051：5.3.1機能性（5.3.1.1-5.3.1.6）

5.3.1.1 インストールに引き続いて、ソフトウェアが機能できるかどうかを認識できなければならない。
例）正常に機能することの検証は、提供されている試験項目の使用若しくは対応するメッセージを伴った自己試験または利用者が実行するその他の試験によって行うことができる。
5.3.1.2 利用者用文書に記述されている全機能は，対応する設備，特徴及びデータを使って実行可能でなければならない。また，与えられた制限の下で実行可能でなければならない。
5.3.1.3 ソフトウェアの機能は，利用者用文書の全ての記述のとおりに実行可能でなければならない。
5.3.1.4 ソフトウェアは，製品説明で参照している要求文書中の全要求事項に適合していなければならない。
5.3.1.5 ソフトウェアは，ソフトウェア自体で矛盾があってはならない。また，製品説明と利用者用文書とで矛盾があってはならない。
例 二つの同一の行為は，同じ結果を返さなければならない。
5.3.1.6 エンドユーザが利用者用文書に従って行うソフトウェア運用操作の制御と，ソフトウェアの振る舞いとは，一致していなければならない。

4.2.2 ソフトウェアの信頼性の例
以下、ソフトウェアの信頼性について具体例で説明します。
 エラー処理が記載内容と一致していること

利用者用文書にエラー処理に関する具体的な記載がある場合、それらが実際のソフトウェア動作と一致している必要があります。利用者用文書に記載がなければ、試験の必要はありません。
 データの保護が検証されていること利用者が利用者用文書に記載された動作環境や注意・制限事項を守り、システムを運用している状態で、データの破損や消去、異常値への書き換えがあってはなりません。

 以下に記すようなケースは注意・制限事項に違反すると考えてよいものとします。
－データ件数の制限が明記してあり、その制限値を超えてデータを登録した場合－連携、連動する他のソフトウェアから、異常データの入力があった場合－利用者の運用ミスや操作ミスによる誤ったデータの登録が行われた場合

 入力構文違反の検証ができていること

入力構文違反として検出された入力はエラーとする必要があります。
入力構文違反とは、入力データの型や桁数の違反、入力不可の文字種や文字列の混入、限界値を超えた数
値や文字などの入力を指します。ソフトウェアは入力の違反を検出する必要があります。また違反した入力値は受け付けないようにしなくてはなりません。

エラー例

76

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

エラー
入力された値は、郵便番号ではありません。

 原文JIS-X-25051：5.3.2 正確性（5.3.2.1-5.3.2.4）
5.3.2.1 ソフトウェアは，利用者用文書に定義された信頼性の特質に従って機能しなければならない。
5.3.2.2 エラー処理に関する機能は，製品説明及び利用者用文書の対応する記述と一致していなければならない。
注記 ソフトウェアは，オペレーティングシステム又はネットワークに起因する多くの種類の故障に対して責任をもつことはできない。
5.3.2.3 ソフトウェアは，利用者用文書に記述してある制限下で使用した場合，データを喪失してはならない。
注記 この要求事項は，次の場合に当てはめてよい。
－ 規定された制限まで容量が使用された場合－ 規定された制限を超えて容量を使用する試みが実行された場合－ エンドユーザ又は製品説明に記述されている他のソフトウェアが不適切な入力を行った場合－ 利用者用文書に明記してある指示に違反した場合
5.3.2.4 ソフトウェアは，入力の入力構文違反を検知しなければならない。また，これらのエラー入力を許容された入力として処理してはならない。

4.2.3 ソフトウェアの使用性の例
使用性とは一般的にはユーザビリティとも言われています。
以下、ソフトウェアの使用性について具体例で説明します。
 メッセージが理解可能であること

ソフトウェアの操作中に表示されるメッセージ類（選択ダイアログボックス、警告メッセージ、処理結果の表示内容）は、利用者にとって理解しやすい内容である必要があります。
ソフトウェアからのメッセージを理解しやすくするためには、以下の配慮が必要です。
 用語が適切であること
 ソフトウェアの使用に関する背景を説明していること
 適切な画像を用いて示していること 表示位置が分かりやすく、読みやすいサイズであること
 音声メッセージなら、音量・音質が聞き取りやすいこと
 メッセージの種別（致命的なエラー、警告、通知など）が分かりやすいこと

以下にメッセージのサンプルを示します。

<入力値違反のエラー例>

77

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック<処理中断を伝えるメッセージ例>

 利用者がエラーに対処できること

ソフトウェアは利用者がソフトウェア実行中に直面したエラーや警告を回避する方法、またエラーの発生を報告する連絡先を示す必要があります。エラーを回避するための情報は、利用者用文書で説明した個所を明示したものでもよいものとします。

 警告が必要な例

復元不可能なデータの削除やシステムに異常をもたらすなど、重大な結果を引き起こす操作があるならば、実行前に警告メッセージを表示する必要があります。明確に分かる警告メッセージにして利用者に伝え、あらためて実行するかどうか確認できるようにしなければなりません。
重大な結果の例としては次のようなものがあります。
 ソフトウェアが操作不能になり、回復に多くの時間を必要とする。
 ソフトウェア実行に必要なデータが削除され、ソフトウェアが実行できなくなる。
 データが上書きされ、元のデータが復元できなくなる。

<顧客データの削除に関する警告メッセージ例>

 通知が必要な例

ソフトウェアの処理時間が長くなる場合には利用者に通知する必要があります。利用者が「これほど処理時間がかかるのは正常な動作ではない」と疑う可能性がある場合などです。あらかじめ処理に相当な時間のかかる場合には、アラート機能などで知らせておかなくてはなりません。

78

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 ヘルプを参照できること

ソフトウェアが提供する機能の使用方法は、ユーザインタフェースやヘルプ機能、あるいは操作マニュア
ルなどの文書で提供されていて、利用者が使い方を習得できるようにする必要があります。

 製品識別を付与すること

ソフトウェアの要素、つまりデータ媒体やソフトウェア製品の提供媒体については、媒体の形式についての説明が必要です。媒体が複数の場合は識別番号か識別文が必要です。
 原文

JIS-X-25051：5.3.3 使用性（5.3.3.1-5.3.3.9）
5.3.3.1 ソフトウェアの実行によって生じた質問，メッセージ及び結果は，理解可能でなければならない。
例 理解性は，次のことで達成できる。
－ 適切な用語の選択－ 図示－ 背景情報の提供－ ヘルプ機能による説明
注記 使用性に関して，この規格に基づいて合意している組織には，JIS Z 8511 シリーズの最新版の適用の可能性を検討することを薦める。特に，ISO 9241 シリーズの第1 部，第2 部，第10 部～第17 部及びISO/IEC 25062 を考慮することが望ましい。
5.3.3.2 ソフトウェアエラーメッセージは，エラーの修正方法又はエラーの報告先を示さなければならない。
例 この情報は，利用者用文書の項目への参照となることができる。
5.3.3.3 ソフトウェアは，エンドユーザが理解しやすい形で情報を提供しなければならない。例えば，文章又は図の出力は見やすく読みやすい形で，音声出力は聞きやすい形で提供する。
5.3.3.4 ソフトウェアからのメッセージは，そのメッセージの種別をエンドユーザが容易に理解できるように設計していなけ
ればならない。
例 これらのメッセージには，次のものがある。
－ 受取り通知－ ソフトウェアからの問合せ－ 警告－ エラーメッセージ
5.3.3.5 入力画面の様式，報告書及びその他の出力は，利用者にとって明確で理解しやすいものでなければならない。
5.3.3.6 重大な結果を引き起こす機能の実行は，取り消すことができなければならない。また，コマンド実行前に，ソフトウ
ェアは，結果について明確な警告を発して，再確認の要求をしなければならない。
例 長時間にわたる処理操作の中断と同様に，データの消去及び上書きは，重大な結果を起こす。
5.3.3.7 エンドユーザは，ユーザインタフェース，ヘルプ機能又は利用者用文書によって提供される方法で，機能の使い方を学ぶことができなければならない。
5.3.3.8 エンドユーザが実行しようとする機能に対する応答時間が一般的な予期される許容限界を超える場合，エンドユ
ーザにその旨を通知しなければならない。
5.3.3.9 個々の要素（データ媒体，ファイルなど）は，製品識別を付けなければならない。また，二つ以上ある場合は，識別番号又は識別文を付けなければならない。

4.2.4 ソフトウェアの効率性の例

以下、ソフトウェアの効率性について具体例で説明します。
 製品説明内の記載と適合していること

例えば、製品説明に記載されている最低動作環境でソフトウェアが動作すれば、ソフトウェアは製品説明内の記載と適合していると言えます。また、製品説明で「何秒で表示される」など具体的な待ち時間に関する記載がある場合には、試験で確認する必要があります。

79

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

製品説明内の効率性に関する記述例
動作環境
Windows 7
CPU Core i7
Memory 2GByte 以上搭載

 原文

JIS-X-25051：5.3.4 効率性（5.3.4.1）
5.3.4.1 ソフトウェア製品は，製品説明の中の効率性に関する記述に適合しなければならない。
例 応答待ち時間が常軌を逸する場合には，エンドユーザにメッセージを出す。

4.2.5 ソフトウェアの保守性の例

以下、ソフトウェアの保守性について具体例で説明します。
 製品説明内の記載と適合していること

例えば製品説明でソフトウェアが「アドオンを追加することで追加機能を提供する」といった記載がある
場合には、アドオンの追加で機能が追加できることを試験で確認する必要があります。

製品説明内の保守性に関する記述例
ニーズに合わせて追加アドオンを選択し、自由にカスタマイズできます。

 原文

JIS-X-25051：5.3.5 保守性（5.3.5.1）
5.3.5.1 ソフトウェア製品は，製品説明の中の保守性に関する記述に適合しなければならない。
例 不良に対する診断機能，改良可能機能など

4.2.6 ソフトウェアの移植性の例
以下、ソフトウェアの移植性について具体例で説明します。
 インストール可能であることを検証する

製品説明に記載した動作環境でインストールが可能かどうか、試験で確認する必要があります。また、インストールの説明書がある場合には、手順に従って実行することで正常にインストールが完了することを確認する必要があります。
 既存ソフトウェアとの競合に対し通知する

ソフトウェアのインストールで制限が見込まれるような場合には、利用者にあらかじめ通知しておく必要があります。例えばソフトウェアをインストールしようとする環境に、すでに別のソフトウェアがインストールされており、この影響で一部の機能が利用できなくなるといった場合です。
より具体的な例として、ソフトウェアが特定のポート番号を使用する製品だと仮定します。インストール
時にソフトウェアが使用するポート番号が他のソフトウェアで使用されているかどうか確認し、それが使用されていれば利用者に警告メッセージを表示するなどの対策が必要になります。

80

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック<既存ソフトウェアとの競合に関するメッセージの例> アンインストール手段の提供

ソフトウェアはインストールしたソフトウェアを削除する、またはアンインストールする手段を提供する必要があります。
 原文JIS-X-25051：5.3.6 移植性（5.3.6.1）
5.3.6.1 利用者がインストールを実行できる場合，ソフトウェアは，インストール文書の情報に従って正常にインストールできなければならない。
5.3.6.2 製品説明に一覧表記されている全ての使用可能なプラットフォーム及びシステムに対して，ソフトウェアが正常にインストールされ，かつ，正しく運用操作できることが検証されなければならない。
5.3.6.3 利用者がインストールを実行でき，かつ，ソフトウェアがインストール済みの構成要素との共存に制限がある場
合，そのことをインストール実行前に提示しなければならない。
5.3.6.4 ソフトウェアは，利用者に対してそのソフトウェアのインストール済みの全構成要素の削除又はアンインストールを行う手段を提供しなければならない。

4.2.7 ソフトウェアの利用時の品質の例
以下、ソフトウェアの利用時の品質について具体例で説明します。

 利用時の品質に関する記述にソフトウェアが適合していることを検証する

製品説明に利用時の品質について記述がある場合には、ソフトウェアがその記述に適合していることが検証されている必要があります。
製品説明内の利用時の品質に関する記述例
SLA
月間稼働率
99.99 % を保証します。
障害通知の保証
弊社が障害を検出後、30分以内に指定連絡先に通知することを保証します。

 原文JIS-X-25051：5.3.7 利用時の品質（5.3.7.1）
5.3.7.1 ソフトウェア製品は，製品説明の中の利用時の品質に関する記述に適合しなければならない。

81

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

82

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

4 用語解説

4

用語解説

83

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1 ソフトウェア品質特性
1.1 ソフトウェア品質特性とはソフトウェア品質特性とは、ソフトウェア製品の品質として考えることができるソフトウェアの諸属性を体系的にまとめたものです。本書で「ソフトウェア品質特性」という時は、JIS X 25051が参照している規格であるJIS X 0129（ISO/IEC 9126）を指します。

 以下、日本国内での規格JIS X 0129を用います。
 JIS X 0129の詳細については、JIS X 25051：2011の巻末に記載された参考文献を参照してください。本書では、PSQ認証制度のための必要最小限の解説にとどめます。

 以下の解説で、品質特性・品質副特性、内部品質・外部品質といった用語や、個々の品質特性に関する説明は、
JIS X 0129を参考にしています。また、内部品質・外部品質の関係性を表す図は、JIS X 0129を参考にしています。

以下は、主にソフトウェアを開発する立場から記しています。
ソフトウェアはさまざまな側面から見ることができます。
例えば、そのソフトウェアが実行する機能という側面から見た例を以下に挙げます。
 データを登録する
 データを検索する
 帳票を印刷する

 ソフトウェアに対する機能面での要求事項を、「機能要求」と呼びます。
機能以外の側面から見ることもできます。個々の機能や、ソフトウェア製品全体に、機能以外の要求が付随することがあります。以下に例を挙げます。
 何件のデータの検索を何秒以内に完了すること。
 コンピュータのことを知らない利用者でも困難なく操作できること。
 不正なデータが送られたら警告メッセージを発すること。
 故障が生じた際に調査が容易であること。

 こうした、機能以外の要求事項を、「非機能要求」と呼びます。
ソフトウェアの品質を考える際には、機能要求の達成度合や、非機能要求の達成度合を考えるのが妥当でしょう。以下に例を挙げます。
 利用者が望む機能がちゃんと実現されているか。
 機能は利用者が使いたいと思っている目的にかなっているか。
 機能の実行を妨げるバグが残っていないか。
 コンピュータのことを知らない利用者が困難なく操作できるようになっているか。
 データの検索は所定の時間内に完了するか。

ここで注意しなければならないことがあります。

84

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

ひとつは、ソフトウェアに対する非機能要求にはさまざまなものを挙げることができます。個々の要求事項を列挙するだけでは、ソフトウェアの開発が困難になる可能性があります。
また、個々の要求事項を互いに関係のない事項として扱うと、ソフトウェア製品全体としての品質の達成が困難になる可能性があります。
これらを整理して考える手がかりになるのがソフトウェア品質特性という考え方です。
ソフトウェアに対する要求事項をソフトウェア品質特性に照らして考えることで、「このソフトウェア製品が達成すべき品質は何か」を明確にすることが容易になります。また、本書では解説しませんが、品質目標や目標値の明確化も容易になります。
JIS X 0129の特徴を以下に記します。
 ソフトウェアの品質を、内部品質と外部品質との両面で捉えている。


内部品質（ソフトウェア製品を作る過程の中間成果物（ソースコードを含む）から測定される品質）

外部品質（ソフトウェア製品自体をある環境で動作させて測定される品質）

 ソフトウェア品質を階層構造で整理している（品質特性と品質副特性）。
 ソフトウェアが実際に使われている状況における品質を考慮している（利用時の品質）。

<ソフトウェア品質特性の関係図>

85

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.2 内部品質と外部品質
内部品質（internal quality）とは、ソフトウェア開発工程の各（中間）成果物から測定される品質を指します。JIS X 0129では次のように述べられています。
特定の条件下で使用される場合に、明示的及び暗示的必要性を満たす製品の能力を決定する製品の属性の全体

外部品質（external quality）とは、ソフトウェア製品自体の品質（ソフトウェア製品をある環境で動作させて測定される品質）を指します。JIS X 0129では次のように述べられています。
製品が指定された条件下で利用された場合に、明示的及び暗示的必要性を満足させる程度

例えば、Xというソフトウェア製品で、「機能AはYという条件下でZ秒以内に実行を完了する」という要求や（後述の「効率性：時間効率性」に該当します）、「コンピュータに不慣れな利用者でも1日以内に操作を憶えられる」という要求（後述の「使用性：習得性」に該当します）があったとします。実際にXという製品（最終的な実装成果物）の振舞いがこれらの要求を満たしているかどうかが外部品質です。
では、これらの要求だけから一足飛びに、目標とする処理速度を達成したり、憶えやすい操作を実現した
りする最終的な実装成果物を作成できるでしょうか。恐らく非常な困難を伴うことでしょう。一般的に、こうした要求を満たすためには適切な仕様と適切な設計（ユーザインタフェース、ソフトウェア構造、データ構造、モジュール間インタフェースなど）が必要です。設計段階から達成すべき品質を念頭に置いていれば、品質を達成しやすくなります。仕様書や設計書などのいわゆる中間成果物を作成する理由のひとつがここにあります。
そのため、中間成果物においてもソフトウェア製品の達成すべき品質を考慮していることが重要になります。ここが内部品質にかかわります。
内部品質と外部品質の関係を下図に示します。

<内部品質、外部品質、利用時の品質が持つ関係性>

PSQ認証制度の基準では、内部品質は審査対象としていません。
本基準が参照するJIS X 25051では次のように述べられており、仕様書や設計書といった中間成果物は審査の対象外となります。
1 適用範囲（中略）
この規格は、COTSソフトウェア製品が提案され、納入された通りに、機能するという信頼を利用者に与えることだけを扱っている（例えば、仕様書のような中間生成物及び活動を含む）生産プロセスには対応していない。供給者の品質システムは、この企画の適用範囲外である。

86

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

 本節では、この後の節で説明する品質特性、品質副特性とも外部品質・内部品質双方に関係すること、外部品質だけ解説しても理解が不十分になることなどの懸念があるため、内部品質も合わせて述べました。

1.3 ソフトウェア品質特性の階層構造
ソフトウェア品質特性とは、ソフトウェア品質の主要な側面を捉えたものです。品質特性の下に、詳細な側面としての品質副特性が含まれます。

<対象となる内部品質、外部品質質が有する特性の関係図>

ソフトウェア品質特性には6つの特性があります。
機能性ソフトウェアが、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力（JIS原文）。
ソフトウェアが提供する機能やサービスそのものにかかわる品質を指します。
品質副特性として以下の5つがあります： 合目的性、正確性、相互運用性、セキュリティ、機能性標準適合性

信頼性指定された条件下で利用するとき、指定された達成水準を維持するソフト
ウェア製品の能力（JIS原文）。
故障の生じにくさ、故障や誤操作・誤入力への耐性といった観点からの品質を指します。
品質副特性として以下の4つがあります： 成熟性、障害許容性、回復性、信頼性標準適合性

使用性指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力（JIS原文）。
利用者にとっての使いやすさ、理解しやすさ、憶えやすさという観点からの品質を指します。
品質副特性として以下の5つがあります： 理解性、習得性、運用性、魅力性、使用性標準適合性

87

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

効率性

明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力（JIS原文）。
処理速度や応答時間（いわゆる性能）、あるいはコンピュータの資源の使用効率という観点からの品質を指します。
品質副特性として以下の3つがあります： 時間効率性、資源効率性、効率性標準適合性

保守性

修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、又は環境の変化、要求仕様の変更及び機能仕様の変更にソフトウェア
を適応させることを含めてもよい（JIS原文）。
故障の原因調査や修正箇所の特定のしやすさ、要求や仕様の変更に対応
する変更作業のしやすさといった観点からの品質を指します。
品質副特性として以下の5つがあります： 解析性、変更性、安定性、試験性、保守性標準適合性

移植性ある環境から他の環境に移すためのソフトウェア製品の能力（JIS原文）。
ソフトウェアを複数の環境・構成へ適応する・移行する、利用者が特定の環境へインストールする観点からの品質を指します。
品質副特性として以下の5つがあります： 環境適応性、設置性、共存性、置換性、移植性標準適合性

1.4 機能性の品質副特性
機能性の品質副特性を下図に示します。

<対象となるソフトウェア品質特性：機能性と副特性の関係図>

合目的性指定された作業及び利用者の具体的目標に対して適切な機能の集合を提供するソフトウェア製品の能力（JIS原文）。
利用者が要求している機能を十分に提供できるかどうかという観点からの品質を指します。

正確性必要とされる精度で、正しい結果若しくは正しい効果、又は同意できる結果
若しくは同意できる効果をもたらすソフトウェア製品の能力（JIS原文）。
入力や操作に対する出力や結果が正しいかどうか、また、出力や結果の数値の精度（桁数など）が期待通りかという観点からの品質を指します。

88

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

相互運用性

1つ以上の指定されたシステムと相互作用するソフトウェア製品の能力（JIS原文）。
当該ソフトウェアが想定する他ソフトウェアやシステムとのデータ交換や通信がどれだけ行えるかという観点からの品質を指します。

セキュリティ

許可されていない人又はシステムが情報又はデータを読んだり、修正した
りすることができないように、及び許可された人又はシステムが情報又はデータへのアクセスを拒否されないように、情報又はデータを保護するソフ
トウェア製品の能力（JIS原文）。
情報セキュリティにおけるいわゆるC.I.A.（機密性、完全性、可用性）にかかわる品質を指します。

機能性標準適合性

機能性に関する規格、規約又は法律上及び類似の法規上の規則を遵守するソフトウェア製品の能力（JIS原文）。
機能性に関する規格、規約、法律上および類似の法規上の規則を遵守しているかどうかという観点からの品質を指します。

1.5 信頼性の品質副特性
信頼性の品質副特性を下図に示します。

<対象となるソフトウェア品質特性：信頼性と副特性の関係図 >成熟性

ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェ
ア製品の能力（JIS原文）。
潜在する欠陥数（欠陥密度）や除去した欠陥数といった観点からの品質を
指します。

障害許容性

ソフトウェアの障害部分を実行した場合、又は仕様化されたインタフェース
条件に違反が発生した場合に、指定された達成水準を維持するソフトウェ
ア製品の能力（JIS原文）。
ソフトウェア中の欠陥のある箇所を実行した場合や想定外の入力・操作・
環境条件などによる故障の発生しにくさ（暴走や異常終了を含む）、誤操作のしにくさといった観点からの品質を指します。

89

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

回復性

故障時に、指定された達成水準を再確立し、直接に影響を受けたデータを回復するソフトウェア製品の能力（JIS原文）。
故障発生時に速やかに復旧し、データなどを回復する能力。
平均復旧時間、データベースやトランザクションの復元性といった観点からの品質を指します。

信頼性標準適合性

信頼性に関する規格、規約又は規則を遵守するソフトウェア製品の能力（JIS原文）。
信頼性に関連する規格、規約、または規則を遵守しているかどうかという観点からの品質を指します。

1.6 使用性の品質副特性
使用性の品質副特性を下図に示します<対象となるソフトウェア品質特性：使用性と副特性の関係図>

理解性

ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、及びどのように利用できるかを利用者が理解できるソフトウェア製品の能力（JIS原文）。
利用者にソフトウェアが自分の用途にどのような条件でどのように利用できるかを、分かりやすく伝える能力ということです。
各機能のデモ、チュートリアルの閲覧のしやすさや効果、必要な機能の探しやすさ、機能やコマンドの理解しやすさ（間違えにくさ）など、ソフトウェアの分かりやすさにかかわる品質を指します。

習得性

ソフトウェアの適用を利用者が習得できるソフトウェア製品の能力（JIS原文）。
機能を習得するのにかかる時間、マニュアルやヘルプの読みやすさや有効性など、ソフトウェアの学びやすさ、覚えやすさにかかわる品質を指します。

運用性

利用者がソフトウェアの運用及び運用管理を行うことができるソフトウェア
製品の能力（JIS原文）。
操作やユーザインタフェースの一貫性、誤りの訂正のしやすさ、メッセージの分かりやすさ、カスタマイズのしやすさなど、ソフトウェアの操作や運用の90

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

簡易性にかかわる品質を指します。
魅力性

利用者にとって魅力的であるためのソフトウェア製品の能力（JIS原文）。
配色やデザインなどユーザインタフェースの魅力、ユーザインタフェースのカスタマイズのしやすさなどを指します。

使用性標準適合性

使用性に関連する規格、規約、スタイルガイド又は規則を遵守するソフトウ
ェア製品の能力（JIS原文）。
使用性に関連する規格、規約、スタイルガイド、規則を遵守しているかどうかという観点からの品質を指します。

1.7 効率性の品質副特性
効率性の副特性を下図に示します<対象となるソフトウェア品質特性：効率性と副特性の関係図>

時間効率性

明示的な条件の下で、ソフトウェアの機能を実行する際の、適切な応答時
間、処理時間及び処理能力を提供するソフトウェア製品の能力（JIS原文）。
応答時間、スループット（単位時間当たりの処理能力）、ターンアラウンド時
間（処理の実行を開始してから完了するまでにかかる時間）、待ち時間な
ど、速度や時間にかかわる品質を指します。

資源効率性

明示的な条件の下で、ソフトウェアの機能を実行する際の、資源の量及び資源の種類を適切に使用するソフトウェア製品の能力（JIS原文）。
メモリやディスクの使用量、ネットワークの占有率など、コンピュータの各種資源の使用度合にかかわる品質を指します。

効率性標準適合性

効率性に関連する規格又は規約を遵守するソフトウェア製品の能力（JIS原文）。
効率性に関連する規格または規約を遵守しているかどうかという観点からの品質を指します。

91

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.8 保守性の品質副特性
保守性の品質副特性を下図に示します<対象となるソフトウェア品質特性：保守性と副特性の関係図 >解析性

ソフトウェアにある欠陥の診断又は故障原因の追及、及びソフトウェアの修
正箇所の識別を行うためのソフトウェア製品の能力（JIS原文）。
イベントログやモニタからの障害原因の特定しやすさ、診断機能など、問題の調査解明のしやすさにかかわる品質を指します。

変更性指定された修正を行うことができるソフトウェア製品の能力（JIS原文）。
修正にかかる時間、修正による問題解決にかかる時間、修正自体の容易さ、パラメータ変更の容易さなど、ソフトウェアの変更・修正のしやすさにかかわる品質を指します。

安定性

ソフトウェアの修正による、予期せぬ影響を避けるソフトウェア製品の能力（JIS原文）。
変更・修正後に障害が発生する度合い、変更・修正の局所化による副作用（二次障害）の抑止など、変更・修正作業の安全性にかかわる品質を指し
ます。

試験性

修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力（JIS原文）。
保守作業後の確認しやすさ、障害解決後の再テストのやりやすさにかかわる品質を指します。

保守性標準適合性

保守性に関連する規格又は規約を遵守するソフトウェア製品の能力（JIS原文）。
保守性に関連する規格または規約を遵守しているかどうかという観点からの品質を指します。

92

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.9 移植性の品質副特性
移植性の品質副特性を下図に示します。

<対象となるソフトウェア品質特性：移植性と副特性の関係図>

環境適応性

ソフトウェアにあらかじめ用意された以外の付加的な作業又は手段なしに、指定された異なる環境にソフトウェアを適応させるためのソフトウェア製品の能力（JIS原文）。
想定された範囲内で、他のハードウェアやソフトウェア（コンピュータ、OS、
ネットワークなど）への適合性にかかわる品質を指します。

設置性指定された環境に設置するためのソフトウェア製品の能力（JIS原文）。
インストールのしやすさにかかわる品質を指します。

共存性

共通の資源を共有する共通の環境の中で、他の独立したソフトウェアと共存するためのソフトウェア製品の能力（JIS原文）。
当該製品以外のソフトウェアが共存する環境で、他のソフトウェアに干渉しない／されないという観点からの品質を指します。

置換性

同じ環境で、同じ目的のために、他の指定されたソフトウェア製品から置き換えて使用することができるソフトウェア製品の能力（JIS原文）。
置き換えるソフトウェアとのデータ互換性や機能互換性にかかわる品質を指します。

移植性標準適合性

移植性に関連する規格又は規約を遵守するソフトウェア製品の能力（JIS原文）。
移植性に関連する規格または規約を遵守しているかどうかという観点からの品質を指します。

93

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

1.10 利用時の品質と利用時の品質の特性
利用時の品質とは、ソフトウェア製品が「特定の環境および特定の利用状況で利用される時の、利用者の視点でのソフトウェア製品の品質」であり（JIS X 0129-1より引用）、さまざまなソフトウェア品質特性
が利用者に与える複合効果と考えられます。
JIS X 0129-1ではまた、利用時の品質は「ソフトウェア自身の特徴というよりも、ソフトウェアを含む環境における利用者の視点の品質」とあり、その測定・評価に当たっては「その環境の中でのソフトウェ
アを利用した結果から測定する」とされています。
利用時の品質にかかわる品質特性として、以下の4つが定義されています。これらの品質特性には品質副特性は定義されていません。

< 利用時の品質と品質特性 >有効性

利用者が指定された利用の状況で、正確かつ完全に、指定された目標を達成できるソフトウェア製品の能力（JIS原文）。
当該ソフトウェア製品を利用することで作業目的を達成できた割合、作業が完了した割合、エラーに遭遇した割合など、作業遂行上の有効性や充足性にかかわる品質を指します。

生産性

利用者が指定された利用の状況で、達成すべき有効性に対応して、適切な量の資源を使うことができるソフトウェア製品の能力（JIS原文）。
当該ソフトウェア製品を用いた場合に作業が完了するまでにかかる時間、作業効率など、いわゆる生産性にかかわる品質を指します。
なお、JIS原文にある「資源」とは、作業を完了するまでの時間、利用者の労力、材料または使用した費用を含めてよいとされます。

安全性

利用者が指定された利用の状況で、人、事業、ソフトウェア、財産又は環境への害に対して、容認できるリスクの水準を達成するためのソフトウェア製品の能力（JIS原文）。
当該ソフトウェア製品を利用することで利用者に健康や安全性の問題、経済的な損失がもたらされる可能性という観点からの品質を指します。

94

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

満足性指定された利用の状況で、利用者を満足させるソフトウェア製品の能力（JIS原文）。
当該ソフトウェア製品を利用することによる利用者の満足度合にかかわる品質（特定の機能に関する満足度も含む）を指します。
なお、満足性とは、製品を対話的に利用した時の利用者の反応を指します（対話的な利用の中には、製品の利用自体が含まれます）。

95

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

2 用語説明本書の内容に関連する用語の解説を、JIS-X-25051および『共通フレーム2007 第2版*』から引用して、以下に掲載しました。なお、(SLCP-JCF2007)と記した用語は『共通フレーム2007 第2版*』に掲載されたSLCP-JCF98からの引用です。
*注）独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編、『共通フレーム2007

第2版』

オーム社、平成21年、P.307～P.317

アーキテクチャ（architecture）
システムの境界（例えば、入力系、プロセッサ、ネットワークなど）に対して、それ以外から見た場合の概
念的あるいは論理的な属性又は構造。「方式」と訳される場合が多い（SLCP-JCF2007）。

ISO（International Organization for Standardization）
国際標準化機構のこと

IEC（International Electrotechnical Commission）
国際電気標準会議のこと

アクティビティ（activity）
プロセスの構成要素で相関の強いタスクをまとめたタスクの集合。例えば「開発プロセス」では、システムやソフトウェアの開発対象に対して、システム要件定義、システム方式設計などをいう（SLCP-JCF2007）。



アプリケーション（application）
データ処理の技術を適用して特定の目的を達成する仕事（SLCP-JCF2007）。



安全性（security）
情報システムの自然災害、不正アクセス及び破壊行為からの保護の度合（システム監査基準）。



アプリケーション管理機能（application administration function）
利用者が実行する、インストール、設定、アプリケーションのバックアップ、保守（パッチ及びアップグレード）及びプログラム削除を含む機能＜JIS-X-25051より＞。



インタフェース（interface）
二つの機能単位の間で共有される境界部分であって、機能に関するいろいろな特性、物理的相互持続特性、
信号交換特性、その他の適当な特性によって定義されるもの（JIS-X-0020-1992）。



受入れ（acceptance）
契約上の要求事項が満足していることを確認した状態（SLCP-JCF2007）。



受入れテスト（acceptance testing）
契約に基づいて行う発注要件と成果物の適合検査で、取得者と供給者が協議の上作成するテスト基準、テス
ト項目、テスト方法などを定めたテスト仕様書に基づいて実施する（SLCP-JCF2007）。

96

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

運用（operation）
コンピュータシステムを稼働して業務を円滑に遂行すること。システムの起動やシステムの終了、監視、ファイルメンテナンスなどが含まれる（SLCP-JCF2007）。



運用者（operator）
システムを運用する組織（SLCP-JCF2007）。



運用プロセス（operation process）
業務運用環境でコンピュータシステムを運用する組織のアクティビティやタスクからなる（SLCP-JCF2007）。



エンドユーザ（end user）
システムの結果から最終的な利益を得る人。

注記：エンドユーザは、ソフトウェア製品の専任の運用者又は公共の一員のような一時的な利用者でもよい（JIS X 25000:2010）。



開発（development）
システムやソフトウェアの設計、製造、テストなどを行うこと（SLCP-JCF2007）。



開発者（developer）
ソフトウェアライフサイクルプロセスを通して開発作業（要件提示、設計及び受入れテストを含む）を遂行する組織（SLCP-JCF2007）。



開発プロセス（development process）
システムやソフトウェアの開発を実行する組織のアクティビティやタスクからなる（SLCP-JCF2007）。



外部委託（subcontract）
他の契約者に対してシステム、ソフトウェア製品又はサービスの一部又はすべてを発注すること（SLCP-JCF2007）。



外部委託先（subcontractor）
システム、ソフトウェア製品又はサービスの一部又は全部を受注した組織（SLCP-JCF2007）。



環境（environment）
一般に使用環境のことを指す。開発時の環境は開発環境、運用時の環境は運用環境、保守時の環境は保守環
境などという。具体的には、ハードウェア、ソフトウェア、ツール、技法、標準、及び企画、要件定義、開発、運用、保守を行うための設備などを指す（SLCP-JCF2007）。



環境整備（infrastructure）
取得、供給、契約の変更管理、企画、要件定義、開発、運用、保守の各プロセスに対して、そのプロセスを実行するために要求される環境を確立すること（SLCP-JCF2007）。



監査（audit）
ソフトウェア製品及びその作成プロセスが要求事項を満足しているかどうか、権限を与えられたものが独立した立場で評価すること（JIS-X-0160-1996）。



監視（monitoring）
取得者又は第三者が、供給者の作業の状況とその結果を監視すること（SLCP-JCF2007）。



管理（management）
進ちょく（捗）、見積、組織、要因、リスク、品質、作業、環境整備などプロジェクトの円滑な遂行に必要なリソースを監視し制御すること（SLCP-JCF2007）。

97

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



管理プロセス（management process）
企画、要件定義、開発、運用、保守の各プロセスの実行を円滑に遂行するために必要な管理のアクティビテ
ィからなる（SLCP-JCF2007）。



企画（planning）
業務システムの構築に向けて環境分析、業務分析、及び計画立案などを行うこと（SLCP-JCF2007）。



企画プロセス（planning process）
コンピュータ・システムが関与する経営戦略、情報システム構想の立案などを行う組織のアクティビティやタスクからなる。システム構想の立案などシステム開発プロジェクトが結成される前の作業や業務分析、業
務設計等の作業を含んでいる（SLCP-JCF2007）。



危険性／リスク（risk）
システムの安全性やプロジェクトを取り巻く環境に対して起こり得る危険と、その結果起こり得る好ましくない事象の影響度合い（SLCP-JCF2007）。



基準線（ベースライン）（baseline）
構成品目がそのライフサイクル上の決められた時期に媒体に関係なく、正式に指定し確定された構成品目の正式版として認定されたもの（JIS-X-0160-1996）。



既製品（off-the-shelf product）
既に開発が終わり、そのままで又は少し手を加えて使用できる状態にある製品（JIS-X-0160-1996）。



機能（function）
ソフトウェアに実装されたアルゴリズム。これを使ってエンドユーザ又はソフトウェアは、課業の一部又は全部を実行することができる。
注記：機能は、エンドユーザから必ずしも呼出し可能である必要はない（例えば、自動データバックアップ
又はデータの退避）＜JIS-X-25051より＞。



規定要求事項（specified requirement）
要件（仕様）を満足しているとき、製品に対して、その仕様に準拠しており、そのターゲット環境で利用可
能であることに資格を与える基準又は条件の集合（SLCP-JCF2007）。



教育訓練（training）
要因の知識と技能を向上させるために、システムやソフトウェアに関わっている要因を研修させ、育成すること（SLCP-JCF2007）。



供給（supply）
取得者の要求に基づいてシステム、ソフトウェア製品又はサービスを提供すること（SLCP-JCF2007）。



供給者（supplier）
取得者と契約を交わし、その条項に基づいてシステム、ソフトウェア製品又はソフトウェアサービスを提供する組織。

注記1：“供給者”という用語は、受注者、製作者、販売者又は納入者と同義である。
注記2：取得者は、自組織の一部を供給者として指定する場合がある（JIS X 0160:1996）＜
JIS-X-25051より＞。



供給プロセス（supply process）
契約に基づいて業務システム、ソフトウェア製品、並びにサービスを提供する組織のアクティビティやタス
クからなる（SLCP-JCF2007）。

98

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



共同レビュー（joint review）
契約に従い、中間成果物に対し取得者と供給者が共同で行う作業レビュー。供給者がプロジェクトの作業内
容や進捗状況及び成果物を取得者に説明し、取得者に対して意見や同意を得ることなど（SLCP-JCF2007）。



業務システム（business system/application system）
大きく事務系、制御系、エンジニアリング系の3つのカテゴリに分けられる。ここでいう事務系とは、受発注管理、在庫管理、販売管理、人事や経理などの事務処理やOA用途のシステム。制御系とは、FA（Factory
Automation）などリアルタイムの信号処理が中心となるシステム。さらにエンジニアリング系とは、
CAD/CAM、CAE、研究開発などアルゴリズムが重要となるシステムをいう。また、業務システムには、それを構成する人間系、ソフトウェア系、及びハードウェア系が含まれる（SLCP-JCF2007）。



契約（contract）
ソフトウェアサービスの提供に関する、又はソフトウェア製品の提供、開発、製造、運用、保守に関する、
法的強制力のある二社間の合意。または、一つの組織の中で行われる同様の内部合意（JIS-X-0160-1996）。



結合テスト（integration testing）
供給者の成果物が要件（仕様）と一致していること及びターゲット環境で利用する準備ができていることを証明するためのテスト（SLCP-JCF2007）。



検証（verification）
規定要求事項が満たされていることを、客観的根拠の調査及び提出によって確認すること。
（備考1）設計及び開発における検討は、ある活動に対して規定要求事項に適合しているかどうかを確定するために、その活動結果に対して吟味を行うプロセスである。
（ 備 考 2 ） 検 証 済 と い う 用 語 は 、 検 証 さ れ た 状 態 を 示 す た め に 用 い る （ ISO8402-1994 ／JIS-X-0160-1996）。

合意（agreement）
業務上の関係を実行するための条件の定義（JIS-X-0160-1996）。



構成管理（configuration management）
システムあるいはプロジェクトを構成する各種の構成品目を定義し、その品目の変更内容を記録し、また品目の保管、取扱い、引き渡しなどを含めた管理を行うこと（SLCP-JCF2007）。



構成品目（configuration item）
決められた時点で実利用者が使用する機能を実現し、かつ全体構成の中で一意に識別できるものをいう（JIS-X-0160-2007）。



合否判定基準（pass/fail criteria）
ソフトウェア項目又はソフトウェア特質が試験に合格したか、又は不合格だったかを判断するために使用される判定規則（IEEE Std 829-1998）。＜JIS-X-25051より＞



効率性（efficiency）
情報システムの資源の活用及び費用対効果の度合い（システム監査基準）。

COTS ソフトウェア製品（Commercial Off-The-Shelf software product）
商用既製ソフトウェア製品は、市場のニーズに応じて定義され、商品として入手可能なソフトウェア製品であり、広範囲の一般利用者によって使用に適していることが明らかにされているもの。
注記1：COTS ソフトウェア製品には、次を含む。

 製品説明（全ての外装表示、データシート、ウェブサイト情報などを含む）
 利用者用文書（ソフトウェアのインストール及び使用に必要）
 コンピュータで処理できる媒体（ディスク、CD-ROM、インターネットからのダウンロードなど）に入っているソフトウェア

99

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

注記2：この定義は、JIS X 0133-4:2001 に変更を加えたものである。
注記3：ソフトウェアは、主にプログラム及びデータからなる。
注記４：この定義は、製品説明、利用者用文書及びソフトウェアにも適用する。これらは、別々の製造品目として生産され、支援されるものであるが、これらに対する典型的な商用料金及びライセンス料が不要なものにも適用する＜JIS-X-25051より＞。

サブシステム（sub-system）
システムを分割あるいは細分化することにより生成する二次的又は従属的な構成実態（SLCP-JCF2007）



支援（support）
システムやソフトウェアの企画、要件定義、開発、運用、保守を行う主作業とは別に派生する付帯的な作業。
文書作成、構成管理、品質保証などが相当する（SLCP-JCF2007）。



試験（test）
システム又は構成要素が規定の条件の下で実行される活動。結果は、観察又は記録される。評価は、システ
ム又は構成要素の幾つかの側面から実行される（IEEE Std 610.12-1990）。＜JIS-X-25051より＞



試験（testing）
規定の条件の下でシステム又は構成要素を操作し、結果の観察又は記録、及びシステム又は構成要素の幾つかの側面からの評価を行うプロセス（IEEE Std 610.12-1990）。＜JIS-X-25051より＞



試験環境（test environment）
試験項目を実行するのに必要なハードウェア及びソフトウェアの構成。＜JIS-X-25051より＞



試験項目（test case）
ある目的のために開発された、入力、実行条件及び予期された結果の一そろ（揃）い。例えば、あるプログ
ラムパスの実行、又は特定の要求事項への適合の検証。＜JIS-X-25051より＞



試験説明（testing description）
試験実行条件（すなわち、試験手順）の説明。＜JIS-X-25051より＞



試験計画書（test plan）
意図した試験活動の範囲、進め方、資源及び日程を記述した文書。

注記：この定義は、IEEE Std 610.12-1990 に変更を加えたものである。＜JIS-X-25051より＞



試験手順（test procedure）
与えられた試験項目に対する準備、実行及び結果を評価するための詳細な指示（IEEE Std 610.12-1990）。
＜JIS-X-25051より＞。



試験文書（test documentation）
試験活動に固有の文書の集合。＜JIS-X-25051より＞



試験目的（test objective）
規定の条件下で、要求された振る舞いと実際の振る舞いとを比較することで測定される、ソフトウェア特質の識別された集合。

注記：この定義は、IEEE Std 610.12-1990 に変更を加えたものである。＜JIS-X-25051より＞



システム（system）
一つ以上のプロセス、ハードウェア、ソフトウェア、設備及び人を統合化して、規定のニーズ又は目的を満たす能力を提供するまとまり（JIS-X-0160-1996）。

100

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



システム監査（system audit）
監査対象から独立かつ客観的立場のシステム監査人が情報システムを統合化して、規定のニーズ又は目的を満たす能力を提供するまとまり（JIS-X-0160-1996）。



システム監査人（system auditor）
次の知識及び能力を有し、システム監査に従事する者（システム監査基準）。
（1）情報システム監査の基本的知識（2）システム監査の知識（3）システム監査の実施能力（4）システム監査の実施に当たっての関連知識

修正（tailoring）
個々のシステム開発プロジェクト等に対して、共通フレームを規定するプロセスをプロジェクトの特性に応じて変更し、適切なフレームを設定すること（SLCP-JCF2007）。



取得（acquirer）
システム、ソフトウェア製品又はソフトウェアサービスを取得又は調達する組織。
（備考）取得者は、発注者、顧客、所有者、利用者、又は購入者のいずれであってもよい。



取得者（acquirer）
供給者から、システム、ソフトウェア、ソフトウェア製品又はソフトウェアサービスを取得若しくは調達する組織。

注記：取得者は、発注者、顧客、所有者、利用者又は購入者のいずれであってもよい（JIS X 0160:1996）＜JIS-X-25051より＞。

障害（fault）
計算機プログラム内の不正確なステップ、プロセス、又はデータの定義（IEEE STD 610.12-1990）＜
JIS-X-25051より＞。



使用権（usage）
目的とするものを自由に使用する権利（SLCP-JCF2007）。



所有権（ownership）
目的とするものを全面的に支配し、自由に使用・収益・処分する権利（SLCP-JCF2007）。



信頼性（reliability）
情報システムの品質並びに障害の発生、影響範囲及び回復の度合い（SLCP-JCF2007）。



成果物
システム開発作業（企画、要件定義、開発、運用、保守）を通じて生成される生産物であるシステム、ソフ
トウェア製品、文書及びサービスの総称（SLCP-JCF2007）。



製品説明（product description）
ソフトウェアの特徴を記述した文書。この文書の主な目的は、潜在取得者がソフトウェアを購入する前に、そのソフトウェアが自分たちに適しているかどうかを評価するのを支援することである＜JIS-X-25051より＞。



セキュリティ（security） （安全性（security）の項も参照）
権限の与えられていない者又はシステムが読み込んだり変更できないように情報及びデータを保護すること。
権限を与えられている者又はシステムがアクセスを拒否されないように情報及びデータを保護すること（JIS-X-0160-2007）。

101

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



専有権／占有権（proprietary）
専有という事実から発生する物権（SLCP-JCF2007）。



ソフトウェア（software）
情報処理システムのプログラム、手続き、規則及び関連文書の全体又は一部分。

注記1：ソフトウェアは、それを記憶した媒体とは無関係な知的創作物である（JIS X 0001:1994）。
注記2：現行の規格では、文書はソフトウェアの一部として考慮されていない。別個の項目として考えられている＜JIS-X-25051より＞。



ソフトウェア構成品目（software configuration item）
ソフトウェアの構成管理を行うために識別されたもの。例えば、業務単位のソフトウェア（会計業務ソフト
ウェア、販売在庫業務ソフトウェア、生産管理ソフトウェア）、オペレーティングシステム、データベース管理システムなどが相当する。従来、習慣的に使われている「サブシステム」は、このレベルに相当する。構成管理上識別された場合は、プログラムも対象となる（SLCP-JCF2007）。



ソフトウェア構成要素（software component）
ソフトウェア構成品目を細分化することによって得られる、あるまとまりのある機能単位の構成要素。ただし、ソフトウェア構成要素はソフトウェアユニットを含んでいる。つまり、より低いレベルのソフトウェア
構成要素を含んでいる場合がある。従来、慣習的に使われている「プログラム」の大半は、このレベルに相当する（SLCP-JCF2007）。



ソフトウェアサービス（software service）
開発、運用及び保守のようなソフトウェア製品に付随した活動、作業又は職務の遂行（JIS-X-0160-1996）。



ソフトウェア製品（software product）
計算機プログラム、手続き並びにその関連する文書とデータを含めたまとまり（JIS-X-0160-1996）。



ソフトウェアユニット（software unit）
分割してコンパイル可能なコードのひとまとまり（JIS-X-0160-1996）。



ソフトウェアライフサイクルプロセス（software lifecycle process）
ソフトウェアの開発から、開発された製品の運用や保守に至るまでの一連の作業の過程（SLCP-JCF2007）。



第三者組織（third-party）
問題になっている事柄に関して、当事者と無関係であると認められる個人又は団体（JIS Z 8002:2006）。
＜JIS-X-25051より＞



タスク（task）
アクティビティを構成する要素である。例えば、開発プロセス中の「システム方式設計」アクティビティを具体的に遂行又は支援しなければならない個々の作業をいう（SLCP-JCF2007）。



妥当性確認（validation）
所定の使用方法に対応した特定の要求事項が満たされていることを、客観的根拠の調査及び提出によって確認すること。
（備考1）設計及び開発における妥当性確認は、使用者のニーズに適合しているかどうかを確定するために、成果物に対して吟味を行うプロセスである。
（備考2）妥当性確認は、通常、最終製品について、規定の運用条件の下で実施される。これはもっと早い段
階で行うことが必要なこともある。
（備考3）妥当性確認済という用語は、妥当性が確認された状態を示すために用いる。
（備考4）複数の異なった用途があるときに、複数の妥当性確認が実施されることがある。
（ISO8402-1994／JIS-X-0160-1996）。

102

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



追跡可能性（Traceability）
開発の各段階で作成される設計文書に明確に記述された情報を元に、要求事項から、ソフトウェア構成品目、
ソフトウェア構成要素、さらにソフトウェアユニットにたどれる能力。これには逆の方向にたどれる能力、
即ち、ソフトウェアユニットから要求事項にたどれる能力も含む。例えば、システム要求事項の中で規定されたある特定の機能が、ソフトウェア構成品目のどこに具体的に記述されているか追跡できるようになっていることである。さらにそれがどのソフトウェア構成要素に割り当てられているかをたどれる能力をいう。



提案見積書[見積依頼書]（request for proposal[tender]）指定されたシステム、ソフトウェア製品又はソフトウェアサービスを取得するために取引者が入札者に対しその意図を伝えるために用いる文書（JIS-X-0160-1996）。



提案書（proposal）
取得者の要求に基づきシステム、ソフトウェア製品又はサービスを受注するために、要求実現可能性を検討
し、受注の意向を公表する手段として供給者（候補者）より提示される文書（SLCP-JCF2007）。



適格性確認（qualification）
対象とするものが規定要求事項を満たす能力があるかどうかを実証すること（JIS-X-0160-1996）。



適合性確認テスト（qualification testing）
ソフトウェア製品が使用に適合し、かつ実環境で利用可能であることを確認するテスト。このテストは開発者が行い、適時取得者が確認する（JIS-X-0160-1996）。



適合性確認要求事項（qualification requirement）
ソフトウェア製品が使用に適合し、かつ実環境で利用可能であることの確認に用いられる基準又は条件（JIS-X-0160-1996）。



適合性評価（conformity evaluation）
製品、プロセス又はサービスが規定の要求事項を満足している度合いについての系統的な試験（JIS Z
8002:2006）。



適合性評価報告書（conformity evaluation report）
COTSソフトウェア製品に対して行った評価の実施状況及び結果を記述した文書。
注記：この定義は、IEEE Std 610.12-1990 に変更を加えたものである。＜JIS-X-25051より＞



テスト網羅性（test coverage）
システムまたはソフトウェア製品に対する要求事項について、テストケースを使用してテストできる範囲（JIS-X-0160-1996）。



テスト計画性（testability）
要求が満たされているかどうか判定するために、客観的かつ実行可能なテストが計画できる程度。
（参考）テスト計画性（testability）は、ソフトウェアの品質特性の観点から、試験性と呼ばれる場合がある[JIS-X-0129ソフトウェア製品の品質]。その場合は、改定したソフトウェアの妥当性の確認に必要な労力に影響する、ソフトウェアの属性を意味する用語として使われている。このJIS-X-0160-1996では、この用語の主旨とJIS-X-0129とのそれと異なるので訳語を変えている（JIS-X-0160-1996）。

103

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



人間工学（human-factor engineering）
人間と機械装置が組になって働くシステムにおいて、人間的要素（人体の形態や作業能力など）を考慮した
合理的な設計を行い、結果として作業の安全性・信頼性・効率性を向上させ、労働意欲を満足させることを目的とした学問分野（JIS-X-0160-1996）。

ハードウェア（hardware）
情報処理システムの物理的な構成要素又は一部分（例）計算機、周辺装置（JIS-X-001-1994）。

ハードウェア構成品目（hardware configuration item）
ハードウェアの構成管理を行うために識別されたものをいう（SLCP-JCF2007）。



廃棄（retirement）
新システムに一部もしくは全体を置き換えるか、または改定したシステムを導入することで。運用又は保守組織が実施中の支援を中止すること（JIS-X-0160-1996）。

版（version）
ある品目の（時間によって）識別された段階。
（参考）ソフトウェア製品の版の変更を行って新しい版とする場合は。構成管理の処置をとる必要がある。
（JIS-X-0160-1996）。



非納入品目（non-deliverable item）
ソフトウェア製品の開発で必要となるハードウェア製品又はソフトウェア製品であるが、契約上は納入する必要がないもの（JIS-X-0160-1996）。



評価（evaluation）
対象とするものが、決められた基準に達していることを系統的に決定すること（JIS-X-0160-1996）。



品質保証（quality assurance）
あるものが品質要求事項を満たすことについての十分な信頼を供するために、品質システムの中で実施され、必要に応じて実証される、全ての計画的かつ体系的な活動（備考1）品質保証には、次に示す内部目的及び外部目的がある。
a）内部品質保証
組織内においては、品質保証は、経営者に対して信頼を与える。
b）外部品質保証
契約下では、品質保証は顧客又はその他に対して信頼を与える。
（備考2）品質管理手法による活動及び品質保証活動の一部は相互に関連している。
（備考3）品質要求事項が利用者のニーズを完全に反映していないときは、品質保証が十分な信頼を与えていないこともある（JIS-X-0160-1996）。



不具合（anomaly）
要求仕様書、設計文書、標準などに基づいた期待から逸脱した状態、又は誰かの知見若しくは経験から逸脱した状態（IEEE Std 1044-1993）。＜JIS-X-25051より＞



プロジェクト（project）
ある特定の目的を持って実施されるシステム開発などで、達成すべき課題を所定の期限までに計画に沿って実行する活動である。この場合、課題の目的（目標と利益）、スケジュール、組織、要因、作業、品質、環境整備などが管理対象として明示されていなければならない（SLCP-JCF2007）。



プロセス（process）
互いに関連をもったアクティビティの集合で、入力を出力に変換するもの。
（備考）用語アクティビティには資源を利用することも含まれる（JIS-X-0160-1996）。

104

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック



文書作成（document）
ソフトウェアライフサイクルのプロセス又はアクティビティによって生成される文書（計画書、仕様書、記録書等）を作成、配布、管理すること（SLCP-JCF2007）。



変換／コンバージョン（conversion）
ある計算機システムで稼働しているソフトウェアを修正して、別の計算機システムでも稼働できるようにする作業（SLCP-JCF2007）。



保守（maintenance）
納入後のソフトウェアシステム又は構成要素の修正プロセス。障害の修正、性能若しくは他の属性の改善、又は環境の変化への適合のために行われる（IEEE Std 610.12-1990）。＜JIS-X-25051より＞



保守（maintenance）
システムやソフトウェアを正常に運用するために実行する、予防保全（定期メンテナンス）、障害解析、復旧、移行などの作業。是正保守、予防保守、適応保守、完全化保守の４つの保守タイプがある（SLCP-JCF2007）。



保守者（maintainer）
保守作業を実施する組織（JIS-X-0160-1996）。



保守プロセス（maintenance process）
システムやソフトウェアの現状を、業務ならびに環境に適合するように変更管理する組織のアクティビティ
やタスクからなる（SLCP-JCF2007）。



問題解決（problem resolution）
企画、要件定義、開発、運用、保守プロセス等で発見された、不適合を含む問題を原因分析し、対策を講じて問題を取り除くこと（SLCP-JCF2007）。



問題の識別／切り分け（problem identification）
不適合を含む問題や障害の原因を分析し、その箇所を確定すること（SLCP-JCF2007）。



要求文書（requirements document）
COTS ソフトウェア製品が満たす必要のある要求事項及び規制の任意の組合せを含んだ文書。
例：これらの文書は、技術文書、規格及び種々の利用者向けの要求事項一覧（若しくはモデル要求仕様書）、
又は管理機関若しくは規制機関が課した法規若しくは規制であってもよい。＜JIS-X-25051より＞



ライフサイクルモデル（life cycle model）
ソフトウェア製品の開発、運用、保守に伴うプロセス、アクティビティ及びタスクの枠組み。この枠組みは、企画からその利用終了までのシステムの生涯に及ぶ。
（参考）プロセス、アクティビティ及びタスクはシステム開発作業を階層化して表すものである。最上位の作業のくくりがプロセス、そのプロセスの構成要素がアクティビティ、そしてアクティビティの構成要素がタスクである（SLCP-JCF2007）。



利用者（user）
1）ある機能を果たすシステムを利用する個人又は組織。
注記：利用者には、運用者、ソフトウェアの結果の受入者、又はソフトウェアの開発者若しくは保守者を含んでもよい（JIS X 0141:2004）。
2）ある機能を果たすために、ソフトウェア製品を使用する個人又はビジネス組織（ISO/IEC 18019:2004）。
＜JIS-X-25051より＞



利用者用文書（user documentation）
利 用 者 が ソ フ ト ウ ェ ア を 使 用 す る に 当 た り 、 利 用 者 を 支 援 す る た め に 供 給 さ れ る 情 報 （ ISO/IEC
18019:2004）。＜JIS-X-25051より＞

105

Copyright© 2012 CSAJ All Rights Reserved.

パッケージソフトウェア品質認証制度申請者ガイドブック

パッケージソフトウェア品質認証制度
申請者ガイドブック
2012年6月13日

106〒107-0052 東京都港区赤坂1-9-15
日本自転車会館1号館5F
TEL：03-3560-8440
FAX：03-3560-8441
http://www.csaj.jp/
Copyright© 2012 CSAJ All Rights Reserved.