ソフトウェア開発におけるソフトウェア品質とは

ソフトウェア開発でのソフトウェア品質

現代社会はシステム・ソフトウェアに深く依存しています。日常的にスマートフォンやパソコンを使って、さまざまなサービスを利用しています。直接ITとは無関係と思われるサービスでも、ソフトウェアが裏方で動いていることが多いです。その様なソフトウェアが思い通りに動かないと不便ですね。ソフトウェア品質が私たちの生活を支えているのです。

今回は、システム開発の中で見落としがちな「ソフトウェア品質」について解説します。

ソフトウェア開発プロセス

日本科学技術連盟SQiPソフトウェア品質委員会と日本品質管理学会ソフトウェア部会の共同プロジェクトとして2007年にSQuBOK(Software Quality Body of Knowledge: ソフトウェア品質に関する知識体系)が発行されました。

SQuBOKではソフトウェアの各開発工程とテスト工程の関係を表わしたV字モデルを紹介しています。

システム開発は利用者の要望・要求をまとめる「要求定義」から始まり、要求定義を基にシステム化の仕様につなげる「要件定義」と移行します。V字モデルの左半分を「品質を作りこむ工程」や「上流工程」、右半分を「品質を確認する工程」や「下流工程」と呼びます。

ソフトウェア品質の定義

ソフトウェア品質については様々な理解がありますが、ここではソフトウェア品質管理の専門家が説明している定義をご紹介いたします。

Philip B. Crosby

経歴:経営理論と品質管理の実践に貢献した実業家で作家。Crosby氏はマーティンカンパニーでゼロ欠陥プログラムを開始しました。
パーシングミサイルプログラムの品質管理マネージャーとして、Crosby氏は全体的な拒否率を25%削減し、スクラップコストを30%削減したとされています。

定義:品質とは「要件に対する適合」であると定義した上で、精密に測定可能であること、及び誤りは不可避ではないと説明しています。
品質マネジメントに関するCrosby氏の考え

・無欠陥(Zero Defect):欠陥の無いものを最初から正しく作るべき。
・検査より予防:予防コストは欠陥を是正するコストに比較するとはるかに少ない。


(出典:SQuBOK策定部会 ソフトウェア品質知識体系ガイド)

William Edwards Deming

経歴:ニューヨーク大学経営大学院(後のスターン経営大学院)の教授などを歴任した方であり、1950年頃から日本の企業経営者に設計・製品品質・製品検査・販売などの改善法を伝授し、日本がイノベーティブな高品質製品を製造し経済力を高めるのに多大な貢献を残しています。

定義:品質について「第一に考えなければならないのは、値段なるものは、その製品の品質という条件を除いてならない。併しそれだけでは不十分である。
”良い品質”と”均一の品質”は消費者の要求に合致したものを除いては無意味である」と述べています。


(出典:SQuBOK策定部会 ソフトウェア品質知識体系ガイド)

Gerald Marvin Weinberg

経歴:アメリカ合衆国の作家、心理学教師、そしてソフトウェア開発の人類学者。彼の有名な著作、『プログラミングの心理学』、『一般システム思考入門』の他多くが、ソフトウェア開発・プログラミング・コンピュータ科学の名著とされています。

定義:品質には、立場によって重視することが異なるという相対性があり、「品質は誰かにとっての価値である」と考え、これを次のような例で述べています。

・ソフトウェアを1日8時間利用するユーザーにとっては使い勝手のよさが高品質である。
・故障のたびに批判されるシステム管理者にとってはゼロ故障が高品質である。
・厳しい予算の制約下にあるプロジェクト管理者にとっては、開発費用が少ないことが高品質である。


(出典:SQuBOK策定部会 ソフトウェア品質知識体系ガイド)

狩野紀昭(かのうのりあき)

経歴:東京理科大学名誉教授。日本の教育者、著述家、コンサルタントです。顧客にとっての品質を左右する、製品に「不可欠な」要素と「他の製品と差別化する」要素とを峻別したシンプルなランキングによる顧客満足モデルを開発しました。 2010年度にはローマ大学の客員教授を務めました。

定義:狩野氏は「魅力的品質」「一元的品質」「当たり前品質」という視点で定義しました。
これは、顧客の心理的満足感と製品・サービスの性質がもたらす物理的充足状況から説明した概念です。

魅力的品質要素
それが充足されれば満足を与えるが、不十分であっても仕方がないと受け取られる品質要素。魅力的本質とも呼ぶ。

一元的品質要素
それが充足されれば満足、不十分であれば不満を引き起こす品質要素。一元的要素とも呼ぶ。

当たり前品質要素
それが充足されれば当たり前と受け取られるが、不十分であれば不満を引き起こす品質要素。当たり前品質とも呼ぶ。


(出典:SQuBOK策定部会 ソフトウェア品質知識体系ガイド)

システム開発におけるソフトウェア品質の重要性

ソフトウェア品質リスク

システム開発におけるソフトウェア品質の重要性を実感して頂くために、ソフトウェア品質が担保出来なかった事例をご紹介いたします。

事例1 セブン&アイ・ホールディングス傘下セブン・ペイ社
<スマホ決済サービス「7pay」の第3者不正アクセス>

・2019年7月1日にサービス開始したが、わずか4日後に不正アクセスが発覚して、サービス停止。
・被害者約800人、被害総額3800万円(7/31時点)。
・外部で不正に入手したID・パスワードのリストを使って容易になりすまし、アクセスできてしまった。
・ログイン時の2段階認証が採用されていなかった。
・サービス開始以降に7pay専用アプリのリリースや不正検知ソフトのバージョンアップ等、段階的にセキュリティ機能を高める方針だったという。

→2019年9月末でのサービス廃止を発表。

事例2 ソフトバンク社
<携帯電話サービスの大規模通信障害>

・2018年12月6日、通信回線をつなぐ交換設備の不具合により、全国で通話とデータ通信が利用できない状態が約4時間つづいた。
・「ワイモバイル」や同社の回線を借りている格安通信事業者でも同様に通信障害は発生した。
・全国をカバーしているスウェーデン通信機器大手エリクソンの交換設備でソフトウェアに異常が発生した。
・エリクソンを利用する海外11か国の通信事業者でもほぼ同じ時刻に障害が発生した。
・ソフトバンクの携帯契約数は4043万件(2018年9月)で、通信障害の影響数は3060万回線。

→解約1万~2万件が発生。

以上のように、ソフトウェアが利用者目線での作りこみがされていないと、利用者に多大な迷惑と不便をかけます。
それだけにソフトウェアの品質を管理し、確保する事が重要となります。

次にソフトウェア品質特性とはどの様なものを含んでいるか解説します。


システム開発におけるソフトウェア品質特性

ソフトウェア品質を「誤りの有無」のみでなく、ユーザーのニーズを満たすためのさまざまな視点でソフトウェア品質特性を評価するために、国際標準として統一された品質モデルが下図の様に規定されました。

ISO25010 製品品質モデル

機能適合性
明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を、製品又はシステムが提供する度合い。

性能効率性
明記された状態条件で使用する資源の量に関係する性能の度合い。

互換性
同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び/又はその要求された機能を実行することができる度合い。

使用性
明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い。

信頼性
明示された時間帯で、明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合い。

セキュリティ
人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように、製品又はシステムが情報及びデータを保護する度合い。

保守性
意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い。

移植性
一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い。


データの品質モデル(JIS X 25012 に基づく)

固有のデータ品質特性
正確性・完全性・一貫性・信憑性・最新性が該当します。

固有及びシステム依存のデータ品質特性
アクセシビリティ・標準適合性・機密性・効率性・精度・追跡可能性・理解性が該当します。

システム依存のデータ品質特性
可用性・移植性・回復性が該当します。


利用時の品質モデル(JIS X 25010 に基づく)

有効性
明示された目標を利用者が達成する上での正確さ及び完全さの度合い。

効率性
利用者が特定の目標を達成するための正確さ及び完全さに関連して、使用した資源の度合い。

満足性
製品又はシステムが明示された利用状況において使用されるとき、利用者ニーズが満足される度合い。

リスク回避性
製品又はシステムが、経済状況、人間の生活又は環境に対する潜在的なリスクを緩和する度合い。

利用状況網羅性
明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において、有効性、効率性、リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

プロダクト品質とプロセス品質

ソフトウェア品質を把握するには、プロダクト品質とプロセス品質の両面から分析することが必要です。

プロダクト品質とプロセス品質

ソフトウェア開発のプロダクト品質とプロセス品質

プロダクト品質

結果の品質

プロセス品質

結果に至る過程の品質

プロダクト品質

ソースコードやドキュメントなどの成果物、アウトプット

プロセス品質

各開発工程そのもののやり方、所要時間など

・プロダクト品質は結果の品質で、製品品質と利用時の品質を総称して呼びます。
・プロセス品質はプロダクト品質に至るまでの開発工程の品質を呼びます。

プロセス品質ではQCDバランスを考慮します。

QCDとは

・Q (Quality) – 品質
・C (Cost) – 費用
・D (Delivery) – 納期

例えば、ウォーターフォールモデル開発では、設計→コーディング→テストと順を追って各工程で進めていますが、プロセス品質は、プロセス実施状況の十分性により評価をします。
プロダクト品質は、各工程の成果物の完成状況により評価します。

ソフトウェア品質は、プロセス品質とプロダクト品質の両面から評価することが重要です。

システム開発品質診断(クオリティドクターカルテ)について

システム開発、ソフトウェア開発では、「炎上」という表現が使われるほど、大きな問題が起きて火消が必要な状況が生まれます。順調に思われるシステム開発でも、目に見えない問題が潜んでいる事も多いです。

システム開発品質診断(クオリティドクターカルテ)とは、プロジェクトのどこに問題があるか、どこに弱点があるのか、システム開発(ソフトウェア開発)のあるべき姿の視点で分析&評価するサービスです。

下記リンクのサービス紹介ページから資料ダウンロードし、ご検討下さい。

まとめ

ソフトウェア品質管理専門家の方々が定義している内容や、ソフトウェア品質が重要視される事例などご紹介をしました。
ソフトウェア開発の段階から、ソフトウェア品質を管理することは必須です。システム構築では、複数の工程を経てソフトウェアの完成に近づきます。

その各工程でソフトウェアのテスト・検証を行うことが、品質を高めるのに大切なステップとなります。テスト・検証を繰り返すことで、不具合を未然に防ぐことが可能です。
プロジェクトチームがテスト・検証を繰り返し行い、品質管理を行う部署がテスト・検証の進捗確認をし、改善を繰り返すことで、ソフトウェア品質を管理、品質向上につながります。

顧客がどれほどの品質を要求しているのか、満足度はどこにあるのかを知ることが、ソフトウェア品質を管理し高めることにつながります。
顧客が抱えている課題を解決する策を要求定義というかたちで書面化することがスタートポイントとなります。

次回予告:「ソフトウェア品質向上」について(2021年12月掲載)
品質向上をするための重要ポイントをレクチャーします!

Twitterでフォローしよう

おすすめの記事