欠陥の定義と対策について考えてみる
プロジェクトにおいては、欠陥を出さないことが重要なテーマです。欠陥を出すことでもたらされる損失はいかほどになるのでしょうか？
今回は、欠陥そのものについて考えてみたいと思います。
欠陥の定義
PMBOKでの定義
欠陥の定義について考えてみましょう。まずはPMBOKでの欠陥の定義を引用します。
欠陥とは、（引用）「構成要素が要求事項や仕様をみたしておらず、修理または交換を必要とするプロジェクト構成要素の不備や瑕疵」
英訳すると「Defect」です。PMBOKでは欠陥の問題を品質マネジメント知識エリアで記載しています。PMBOKでも相当量のページを割いてこの品質について解説しています。プロジェクトの成否が問われる知識エリアでしょう。
PMBOKでは「欠陥」という言葉を多用しています。これは、各業界で標準的に呼べる言葉を使用しているのでしょう。「不適合品」という言葉も出てきます。製造業を意識しての言葉と思われますね。
システム開発においての欠陥とは？
われわれシステム開発も製造業のひとつですが、あまり「欠陥」という言葉を使っていないと感じています。
文化というものですかね？
管理人は「欠陥」という言葉より、「障害」・「不具合」・「バグ」と呼んでいるケースが多いですし、使われていると感じています。皆さんはどうでしょうか？
まあ呼び方なので、意味するものが同じならばあまりこだわることはないと思います。
欠陥が発生した場合、どのようなことになるか
欠陥は先程の定義どおり、要求事項や仕様を満たしていないものです。
構成要素というのは、プロジェクトの最終成果物を構成する要素という意味です。最終成果物はスコープ記述書で定義されています。
システム開発を例に取れば、最終成果物は「○○システム」とした場合、その構成要素とは個別のプログラムなどを指します。
このプログラムに要求事項や仕様を満たしていないものが発見された場合、「欠陥」と呼ばれます。
欠陥が発生するとその対応をしなければなりません。PMBOKでは「欠陥修正」または「手直し」と呼んでいます。
品質が高いというものは「欠陥」がないということにもなります。「欠陥」は要求事項や仕様を満たしていないものですから、当然品質は悪いということです。
この要求事項や仕様は、スコープ・マネジメント計画で定義・承認されたものです。ここで決められた要求事項を満たしていないことになりますね。
決められていないものは構成要素に含まれている必要はありません。仮に含まれているとした場合、過剰仕様、金メッキ仕様などと呼ばれ、違う意味で要求事項を満たしていないものとして扱われます。
欠陥を作り込まない
重要なことは
また欠陥を作りこまないようにすることも重要です。設計、製造工程で、欠陥のもとを作りこまないようにするということです。
PMBOKでも、「検査より予防」という言葉でその必要性を訴えています。別のところで聞いたことがあるたとえでは「消火より防火」、要するに火の用心ということです。
これは、非常に的を射た例えだと感じています。火を出してからの対応（消火）よりも、火をおこさないようにする対応（防火）のほうが、コストが低いということですね。
みなさんもプロジェクト遂行においてこのようなことは少なからずあったのではないでしょうか？
火を出してしまったプロジェクト
こうなると後処理が大変ですよね。火を出す前に対策を打てなかったのか？ と悔やむところです。
そうなる前に、PMBOKに限らず、品質マネジメントについては多くの書籍などで語られているものです。
管理人も火を吹き出してしまったプロジェクトに参画した経験もあり、またそのようなプロジェクトを見聞きしてきました。別の機会で紹介します。
プロジェクトマネージャの対応
さて、欠陥の定義はわかりましたが、プロジェクトマネージャは具体的にどのように対応いていけばよいのでしょうか？
まず、プロジェクトマネージャは欠陥を作り込まないように手を打たねばなりません。そのためには、少なくとも2つの手を考えておくべきと管理人は考えています。
- 予防策
- 火消し策
予防策
予防策について考えてみましょう。予防策は次の手が考えられるのではないでしょうか？
- 品質計画
- レビュー計画
品質計画
予防策の一つ目は品質計画を立てることです。品質指標は組織として決められているケースが多いでしょう。
品質指標はセンサーと考えてください。指標に引っかかってきたものは、欠陥が潜んでいる可能性が高いと感じてください。
しかし指標だけでは捉えきれない欠陥も存在するので、必ず現物で確認することを怠らないでください。
レビュー計画
もう一つは、レビュー計画です。他の記事でも書いていますが、検査より予防です。これを実践するためには、各工程での成果物に対してのレビューが重要です。
理由は言うまでもありませんが、欠陥を作り込まないようにするためです。
プロジェクトマネージャは、各工程で常時（抜き打ちで）受入検査を実施してください。そしてスコープ（要求事項）が満たされているかを十分に確認してください。
工程完了時点になってからの受入検査では遅いと管理人は考えています。
火消し策
システム開発の多くは、テスト工程もしくは、それ以降の運用テスト（ユーザの受け入れテスト）時点で重大な障害が発生しています。
プロプトジェクトマネージャは、当然、欠陥を作り込まないように設計〜製造工程を進めてきています。しかしながら、それでも欠陥は作り込まれ、障害となって現れてきます。
正直なところ・・
プロジェクトも後半になって火を吹き始めると、これといった特効薬がないのが正直なところです。
欠陥の種類も千差万別、プロジェクトによって特性が異なりますしね。そのため全てのプロジェクトに当てはまる火消し策は見当たりません。
この辺りは、PMBOKでも語っていないところです。
リスク・マネジメントで、あらかじめリスクの特定を行っておき、それに対する対策を事前に準備しておくことが該当するでしょう。
PMBOKのスタンスとしては、あらゆる事態を事前に計画しておくことが挙げられます。管理人もこの趣旨には賛同していますが、それでも予測できないことは起きてしまいます。
まとめ
PMBOKで言うところの欠陥に関する記述は、システム開発においても充分役に立つものだと感じています。
「検査より予防」というスローガン（？）は、どの業種においても当てはまるものです。
PMBOKを熟読して、十分に腹落ちさせてください。きっと役に立つことでしょう。