ソフトウェア品質の重要性とは?評価するための方法や品質向上の解決策
目次[非表示]
- 1.ソフトウェア品質とは
- 2.ソフトウェア品質管理の7つの手法
- 3.ソフトウェア品質管理の実践方法
- 4.ソフトウェア品質の標準化が必要な理由
- 5.「正常に動作する」から「満足するモノづくり」へ
- 6.ソフトウェア品質への要求はステークホルダーによって違う
- 7.ソフトウェア品質の国際規格と8つの分類
- 8.ソフトウェアテストの実施と7原則
- 8.1.【1】テストが示せるのは欠陥の有無だけ
- 8.2.【2】全てのテストを行うことは不可能
- 8.3.【3】早期テストは時間とコストを抑えられる
- 8.4.【4】欠陥の偏りを予測する
- 8.5.【5】殺虫剤のパラドックスに注意
- 8.6.【6】テストは状況や目的に合わせる
- 8.7.【7】「欠陥ゼロ」の落とし穴
- 9.テスト自動化を導入する4ステップ
- 9.1.ステップ1ーテスト自動化の導入に向けて調査・分析を行う
- 9.2.ステップ2ー何のためにテスト自動化を導入するのかを明確にする
- 9.3.ステップ3ーテスト自動化をする範囲を決める
- 9.4.ステップ4ー自動化するためのツールを選ぶ
- 9.5.ステップ5ーテスト自動化の環境を整えてテストする
- 10.まとめ
ソフトウェア品質とは
ソフトウェア開発では「Quality(品質)」「Cost(費用)」「Delivery(納期)」が重要とされており、頭文字をとって「QCD」と呼ばれています。
「QCD」では、品質が最も重視されています。しかし、一口にソフトウェアの品質と言っても、捉え方は人それぞれ違います。バグがなく、ソフトウェアが仕様通りに動作するだけで高品質という人もいれば、それ以上の機能が備えられていなければ品質が低いと考える人もいるでしょう。目に見えて触れることのできるハードウェアに対して、ソフトウェアの品質を評価することは困難と言えます。
ソフトウェア品質管理とソフトウェア品質保証の違い
そんなソフトウェアの品質を管理することを「ソフトウェア品質管理」と言います。名前の通り、業務で必要となるシステムやソフトウェアの開発工程や予算、スケジュールの管理を行い、滞りなくプロジェクトを進めることを指しています。
「ソフトウェア品質管理」と似たものに「ソフトウェア品質保証」があります。「ソフトウェア品質管理」は、品質の高いソフトウェアを開発するためにどうすれば良いかを開発側の視点で行うことです。それに対して「ソフトウェア品質保証」は、ユーザーがソフトウェアを使う上で、性能や機能など要求を満たしていると保証することです。
■関連記事:
ソフトウェア品質管理の7つの手法
品質管理を行う代表的な手法に「QC7つ道具」があります。
- パレート図
- 特性要因図
- グラフ
- ヒストグラム
- 散布図
- 管理図
- チェックシート
「QC7つ道具」を使うことで、ソフトウェアの品質を効果的に分析することが可能です。以下では「QC7つ道具」について詳しく解説します。
パレート図
項目別に数値の大きい順に並べた棒グラフと、項目の数値を累積数の合計で割った数値を示す折れ線グラフで構成された表を言います。パレート図を作成することで、全体の中で最も影響を与えるものが何かを明確にし、潜んでいる問題を特定することが可能です。
特性要因図
なぜその結果に至ったのかの原因を書き出すことで、どのような影響を与えたかを可視化した図を言います。図形が魚の骨に似ていることから、「フィッシュボーン図」「フィッシュボーンチャート」とも呼ばれています。
グラフ
データや数値を可視化することで、全体の把握がしやすくなります。グラフには以下のようにさまざまな種類があります。
- 棒グラフ
- 円グラフ
- 折れ線グラフ
- 帯グラフ
- レーダーチャート
折れ線グラフであれば時間経過、棒グラフであれば大きさの比較、割合を可視化したければ円グラフといった具合に、どのデータを可視化したいかによって適切なグラフを選ぶことが重要です。
ヒストグラム
度数分布表にまとめたデータを棒グラフで表すことで、分析する対象がどのように分布しているか、ピーク値やバラツキ、抱えている問題点などを把握することが可能です。
散布図
データをもとにして縦・横の項目で数値を計測し、分布を把握するために使われます。散布図では、収集したデータに関して、縦軸と横軸の要素にそれぞれ関係があるかを知ることができます。
管理図
品質や工程を管理するために用いられています。管理限界の上限値と下限値を決定し、時系列に折れ線グラフで表示します。上限値と下限値の範囲を正常値とし、その範囲を超えないように管理します。仮に超えそうであればすぐに状況を把握できるため、素早い対処が可能です。
チェックシート
工程に漏れがないかをチェックするために利用されます。チェックが必要な項目を準備し、確認後にチェックマークや○・×を入れることで、見落としなどのヒューマンエラーを防げます。
ソフトウェア品質管理の実践方法
ソフトウェア品質管理を実践する際、次の2点を押さえておく必要があります。
- 計画の立て方
- レビューの進め方
以下で詳しく解説します。
計画の立て方
ソフトウェア管理をどのように実施するかを、次のように計画立てする必要があります。
①リスクの分析や管理
ソフトウェア開発では、不具合などのリスクが必ず現れるものです。この段階では、開発の完了から終わりまで出てくるであろうリスクを分析・管理します。
②品質の目標値を設定
いくら自分たちが「これは高品質だ」といっても、指標がなければ判断がつきません。そこで、品質管理指標通りにソフトウェアの品質が保たれているかをチェックするために、品質の目標値を決めます。
③テスト工程の定義付け
ソフトウェア開発では、品質を保つためにいくつかテストをします。ここでは、各工程でどのような内容のテストをするのかの定義付けを行います。
レビューの進め方
ソフトウェア開発の工程が正しく行われているかを評価・確認する作業が「レビュー」です。レビューの効果を最大限に高めるために、次のように進めるのが一般的です。
①計画を立てる
どの成果物に対して、どのような方法で、いつレビューを行うかといった計画を立てます。
②実施する
成果物が要件定義や設計書などの要求を満たしているか、手戻りが発生するような欠陥がないかを確認します。
③記録を取る
レビューの結果を記録することで、レビューが確実に行われたことの証明とします。レビューで問題となる指摘があった場合は、記録を参考に速やかに修正・改善をする必要があります。
ソフトウェア品質の標準化が必要な理由
ソフトウェア品質を標準化することで、開発側・ユーザー側ともに共通認識を得ることにつながります。基準が定まっていないと、開発側とユーザー側の求めるものが同じなのに、名前や定義が違うといった理由で食い違いが生じる恐れがあります。また、データを収集しても、目安が明確でないと正しい評価が難しくなるでしょう。ソフトウェア品質を標準化することで、開発側・ユーザー側ともに正しい認識のもとでの評価が可能となります。
「正常に動作する」から「満足するモノづくり」へ
従来であれば、正常に動作することが「高品質」と考えられていました。しかし、ユーザー側の要求が高くなるにつれて、ただ動くだけでは高い評価を得ることは難しくなりました。これからは、正常に動作することは当然として、ユーザーが求めている以上のモノづくりが求められています。
ソフトウェア品質への要求はステークホルダーによって違う
さまざまな分野でDX化やデジタル化が進んでいる昨今、ソフトウェア製品への要求にも変化が現れています。一昔前であれば、ひとつの業種をこなすことができれば十分と捉えられていました。
しかし、ソフトウェアやハードウェアが進歩したことで、ステークホルダーの要求も多様化しています。例えば、開発側であれば正常に動作すること、ユーザー側であれば利便性、発注側であればサービスの提供や運用・保守のしやすさなど、ソフトウェアに関わる人によって求めるものが違います。これからは、ステークホルダーの要求に答えることが高品質の指標となるでしょう。
ソフトウェア品質の国際規格と8つの分類
ソフトウェアの品質を明確に定義・評価する基準として、国際規格「ISO/IEC 25010:2011」があります。国際規格は次の8つに分類されています。
- 機能適合性:実装した機能が顧客のニーズを満たしているか
- 性能効率性:性能の高さや資源を効率的に使用しているか
- 互換性:他のシステムや製品との間に機能面で互換性はあるか
- 使用性:ユーザーにとって使いやすいか
- 信頼性:正常に動作するか
- セキュリティ:情報やデータが保護されているか
- 保守性:機能の追加や不具合に対応しやすいか
- 移植性:他のハードウェアに移植しやすいか
これら8つの品質特性を意識して開発することで、ユーザー満足度を高めることにつながります。
ソフトウェアテストの実施と7原則
ソフトウェアの品質を高めるために、テストを実施することは必要不可欠です。ですが、ソフトウェアテストを実施するうえで、以下にご紹介する「ソフトウェアテストの7原則」を理解しておく必要があります。
【1】テストが示せるのは欠陥の有無だけ
ソフトウェアテストをすることで、欠陥の有無を把握できます。しかし、欠陥がないことを証明することはできません。必要十分なテストをしたとしても、絶対に不具合がないとは言い切れないのです。
【2】全てのテストを行うことは不可能
簡単なソフトウェアでもなければ、全てのテストを行うことは不可能です。不具合が出るかもしれないパターンは無数に存在しています。それら全てをテストすることは、時間・労力・予算面などから考えて現実的ではありません。
【3】早期テストは時間とコストを抑えられる
開発の早い段階で行うテストのことを「早期テスト」と言います。ソフトウェアテストでは、早期テストを行うことで修正も容易になるため、時間やコストを抑えることにつながります。時間が経過するほど、バグの修正に時間や労力が必要となり、コストも多くかかってしまうのです。
【4】欠陥の偏りを予測する
ソフトウェアの欠陥は、一部に偏ることがあります。機能によっては簡単に構築できるものがあれば、難しいものまでさまざまです。大規模なソフトウェアになれば、それだけ多くの人の手が入るため欠陥も偏ってしまうのです。つまり、欠陥の偏りを予測できれば、その部分に集中してテストが実施できます。
【5】殺虫剤のパラドックスに注意
同じテストを繰り返すと、最後は欠陥が見つからなくなることを「殺虫剤のパラドックス」と言います。同じパターンでテストを繰り返し実施し、その都度修正して最終的に欠陥がなくなるのであれば悪いことではありません。しかし、同じテストを繰り返しているにもかかわらず、修正が行われないのであれば意味がありません。
【6】テストは状況や目的に合わせる
ソフトウェアを使う環境や目的に合わせて、テストの方法も変えるべきです。ユーザーの使い方に合わせたテストをしなければ、修正すべき欠陥を見つけるのは困難になります。
【7】「欠陥ゼロ」の落とし穴
ソフトウェアテストで発見したバグを全て修正したからといって、高品質なものができるとは限りません。欠陥を修正したことが原因で、ソフトウェアが正常に動かなくなるケースも少なくありません。仮に欠陥をなくしたとしても、ユーザーが求めるニーズを満たしていなければ高品質とは言い難いものになります。
▼ソフトウェアテスト7原則は、こちらを参考にしてみてください。
→ソフトウェアテストとは?第三者検証との違い、種類や目的、7原則を解説
テスト自動化を導入する4ステップ
ここからは、テスト自動化を導入するために必要なステップを4つご紹介します。各ステップをそれぞれ確認して把握しておくことで、スムーズに導入できるでしょう。
ステップ1ーテスト自動化の導入に向けて調査・分析を行う
自動化を導入する前に、「ソフトウェアの仕様や開発工程を洗い出し」や自動化の導入が可能かを分析することが必要です。調査や分析を行わなかった場合、失敗する可能性があります。
ステップ2ー何のためにテスト自動化を導入するのかを明確にする
自動化を導入する「目的」を明確にしましょう。なにも決めずに導入した場合、扱いきれずに失敗する恐れがあります。
ステップ3ーテスト自動化をする範囲を決める
自動化の範囲を決めますが、自動化には次のような8つの原則があります。
1つ目は、手動テストは残る
2つ目は、手動テストで効果のないものを自動化しても無駄となる
3つ目は、自動テストでは、書いたことだけをテストする(書いたことしかテストをしない)
4つ目は、テスト自動化による効用は、コスト削減やバグ修正日数の低減など多岐にわたる
5つ目は、自動テストシステム開発は継続的に行うほうが良い
6つ目は、プロジェクト初期から自動化の検討をしておく
7つ目は、自動テストで新種のバグが見つかることは稀
8つ目は、テスト結果分析など、追加タスクが発生する
自動化だけで判断できない部分を考慮し、自動化の対象や範囲を絞り込みましょう。
ステップ4ー自動化するためのツールを選ぶ
開発するソフトウェアの目的や自動化ツールを導入した後の運用のしやすさなどを考慮して、必要なものを選びましょう。
ステップ5ーテスト自動化の環境を整えてテストする
環境が整ったら、テストを実施します。テスト結果から、目的が達成されているかなどを判断します。
▼テスト自動化は、こちらを参考にしてみてください。
→テスト自動化とは?導入するメリットや注意点、実行方法、失敗しないポイントなどを紹介
まとめ
当記事では、ソフトウェアの品質や管理について解説しました。
これまでは正常に稼働することが高品質とされてきましたが、これからはステークホルダーの要望に応えられることが高品質の指標となります。品質の目安として、国際規格「ISO/IEC 25010:2011」や、8つの品質特性を意識した開発が求められます。
開発工程でミスや漏れがないか確認を行い、早期に不具合を発見することが手戻りを防ぐ鍵になります。そのためには、特定の開発工程だけではなく、要件定義、設計、コーディング(実装)、テスト、メンテナンスといった開発工程でテストを行うことが重要です。
ただ漫然とテストをするのではなく、何のためにテストを行うのかを明確にし、バグを発見できるよう進めることが理想的です。不具合やバグの早期発見のためには、開発段階でチェックする体制を整える必要があります。
コウェルでは2007年の創立以来、多くのオフショア開発における品質保証支援を行ってきました。
これまでに様々なオフショア開発での品質課題を解決するなかで蓄積したノウハウや方法論をベースに、オフショア開発に加えソフトウェアテストのご支援もさせていただいております。
特にオフショア開発における品質面においてお悩みや課題を抱えられている方は、ぜひ一度コウェルにご相談ください。
なお、コウェルに関する詳細資料は以下でダウンロードすることが可能ですので、何かございましたらお気軽にお問い合わせください。
このほか、弊社の具体的なサービスや導入事例については以下をご覧ください。
コウェルのソフトウェアテスト>>>
コウェルは、日本とベトナムから世界中のお客さまへ高品質なソフトウェアテスト・品質保証・オフショア開発サービスを提供しています。
コウェルの導入事例>>>
コウェルは情報通信、金融、流通・小売サービス、医療・ヘルスケアなど、さまざまな業界のお客様の導入を支援しています。