これからのシステム開発には絶対必要?ソフトウエア品質管理、特性、保証について解説!

現代は世の中の多くの企業が、システムの導入を検討している時代です。 大手企業などでは、DX推進部という名前で専門のチームが組まれるほど、本格的にIT導入を検討している企業が多いです。 そんな中で、 「ソフトウェアを作る上での品質」 が重要になってきます。 一昔前であれば、 「システムを導入しただけでも進んでいる」 という時代がありました。 しかし、今の時代は安価でシステム導入が可能になったことや、開発環境が整ってきたからこそ、そのシステムの品質が問われるようになってきました。 今回は、そんなソフトウェアにおける「品質」についてお話していきます。

ソフトウェア品質とは

ソフトウェア品質とは

ソフトウェア品質とは ソフトウェア品質とは、その名前の通りシステムを開発した際の品質に関するものになります。 「品質」と一言で言っても、明確な定義が難しく、また技術革新とともにその意味合いも変化してきました。 昔のシステムは、速度も遅くエラーも多かったため、 「バグがないこと」 が最も重視されていました。 もちろん、現在でも品質を測る上でバグの有無は重要な要素ですが、徐々にシステムを利用するユーザーの目線は 「バグがなく動くことは当たり前」 と考えるようになってきました。 また、システムの速さに関しても、 「数十秒から数分待つ必要があるシステム」 というのは、品質が高いとは言い難いです。 ハードウェアのスペックも高くなり、通信速度も速くなっている現在では、 「単にスムーズに動く = 高品質」 とは言えないのです。

ソフトウェア品質管理

ソフトウェア品質管理

ソフトウェア品質管理 ソフトウェアの品質を高い次元で管理することは、 ・商品/サービスの評判が高くなる ・ユーザーが長期的に利用してくれる ・会社の信用につながる など、様々なメリットがある一方で、「どの様に管理するのか」が非常に重要になります。 前項でもお話したように、時代とともに基準となる品質は変化し、少し前までは革新的な機能だったのに、今ではその機能が付いていて当たり前・・・となる事も多く、管理するのは簡単ではありません。

ソフトウェア品質管理って何?どうやって管理するの?

「ソフトウェア品質を管理する?それって具体的にどうすればいいの?」 ソフトウェア品質管理を行う上で、最初に品質管理の計画を立てる必要があります。代表的な3stepがこちらです。 1.品質目標の設定 まずは、品質目標を設定します。 目に見える商品ではないソフトウェアにおいて、品質目標というのは非常に曖昧な表現になる事も多いですが、例えば ・納期 ・工数 ・金額 ・メンテナンス性 ・ドキュメント などによって目標を設定します。 例えば、同じ品質であれば納期は早く、工数は短い方がユーザー側からするとメリットが多く、品質の向上に繋がります。 工数が少なければ、金額も安くなるため、「良いものが安くなる」という意味合いで品質が上がります。 2.異常の発見と是正 品質目標に従って、バグの発見や修正を行っていきます。 可能な限り上流工程で様々なリスクを考慮し、事前にバグの対策を取っていきます。 一般的にバグは、上流で発見するほど修正が簡単で、下流に行くほど修正は難しく、同時に影響範囲も拡がっていきます。 また、製品のリリース後・運用開始後にバグが発見されれば、過去にさかのぼってデータの修正を行う必要が出てくるなど、非常に大きな影響が出てしまいます。 3.目標達成予測 設定した目標に対して、どのくらい達成できるのかを予測・管理する事が重要になります。 プロジェクトが進むに連れて ・思ったよりも大きなリスクが出てきた ・思ったよりも工数がかかりそう ということは多々あります。 しかし、事前にある程度予想ができないと、適切な見積もりを出すことは難しいです。

ピアレビュー

ピアレビューは、開発中の工程で完成した成果物に対して、何がいいのか、悪いのかを確認(レビュー)することです。 ここで言う成果物とは、単にプログラムのソースコードだけではなく、仕様書などのドキュメントも含みます。 上記の「テスト方法の規定」に対して良く行われる手段です。 ピアレビューは早期で行うことが推奨されています。 開発がある程度進んでしまうと、成果物も規模が大きくなり、修正する量が多くなってしまう恐れがあるからです。 加えて、ソフトウェア品質に関する論文を執筆したカール・E・ウィーガーズ氏は、次のように述べています。 「早期、かつ頻繁に検査せよ」 早い段階でかつ、何度もピアレビューをするべきだと唱えています。 ピアレビューの「ピア」は同僚を意味し、自分以外の人間が検証することによって、客観的なレビューをすることができます。 例えば、 ・開発した人とテストする人が別 ・単体テストと結合テストの実行者が別 ・テスト仕様書を作成した人とテスト後のチェックをする人が別 などのように、作業者と確認者を分ける事で、先入観なくチェックを行うことができるのです。

ソフトウェア品質特性とは

ソフトウェア品質特性とは

ソフトウェア品質特性とは ソフトウェア品質特性とは、ソフトウェアの品質判断をするときに利用される、6つの指標のことを意味します。 その6つの材料は、「品質特性」と言われ、6つに分類されます。加えて、この「品質特性」を詳細に分類した「品質副特性」という指標も存在します。

品質を決める6個の特性

信頼性

信頼性とは、ソフトウェアが正常に作動できるかどうかを表す指標のことです。 ここから品質副特性に分類すると、 「成熟性」 「障害許容性」 「回復性」 に分類が可能です。

成熟性

成熟性とは、バグが発生する頻度のことを指します。 当然ですが、この成熟性に関して「少なければ少ないほど良い」ということになります。

障害許容性

障害許容性は、ソフトウェアのバグ部分を実行した際に、 「いかにユーザーに迷惑をかけないか」 という点になります。 例えば、フォルダ内にあるファイルを順番に処理していくようなシステムの場合に、 「エラーがあった時点でストップする」 という仕様よりも 「エラーになったファイルは別フォルダに移動し、その他のファイルは順次処理する」 という方が、ユーザーに迷惑がかかる可能性が低いです。 もちろん、仕様によっては「どうしても順番通りに処理しないといけないファイル」もあるかもしれません。

回復性

影響を受けたデータを回復できるのかを表します。 例えば、停電などによりデータが破損した場合。 定期的にデータのバックアップを取っており、それを瞬時に復旧できれば、回復性は高いと言えます。

効率性

メモリやレスポンス等に対して効率がいいかを表す指標のことです。 この効率性を品質副特性に分類すると、 「時間効率性」 「資源効率性」 「効率性標準適合性」 に分類が可能です。

時間効率性

提示された条件下において、ソフトウェアの機能を実行する際の、応答時間、処理能力、処理時間などを提供するソフトウェア製品の能力のことです。 1つのSQLを実行する上でも、テーブルの結合方法を変えるだけでも、実行時間は数秒から数十秒変化することは多いです。 特にデータ量が多くなれば、その分実行時間も大幅に変化します。

資源効率性

提示された条件下において、ソフトウェアの機能を実行する際の、資源量、資源の種類を最適に使用するソフトウェア製品の能力のことです。 同じ処理を行うなら、メモリの利用は少ない方が良いですし、保存するデータ量は少ない方が良いです。 そのために、 ・データは定期的に集計を行い、不要なデータはデータベースから削除し、テキストデータとしてサーバーに保管するべきか ・過去にさかのぼってデータを確認する必要がない場合には、保管期限を決めてデータを削除していくべきか などを検討します。

効率性標準適合性

効率性に関係する規約を守るソフトウェアの能力のことです。

保守性

機能を追加できるか、あるいは故障やバグ等に対応できるかを表す指標のことです。 この保守性を品質副特性に分類すると、 「解析性」 「変更性」 「安定性」 「試験性」 「保守性標準適合性」 に分類が可能です。

解析性

ソフトウェアに潜在する欠陥の検証、故障原因の調査、または修正箇所の判別を行うためのソフトウェアの能力を表します。 例えば、可能な限りtry/catchを用いて細かくエラーメッセージをログとして残すだけでも、バグが発生した際に解析しやすくなります。

変更性

仕様変更やバグ修正を行う際に、変更しやすいソースになっているかを表します。 スパゲッティソースと言われるような可読性の低いソースではなく、きちんと共通部品化されていたり、オブジェクト指向を用いられたプログラムの方が、変更性に優れています。 他にも、詳細なマニュアルや仕様書が用意されているかも重要になってくるでしょう。

安定性

一般的なシステムは、社内外からの操作を前提としています。 そのため、安全に利用できるのかという点も大きなポイントになります。 ログイン設計や二段階認証などもそうですが、保守していく上では、システムを開発した側がどのようにして最新版にアップロードするのかなどの操作方法も含まれてくるでしょう。

試験性

修正後のソフトウェアが正常であるか確認できることは、非常に重要です。 フレームワークを用いた開発などでは、リリースモードとデバッグモードを簡単に切り替えられる設定がつけられていることも多いですし、様々なテストデータを自動的に用意してくれる仕組みもあります。

保守標準適合性

保守性に関係する規約を守るソフトウェアの能力のことです。

移植性

別の環境に移りやすいソフトウェアかを表すものになります。 移植性を品質副特性に分類すると、 「環境適応性」 「設置性」 「共存性」 「移植性標準適合性」 「置換性」 に分類が可能です。

環境適応性

決められた他の環境にソフトウェアを順応させるためのソフトウェアの能力のことです。 システムを動かす環境は日々変化します。 ・OSアップデート ・物理サーバーOR仮想サーバー ・入っているセキュリティソフト ・フォルダ構成 どうしても環境を変えなければいけない際に、できるだけ環境による影響が最小限になる方が、システムとしての品質は高いと言えます。

設置性

決められた他の環境に設置するためのソフトウェアの能力のことです。 「特定のフォルダを全て別のサーバーに移動させるだけで移植が完了する」 といった設計や 「シンボリックリンク先を変えるだけ」 といった形で簡単に設置ができれば、品質は非常に高いと考えられます。

共存性

他のソフトウェアと共存できるソフトウェアの能力のことです。 様々なシステムが共存する中で、 「他のシステムのポート番号と被るため、不具合が起きる」 といったような状況も考えられます。

移植性標準適合性

移植性に関係する規約を守るソフトウェアの能力のことです。

置換性

同一の環境と目的で、ソフトウェア製品から換えて使用できるソフトウェアの能力のことです。 システムを開発する際に、部分的に他システムを利用することもありますし、APIなどの連携を行う可能性もあります。 そのため、部分的に置き換えることができるのかもポイントになります。

使用性

ある環境や条件で使用する時、快適に使用/理解ができ、そして魅力的であるソフトウェアの能力のことです。 この使用性を品質副特性に分類すると、 「理解性」 「習得性」 「運用性」 「魅力性」 「使用性標準適合性」 に分類が可能です。

理解性

ソフトウェアがある作業をある環境と条件で使用した際に、使用者がそれを理解できるソフトウェアの能力のことです。 複雑な仕様はユーザーに取って負担になります。 業務用のシステムでも、一般ユーザーが利用するサービスとしてのシステムでも、ユーザーが理解できない仕様にしてしまうと、利用度が下がってしまいます。

習得性

ソフトウェアを使用したことを利用者が習得できるソフトウェアの能力のことです。 業務システムなどでは、 「ついつい手書きでやってしまっていた」 という状況になれば、他の部署のデータにも影響が出てしまいます。 そのため、常に確認してもらうための工夫が必要になるのです。 一般ユーザー向けのサービスであっても、スマホで一般的に利用するアプリの数は数十個程度です。 そのため、より習慣的に見てもらえるような設計が必要です。

運用性

利用者がソフトウェアが運用できるかを管理できるソフトウェアの能力のことです。 例えば、業務用システムで管理者権限が細かく設定できない仕様であれば、アルバイトやパートの従業員に大事なデータを触らせるわけにはいかなくなります。 しかし、閲覧専用の権限を持ったアカウントを作ることができれば、運用性は高まります。 更に、上記のような運用をユーザー側で完結させることができる方が運用性は高まるでしょう。 ホームページで言うなら、静的ホームページにしてしまうと、ユーザー側での運用は難しくなりますが、ワードプレスなどのように、ユーザー側で投稿やメンテナンスができる形にする方が望ましいでしょう。

魅力性

そのソフトウェアが魅力的であるソフトウェアの能力のことです。 「魅力」とは、そのソフトウェア自体が 「どのような価値を提供しているのか」 ということに起因します。 ・業務が効率化される ・エンターテインメント性がある ・見える化ができる システムにはその仕様によって様々な問題を解決する能力があり、その魅力を高めていく必要があります。

使用性標準適合性

使用性に関係する規約を守るソフトウェアの能力のことです。

機能性

ソフトウェアが一定の条件で使用されるときに、機能を提示できるソフトウェアの能力のことです。 この機能性を品質副特性に分類すると、 「合目的性」 「正確性」 「相互運用性」 「セキュリティ」 「機能性標準適合性」 に分類が可能です。

合目的性

決められた作業または、利用者の目標に対して、最適な機能を提供するソフトウェアの能力のことです。 「〇〇のためにシステムを導入する」 という目的があるからこそユーザーはシステムを利用します。 その目的に合っているか否かは、非常に大きなポイントになります。

正確性

正確な結果、効果、または同意可能な結果、効果をもたらすソフトウェアの能力のことです。 同じ処理を複数回実行すると、結果が変わる。 こういったシステムであれば、業務用のシステムでは困るケースが多々あります。 そのため、正確な結果が得られる必要性があるのです。

相互運用性

決められたシステムと相互作用するソフトウェアの能力のことです。 単独でシステムが動くことは少なく、通常複数のシステム・複数のユーザーが利用します。 その中で、きちんとデータの整合性が取れる事が必須になります。

セキュリティ

許可されていない人が、データを読んだり修正したりできないソフトウェアの能力のことです。 特に多くのユーザーが使用するシステムや、一般ユーザーに公開するようなシステムの場合には、悪意のある攻撃からシステムやデータを守る必要性も出てくるでしょう。

機能性標準適合性

機能性に関係する規約を守るソフトウェアの能力のことです。

ソフトウェア品質保証

ソフトウェア品質保証

ソフトウェア品質保証

ソフトウェア品質保証って何? 品質特性と勘違いしない!

ソフトウェア品質保証とは、求められた品質水準を確認することです。 そして必要な時は、品質保証の根拠を顧客に説明しなければなりません。 品質保証は長期にわたります。 「作って終わり」 ではなく、きちんと運用が開始され、数ヶ月・数年と運用していく中でその品質が保証されることが必要になるのです。 品質保証は品質特性と混同される事が多々ありますが、大きな差の一つとして 「ソフトウェア品質に対する目的」 の違いが挙げられます。 品質管理の目的は、ソフトウェアに要求される品質を実現すること 品質保証の目的は、文字通りソフトウェアの品質を保証すること このように目的によって異なります。

どんなプロセスでされるの?

では、ソフトウェアの品質の保証には誰が関わり、どのような過程があるのでしょうか? 関わる職種は主に4つあります。

テストエンジニア

テストエンジニアはソフトウェアテストを実行する人のことを指します。 しかし、後述するQAエンジニアもテストを行う時があります。 QAエンジニアはこれに加え、データの収集等の作業を行ったりします。

テストマネージャー

テストマネージャーとは、テストのマネジメントを行います。 テスト方針の制定、管理、問題解決などがあります。

テスター・デバッガー

テスター・デバッガーとは、手順書に書かれたテスト方法を実行して、バグの有無を確認し、バグを解決する職種です。

QAエンジニア

QAエンジニアとは、ソフトウェア品質の保証を行う職業のことです。設計、計画、テスト結果分析など多岐にわたる役割があります。

システム開発における品質の高さならAMELA

システム開発における品質の高さならAMELA

システム開発における品質の高さならAMELA 今回は、 ・品質管理 ・品質特性 ・品質保証 という3つの説明をしてきました。 内容的に少し難しいものになりましたが、いずれも 「ユーザーに高い品質のシステムを提供する」 という目的は変わりません。 世の中に様々なシステムが登場し、それに伴って利用者の「当たり前」のハードルは高くなっています。 だからこそ、システムを開発する側としても「当たり前を超えた高品質の開発」が求められるのです。 AMELAでは、オフショア開発を得意とし、非常に高い品質のシステムを多数開発してきました。 「今までシステム開発をお願いした経験はあるけど、満足いく開発をしてもらえなかった」 という企業様は是非ご連絡ください。