スライドトップと してご利用ください マネーフォワード事業本部 山田 太郎 © Money Forward, Inc.品質特性のすすめpresented byhonamin / QA Engineer© Money Forward, Inc.
View Slide
1. 品質特性の概念を完全に理解する2. 💪日々やってることが品質特性と結びつくようになる
品質特性とはabout Quality Characteristic「 要求事項に関連する製品、 プロセス又はシステムに本来備わっている特性」1. “本来備わっている”とは、そのものが存在している限り、もっている特性を意味する。2. 製品、プロセス又はシステムに付与された特性（例:製品の価格、製品の所有者）は、その製品、プロセス又はシステムの品質特性ではない。3. 品質工学では、システムの機能を確保するために必要とされ、仕様で規定される特性。
なぜ定義されたのか？品質は従来「目に見えないもの」だったので、確認するための基準を設けた。（品質の構造をモデル化した）
ISO標準（国際標準）での分類：1991年
ISO標準（国際標準）での分類：2011年・JIS規格になったのが2013年・セキュリティ／互換性が品質特性として追加・いくつかの特性／副特性はより的確な名称がつけられた・時代と共に変わっていく可能性大いにありhttps://www.otsuka-shokai.co.jp/erpnavi/topics/column/ipapsq/softwarehinshitsunotokusei2.html
品質特性／副特性の説明
◆機能適合性明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い。※機能仕様にではなく、機能が明示的ニーズ及び暗黙のニーズを満足させるかどうかにだけ関係functional suitability仕様書通り！ではなくユーザーストーリーを満たす機能を提供できているか。
➖ 機能完全性機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。テスト観点：新しく追加された機能が正しく実装できているかfunctional completeness➖ 機能正確性正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い。テスト観点：処理・出力データ正誤functional correctness➖ 機能適切性明示された作業及び目的の達成を、機能が促進する度合い。テスト観点：目的に合った機能が実装されているかfunctional appropriateness
◆性能効率性明記された状態（条件）で使用する資源の量に関係する性能の度合い。※資源には、他のソフトウェア製品、システムのソフトウェア及びハードウェア構成、並びに材料（例えば、印刷用紙、貯蔵媒体）を含むことができる。performance efficiencyCSV出力や検索の速度がはやい。など。ただし明記された状態（条件）が必要。低スペックPCで速度出そうと思っても無理。「どんな環境でどれくらいのデータ上限であれば補償する」。
➖ 時間効率性製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間、並びにスループット速度が要求事項を満たす度合い。テスト観点：適切な応答時間及び処理時間（一定の処理を完了するのに要する時間）time behavior➖ 資源効率性製品又はシステムの機能を実行するとき、製品又はシステムで使用される資源の量及び種類が要求事項を満たす度合い。テスト観点：使用領域を使いすぎない（CPU負荷・通信資源など）resource utilization➖ 容量満足性製品又はシステムのパラメータの最大限度が要求事項を満たす度合い。テスト観点：パラメータを最大限までつかえること（保存できる項目数・同時に利用する利用者の数・データベースの大きさ）capacity
◆互換性同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び／又はその要求された機能を実行することができる度合い。compatibility想定出来うる利用者の利用環境にシステムが対応できているか。利用環境の優先順位についてはGAなどで調査することが多い。
➖ 共存性その他の製品に有害な影響を与えずに、他の製品と共通の環境及び資源を共有する間、製品が要求された機能を効率的に実行することができる度合い。テスト観点：他のソフトウェアとの共存co-existence➖ 相互運用性二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い。テスト観点：他のシステム、装置との連動resource utilization📄memo推奨環境との繋がりについて？？？と思う人もいるかもです。本来推奨環境とは「このスペック以上の環境を用意してね。用意できないならもしかしてもしかするとアプリケーションが正常に動かないかもしれないけど、補償はしないよ」という環境のこと。この環境には自アプリケーションの負荷がかかっていても他アプリケーションが正常に動く、という観点も含まれる。ただしWEBブラウザ上のアプリケーションに対してはここらへんを考えて品質設計されてるものを知らない🤔（ネイティブアプリではよくある）。そこらへんはブラウザアプリ側でよしなにしてくれているという仮説。（宿題にさせてください・・・）
◆使用性明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い。usability明示された利用状況・明示された利用者。というところがミソ。「誰でも」ではない。
➖ 適切度認識性製品又はシステムが利用者のニーズに適切であるかどうか（機能適切性）を利用者が認識できる度合い。テスト観点：利用者のニーズに適した利用。（スタートアップガイド・ヘルプページなども含む）appropriateness recognizability➖ 習得性明示された利用状況において、有効性、効率性、リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために、明示された利用者が製品又はシステムを利用できる度合い。テスト観点：覚えやすい使用方法になっているか。learnability➖ 運用操作性製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い。テスト観点：作業順序に応じた操作になっているか。operability
➖ ユーザーエラー防止性利用者が間違いを起こすことをシステムが防止する度合い。テスト観点：誤操作防止user error protection➖ ユーザーインターフェース快美性ユーザインタフェースが、利用者にとって楽しく、満足のいく対話を可能にする度合い。テスト観点：利用者が満足するシステムとの対話UI aesthetics➖ アクセシビリティ製品又はシステムが、明示された利用状況において、明示された目標を達成するために、幅広い範囲の心身特性及び能力の人々によって使用できる度合い。テスト観点：身体障害者を含む全ての人が快適・有効に使用できるか（年齢による身体障害も含む）accessibility
◆信頼性明示された時間帯で、明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合い。reliabilityソフトウェアが正常に稼働し続けられるか。また、障害発生時はすぐに復旧できるか。
➖ 成熟性通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。テスト観点：障害発生時に機能停止しない。（MTBF・・・Mean Time Between Failure）maturity➖ 可用性使用することを要求されたとき、システム、製品又は構成要素が運用操作可能及びアクセス可能な度合い。テスト観点：使用可能な状態の継続度。（24時間利用可能か）availability➖ 障害許容性（耐故障性）ハードウェア又はソフトウェア障害にもかかわらず、システム、製品又は構成要素が意図したように運用操作できる度合い。テスト観点：回避（エラー表示・制限）fault tolerance
➖ 回復性中断時又は故障時に、製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。テスト観点：障害復旧（ロールバックなど）recoverability📄memo機能仕様に対する不具合は「機能適合性」に包括されます。信頼性では障害（主には外的要因。AWS障害とか）時でもどれだけソフトウェアが正常に動くかが評価されます。ただし、不十分なエラー処理などシステム障害の起因となる不具合については信頼性に影響を及ぼします。例：AWS障害＞さくらに切り替えて回避・・・障害許容性を満たしていると言える。
◆セキュリティ人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように、製品又はシステムが情報及びデータを保護する度合い。securityハッキングやサイバーテロなどの全ての攻撃に対応できるセキュリティシステムは存在しない。今できうる最大の対策を継続する。権限管理は機能仕様のひとつではあるが、セキュリティを観点にした機能と言える。（必要な人にだけ必要なアクセスを）
➖ 機密性製品又はシステムが、アクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。テスト観点：許可された者のみがアクセスすることができるかconfidentiality➖ インテグリティコンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システム、製品又は構成要素が防止する度合い。テスト観点：許可していない者がアクセスすることができないかintegrity➖ 否認防止性事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明することができる度合い。テスト観点：利用事実の証拠を証明できるか（利用規約の同意チェックの記録など）non-repudiation
➖ 責任追跡性実体の行為がその実体に一意的に追跡可能である度合いテスト観点：ログの追跡が可能か（ユーザークレームに対して本当にそのユーザーがその手順で作業を行ったか確認できるのかなど）accountability➖ 真正性ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。テスト観点：本物であるかどうかを確実に証明できる（ID／Pass、生体認証など）authenticity
◆保守性意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い。maintainability「修正」には、環境における変更、機能仕様変更に対する訂正、改良または適応を含む。主には静的テスト対象物（ドキュメント・コード）の品質である。
➖ モジュール性一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。テスト観点：別々の構成要素の構成度合いmodularity➖ 再利用性一つ以上のシステムに、又は他の資産作りに、資産を使用することができる度合い。テスト観点：他システムへの再利用（ドキュメント類も含めることができる）reusability➖ 解析性製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。テスト観点：障害監視・ログ取得analysability
➖ 修正性欠陥の取込みも既存の製品品質の低下もなく、有効的に、かつ、効率的に製品又はシステムを修正することができる度合い。テスト観点：修正のしやすさmodifiability➖ 試験性システム，製品又は構成要素について試験基準を確立することができ、その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。テスト観点：試験のしやすさtestability
◆移植性一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い。portabilityオンプレなどインストール先の環境に変更が入る可能性の高いシステムでは重要度が高い。が、クラウド型サービスではクラウドという形自体が移植性をある程度までは担保できるサービスの形ではとおもったりしてます。（完全に個人談）
➖ 適応性異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に、製品又はシステムが適応できる有効性及び効率性の度合い。テスト観点：移植・OSの入れ替えadaptability➖ 設置性明示された環境において、製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度合い。テスト観点：インストールのしやすさ、システムの初期導入手順installability➖ 置換性同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。テスト観点：他製品（またはスプレッドシートなどの管理機構）からの置換えが可能か。csvのインポート機能なども含まれるreplaceability
品質特性を知っておくと何がいい？1. 開発しているサービスの現状の品質を客観的に意識することができる2. システムの成長フェーズによって注力する品質は異なる。「今本当に注力したい品質（今ユーザーに届けたいもの）」について、チーム内で認識するための共通言語が持てる3. 競合サービスを品質特性から分析し、自社サービスと比較することができる
品質は常に相対評価である競合サービスと比べてどうか 時代と環境に合っているのかまずは実務に必要な機能があるのか、あるとしたらコストはどうか、コストに対して使用性はどうか。いろんな面で比べられています。自分たちではいい！と思っていても周りと比べるとその品質ってどうですか？※品質がいい ≠ 不具合がない例えば2020年1月1日に「高品質」かつかぎりなくパーフェクトな状態でリリースしたシステムを2025年12月31日まで放っておいたらどうでしょう。システムの品質は100%下がります。子どもと違って、システムは一人では育たないし、周りの環境は常にアップデートされていくからです。
まとめ品質に正解はない。何年も何十年もその先も、ユーザーと伴走できるシステムになるには、何が必要か考えてみよう！
参考資料：◆日本工業規格http://kikakurui.com/x25/X25010-2013-01.html◆ISO／IEC 25010の品質モデルを使って市場不具合を減らすテスト設計千尺〜品質を「見える化」する〜http://www.jasst.jp/symposium/jasst21tokyo/pdf/A4.pdf◆第8回 「ソフトウェア品質特性」（2）https://www.otsuka-shokai.co.jp/erpnavi/topics/column/ipapsq/softwarehinshitsunotokusei2.html◆非機能要求とISO9126https://www.ogis-ri.co.jp/otc/hiroba/technical/JavaPress_ISO9126/◆システム及びソフトウェア製品の品質要求及び評価（SQuaRE) -システム及びソフトウェア製品品質の測定量http://www.sic.shibaura-it.ac.jp/~tsnaka/lecture/ese/JIS%20X25023.pdf
スライド構成👑「品質特性」を意識することでなにがいいのか● 品質特性とは○ 国際標準のはなし○ 品質要因のはなし○ なぜ作られたのか○ ソフトウェア製品の品質特性について（その他６つパターンなどもせつめい）● 個々の品質特性と副特性のはなし○ 機能適合性からじゅんばんに● 品質特性とユーザーフォーカス
Meety や Twitterでぜひお話ししましょう🐥
honamin09
ryomaru0825
lefred
optim
shohata
whywaita
shin_higuchi
microcms
yoyakoba
miyake
yuya4
ryohatanmonolog
nagauta
chriscoyier
holman
akmur
sachag
hursman
colly
davidbonilla
mthomps
keathley
tenderlove
zakiyama
zenorocha