『プロジェクトを絶対に失敗させない！やり切るための100のヒント』とは
本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない！やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。
当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
お問合せはこちらからどうぞ。
※『プロジェクトを絶対に失敗させない！やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます
PMOとしてプロジェクトマネジメントを実施していく場合、期待される効果に「品質マネジメント」があります。私はPMOとして数多くのプロジェクトに関わってきましたが、PMBOKに書いてあるような標準偏差を用いた管理などは、実施したことがありません。
それでは、PMOとしてどのように品質に関わっていけばよいでしょうか。今回はシステム開発における品質マネジメントについて考えてみます。
PMBOK（第4版）の品質管理の章には「プロジェクト品質マネジメントは、品質計画と品質保証、品質管理の3つのプロセスから構成されている」と記載されています。PMBOKはプロジェクトマネジメントを実施する人にとっては教科書的な存在ですが、果たしてどれだけのシステム開発プロジェクトでPMBOK通りの品質管理が行われているでしょうか。「品質保証」と「品質管理」の違いが分かる人が、どれだけいるか疑問です。違いが分かったとして、品質は本当に向上するのでしょうか。
恥ずかしながら、私も「品質保証」と「品質管理」の違いを正確に暗記して言うことができませんし、誤解を恐れずに言えば、その違いを理解したからといって「品質管理（品質保証）」ができるようになるとも思えません。
PMBOKには品質管理のツールとして「特性要因図」「管理図」「ヒストグラム」「パレート図」「統計的サンプリング」などが挙げられています。しかし、私は管理図で標準偏差を利用し、品質管理した現場を経験したことがありませんし、あまり聞いたこともありません。そもそも、「このプロジェクトの品質は目標値±3σ（σは標準偏差）の間に入っていますので」と言われても、ほとんどの人が「何のこっちゃ」という感じになるでしょう。
PMBOKはベストプラクティスであり、役に立つ場合が多いのは確かです。しかし、超大規模のプロジェクトを除けば、PMBOKの品質管理は実際のシステム開発には大げさすぎるというのが実感です。私がPMOとして品質マネジメントを行う場合に注意する主なポイントは、以下の4つです。
（1）品質指標の妥当性と目標値の意味付け
（2）設計品質と開発品質
（3）プロセス品質とプロダクト品質
（4）非機能要件に関する品質の確保
品質指標は目安に過ぎない
プロジェクトの、特にテスト工程で、みなさんは品質目標を立てたことがあると思います。よく使われる指標には「テスト密度（単位当たりのテストケースの数）」や「バグ密度（単位当たりのバグの数）」などがあります。ここで、ファンクションポイントやコード行数といった単位に、各社が独自に持っている係数を掛け、基準値を計算するのが一般的です。ただし、この係数自体、あまり説得力のないものであったりします。
『ソフトウェア開発データ白書』（情報処理推進機構著・編集）などで公表される平均値を、係数として利用する場合も少なくありません。大手のシステムインテグレーターやITコンサルティングファームは独自の社内指標を持っています。しかし、これらもプロジェクトごとに異なる規模や特性、前提条件を加味して考えると、設定した単一の指標を満たしていれば、品質OKというものでもありません。
それでは、品質指標とは何なのでしょう。誤解を恐れずに言えば、「品質の指標とは単なる目安でしかない」と私は考えています。具体的に言えば、「その指標を満たしていないから品質が悪い」「指標を満たしたから品質が良い」と判断できるほど確かなものではない、ということです。それでは、その指標を満たす場合と満たさない場合を、どのように考えればいいでしょうか。テスト密度やバグ密度で考えてみましょう。
＜テスト密度＞
（1）指標を満たす場合（テストケース数が目標値を超える場合）
（2）指標を満たさない場合（テストケース数が目標値を下回る場合）
（1）は、目標のテストケースを上回ったので、問題がないと判断できるでしょうか。ポイントは「テストケースの粒度が小さすぎて、テストケース数が多すぎるのではないか」という観点です。テストケース数は、どの単位で1ケースと数えるかによって、極端な話、1ケースを10ケースに分割することもできます。ここでは、過去の類似プロジェクトや他のチームのテストケースの粒度を見て、正しい粒度でテストケース数がカウントされているかを見ます。
（2）は、目標のテストケース数に達していないので、もっとテストケース数を増やさなければならないのでしょうか。注意すべきポイントは「テストケース数よりも、テストの観点に漏れがないか」です。テストの観点とは、正常ケースやエラーケース、業務上の特別運用に伴うイレギュラーなデータの取り扱い、業務の最大ピーク時データ量に耐えられるか否か、システムが止まった場合に待機系にスムーズに移行できるかなどを指します。
さすがにこの点はPMOには分かりませんので、有識者を交えて観点の漏れをつぶしていきます。結果としてテストの観点に漏れがなければ、無理やりテストケースを増やす必要はありません。テストケースが少ない理由をきちんと説明できればいいのです。
＜バグ密度＞
（3）指標を満たす場合（バグ数が目標値を超える場合）
（4）指標を満たさない場合（バグ数が目標値を下回る場合）
（3）は、意見が分かれます。1つは「目標値を超えたので、意味のあるテストができ、バグを出すことができた」。もう1つは「目標値を超えたということは、開発したシステムの品質が悪いのではないか」。あなたなら、どう判断しますか。答えは、どちらも正解です。
バグに関していえば、大切なのは数よりも中身です。PMOはバグの表面的な数だけでなく、バグの傾向やバグが作り込まれた原因を追究していく必要があります。定量的な数よりも、定性的に中身を精査し、根本原因や類似バグをつぶして品質を向上させることが求められます。
（4）の場合も、同じく意見が分かれます。（3）と同じように、中身を見てどちらに当てはまるのか判断しなければなりません。