ソフトウェア品質とは|上流工程が重要

10/17/2021 09/11/2023

yoshida

1 品質とは

品質とは

システム開発やソフトウェア開発では完成したソフトウェアの品質を担保するために、様々なテスト・検証を行い、ソフトウェア品質の管理をされていると思います。ソフトウェアはハードウェアと異なり、目で確認したり触ったりできませんので、品質を測ることが非常に難しくなります。そのため、構成するソースコードを見てソフトウェア品質を評価することよりも、利用者が体験する利便性など、利用者の価値評価が重要になります。

ここでは、ソフトウェア品質とは具体的に何か、その定義やソフトウェア品質を管理する鍵を解説します。

品質の定義

ソフトウェアに関わらず、製品・サービスは顧客の満足感が得られて品質が良いと定義されます。1984年に品質管理の大家、狩野紀昭氏が「当たり前品質」「一元的品質」「魅力的品質」という視点で品質を説明しました。

当たり前品質：充足されれば当たり前と受け取れられるが、不十分であれば不満を引き起こす品質要素。例: 予約システムにおいて予約登録ができること。
一元的品質：充足されれば満足、不十分であれば不満を引き起こす品質要素。例: 画面遷移速度が速い or 遅い。
魅力的品質：充足されれば満足を与えるが、不十分であっても仕方ないと受け取られる品質要素。例: 普段の食の好みを自動的に記憶しておいて最適なレストランを予約してくれるアプリ。

それ以前の1979年に経営理論と品質管理の専門家フィリップ・B.クロスビー氏が著書「クオリティ・マネジメント」で「品質とは要件に対する適合である」と定義していました。それに対して、狩野氏は利用者思考の「魅力的品質」を提唱したところに意味があります。

1994年にはソフトウェア開発の専門家であるG.M.ワインバーグ氏が「品質は誰かにとっての価値である」と説明しています。（出展：ワインバーグのシステム思考法ソフトウェア文化を創る）

システム、ソフトウェアの品質では利用者の「利用価値」が品質となります。仕様書通りに作られても、利用者が満足するものでなければ、品質が高いとは言えません。そのため、ソフトウェアの開発初期段階で「利用価値」とは何かをしっかりと「見える化」する必要があります。

品質の判断

プログラミングされたソフトウェアは、仕様通りに正しく動くかという視点で、モジュール毎に「単体テスト」を行います。単体テストで合格したモジュールを組み合わせて「結合テスト」をします。そして、最後に利用者に届ける最終的な形で「総合テスト」を行います。「総合テスト」でもソフトウェアがソフトウェア設計仕様書通りに正しく動くことかを確認します。

しかし品質の定義からすると、利用者が「利用価値」を感じて「品質が良い」と評価することになります。設計仕様書が利用者が望む満足を網羅していなければ、ソフトウェアが仕様書通りに動いても品質が良いとは言えません。さらに、ソフトウェアは単独の動きでだけではなく、それが動く基盤のハードウェアやネットワーク、他のソフトウェアとの互換性、使用環境なども含めて評価されます。なので、利用者が使用する状況でどの様に働き、利用者の操作ミスさえも見越した対応がされていて「品質が良い」という判断となります。

「ソフトウェア品質」の重要性

みずほ銀行、システム障害

みずほ銀行は2021年9月8日、最大100台のATMとインターネットバンキングが一時利用できなくなるシステム障害を起こしました。2021年を通して7回目のシステム障害です。みずほ銀行は、2000年9月に第一勧業銀行、富士銀行、日本興業銀行が株式移転をし、2002年4月に3つの銀行を統合・再編して誕生した経緯があります。統合前の各銀行はまったく別の基幹システムを使っていたため、統合途中でもトラブルが発生し、今でも結合前の問題を引き継いでいるのかもしれません。

現実的な策は、ブラックボックス化しているモジュールが何等かの理由で障害を起こしたとしても、自動的に対応策が始動するバックアップシステムの必要性です。障害が起きた際は運用で解決するという体制自体が問題であって、障害を検知したら自動的にそれを制御するバックアップ機能をシステムに取り入れ、ソフトウェアで自動的に対応するところまで最初から要件として組み込む必要があります。それこそ、ソフトウェア品質の課題です。　

NTTドコモ通信障害

2021年10月14日午後5時頃からNTTドコモの携帯電話で、音声通話とデータ通信サービスがつながりにくい事象が全国規模で発生しました。IoT機器向けのネットワーク工事の過程でロールバック（元に戻す作業）を行った結果、同機器からの信号が増えて通信ネットワークに影響が出てしまったそうです。必要な対策はみずほ銀行のシステム障害と同様だと思います。

ソフトウェア品質は重要

みずほ銀行の障害例、NTTドコモの障害例は当初のシステム構想、設計とは関係がないとは言い難いものです。5G通信が当たり前、IoTであらゆるものがインターネットで接続され、自動運転が普及してきたら、利用者のシステム依存度はますます高まります。問題が起きたら人海戦術で対処という手順では対応できず、予め問題をソフトウェアで解決するシステムが求められます。利用者が安心してシステムを使い続けられる様に、非常時対応要件を予め入れておく事が必須になってきたと言えるでしょう。

利用者の求める要件はだんだんと変化していきます。利用者の「利用価値」が品質である限り、顧客に満足感を与えるソフトウェア品質はより重要になってきたと言えるでしょう。

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

ソフトウェア開発は1960年代から始まり、開発工程での知識の蓄積や研究から抽出されたノウハウが2004年にSWEBOK（Software Engineering Body of Knowledge: ソフトウェアエンジニアリング知識体系）として発行されました。これはIEEE（Institute of Electrical and Electronics Engineers:米国電気電子技術者協会）とACM （Association for Computing Machinery:米国計算機学会）が策定したものです。

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

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

ユーザの要求分析・抽出をする要求定義が最初の工程で、その次が要件定義工程となります。

要件定義では要求定義を元に機能を明確化し、非機能要件と呼ばれる機能以外の要求項目も含めてソフトウェアの仕様書を作ります。その次に基本設計、詳細設計と続き、プログラムのコーディングである実装工程へとつながります。

ソフトウェア開発の要求定義から詳細設計までを上流工程と呼びます。実装工程でプログラムが作成されると、テスト工程へと進みます。テストは単独の機能をテストする単体テスト、単体で動作するコンポーネントを組み合わせてテストを行う結合テストと順番に行っていきます。

最後はソフトウェア全体をテストする総合テスト（システムテストとも呼ぶ）で検証をします。各テストで不具合が見つかると、不具合の原因を発見し、修正して再度テストに戻ります。

開発会社が総合テストで問題ない事を確認した後、ソフトウェアを発注元が受入れテストをして正常な動きが確認できると、本番環境での使用が始まります。これをリリースと言います。単体テストから受入れテストまでを下流工程と呼びます。

この一連の開発工程は上図の様にVの字で表すのでV字モデルと呼ばれます。

ソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組みで共通フレームと呼ばれるドキュメントがあり、IPA（Information-technology Promotion Agency, Japan: 情報処理推進機構）が発行しています。共通フレームはJIS X 0160（ISO/IEC12207）を参照しています。

ISO/IEC12207の初版は1995年発行、翌年の1996年にJIS X 0160としてJIS化されました。共通フレームでは要求と要件の区別は無く、ISO/ IEC 12207（ JIS X 0160）で使われている「要求分析」という言葉が「要件定義」と置き換えられて使われています。英語ではRequirementは要求と要件の両方の意味があり、特に使い分けしていませんが、SQuBOKを初めとして日本では以下の様に「要求」と「要件」を使い分けることが多い様です。

要求定義：プロジェクト当事者が、プロジェクトで実行すると決定した項目に対して、必要な条件や能力を明確化して文書化し経営責任者の合意を得たもの
要件定義：要求定義で明確になった内容に対して、技術的達成が可能な方法、解決策を文書化したもの

みずほ銀行のシステム障害やNTTドコモ通信障害などを回避する要件は要求定義、要件定義工程で考慮されなければ設計仕様書に載りません。それだけに、システム開発における要求定義、要件定義は大変重要な工程となります。

この様にソフトウェア開発の上流工程からソフトウェア品質を管理することがとても重要です。ソフトウェアのリリースまでは複数の工程を経てソフトウェアの完成度が高まっていきます。その各工程でテストファースト的にソフトウェアのテスト検証を行うことが、品質を高めるのに大切なステップとなります。各工程での漏れを防ぐためには第三者のチェックを受けることも有効です。

まとめ

ソフトウェアは目にみえないだけに、品質とは何かを理解するのは難しいです。しかし、具体的なシステム障害、通信障害がおきると利用者はどんなに不便な目に合うか、皆様も実感していることと存じます。場合によっては命にかかわる事故さえも起きかねません。

これらの問題が起きない様、利用者が安心と満足感を持って利用できる様にするのがソフトウェア品質です。品質の大半は開発の上流工程で決まります。システムの要求は何か、要求定義工程からしっかりとシステム要件に漏れなく落とし込むことがソフトウェア品質の作りこみへとつながります。

研修で品質を正しく理解

品質マネジメントコース

ソフトウェアではテスト項目が多すぎて絞り込めない、リリース後の不具合修正が大変、そもそも不具合の根本原因がわからないという事はありませんか。QualityCubeはお客様のソフトウェア品質を効率良く、低コストで向上するためのノウハウをお教えします。

品質マネジメントコース (集合研修/Web研修/eラーニング)　　 <eラーニング動画サンプル>
ソフトウェア品質の基礎講座	品質の定義・ソフトウェア品質の特性からソフトウェア開発の各工程での要点をまとめたソフトウェア品質の基礎を網羅したダイジェスト版です。
要求定義講座	要求はどのようにしたらまとまるのか？を解説。業務フローの整理の仕方など実践的な内容も学べます。
要件定義講座	業務要件・機能要件・非機能要件をどのようにして抜け漏れなくまとめるのか？が学べます。おすすめです。
設計講座	データベース設計書やAPI設計書、画面設計書など実際の設計書を基に実務で活用できる形で学べます。
テスト講座	IEEE829をベースとしたテスト3表（テスト計画書・テスト設計書・テスト仕様書）についてポイントを解説します。よりよいテストを実施するためのコツがわかります。
プロジェクトマネジメント講座	PMBOKをベースとしたQCDバランスの取れたプロジェクトマネジメントのノウハウが学べます。プロマネ初心者から経験者まで学びや気づきの多い内容です。
運用講座	ITIL（ISO20000）をベースとした保守・運用フェーズの管理方法やポイントが明確になります。