品質基準のメモ

## 1. はじめに
前回、[バグ票のタイトルの分析](https://qiita.com/pbjpkas/items/d6fe3a33067f3e062fa8)で取り上げたようにQAエンジニアの役割の一つに「品質計画の策定」があります。
> 3-7 品質計画の策定
> QAエンジニアは「品質計画」の策定に関与するケースも少なくありません。品質計画とは、プロジェクトが達成すべきソフトウェアの品質目標や、その達成に向けたプランを明確にするプロセスのことです。
> 出典：[QA(品質保証)とは？主な7つの役割と求められるスキル・資格を解説【ソフトウェア開発・テスト用語 】| Qbook](https://www.qbook.jp/column/714.html)

品質計画の策定の一環として品質基準作りがあることや[JaSST'25 Tokyo](https://jasst.jp/tokyo/25-about/)で品質基準のセッションが開催されたこともありメモがてら考えを整理してみます。

## 2. 品質基準のセッション＠JaSST'25 Tokyo
### 2.1 セッションの内容
セッションの内容を[JaSST'25 Tokyo](https://jasst.jp/tokyo/25-about/)のセッション情報より引用します。

A4）ソフトウェアがJISマーク認証される時代に！～標準化がもたらすソフトウェア品質の確保や市場への信頼性向上～
> 伊藤 潤平（ウイングアーク1st）
> 八城 洋一（日立ソリューションズ・クリエイト）
> 浅井 秀一（一般財団法人日本品質保証機構）
>
> 令和元年7月に施行された産業標準化法の改正により、ソフトウェアもJISマーク表示制度の対象となりました。これまでJISマークは鉱工業品に限られた印象がありましたが、今回の改正により、ソフトウェアにも適用されるようになったことで、業界に新たな視点をもたらしています。
>
> 本発表では、ソフトウェアにおけるJISマーク認証の取得がもたらすメリットとデメリット、さらにはどのような企業やユーザーにとって価値があるのかについて探ります。また、認証取得のプロセスが実際にどの程度のハードルを伴うのか、認証を取得した製品が具体的にどのような対策を講じたのかについても詳細に説明したいと思います。
>
> 今回の発表を通じて、ソフトウェア業界における標準化の重要性とその影響を明らかにし、ソフトウェア品質の確保と市場での信頼性向上を目指す企業にとっての一助になればと思います。

[資料](https://jasst.jp/symposium/jasst25tokyo/pdf/A4.pdf)

A5）「保証するための品質基準」がQAには必要か？
> 湯本 剛（yttelab）
> 末村 拓也（Autify）
> 河野 哲也（ナレッジワーク）
>
> もともと、製造業から始まった「品質保証」と言う活動は初めから品質の良い製品、サービスを提供できるシステムを構築するとともに、品質の良い製品やサービスを提供できない場合は適切な補償と再発防止をするといった一連の活動のことを指しているが、そのためには品質基準が必要である。ところがIT業界ではそういった品質基準を明確にした活動ができているのか？私たちの属するQAオンラインコミュニティでこのような話題で盛り上がっていました。本セッションではこの疑問について、各自の見解をパネル形式で話ししながら追求していきたいと思います。

[資料](https://docs.google.com/presentation/d/13piQ3dyEUziEkQJd1CEi1xq1Flfmr9JPzqT4hTXwbZ4/)

### 2.2 JaSST'25 Tokyo参加前のメモ
「IT業界ではそういった品質基準を明確にした活動ができているのか？」は筆者はNoになる気がしないしそもそもQAは説明責任が求められるし、、、と思って事前にちょっと調べたときのメモです。

結論としては「『保証するための品質基準』がQAには必要か？」は自分はYes（品質基準は自主的なものもあれば契約や法令にもとづくもの、認証のような客観的に認められるものもあってどこに基準を置くかは組織や製品次第）です。

- リリース判定のクライテリアは品質基準の一つと考えられ、（筆者が属する組込み系とは異なる業界の）IT業界ではカットオーバークライテリアと呼ばれたりもするようで、こういう用語があることからIT業界は品質基準に則った活動をしているように見える
- このバグは直さずにリリースしたらまずいよねなどと考えながら付けている重要度や優先度は組織や製品の品質基準を反映しているはずで、品質基準は何かしら身近にあるといえる
- 組織や製品によっては自主的ではない（＝契約や法令にもとづく）品質基準もある
- 「ソフトウェア 説明責任 品質基準」で[ググってみた](https://www.google.com/search?q=ソフトウェア+説明責任+品質基準)
  - 「[ソフトウェア品質説明のための制度ガイドライン(IPA)](https://www.ipa.go.jp/archive/digital/iot-en-ci/mieruka/ps6vr7000000y3u7-att/000029495.pdf)」にソフトウェア品質説明事項がまとまっていて、この中で品質基準に近いのは「目標」
  - このガイドラインに基づいた制度事例にパッケージソフトウェア品質（PSQ）認証制度があり[^1]PSQ認証を取得している製品のベンダーさんは品質基準を明確にした活動をしている、できていると言えるのでは？
  - PSQ認証が始まったのは2013年で10年以上続いていることや認証を取得されているベンダーさんも[何社もある](https://archive.saj.or.jp/activity/project/psq/)ことから「IT業界ではそういった品質基準を明確にした活動ができているのか？」はできていると言えるだろう
- 「A4）ソフトウェアがJISマーク認証される時代に！」は[JIS X 25051](https://webdesk.jsa.or.jp/books/W11M0090/?bunsyo_id=JIS%20X%2025051:2016)[^2]のセッションで客観的な品質基準にもとづいた活動の下地が整ってきている模様

:::note
ソフトウェア品質説明事項を以下に引用します。
>ソフトウェアが重要な役割を果たす製品・システムにおいて、利⽤者が品質を確認し判断できるように供給者が利⽤者に対して説明することを、「ソフトウェア品質説明」と呼び、その説明が持つ⼒を「ソフトウェア品質説明⼒」と呼ぶ。ソフトウェア品質説明とは、製品・システムについて以下の事項を根拠や事実に基づいて説明することである。
> 1.製品・システムが想定する利⽤者、利⽤⽬的、利⽤状況、制約事項
> 2.製品・システムを利⽤者が利⽤する上で必要なソフトウェアの品質とその⽬標
> 3.品質⽬標を達成するための設計・実装・運⽤及び保守
> 4.品質⽬標を達成したことの検証・監査
> 出典：[ソフトウェア品質説明のための制度ガイドライン(IPA)](https://www.ipa.go.jp/archive/digital/iot-en-ci/mieruka/ps6vr7000000y3u7-att/000029495.pdf)
:::

### 2.3 JaSST'25 Tokyo 品質基準のセッションの感想
JaSST'25 Tokyoの品質基準のセッションは、守破離でいえば「A4）ソフトウェアがJISマーク認証される時代に！」がデジュール標準に則った「守」とすると「A5）「保証するための品質基準」がQAには必要か？」はさまざまなトピックスが登場し「破・離」といった感じでした。JaSST Tokyoの「年に一度のテストのお祭り」を体現したセッションと思いました。

## 3. 品質基準を改めて考えてみる

### 3.1 品質保証と品質基準
品質保証と品質基準の関係はOxford Business English DictionaryのQuality Assuranceの説明がわかりやすいと思います。

> Quality Assurance
> (Production) the practice of managing every stage of the process of producing goods or providing services to make sure they are kept at the standard that the customer expects.
> 【参考訳】
> 品質保証
>（製造）顧客が期待する品質のレベルに商品やサービスが確実に適合するように、商品を生産したりサービスを提供したりするプロセスの各段階のやりくりを実践すること

:::note
- standardを "level of quality" と訳しています
  - 参考：[standard (Oxford Advanced Learner's Dictionary)](https://www.oxfordlearnersdictionaries.com/definition/english/standard_1)
- managingをやりくりと訳しています
  - 管理と訳するとcontrolの意味合いが出てしまいそれを避けるためです
  - 参考：[マネジメント やりくり - Google検索](https://www.google.co.jp/search?q=%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88+%E3%82%84%E3%82%8A%E3%81%8F%E3%82%8A)
:::

リリース判定のクライテリアは、1.プロダクトの出来はOKか、2.プロセスをちゃんとやったか、のどちらもあります。ここで「A5）「保証するための品質基準」がQAには必要か？」のセッションで話題に挙がった品質基準、品質管理基準を次のように定義すると品質基準が明確になるように思いました。

- 品質基準―プロダクトが満たすべき、顧客が期待する品質のレベル
- 品質管理基準―プロセスが満たすべき、やりくりのレベル

「顧客が期待する品質のレベル」がふんわりしていて扱いづらい場合は、例えばISO 9001にならって「顧客要求事項及び適用される法令・規制要求事項を満たす品質のレベル」と読み替えてもよいと思います。例えばSLA（Service Level Agreement）は顧客要求事項から導かれる品質基準です。

### 3.2 品質基準の縦軸・横軸
品質基準は高い・低いといった縦軸だけでなく、対象とする品質の範囲、面の広さといった横軸もあります。以下は機能安全の解説ですが品質基準にも当てはまる考え方と思います。

> 確かに、「製品すべてについて安全規格を順守した開発が行われ、製品全体が安全認証を受けている」という点には大きな魅力を感じますが、それを実現するために膨大な工数や開発費を掛けるのも現実的ではありません（開発費を回収するために製品価格を跳ね上げてはモノは売れません）。機能安全規格に対応する範囲が大きければ大きいほど、製品価値は高まります。しかし、製品としての魅力（価格を含めて）を損なうことのないように、実現可能かつ製品として成立する範囲を適切に定める必要があります。
> 出典：[いまさら聞けない 機能安全入門：機能安全規格基礎（4/4 ページ） - MONOist](https://monoist.itmedia.co.jp/mn/articles/0906/15/news091_4.html)

「A4）ソフトウェアがJISマーク認証される時代に！」の[資料](https://jasst.jp/symposium/jasst25tokyo/pdf/A4.pdf)pp.43-46（品質保証基準、品質は段階的に確保する、テストは体系的にマネジメントする、戦略的なテスト計画）は品質基準の縦軸・横軸、あるいは「何をどこまでやるか」の大変わかりやすい資料と思いました。

### 3.3 グレードと品質基準
入門機種と上位機種では顧客が期待する機能・性能のレベルは異なります。品質基準はグレード次第です。

> 11.5 等級／グレード
同一の用途をもつ製品・サービス(2.1)，プロセス(4.1)又はシステム(5.1)の，水準の異なる要求事項に対して与えられる区分若しくはランク．
[JSQC-Std 01-001:2023 品質管理用語](https://jsqc.org/wp/wp-content/uploads/2023/10/JSQC-Std-00-001_yougo.pdf)

> 品質を論じる場合には，必ずグレードを意識していなくてはならない。言い換えれば，品質を1つの価値として議論する場合は，もう1つの価値である価格（コスト）を同時に含めて議論しなければならないのである。
> [平林良人「ISO9001内部監査の仕方」アーカイブ　第1回](https://www.technofer.co.jp/iso/naibuk-s-2/)

:::note
- グレードが高いことと品質が高いことはイコールではありません。品質が良いとは顧客が期待する水準を満たしていることです。
参考：[TQM／品質管理　こんな誤解をしていませんか？　第2回　『高品質＝高級・高グレード・高価な製品ではないのか？』（前編）　 (2019-5-7)](https://www.tqm9000.com/news/2019/05/07/iso-qms-misund2-2/)
- [JIS Q 9005:2023 品質マネジメントシステム―持続的成功の指針 ](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+9005%3A2023)は品質に価格も含みます。
:::

### 3.4 リスクと品質基準
重大な影響のない適用業務では一定の水準の欠陥は容認されることが[JIS X 25051:2016](https://webdesk.jsa.or.jp/books/W11M0090/?bunsyo_id=JIS%20X%2025051:2016)の付属書Aで述べられています。

> 典型的な既製ソフトウェア製品（RUSP）は，リスクの低い適用業務に使用される。多くの既製ソフトウェア製品（RUSP）は，安全性，ビジネス，法律又は組織の目標に対するリスクを考慮せずに開発されている。重大な影響のない適用業務では，既製ソフトウェア製品（RUSP）の特質として，運用操作不可又は機能不全となった場合には，最悪の場合，利用者の不満足という結果を引き起こすであろう。その最悪の場合には，開発者は，利用者の評価を満足させるために，バグを解決し，特質を追加及び／又は削除することによって回復させなければならない。こうした場合の多くでは，市場は厳密な試験を要求せず，既製ソフトウェア製品（RUSP）の一定の水準の欠陥は容認する。

一方で「既製ソフトウェア製品（RUSP）の使用が安全性又はビジネスリスクに明らかな影響を及ぼす状況では，既製ソフトウェア製品（RUSP）の不十分な適用又は不十分な試験の結果がもたらすものは深刻である」ともあり、1件の障害でも悲惨な結果をもたらすシステムが例示されています。リスクの高い分野は期待されるレベルも高くなります。

> しかし，既製ソフトウェア製品（RUSP）の使用が安全性又はビジネスリスクに明らかな影響を及ぼす状況では，既製ソフトウェア製品（RUSP）の不十分な適用又は不十分な試験の結果がもたらすものは深刻である。このような環境での既製ソフトウェア製品（RUSP）の適用業務には，航空用途，医療機器，薬及び調剤，宇宙及び探査，電気通信，建築，会計，エレベータ，鉄道，防衛システムなどを含む。航空及び鉄道輸送管理，がん患者に対する放射能照査量の調整，税金及び会計報告書の正確性などの機能は，1件の障害でも悲惨な結果をもたらすシステムの例である。

#### 3.4.1 セーフティと品質基準
顧客の期待には暗黙的なものもあります。例えば家電製品で感電しないことは当たり前に期待されることです。生命や財産のリスクが特に高いものは法律（例：[電気用品安全法](https://www.meti.go.jp/policy/consumer/seian/denan/act_outline.html)）で規制されます。

> 第一条
>この法律は、電気用品の製造、販売等を規制するとともに、電気用品の安全性の確保につき民間事業者の自主的な活動を促進することにより、電気用品による危険及び障害の発生を防止することを目的とする。
> 出典：[電気用品安全法](https://laws.e-gov.go.jp/law/336AC0000000234)

IEC 60730（JIS C 9730 自動電気制御装置）においてはソフトウェアを使用する制御機能がクラスA、B、Cに分類され、規格要求はクラスBおよびクラスCにだけ適用されます。

><dt>クラス A 制御機能（class A control function）
><dd>機器の安全を担保することを意図していない制御機能。
><dd>例：ルーム・サーモスタット、湿度コントローラ、照明コントローラ、タイマ、スイッチ
><dt>クラス B 制御機能（class B control function）
><dd>機器の不安全を防ぐことを意図する制御機能。
><dd>例：洗濯設備用のサーマル・カットオフおよびドア・ロック
><dt>クラス C 制御機能（class C control function）
><dd>機器内での爆発又は故障が直接機器に危険の原因となるような特定の危険を防止するように意図した制御機能。
><dd>例：密閉型機器用の自動バーナー制御およびサーマル・カットオフ
></dd>
> 
><dt>H.11.12 ソフトウェアを使用する制御装置
><dd>ソフトウェアを使用する制御装置は，ソフトウェアが制御装置のこの規格の要求事項から逸脱しない構造でなければならない。
><dd>適否は，この規格中の電子制御装置に対する試験，この細分箇条の要求事項による目視検査及び表 1 の項目 66～72 の製造業者の宣言によって判定する。
><dd>H.11.12.1～H.11.12.4 は，ソフトウェアクラス B 又はソフトウェアクラス C を用いた制御機能にだけ適用する。
> </dd>
>
> 出典1：[JIS C 9730-1:2019 自動電気制御装置―第１部：一般要求事項](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+C+9730-1%3A2019)
> 出典2：[家電向け機能安全ソリューション（ルネサスエレクトロニクス株式会社）](https://www.renesas.com/ja/applications/consumer-electronics/appliances/iecul-60730-functional-safety)

#### 3.4.2セキュリティと品質基準
##### 3.4.2.1 市場、社会の期待
[第2回 産業サイバーセキュリティ研究会 ワーキンググループ3 IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会（経済産業省）](https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_cybersecurity/iot_security/002.html)の資料3に代表的な製品において求められる対策レベルのイメージが図示されています。「あくまでもイメージ図であり、求められる対策のレベルを厳密に図示したものではない」とあるものの検討会を構成するセキュリティ専門家の認識がうかがえます。製品の分野によって期待される対策レベルがさまざまなことがわかります。

![セキュリティ対策レベルイメージ図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221758/249f2653-b04d-4630-8ee5-e7739314e380.png)

2024年9月30日にスタートした[セキュリティ要件適合評価及びラベリング制度（JC-STAR）](https://www.ipa.go.jp/security/jc-star/index.html)は需要者を考慮し適合基準のレベルとその位置付けを次のように定めています。

><dl>
><dt>★４（レベル４）／★３（レベル３）
><dd>政府機関や重要インフラ事業者、地方公共団体、大企業等の重要なシステムでの利用を想定した製品類型ごとの汎用的なセキュリティ要件を定め、それを満たすことを独立した第三者が評価して示すもの
><dt>★２（レベル２）
><dd>製品類型ごとの特徴を考慮し、★１（レベル１）に追加すべき基本的なセキュリティ要件を定め、それを満たすことをIoT製品ベンダーが自ら宣言するもの
><dt>★１（レベル１）
><dd>製品として共通して求められる最低限のセキュリティ要件を定め、それを満たすことをIoT製品ベンダーが自ら宣言するもの
></dl>
>
>![JC-STAR適合基準](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221758/91f3cd88-e88c-4939-a3ad-994083ef362b.png)
>図の出典：[IoT製品のセキュリティ確保に向けて～セキュリティ要件適合評価及びラベリング制度(JC-STAR*)の紹介～](https://www.ipa.go.jp/security/jc-star/begoj9000000gg60-att/JC-STARsetumeikai_1.pdf)

このほかにも、総務省の[電気通信事業法に基づく端末機器の基準認証に関するガイドライン(第２版)](https://www.soumu.go.jp/main_content/000705080.pdf)によるとひとくちに "ウェブカメラ" といってもインターネットに直接つながるケースはセキュリティ基準に係る認証の対象、ルータ越しにつながるケースは対象外となっています。

![技適セキュリティ基準の対象機器イメージ図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221758/fc4362d8-a135-4198-bd93-8f7f175a771e.png)

##### 3.4.2.2 欧州サイバーレジリエンス法（EU CRA）
欧州サイバーレジリエンス法はデジタル製品をセキュリティリスクの大きさで3つに分類し適合性の評価方法を定めています。CEマークの要件で強制力のあるものです。

- デジタル製品：⾃⼰適合宣⾔か第三者認証かを選択
- 重要なデジタル製品（クラスI・低リスク）：第三者認証（該当する場合はEUCC）
- 重要なデジタル製品（クラスII・高リスク）：第三者認証

出典：[EUサイバーレジリエンス法（草案概要）（経済産業省）](https://www.jasa.or.jp/dl/gov/20220926.pdf)

##### 3.4.2.3 CEM（ISO/IEC 18045:2022）
[CC(ISO/IEC 15408)概説(IPA)](https://www.ipa.go.jp/security/jisec/about/about.html)によると「情報技術セキュリティの観点から、情報技術に関連した製品及びシステムが適切に設計され、その設計が正しく実装されていることを評価するための国際標準規格」としてCC（コモンクライテリア、ISO/IEC 15408）があり、その評価手法としてCEM（共通評価手法、ISO/IEC 18045）がCCとともに開発されました。

- [セキュリティ評価基準（CC/CEM）](https://www.ipa.go.jp/security/jisec/about/kijun.html)
- [セキュアな製品調達のために・参考資料](https://www.ipa.go.jp/security/jisec/about/knowledge/sankou.html)
- [脆弱性対処に向けた製品開発者向けガイド](https://www.ipa.go.jp/security/guide/vuln/forvendor.html)

### 3.5 品質基準の向き不向き
アクションゲームのソフトウェアで難易度の高い技を何度も練習して習得しボスキャラを倒して次のステージを遊べるようになることは[JIS X 25010:2013](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+25010%3A2013)の利用時の品質モデルにおける快感性（満足性の副特性の一つ）といえます。

> JIS X 25010:2013
> 4.1.3.3
> 快感性（pleasure）
> 個人的なニーズを満たすことから利用者が感じる喜びの度合い。
> 注記 個人的なニーズには，新しい知識及びスキル（技術）を獲得するというニーズ，個人のアイデンティティを伝えるというニーズ及び心地よい記憶を引き起こすニーズを含むことができる。

満足性の評価はJIS X 25022:2019で質問票（5段階尺度などを用いたアンケート、計量心理学的測定）が挙げられています。

- [JIS X 25022:2019 システム及びソフトウェア製品の品質要求及び評価（ＳＱｕａＲＥ）―利用時品質の測定](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+25022%3A2019) pp.15-17
- [つながる世界のソフトウェア品質ガイド](https://www.ipa.go.jp/archive/publish/tn20150529.html) pp.135-140

満足性の適合性はJIS X 25051で製品説明に対する要求事項、利用者用文書類に対する要求事項、ソフトウェアに対する品質要求事項が定められていて、これに従って評価されます。

満足性の要求事項を以下に抜粋します。

><dl>
><dt>製品説明に対する要求事項
><dd>製品説明は，該当する場合，JIS X 25010 に基づいて，満足性に関する記述を含まなければならない。
><dd>満足性という特性には，実用性，信用性，快感性及び快適性という副特性があり，これらを考慮しなければならず，“検証可能な適合の証拠を示すことができる。”という形で書かなければならない。
><dt>利用者用文書類に対する要求事項
><dd>利用者用文書類は，利用者が製品説明に記述されたような満足性を達成できるために役立つものでなければならない。
><dt>ソフトウェアに対する要求事項
><dd>ソフトウェアは，製品説明に記述され，かつ，利用者用文書で支援されている満足性の特質を満足するように動作しなければならない。
></dl>

先に挙げた難易度の高い技の快感性の適合性は次の三点が評価されると考えられます。
- JIS X 25010に基づいて示された満足性の「検証可能な適合の証拠」
- 利用者用文書類が、利用者が製品説明に記述されたような満足性を達成できるために役立つこと
- 製品説明や利用者用文書類（例えば取扱説明書やチュートリアル）に記載の手順通りに操作し、技が発動してゲームが進行すること

ところでJIS X 25051の適用範囲は次のように説明されています（強調筆者）。
> 1 適用範囲
> （略）
> この規格は，既製ソフトウェア製品（RUSP）が提示されたとおりに，かつ，引き渡された状態で<b>動作する</b>という信頼を利用者に与えることだけ扱っている。（以下略）

難易度の高い技の快感性はゲームエンジンの動作だけでなく、ステージのレベルに見合った難易度や、シナリオやキャラクターの魅力、グラフィック、BGMや効果音の演出といったコンテンツとの相乗効果でもたらされるものと思います。JIS X 25051の適用範囲に従うとゲームエンジンの動作は範囲内ですが難易度やコンテンツの妥当性は範囲外と考えられます。品質基準はある分野で有用でもほかの分野に当てはまるとは限らず、プロダクトとの相性、向き不向きがありそうです。

### 3.6 品質基準の成熟
今でこそUSBデバイスはPCへ挿したらすぐ使えるのが当たり前ですがMicrosoftがWindows 95 OSR2でUSBをサポートを開始した当初は "Plug & Play" が "Plug & Pray（挿して祈る）" と揶揄されていました。Windows 95 OSR2.5、Windows 98、98 SE、Windows Meを経て、安定して使えるようになったのはWindows 2000やWindows Xpあたりからだったと思います[^3]。

また、OSにしてもWindows 95や98のころはクラッシュするのを想定して編集中のファイルをこまめにセーブしたりしていましたが今どきはブルースクリーンにお目にかかることが少なくなり成熟したように思います。プロダクトが成熟するにつれてユーザの期待値、ひいては品質基準も上がってゆきます。

## 4. おわりに
品質基準のセッションでさまざまなキーワードやトピックスに触れたことで参加前と比べて品質基準の考えが深まりました。登壇者のみなさま、[JaSST TokyoのDiscord](https://discord.com/invite/ZxHS4cmNA8)[^4]でチャットしてくださった参加者のみなさま、ありがとうございます。

本稿では品質保証の定義を起点に「プロダクトが満たすべき、顧客が期待する品質のレベル」を品質基準と考え、次のように品質基準を整理しました。

- 品質基準は顧客の期待やグレード、リスク次第
- 顧客の期待は顧客要求事項及び適用される法令・規制要求事項次第と読み替えるのもあり
- 何をどこまでやるか範囲を適切に定める必要がある
- プロダクトの成熟に合わせて基準も変わってゆく
- ある分野で有用な品質基準がほかの分野にも有用とは限らない
  - 顧客の期待やグレード、リスクが異なる可能性
  - プロダクトとの相性、向き不向きの可能性

## A. 補足
説明責任の参考資料を以下に挙げます。

- [QAアーキテクチャの設計による説明責任の高いテスト・品質保証（Vector Testing User Day 2016/10/24、電気通信大学 西 康晴・著）](https://www.slideshare.net/slideshow/qa-67559281/67559281)
- [D-Case導入によるシミュレーションＳ／Ｗの期待結果明確化と合意形成（SQiP2014、三菱電機株式会社 森 素子・著）](https://www.juse.jp/sqip/library/shousai/?id=261)
- [D-Case 適用ガイドライン策定によるシステム妥当性確保の取り組み（SQiP2017、三菱電機株式会社 森 素子・著）](https://www.juse.jp/sqip/library/shousai/?id=339)
- [セキュリティ・バイ・デザインとアシュアランスケース（SEC journal Vol.12 No.3 Dec. 2016 pp.28-33、IPA/SEC 金子朋子・著）](https://www.ipa.go.jp/archive/files/000055727.pdf)

[^1]: [ソフトウェア品質説明の考え方（IPA・2014年）](https://www.ipa.go.jp/archive/digital/iot-en-ci/mieruka/ps6vr7000000y3u7-att/000040880.pdf)
[^2]: JIS X 25051:2016 システム及びソフトウェア製品の品質要求及び評価（ＳＱｕａＲＥ）―既製ソフトウェア製品（ＲＵＳＰ）に対する品質要求事項及び試験に対する指示
[^3]: 参考：[USBが誕生したのは「奥さんのプリンタをつなげる手間にキレたから」　USBの設計当時を振り返る p.6（大原雄介・著）](https://www.itmedia.co.jp/news/articles/2106/23/news137_6.html)
[^4]: JaSST TokyoのXの[ポスト](https://x.com/jassttokyo/status/1904350070969172423)