ソフトウェア品質管理

ソフトウェア品質管理とは、必要な機能を実現させる開発工程や予算の管理を行いプロジェクトを計画通りに成功させることを指します。

ソフトウェアの上流工程で品質管理を怠ってしまうと、開発工程の作業を止めてしまうこともあります。具体的には、ソフトウェアテストなどのテスト工程を予定通りに行えなくなります。システムがリリースされてから問題が発生した場合、金銭的な損失だけでなく企業としての信頼も失う大きなリスクを背負います。

この記事ではリスクを未然に防ぐ対策として、ソフトウェア品質管理が重要視されている点について解説します。是非、お役立てください。

ソフトウェア品質管理とは

ソフトウェア品質管理の定義

ソフトウェア品質管理(Quality ManagementもしくはQuality Control)とは 「要求を満たすソフトウェア製品・サービスを提供するために、組織を指揮し、管理すること」です。(※ISO9000の定義に基づく)

ソフトウェア品質とは

ソフトウェア品質の考え方は、発注者の要求に応えて提供すべき価値を実現するものと認識されています。何をもとに品質の評価基準とするのかを定義し、発注者が満足できるサービスを提供しなければなりません。ソフトウェア品質の基準は、発注者の評価によって変化するということがポイントとなります。

「ソフトウェア品質」について以下のページよりご参照ください

ソフトウェア品質管理、ソフトウェア品質保証の違いを知る

ソフトウェアの品質保証 (Software Quality Assurance)とよく混同するのが、「ソフトウェアの品質管理」です。いずれもソフトウェアの品質に関わる点は共通していますが、目的や視点は異なります。

ソフトウェア品質管理とは、文字通りソフトウェアの品質を管理することです。最も大きな違いは、ソフトウェアの品質に対する関わり方にあります。ソフトウェアに要求される品質を「実現」するための活動がソフトウェア品質管理であり、「保証」する活動がソフトウェア品質保証ということです。

ソフトウェア品質保証が発注者の視点で行われる活動だったのに対し、ソフトウェア品質管理では開発者側の視点が必要と言えるでしょう。

ソフトウェアの品質保証ソフトウェアの品質管理
目的ソフトウェアの品質を「保証」することソフトウェアに要求される品質を「実現」すること
視点ユーザーの視点ソフトウェア提供者の視点
具体的な活動内容ソフトウェアの品質を保証するのに必要なデータの収集やチェック業務の改善など

ソフトウェア品質管理をする際のポイント

ソフトウェア品質管理の原則

ソフトウェア品質管理はISO9001およびISO14001にて確立しています。原則となるルールを順守することで、より効果が得られることでしょう。ソフトウェア品質管理の7原則についてご紹介します

顧客重視

顧客とは、この記事で発注者や発注者の関係者を指します。発注者中心という考え方ではなく、発注者も管理システムの一環として取り組み、要求に応えるよう行動することです。

リーダーシップ

将来に対する明確なビジョンを描き、言語化・成文化し組織内に周知することで社風として確立し、プロジェクトを依存型から自立型に導きます。

プロジェクトメンバーの積極的参加

プロジェクトリーダーが掲げた目標を達成する上で、プロジェクトメンバー全員が一丸となり、参加することです。プロジェクトメンバーそれぞれが目標達成に向け何ができるか、常に考えておく必要があります。

プロセス重視

すべての作業が必要なプロセスに基づいて行われているのか、開発作業工程に無駄、漏れがないかを確認し、見直すことです。これが、各プロセスが一連の活動として実施されている状態のことです。

リスクマネジメント

問題点を解決するだけではなく、改善する点がない場合でも考えられるリスクを回避する点がないかプロジェクトメンバー間で検討し、マネジメントの最適化を考え続ける活動です。

客観的事実に基づくデータ管理

客観的な事実であるデータや記録に基づいて、具体的で明確な目標を立てます。やみくもに記録を残すのではなく、何らかの活用できる形としてデータや記録を行います。

プロジェクトメンバー全員で管理

組織に関わるプロジェクトメンバーや利害関係者は、対等かつ平等であるという意識の基、協力関係を築き気持ちのよい関係で仕事し、価値実現を目指す必要があります。

ソフトウェア品質管理の開発工程を明確にする

ソフトウェア品質管理をする上で、何を基準とした開発工程なのか明確にする必要があります。ソフトウェアの場合には、指標となる成果物はサマリーレポートなどの報告書です。

収集したデータの基準を統一し、指標となるデータを集めます。集められたデータを可視化することで、開発工程を実施する手助けになります。データの作成は主にグラフや散布図などを使って行われています。プロジェクト状況を可視化することは、適切なマネジメントを行うのに必要とされています。

さらに、各工程毎にレビューをすることも重要です。

ソフトウェア品質管理に必要なもの

ソフトウェア品質管理をする前に定義する3つの項目

ソフトウェア品質目標の設定

ソフトウェア品質目標とはいっても、目に見える工業製品のように品質を計測することはできません。この項目はソフトウェア品質目標そのものではなく、問題の早期発見の手段として構築するものとなります。

ソフトウェア品質管理は、「QCD(Quality=品質、Cost=コスト、Delivery=納期)」の観点から行います。

それぞれの要素がバランスよく保たれている状態を目指し、ソフトウェア品質向上を図ります。

異常の発見と是正

ソフトウェア品質目標に基づき、異常の発見と修正を行います。開発工程で発見された異常は、開発工程内で修正することを原則とします。上流工程で発生した異常(要件漏れなど)を下流工程まで発見せずに進めてしまうと、開発の進行とともに影響範囲が拡大し、改修が困難となります。

目標達成予測

プロジェクトの進捗に応じ、設定したソフトウェア品質目標を達成できるか予測することです。プロジェクト全体の状況を統計的に分析し、目標達成の可能性を調べることで達成までの課題を確認し、対策を練ることです。

ソフトウェア品質管理に必要な7つの技術

「ソフトウェア品質管理の7つ技術」を用いることで、業務上の問題点を定量的に分析し、明確にすることができます。

特性要因図

問題とする特性と要因の因果関係を、魚の骨のような太いラインの周囲に細かいラインのある形で表した図です。体系的な関係づけを可視化できる利点があります。

パレート図

データを分類項目別に分けて、棒グラフと折れ線グラフで表した図です。対策の優先度を決定しやすく、問題や改善内容の合理的な選択が可能です。

チェックシート

データを項目別に分類し、分布を知るためのシートです。また、要因の系統的整理において、データ採取の効率化を図るためにも用いられます。発注者側の関係者から意見を継続的に聞き、改善することが大切です。

グラフ

複数のデータを数字から図へと可視化し、把握しやすくします。用いる図には、棒グラフ、折れ線グラフ、レーダチャートなどがあります。

ヒストグラム

データが存在する範囲をいくつかに区切り、各区間に入るデータ数を縦軸に置いた柱状のグラフです。データのばらつきを可視化し把握します。

散布図

対になった変数を、それぞれ縦軸・横軸にとって値を打点することで作成する図です。ふたつのデータを検討する上でデータの関係性が可視化され、把握しやすくなります。

管理図

工程の安全性をチェックするため、もしくは工程の安全性を保持するために用いられる折れ線グラフです。UCL=上方管理限界、CL=中心線、LCL=下方管理限界という、3本の管理線を基準としています。

ソフトウェア品質管理の実践方法

ソフトウェア品質管理における計画の立て方

どのような手順で、ソフトウェア品質管理の計画が立てられているのかご紹介します。

リスク管理~計画

プロジェクトが開始する前の見積もり時から、ゴール地点である開発完了時までに、どのようなリスクがあるかを分析・管理します。

ソフトウェア品質目標値の設定

ソフトウェア品質管理指標に応じて、プロジェクトにおけるソフトウェア品質目標値を決定します。ソフトウェア品質評価は、この目標値と実績値を比較します。

テスト工程の定義

テスト作業はいくつかのテスト工程に分かれます。ここでは、各工程でどのようなテストを行うかを定義づけすることが大切です。

ソフトウェア品質管理の手法レビューの手順

レビューは、ソフトウェア開発工程全般で行われる評価及び確認作業のことです。プロジェクトの関係者(発注者や開発者)が多角的に検討することで、レビュー計画、実施、記録、実施結果へと最大限の効果を得るようします。

レビューを効果的に行うには、レビューを実施する開発工程、対象となる成果物、レビューアなどをあらかじめ計画し、チーム内で共有しておくことが必要です。事前の準備段階として、工程のレビューチェックリストの整備、対象ソフトウェアの理解を手助けするシステム構成図やアーキテクチャ、基本アルゴリズムを説明したものなどの関連資料の整備も必要です。自然と必要書類が作成されるという効果も生まれます。

レビューを実施するあたり、レビューの計画、実施、記録、及び実施結果の評価で考慮すべき点を下記に挙げています。

レビュー計画

レビュー開催時期、対象成果物、レビューア、適用するレビュー方法及びリーディング技法などのレビュー計画を、プロジェクト計画策定時に計画して明確にします。計画では、レビューの完了判断基準を明確にし、計画内容が妥当であるかを確認します。

レビュー実施

対象成果物が、当該プロセスのインプットの要求事項を満たすこと、すなわち前のプロセスで示された要求を網羅している記述内容になっていることを確認します。

レビューの記録

レビュー実施後、その結果を記録します。一般に言われるレビュー報告書の発行となります。これは品質記録としての意味を持ち、品質保証活動の一環としてのレビューが確実に実施されたことの証拠となります。レビューの結果、特に指摘事項はこの記録をもとに追跡した完結したことをフォローする必要があります。

①対象プロジェクト名
②対象プロセス(工程)
③対象成果物
④実施日時、時間、場所4
➄レビュー参加者(氏名・役割)
⑥レビュー項目、結果、指摘事項、指摘のフォロー結果

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

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

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

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

プロダクト品質

結果の品質

プロセス品質

結果に至る過程の品質

プロダクト品質

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

プロセス品質

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

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

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

心得ておくべきソフトウェア品質管理

開発工程で不具合・バグを発見する

ソフトウェア品質管理の手法の中でも開設されたように、開発工程でミスや漏れがないか確認を行い、早期に発見することが解決に繋がります。特定の開発工程だけではなく、要件定義、設計、コーディング(実装)、テスト、メンテナンスといった開発工程でテストを行います。何のためにテストを行うのかを明確にし、バグを発見できるよう進めることが理想的です。

実現に向けるには、開発段階でチェックするプロジェクト体制を設けます。できるだけ早くバグや不具合を発見・修正することで、ソフトウェアテストにおいて非常に重要なことです。

ソフトウェア品質の重要性を認識する

ソフトウェアテストにおいては、ソフトウェア品質の重要性を認識します。定義するべきは、ソフトウェア品質を向上させることでどのような価値を発注者にもたらすことができるのかということです。これによって、ソフトウェア品質向上の目的をはっきりさせます。次に必要なのが、不具合を見つけることです。ソフトウェアテストにおけるチェック項目を設けます。ソフトウェアテストで見つかった不具合からフィードバックを行い、ソフトウェアテストをアップデートしていきます。

まとめ

ソフトウェアの品質管理を怠ってしまうと、システムがリリースされてから問題が発生した場合、金銭的な損失だけでなく企業としての信頼にも大きなリスクを背負います。未然に防ぐ対策として、ソフトウェア品質管理の重要性をご紹介しました。

ソフトウェア品質管理をする上で、何を基準とした開発工程なのか明確にします。収集したデータを統一し、集められたデータを可視化することで、開発工程を実施する手助けになります。プロジェクト状況を可視化することは、適切なマネジメントを行うのに必要とされているでしょう。

ソフトウェア品質管理のソリューションとして、「可視化」が重要です。

弊社サービスクオリティゲートは、工程移行判定する際に品質基準を設け、品質向上を支援し、課題傾向とリスクの見える化や経営分析が可能です。(※お気軽にご相談ください)お問い合わせ

この記事が気に入ったら
いいね!しよう

最新の情報をお届けします

この記事を書いた人

Omoriqc

2020年QualityCube入社、美容業界からIT企業へ転職。
美容サービス業におけるサービスの品質に力を入れておりました。
お客様の立場にたって、「品質」に対する課題を解決するサービスを提供できればと思います!よろしくお願いいたします。