ソフトウェア品質とは?

現代の日本では生活やビジネスにソフトウェアは欠かせないほど依存している。誰もが日常的にスマートフォンやパソコンを用いて、様々な便利なサービスを毎日利用しているのだ。また直接ITと関係ないようなサービスであっても、ソフトウェアを用いて管理されている。つまりなんらかのかたちでソフトウェアの品質が私たちの生活に関わっているのである。
このブログではソフトウェアの品質保証に関わる内容を取り上げているが、そもそも「ソフトウェア品質」とはいったいどういったものだろうか。

品質の定義

ソフトウェアが用いられ始めた1970年代、品質についてケイパース・ジョーンズ(Capers Jones)はこう述べている。

ソフトウェアを完全に停止させたり、容認できないような結果を出す欠陥が全くないこと

つまり、致命的なバグのない=「品質が良い」と考えられていたのである。当時はコンピュータやソフトウェアの性能があまり良くなく、かつ高価であったがゆえに、あまり流通していなかった。そのため、問題なく動くことが品質が良いと考えられていたのだろう。

しかし、この定義を現代に当てはめることはできない。仮に一切バグのない(ソフトウェア工学的にはありえないが)ソフトウェアがあったとして、使い勝手や性能が悪くても、利用者を満足させることはできるだろうか。

ソフトウェアが社会に普及していく中で、ソフトウェア品質の定義について議論は交わされるものの、明確な答えが出ることはなかった。そうした中で、1994年にソフトウェアの人類学者ジェラルド・ワインバーグは著書でこう述べている。

品質とは誰かにとっての価値である

出典 Quality Software Management: Systems Thinking v. 1

近代のソフトウェア品質に大きな影響を与えたきっかけとなる著書でもあるが、品質とは確かな答えがあるのではなく、実は主観的なのだということを示している。先ほど例に挙げたバグがないだけのソフトウェアは、一般人が日常生活で利用するのであれば、決して品質の良いものではない。

例えば、あなたがランチによく訪れるA定食屋とB定食屋があり、値段・提供される時間・混み具合など、定量的なデータは殆ど一緒であるが、A店の方は「いらっしゃいませ!」「またのお越しをお待ちしております!」と元気よくあいさつしてくれる。B店は反対に、「らっしゃい、また来たの」「毎度」と同じ親父からぶっきらぼうにあいさつされる。

あなたはどちらの方が、品質が良いお店だと感じるだろうか?

ここでキーになるのが、”誰か”である。
A店は万人ウケするサービスを提供しており、誰か=万人にあたる。
しかし、B店は「また来たの」と来店してきた個人を認識しており、誰か=あなたである。
自分を認識されるという事は気持ちの良さがあり、ロボットのようなあいさつしかしない店員とはまた違った満足度を得られる事ができる。ただ、個人を認識されたくない(食事の邪魔をされたくない)人にとってはありがた迷惑な話でもある。このように求められる品質は、そのユーザーそれぞれで全く異なるなのだ。

ジョーンズ氏とワインバーグ氏の品質定義について述べてきたが、2つの考え方のどちらが正しいかではなく、要は多角的な観点での品質分析を行う事が重要であると読み解いていただきたいのである。

高い品質を確保するには

346461

品質に関する考え方について考察したが、これを踏まえて顧客の求める品質を確保するには、どうアプローチすべきなのだろうか。
それにはまず、ソフトウェアの特徴を押さえる必要がある。

  • 目に見えない
  • 自由度が高い
  • 人への依存度が高い

出典 第3者検証におけるアシュアランスケース入門 宇宙航空研究開発機構(JAXA)

まず「目に見えない」というのは、ひと目見ただけではどう動いているのかわからないということである。例えば車を作る工場であれば、パーツを作る、組み立てる、溶接する、といったように過程を目で見ることができる。しかしソフトウェアはそうした工程をすべてソフトウェア内で行うため、実際に目で見ることはできない。そのため問題が発生した場合、原因の特定が難しい。

次に「自由度が高い」というのは、要望にあわせて機能やデザインを変更、追加が行い易いということである。製品開発に制限が少なく柔軟に対応できる。加えて、アップデート等で、ソフトウェアの改善や問題解決が行えるという点も自由度が高いというところにつながっている。

最後に「人への依存度が高い」というのは、開発者のスキルに左右されやすいということである。ソフトウェアはあくまで人が作るため、個人のスキル、環境、人員、時間などに影響を受けやすいのだ。

これらの特徴から、より高い品質を確保するために行うこととして以下のように記載されている。

  • テスト結果から、ソフトウェアが期待通り動作することを確認すること
  • ソフトウェアへ期待することを要求仕様として記録すること
  • 開発方法やプロセスを決め、個人スキルへの依存を減らすこと

出典 第3者検証におけるアシュアランスケース入門 宇宙航空研究開発機構(JAXA)

しかし、これだけでは真に顧客の要望に応えられているのかわからない。そのためこれらを踏まえた上で、品質の可視化が求められている。

近年のいくつかの大規模システム障害の発生により、システム・ソフトウェアの品質が個人の みならず社会に大きな影響を与えることが強く認識されてきている。こうした背景より、 システム・ソフトウェアに具備すべき品質は何かが問われるとともに、他産業のサービス同様に、利用者のニーズや利用シーン、運用コスト等の制約条件に適応した品質の可視化、確保が求められてきている。

出典 システム及びソフトウェア品質の見える化、確保及び向上のためのガイド ソフトウェアメトリクス高度化プロジェクト プロダクト品質メトリクスWG

品質の可視化とは顧客の求める品質を明確化し、開発者との共有を行うことだ。顧客から提出された要望を正しく整理し設計に組み込むことが必要となる。さらに開発者はソフトウェアの品質について顧客と情報を共有しなければならないのだ。

ソフトウェアの品質特性

品質を評価するに当たって、特性を分析して整理することが品質向上につながる。ソフトウェアの持つ様々な特性を分類したものは、ソフトウェア品質特性モデルと呼称され、JIS X 0129-1:2003 (ISO/IEC 9126-1:2001)に定義されている。

図1

photo by 組込みソフトウェア開発における品質向上の勧め(コーディング編)/IPA公開資料

図2


出典 JIS X 0129-1(ISO/IEC9126:2001)ソフトウェア品質特性

ソフトウェアをこの品質特性モデルに当てはめることで様々な視点から長所、短所を分析できるため、品質の可視化を行うことができるだろう。

次に各品質特性をより細かく分類した品質副特性を紹介する。

機能性

  • 合目的性

    指定された作業及び利用者の具体目標に対して適切な機能の集合を提供するソフトウェア製品の能力

  • 正確性

    必要とされる精度で、正しい結果、または同意できる結果をもたらすソフトウェア製品の能力

  • 相互運用性

    1つ以上の指定されたシステムと相互作用するソフトウェア製品の能力

  • セキュリティ

    許可されていない人またはシステムが、情報やデータを読んだり、修正したりすることができないように、もしくは許可された人またはシステムがアクセスを拒否されないように、保護するソフトウェア製品の能力(JIS X 0160:1996)

  • 機能性標準適合性

    機能性に関連する規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力

機能性は以上4項目に分類される。正しい結果を出力する正確性の重要性はもちろん、セキュリティも重要な特性と言えるだろう。個人情報など重要なデータを扱うのであれば、より一層の注意が必要である。

信頼性

  • 成熟性

    ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力

  • 障害許容性

    ソフトウェアの障害部分を実行した場合、または仕様化されたインタフェース条件に違反が発生した場合に、指定された達成水準を維持するソフトウェア製品の能力

  • 回復性

    故障時に指定された達成水準を再確立し、直接に影響を受けたデータを回復するソフトウェアの能力

  • 信頼性標準適合性

    信頼性に関連する規格または規約を遵守するソフトウェア製品の能力

信頼性は以上4項目に分類される。障害が起こるという想定のもと、無用な混乱を引き起こさないために準備は必須である。障害が発生してからでは遅いのだ。

使用性

  • 理解性

    ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、およびどのように利用できるかを利用者が理解できるソフトウェア製品の能力

  • 習得性

    ソフトウェアの適用を利用者が習得できるソフトウェア製品の能力

  • 運用性

    利用者がソフトウェアの運用及び運用管理を行うことができるソフトウェア製品の能力

  • 魅力性

    利用者にとって魅力的であるためのソフトウェア製品の能力

  • 使用性標準適合性

    使用性に関連する規格、規約、スタイルガイドまたは規則を遵守するソフトウェア製品の能力

使用性は以上5項目に分類される。利用者が使いやすく魅力的なものを作るということは、ソフトウェアに関わらずモノづくりの基本的な原則である。

効率性

  • 時間効率性

    明示的な条件の下で、ソフトウェアの機能を実行する際の、適切な応答時間、処理時間及び処理能力を提供するソフトウェア製品の能力

  • 資源効率性

    明示的な条件の下で、ソフトウェア機能を実行する際に、適切な資源の量及び資源の種類の選択の下に使用するソフトウェア製品の能力

  • 効率性標準適合性

    効率性に関連する規格または規約を遵守するソフトウェア製品の能力

効率性は以上3項目に分類される。主に性能に関する品質特性です。コードレビューやリファクタリングを行い、無駄な処理を減らすことができる。

保守性

  • 解析性

    ソフトウェアにある欠陥の診断または故障の原因の追求、およびソフトウェアの修正箇所の識別を行うためのソフトウェア製品の能力

  • 変更性

    指定された修正を行うことができるソフトウェア製品の能力

  • 安定性

    ソフトウェアの修正による、予期せぬ影響を避けるソフトウェア製品の能力

  • 試験性

    修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力

  • 保守性標準適合性

    保守性に関連する規格または規約を遵守するソフトウェア製品の能力

保守性は以上5項目に分類される。修正の難しいプログラムは問題発生時に、無駄なミスやコストを生んでしまいかねない。信頼性と同じく、あらかじめ問題を想定したソフトウェアを作る必要があるのだ。

移植性

  • 環境適応性

    ソフトウェアにあらかじめ用意された以外の付加的な作業又は手段なしに、指定された異なる環境にソフトウェアを適応させるためのソフトウェア製品の能力。

  • 設置性

    指定された環境に設置するためのソフトウェアの能力

  • 共存性

    共通の資源を共有する環境の中で、他の独立したソフトウェアと共存するためのソフトウェア製品の能力

  • 移植性標準適合性

    移植性に関連する規格または規約を遵守するソフトウェア製品の能力

  • 置換性

    同じ環境で、同じ目的のために、他の指定されたソフトウェア製品から置き換えて使用することができるソフトウェア製品の能力

移植性は以上の4項目に分類される。開発環境でのソフトウェア動作を確認するだけでなく、利用者の動作環境を考慮に入れてテストを行う必要がある。

出典 ISO/IEC9126(JIS X 0129-1:2003)ソフトウェア品質特性

まとめ

ここまで、「ソフトウェア品質」について詳しく記載したが、いかがだっただろうか。読者が品質に対する意識が強まったのであれば、筆者にとって品質の高い記事であったと言えるであろう。品質の良いソフトウェアと言って出荷をしても、人それぞれの基準が大きく異なってしまうため悪い評価を受けてしまう事もある。品質に対する知識を深めていただき、誰かにとってもあなたにとっても価値のあるソフトウェアを世に送り出してもらいたい。


テクバンの品質ソリューション事業部 特設サイトでは、「ソフトウェアテスト」や「テスト自動化」に関するサービスのご紹介をしております。

「プロダクトやサービスの品質がなかなか上がらない…」

「テスト自動化の導入/運用をしたいがどう進めたらよいか分からない…」

などのお悩みをお持ちの方は、以下のリンクからぜひお気軽にご相談ください。

また、「ソフトウェアテスト」や「テスト自動化」のお役立ち資料も掲載しておりますので、こちらも合わせてご利用ください!