~ソフトウェア品質の向上とそこに関わるすべての方へ~ Software Quality Profession

3.SQuBOK®

ソフトウェア品質知識体系ガイド-SQuBOK® Guideについて 第2回

SQuBOK® 編集チーム

株式会社NTTデータ 町田 欣史
富士通株式会社 辰巳 敬三
日立情報通信エンジニアリング株式会社 池田 暁


はじめに


 QualityOneをご覧になっている方々はすでにご存じかもしれませんが、本連載で取り上げているSQuBOK®ガイドが、2008年度の日経品質管理文献賞を受賞しました。このような栄誉ある賞をいただき、策定部会メンバも、よりいっそう気を引き締めて取り組んでいく決意を新たにしております。今後とも皆様のご指導ご鞭撻をいただければ幸甚でございます。
(参考:2008年度 デミング賞本賞・実施賞・日経品質管理文献賞 受賞者一覧

さて、第1回ではSQuBOK®およびSQuBOK®ガイドがどういうものであるかを解説しました。今回からは、いよいよ実際のSQuBOK®ガイドの中身に入っていきたいと思います。
第2回は、SQuBOK®ガイドの1つめのカテゴリである「ソフトウェア品質の基本概念」について解説します。と言っても、カテゴリ内のすべてをとりあげるわけにもいきませんので、読み進める上で、意識すべきことや重要な部分を中心に解説します。


「ソフトウェア品質の基本概念」カテゴリの概要


 このカテゴリは、基本概念というだけあって、「品質」「品質管理」といった、普段何気なく使っている用語の定義や考え方について整理をしています。
そもそも、「品質」という言葉自体が漠然としたものです。皆さんも普段から「このシステムの品質はボロボロだ」とか「ちゃんと品質を満たしているのか」などという会話をすることがあるでしょう。こんなとき、その「品質」という言葉が何を指しているのか、会話の相手と認識が合っているでしょうか。この意識が組織でブレてしまうと、目指すべき品質のベクトルが決まらないどころか、気がついてみたら全く別のところを目指していたという事態にもなりかねません。また、顧客やユーザとの間でも、求められる品質について早い段階で意識合わせをしておくことが非常に大切です。
まずは、このカテゴリに書かれた品質の概念をしっかりと理解し、それを踏まえた上で共通の認識をもつこと(決めていくこと)が重要となります。


「品質の定義」が10個もある!


 さて、「ソフトウェア品質の基本概念」カテゴリの樹形図を見てみると、「品質の定義」というトピックスがなんと10個もあります。先ほど、「品質」の認識を合わせましょうという話をしましたが、これでは、「じゃあどの定義に従えばいいの」と逆に混乱してしまうかもしれません。

SQuBOK®ガイドは、読者を混乱させようとして10個もの定義を載せているわけではありませんし、どれかの定義を選ばなければいけないということでもありません。
では何故それだけの定義を載せているのでしょうか?
その答えの一つは「様々な視点により品質の考え方は異なる」ということです。また、言葉は時代によって変わると言われますが、品質についても、その時代の社会環境や技術の進展にともなって考え方や概念は変わります。
先人たちが考え、そして実践してきた定義は皆さんにとってきっと品質に関するベースを作ってくれることでしょう。そして、これらの定義を皆さんの組織で、かみ砕いて、よりわかりやすく、より具体的に表現することで、品質に対する認識の共有を図ることができるでしょう。

これら10個の品質の定義をよく読んでみると、共通して言えるのは「顧客やユーザの要求・ニーズを満たしているかどうか」であると言えそうです。ソフトウェア開発に携わる人は、どうしても作り手の視点になってしまいがちです。使う側の視点を常に意識することで、品質の高いソフトウェアを開発することができるでしょう。


「品質」をもっと具体的に(品質特性)


 さて、品質の定義に共通した概念はユーザのニーズに対する満足度だということが見えてきましたが、一口にユーザのニーズといっても様々なものがあります。また、「品質の定義」知識領域の解説には次のように書かれています。『例えば、1950年代は正しく動くことがユーザにとって重要であったが、その後、信頼性や処理時間に焦点が移り、1980年代には信頼性は当たり前品質と言われてユーザビリティに目が向けられた。そして現在はセキュリティがユーザの大きな関心事の一つになっている。』このように、求められる品質は時代とともに変化していることが伺えます。

この「品質」を、より具体的な「品質特性」として表したものにソフトウェア品質モデルがあります。有名なものにISO/IEC 9126シリーズがあり、SQuBOK®でもトピックスとして取り上げています。このモデルではソフトウェアの品質を「内部品質」「外部品質」「利用時の品質」の3つに分け、開発の途中段階、完成段階、および利用状況下での品質評価に対応させています。また、外部及び内部品質を「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の6つの品質特性、利用時の品質を「有効性」「生産性」「安全性」「満足性」という4つの品質特性で表しています。

このように「○○性」という言葉まで具体化されると、品質というものがよりイメージしやすくなったのではないでしょうか。顧客やユーザによって、どの品質特性を重視するかは異なることが多いものです。これらの具体化された品質特性を基に、顧客と合意を得ることで、より高い品質、すなわち顧客満足度の向上につながるでしょう。


マネジメントとコントロールの違いが分かりますか?


 SQuBOK®ガイドでは「品質マネジメント」「品質コントロール」という用語が使われています。なぜ「品質管理」と言わないのだろうと不思議に思った人がいるかもしれませんね。

日本では、controlとmanagementの訳語としてどちらも「管理」が使われてきましたが、別の単語であることから明らかなように欧米では異なる概念です。SQuBOK®ガイドではこの違いを明確に意識できるように「管理」とは訳さず、「マネジメント」「コントロール」のままとしています。
では、それぞれどういう意味なのでしょうか。

ISO9000では、「品質マネジメント」は『品質に関して組織を指揮し、管理するための調整された活動』と定義されています。また、「品質コントロール」は『品質要求事項を満たすことに焦点を合わせた品質マネジメントの一部』と定義され、品質マネジメントの下位の概念になっています。


「品質コントロール」と「品質保証」の役割


 品質管理(品質コントロール)や品質保証という言葉を、特に違いを意識せずに使っている方も多いのではないでしょうか。

SQuBOK®では「ソフトウェア品質の基本概念」カテゴリの2つ目の知識領域「品質のマネジメント」で、それぞれISO9000の定義を引用して解説を加えています。「品質コントロール」の定義は前述したとおりです。一方、「品質保証」は『品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部』と定義されています。

これらの定義を読むと、まず「品質マネジメント」の中に「品質コントロール」と「品質保証」があることが分かりますね。ただ、両者の違いを、品質要求事項を「満たすこと」か「満たされるという確信を与えること」という表現の違いだけで理解するのは難しいかもしれません。
「品質保証」の具体的な方法には、副知識領域にもなっている「検査」や「V&V」「ソフトウェア測定」などがあります。これらの方法が、「確信を与える」ための手段ということになります。一方、これらの方法を使って品質を保証するために、求められる品質の基準が満たされるように活動を進めていくことが「品質コントロール」と言えます。

皆さんの組織では、「品質マネジメント」つまり品質に関する一連の活動を指して「品質管理」と言っていることが多いのではないでしょうか。それ自体は悪いことではありませんが、その中で「品質保証」と「品質コントロール」を正しく行うことが大切です。


「ディペンダビリティ」って?


 最後に、このカテゴリの中で重要なキーワードを1つとりあげましょう。それは「ディペンダビリティ」です。同じ知識領域にある「セキュリティ」や「ユーザビリティ」はご存じの方も多いと思いますが、この「ディペンダビリティ」という言葉はなじみのない方が多いのではないでしょうか。

「ディペンダビリティ」については副知識領域の説明が最もわかりやすいと思います。ディペンダビリティは信頼性と訳されることもありますが、同じく信頼性と訳されるReliabilityやAvailability(可用性)、Maintainability(保守性)の上位に位置付けられ、時間的な経過や様々な利用状況の下での品質までを含めた包括的な概念です。

私たちの身の回りは、その大部分がIT化され、ソフトウェアなしでは生活できないのが現状です。そういった中で利用しているソフトウェアには、作られてから何十年も経ってしまい、それに伴う品質問題が起こりうる可能性があることを意識する必要がでてきました。
この考えは、ソフトウェアが一部の人のためのものだった時代にはなかったもので、現代ならではの新しいものです。これも、品質の考え方が時代によって変わることの例と言えるでしょう。今後は、ソフトウェアの作り手として、長期的な利用も意識した品質保証が必要になるということに注意しましょう。


終わりに


 このカテゴリは、「そもそも品質とは」というかなりお堅いテーマなので、理解に時間がかかるかもしれません。SQuBOK®ガイドでは、実際の定義が書かれている規格を引用しつつ、それらをよりわかりやすく解説していますので、皆さんの理解の手助けになると思います。
次回は残り2つのカテゴリのうち、開発者の方にとってより身近な「ソフトウェア品質技術」を取り上げる予定です。


プロフィール
町田 欣史(SQuBOK® 編集チーム)
株式会社NTTデータ 技術開発本部 ソフトウェア工学推進センタ
JSTQBテスト技術者資格認定 技術委員会
社内にてテストプロセス改善の研究、テスト支援ツールの開発、プロジェクト支援を行う。

辰巳 敬三(SQuBOK® 編集チーム)
富士通株式会社 ソフトウェア事業本部・事業計画統括部
日科技連SQuBOK®策定小委員会・副委員長
ライフワークとして、ソフトウェア品質、テスト技術に取り組む。

池田 暁(SQuBOK® 編集チーム)
日立情報通信エンジニアリング株式会社 技術・IT戦略本部 ソフトウェア技術部
NPO法人ソフトウェアテスト技術振興協会 理事
ソフトウェアテストワークショップ 実行委員長
社内では設計/テストツールの普及活動やプロセス改善業務に従事。また社外においてもコミュニティを中心に品質/テスト技術の普及に取り組む。最近主に取り組んでいるテーマはテスト設計技術で、自らも日々勉強中。
ソフトウェア品質のホンネ
SQuBOKソフトウェア品質体系ガイド
セミナー
SQiPセミナー
SQiPセミナー開催レポート
研究会
ソフトウェア品質管理研究会
シンポジウム
ソフトウェア品質シンポジウム
資格試験
ソフトウェア品質技術者資格試験
JSTQB 認定テスト技術者資格
国際会議
世界ソフトウェア品質会議
ASQN
ニュース
SQiPニュース
webマガジン「QualityOne
コミュニティ
ソフトウェア品質確証部長の会(東京)
ソフトウェア品質保証責任者の会(大阪)
SQiPコミュニティ
SQiP SIG
SQiPアーカイブ(研究成果や実践事例集
SQiPライブラリ
ソフトウェア品質管理の宝箱
調査・研究
ソフトウェア品質実態調査
調査・研究
 SQuBOK®ガイド