品質と等級をシステム開発に当てはめてみる
PMBOKに「品質と等級」という言葉が出てきます。どちらかというと製造業の方には良くわかる言葉と思います。
ITベンダー勤務の管理人にはいまいちピンと来ない考え方でした。
しかしそれを理解すると、品質に関する考え方が変わりました。さすがPMBOKです。
品質と等級の意味の違い
品質について
他の記事でも書いていますが、品質とは次の内容で表現されています。ISO9000シリーズで説明されている内容のほうがわかりやすいかもしれませんので、そちらから引用します。
本来備わっている特性の集まりが、要求事項を満たす程度
ISO9000シリーズとは、「ISO(国際標準化機構)による品質マネジメントシステムに関する規格の総称」です。
品質に関するデファクトスタンダードだと考えてください。十数年前から、ITベンダーでも取得しているところが増えていますので、ご存じの方も多いでしょう。
等級について
等級については、PMBOKの説明がわかりやすいので、こちらから引用します。
同一の用途であっても技術的特性が異なる成果物に定めた区分のこと
具体的にはどう違うのか？
どちらの引用例も抽象的で具体的にどういうことなのかがわかりにくい内容です。そこでよく参考書などで例に出されるのが、車を題材にした例です。
車の品質例
- アクセルを踏めば進む
- ブレーキを踏めば止まる
- ハンドルを切れば曲がる
車の品質とは、「車が本来備わっている特性」を表します。車ならば「当然持っていなければならない特性」と読み替えてもらっても構いません。
車の等級例
それでは等級とはどのような例になるのでしょうか？
- 同一車種内でのグレード（高級モデル、一般モデル、廉価版モデル）
- 同一の車種（用途）であっても、技術的特性が異なる（排気量が違う、ターボ付きなど）
- しかし品質はすべて同じである
何が違うのか？
車の品質が悪いということは、ブレーキが利かないなど「車本来が持っているべき特性が悪い」と、いうことです。
このような場合「欠陥」と呼ばれます。
しかし等級とは「品質は満たされているが、そのグレードが異なる」という点で、品質とは大きな違いがあります。
顧客は、自分が求めるグレードの車を買えばよいのです。高級感を求めるならば、高級モデルを買うなど。
ただし品質が満たされていることが条件です。本来備わっている特性が満たされていないと、高級モデルであっても「欠陥品」として扱われます。
簡単な例ですが、品質と等級が違うというイメージがわいたでしょうか？
システム開発に当てはめる
これをシステム開発に当てはめてみるとどうなるかみていきましょう。
品質に該当するもの
パッケージソフトウエアなどは、車の例と似たようなものになるのですが、スクラッチ開発の場合、うまく当てはめられるでしょうか？
まずはシステム開発における成果物の品質に該当するものを考えてみましょう。
管理人は大きく分けて、2つあると考えています。
- 顧客が出してきた要求事項
- 本来システムが持っていなければならない特性
この2つを満たさないと品質がよいとはなりません。ではどのようなものでしょうか？
顧客が出してきた要求事項
顧客が出してきた要求事項は、通常、明文化されているので、わかりやすいですね。要求事項一覧などにまとめられ、さらにスコープ記述書やWBSにまとめて管理されます。
最終的には、スコープ妥当性確認プロセスにて、顧客による検証を行い、要求事項が満たされているかを検査します。
一貫して管理されるので、目に見える、誰もが理解できる品質です。
本来システムが持っていなければならない特性
それでは本来システムが持っていなければならない特性とは、何でしょうか？
機能要件と非機能要件に分かれますが、次のことを満たさないとだめだということです。
- 業務運用に支障がない
- 十分なレスポンスが得られている
- システムエラーとして落ちない
- わかりやす操作性
- ・・・
他にもあるとは思いますが、すなわち「隠れた要求事項」のことを指します。暗黙的に要求される特性と考えてください。
この内容を満たさなければ、最終的な顧客の要求事項を満たせません。
そしてこの「本来システムが持っていなければならない特性」というものは、明文化されていない場合が非常に多いのです。（どちらかというと、非機能要件に該当する内容が多く含まれます）
そのためプロジェクト終盤になって問題が発覚するところが、この明文化されていない要求事項に関する問題です。
それを避けるためにも、明文化しておいてください。
「本来システムが持っていなければならない特性」は、プロならば当たり前だろうといわれるレベルの話です。
顧客により要求度合いは異なりますが、この当たり前といわれる部分も洗い出して要求事項に入れておくべきです。
そうすれば最後の受け入れ時点でもめることが少なくなります。
等級に該当するもの
等級に該当する内容ですが、さきほどの車の例に該当するものは、「パッケージソフトウエア」や「ミドルウエア」などが挙げられます。
グレード別に価格も決まっており、プロダクトとして顧客にも理解しやすいことでしょう。
しかし基幹システム開発などのスクラッチ開発に近い場合は、この等級という概念を当てはめることが難しいと感じています。
なぜなら顧客要求がすべてだからです。
当然たくさんの要求事項を満たすためには、期間と費用が掛かるため、要件の絞り込みを行います。そして松竹梅モデルで提案して、「等級」のように見せることもあります。
苦肉の策ですね。
品質と等級の考え方を学んで
この、PMBOKの品質と等級の違いを理解することで、プロジェクト運営における「満たすべきもの」と「満たす必要がないもの」を見分けられるようになったと感じています。
今までは、「満たすべき」品質がおろそかになっていたため、終盤でトラブルが発生することが多々ありました。
それは、顧客の隠れた要求だけではなく、システムが本来持っていなければならない品質が満たされていないことを重視していなかったことが原因でした。
別記事でも書いていきたいと考えていますが、品質の考え方と品質保証の取り組み方で、プロジェクトの成否がかかっていると言っても過言ではありません。
しかしながらPMBOKで体系的に知識を得たことが、自分の血肉になり始めていると実感できる腹オチ感です。
まとめ
PMP試験に合格するためには、まずは「品質と等級」の違いを額面通りに理解してください。
ところがシステム開発の実務に当てはめようとすると、そう簡単にはいかないことが実感できます。
しかしPMBOKで得た知識は、必ずあなたの後ろ盾となり、実際のプロジェクトでも「品質と等級の違い」を理解することの手助けになるでしょう。
管理人もPMBOKの内容と照らし合わせながら、日々の業務をこなしています。