DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、品質評価の多面性を筒井康隆氏のＳＦ小説風に描いてみました。現実のシステム開発プロジェクトにおいても、ステークフォルダーによって品質については実にさまざま思い（定義）があるのではないでしょうか？

今回は、もう語りつくされているようで、まだまだしっくりした定義に出会ったことのない、「品質とは何か？」というテーマにチャレンジします。

【　PMBOKにおける品質の定義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは、PMBOK第5版から品質の定義を引用してみます。用語集には以下のような定義が記載されています。（※１）

品質（Quality）．一連の固有の特性が要求事項を満足している度合い。

これだけ読んでもなんだかピンと来ない感じですね。PMBOK第5版の本文中には、品質と等級を比較している箇所に以下のように記載されています。

品質とは、実現されたパフォーマンスや結果であり、「本来備わっている特性の集まりが、要求事項を満たす程度」（ISO9000）のことをいう。

こちらはISO9000の定義を引用しています。どうやら、どちらの記載にも登場する「特性」や「要求事項」がキーワードのようです。（※２）

「一連の固有の特性」と「本来備わっている特性の集まり」という表現から、「特性」は複数あることがわかります。「特性」といえば、いわゆる「JISの品質特性」として知られる、機能性、信頼性、使用性、効率性、保守性、移植性などを思い浮かべることができます。つまり、いくつもある品質特性のそれぞれについて、どのくらい要求を満足しているかを示しているのが、「品質」ということになります。（※３）

前回の「プロジェクト八景」で描いた品質評価の多面性は、評価すべき品質特性がいくつもあることにより生じているという具合に考えると理解しやすいのではないでしょうか？JISの品質特性は、多面性のあるソフトウエアの品質を扱う上で、けっこう役に立つ概念だと思います。実際、私がご支援しているいくつかのシステム開発プロジェクトにおいても、このJISの品質特性を活用した品質評価を取り入れることで、一定の成果が得られていると思っています。

それにしてもPMBOK第5版には、「品質」という言葉が含まれている用語がものすごくたくさん出現してきます。そのことからも、「品質」に関係する概念の広さをうかがい知ることができます。

＜　PMBOK第5版に出現する「品質」を含む用語　＞

品質コントロール、品質要求事項、品質コスト、品質方針、品質目標、品質標準、品質マネジメント、品質保証、品質尺度、品質検査、品質改善、品質監査、品質チェックリスト、品質向上、品質手順、品質ガイドライン、品質活動、品質適合、品質不良コスト、品質ツール、品質計画、プロセス品質、品質プロセス、品質レベル、品質パラメータ、品質測定、品質査定、品質機能展開・・・

【　ワインバーグ氏の品質の定義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、品質に関するもうひとつ別の定義を引用してみたいと思います。ウイキペディアの「ソフトウェア品質」を参照してみると、以下のような記述があります。（※４）

ジェラルド・ワインバーグは著書 Quality Software Management: Systems Thinking v. 1 で「品質とは誰かにとっての価値である」と書いている。この定義は品質が本来主観的なものであることを強調している。同じソフトウェアであっても人によって品質の感じ方は全く異なる。この定義の利点は、ソフトウェア開発チームに「このソフトウェアは誰のために作っているのか?」とか「彼らにとって価値とは何か?」といった疑問を抱かせる点にある。

実に興味深い定義だと思いませんか？この定義の「誰かにとっての」という部分で、品質を評価する人（ステークフォルダー）によって、品質の定義がさまざまであること、つまり、品質の多面性を表現しているととらえることができます。システム開発のプロジェクトには多くのステークフォルダーが存在することから、まさに前回の「プロジェクト八景」で描いたように、それぞれのステークフォルダーが持つ品質に対する思い（定義）はさまざまであり、主観的なものなのだということを強調しているのです。

PMBOKの定義で「要求事項」と言っていた部分が、ワインバーグ氏の定義では「価値」という言葉に置き換わっています。「要求事項」といえば、すぐに思い浮かべるのは「システムが何をしなければならないかを記述したもの」すなわち「要求仕様」です。つまり、「要求事項を満足しているかどうか」ということを評価する場合、要件定義書や設計書通りにシステムが出来上がっているかどうかということを連想しがちです。（※５）

しかし、よくよく考えてみると、設計書通りにシステムが出来上がっていたとしても、設計書自体が間違っていることもあるので、その場合は品質が良いことにはなりません。。。

ん？ちょっと言葉足らずでしたか。。。

設計書通りにシステムが出来上がっていた場合は、その設計書をもとにシステムを構築するのが仕事であるＳＥやプログラマにとっては「品質は良い」ということになりますが、設計書自体が間違っていたとしたら、いくら設計書通りにシステムが作られていても、システムの利用者にとっての「品質は悪い」ということになります。これが、ワインバーグ氏の言う「誰かにとっての価値」ということであり、品質を評価するステークフォルダーの主観にゆだねられることになるのです。

さらにこの主観ということを広げて考えてみると、たとえば何人かのシステム利用者が、それぞれの主観の違いによって、同じシステムを使っていたとしても品質の良し悪しの評価が分かれる可能性もあるということです。

前回の「プロジェクト八景」で、受注側システム開発部長のＤ氏の心の声を思い出してください。Ｄ氏は「たとえ本番障害が出たって、すぐにリカバリーできればお客様に迷惑はかけないし、かえって夜遅くまで一生懸命やっている姿を見せることで、お客様満足度は上がる」と考えているという設定でした。実際に本番障害が発生した場合に、お客様がＤ氏の思っているような評価をするかどうかはわかりません。しかし、Ｄ氏は品質についてこのような主観を持っており、Ｄ氏の考え方が受注側組織内の重要な品質評価尺度となりうる可能性（すなわちプロジェクトの実行に影響を及ぼす可能性）は否定できないのです！

私は、この「主観」ということについて、当ブログの　【第３回】問題とは何か？　で登場した「見方や立場が変われば、問題が問題では無くなってしまう」という「問題認識の相対性理論」と同じだと考えています。つまり、品質評価についても、「見方や立場が変われば、品質の良し悪しが変わってしまう」という「品質評価の相対性理論」が成り立つものと考えているのです！

【　品質とは何か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
それでは多面性があるだけでなく、相対性まで持ち合わせている「品質」をどう定義すればよいのでしょうか？ここまで考察してきた中では、なんとなくワインバーグ氏の定義が全てをあらわしているように感じます。。。

しかし、そもそも「品質とは何か」を定義すべき理由は、前回の「プロジェクト八景」において、各ステークフォルダーが品質についてさまざまな思い（定義）を持っていたことが原因でＰ子さんが混乱してしまったため、その混乱をどうにか解消したいためのはずです。それなのに、「品質とは誰かにとっての価値である」と文学的な表現をしていただけでは、Ｐ子さんの混乱は解消しないのではないでしょうか？

では、どうすればよいか？

そうです！先ほど考察したように、「問題認識の相対性理論」と「品質評価の相対性理論」は同じような性質を持つことに着目すればよいのです！当ブログの　【第４回】プロジェクトにおける問題とは何か？　では、「プロジェクトにおける問題とは、プロジェクト計画と現状とのギャップである！」と定義しました。これと同じように、各プロジェクトにおける品質の定義も、プロジェクト計画書、または、品質マネジメント計画書に具体的に定義し、プロジェクトのステークフォルダー全員に合意を得ておく必要があるのです！

「システム開発プロジェクトにおける品質の定義とは、品質マネジメント計画書に具体的に定義し、合意したものである！」

現実のプロジェクトは文学ではありません。前回の「プロジェクト八景」のように、各ステークフォルダーが品質についてばらばらの考え（定義）を持っていてはプロジェクトは混乱し、成功などそれこそ夢物語になってしまいます。

一般論でいう品質は多面的で相対的な性質を持つものであることは事実だと思いますが、システム開発プロジェクトで目指すべき品質目標は、プロジェクト計画書や品質マネジメント計画書に具体的に定義して、ステークフォルダー間で合意することが、プロジェクトの成功のために必要なことなのです。

ご納得いただけたでしょうか？

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※２　ISO9000については、以下参照。
・「ISO 9000」『フリー百科事典　ウィキペディア日本語版』
2015年6月22日 (月) 01:41 utc https://ja.wikipedia.org/wiki/ISO_9000

※３　いわゆる「JISの品質特性」については、以下参照。
・「ISO 9126」『フリー百科事典　ウィキペディア日本語版』
2014年7月16日 (水) 13:57 utc https://ja.wikipedia.org/wiki/ISO_9126

※４　ワインバーグの品質の定義については、以下参照。
・「ソフトウェア品質」『フリー百科事典　ウィキペディア日本語版』
2014年9月23日 (火) 19:55 utc https://ja.wikipedia.org/wiki/ソフトウェア品質
・「ジェラルド・ワインバーグ」『フリー百科事典　ウィキペディア日本語版』
2014年8月1日 (金) 08:11 utc https://ja.wikipedia.org/wiki/ジェラルド・ワインバーグ

※５　要求事項については、当ブログの以下の回も参照してください。
・【第５１回】カルメンの心変わりと仕様変更～不適切な対応が悲劇を生む！