このエントリーをはてなブックマークに追加LINEで送る

12.1. 品質とは何か?

ハッピィ・エンジニアリング表紙

 欧米のシステム開発では、「品質の向上には多くのコストが必要になる」「スケジュールと品質は相反する項目である」という考え方が一般的である。ところが、古き良き日本のシステム開発には、「品質を高く保ちながら開発することこそが、コストダウンにつながる」という、素晴らしい(そして、ごく当然の)価値観が存在した。

 

 スケジュールの短縮を最優先にプロジェクトを進めた場合、かなり高い確率でコストやスケジュールが大幅に増加する結果となる。なぜならば、短縮が不可能なスケジュールを強引に短縮することで、間違いなく品質における手抜きが発生するからである。

 

 スケジュールを短縮する意識が、結果的にレビューやテストプロセスの省略、正常系の動作確認をした程度でのリリースなど、品質への手抜きにつながり、かえって結果を悪くする。さらに、品質への手抜きは、どこかのタイミングで必ず発覚する。品質面での問題が発覚したところで、そのツケは大幅な手戻りとしてプロジェクトにはね返ってくる。

 

 品質を最優先にすることは、各プロセスの成果物品質を高めていくことにほかならない。すなわち、各プロセスの成果物品質を高めることは、手戻りが発生する範囲を極めて狭くするということである。手戻りのコストは、開発工数全体の40〜60%にもなるといわれている。つまり、高品質を意識しなかったプロジェクトで発生する手戻りと比較すれば、品質を高く保ちながら開発を行ったプロジェクトは生産性が高く、コストダウンとスケジュールの短縮を実現できるのである。*1

 

 ユーザ企業・SIベンダ・開発者の間で、それぞれの立場や責任が異なるように、品質に対する考え方も異なっている。ユーザ企業は、システムのライフサイクル全体に対する責任を持つ。SIベンダは、基本設計からシステムの運用開始までの責任を持つ。そして、多くの開発者の責任範囲は詳細設計からシステムテストの支援までである。

 

 一般的に多くの開発者は、品質は「バグが出ないこと」だと考えている。ソフトウェアテストの原則に従って考えれば、「バグが出ない」ということは、テストの結果にすぎず、「バグが存在しないこと」の証明にはならないのである。とはいえ、開発者が担当している範囲と責任から考えれば、「バグが出ないこと」を品質の基準とするのは、決して正しくはないが、間違いとはいいきれない。しかし、ユーザ企業やSIベンダは、開発者より広範囲にわたる責任を持つ以上、「バグが出ないこと」は品質の定義として不十分である。

 

 まず、本節では、「品質」という、全体を包括したあいまいな言葉が持つ本来の意味について考えてみることにする。

 

品質とグレード

 品質を語るうえで、非常に重要なことは、それがグレードという言葉が意味するものとは明確に区別されるべきものであることである。

 

 品質とグレードの意味の違いを明確にするために頻繁に用いられる比喩は、飛行機のエコノミークラスとビジネスクラスであろう。エコノミークラスの窮屈なシート、学校給食と大差ない食事に対して、ビジネスクラスは足を伸ばしてゆったり座れるシート、ひとつひとつの料理がそれぞれのお皿にきれいに盛りつけられた食事、飲み放題のドリンク、公衆回線に接続可能な電話機などのサービスがある。エコノミーとビジネスクラスの価格帯の違いを考えた場合に、納得感のあるサービスレベルである。このサービスレベルの違いがグレードである。移動という本来の目的や安全性に関してはエコノミーであれ、ビジネスクラスであれ同一の条件である。この同一の条件となっているものが品質である。

 

 業務システムでは、システムを利用する顧客の利益や満足につながらない限り、グレードはあまり意味をなさないものである。あくまで、あるべき要求を満足させ、ユーザがきちんと利用できる「品質」こそが重要なのである。

 

 特に技術者の判断が独り歩きした結果、設計書に存在しない「グレードアップされた」プログラムを開発しているようなケースがある。多くのソフトウェアエンジニアリングの書籍において、プロジェクトに要求されていない機能や要求されていない品質以上のものを作り込むことを「金メッキ」と呼び、無駄なコストであると書かれている。

 

品質の定義

 システム開発プロジェクトにおいて、「品質」について語られることは多いが、その「品質」の定義がなされることはほとんどない。この事実が、開発者を疲弊させる一因となっている。「品質を上げよ」という言葉を、単なる掛け声としないためには、「品質」という言葉が意味するところを明確にし、その中で何を重要視すべきかの基準が必要である。

 


品質とは属性の集合である
『ソフトウェア開発 55の真実と10のウソ』ロバート・L・グラス著, 山浦恒央訳,日経BP社, ISBN4-8222-8190-6

 

 ロバート・L・グラスの「属性の集合」という定義は非常に的確に品質という言葉を表している。

 

 品質に関わる属性は、それを提唱している技術者や研究者によりいくつかの意見がある。ロバート・L・グラスは以下の属性を提唱している。

 

  • 移植性(Portability)
  • 信頼性(Reliability)
  • 効率(Efficiency)
  • 使用性(Usability:人間工学)
  • 検証性(Testability)
  • 理解性(Understandability)
  • 変更容易性(Modifiability)

 

 さらに、ロバート・L・グラスは、一般的なプロジェクトにおける品質属性の優先順位を以下のように例示している。

 

  • 信頼性
  • 人間工学
  • 理解容易性と変更容易性
  • 効率
  • 検証性
  • 移植性

 

 ところが、開発するシステムの特性により、これらの優先順位はまちまちであるという考え方、そして、理解性が高ければ、検証性、変更容易性が必然的に高まるというような依存関係を考慮した考え方など、優先順位の考え方には諸説が存在し、どれが正しいというものではない。

 

 重要なことは、このような品質を定義する上で必要な属性をピックアップし、プロジェクトを開始する時点でそれらの属性に優先順位を付けることである。

 

 品質を評価する対象になるのは、「すべての成果物」である。プログラムに対するテストを通ったものに対して「品質」という言葉を使うプロジェクトは多いが、それは大きな間違いである。テストを通ったということは、「このテストを行った上ではバグがなかった」というだけのことであり、上記の属性を満たしているとは言えないことが理解できるだろう。

 

 つまり、要件定義書、要求仕様書、各種設計書などのドキュメント群、開発したプログラム、構築したシステム基盤など全ての成果物が上記の品質属性により定められた品質基準を満足している必要がある。

 


*1 品質のうち、信頼性に関しては、高品質を保ちながら開発することがコストダウンにつながる。効率や人間工学というような品質要素では、ユーザ企業の全社的な標準やモデル、ガイドラインの設定により、品質向上と、試行錯誤を避けることによるコストの低減が可能になる。ただし、人命に関わるようなシステムにおける高い欠陥除去は、コストをかけて行うべきものであり、通常の業務システムと同じ次元で語るべきではない。
シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

12.1. 品質とは何か? ハッピィ・エンジニアリング関連ページ

12.2. テストのプロセス区分
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.3. 現状のシステム品質
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.4. 品質低下の根本要因
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.5. 欠陥とは何か?
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.6. 品質向上の手法
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.7. 品質は作り込まれる
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング