『プロジェクトを絶対に失敗させない！やり切るための100のヒント』とは
本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない！やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。
当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
お問合せはこちらからどうぞ。
※『プロジェクトを絶対に失敗させない！やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます
『［ヒント84］PMOとして品質にどう向き合うか1』では、品質マネジメントの勘所として4点を挙げ、最初のポイントについてまず考察しました。次に残りの（2）～（4）を見ていきます。
私はプロジェクトの現場で「良いシステムを開発するために、テスト期間を長めに取って、たくさんテストを実施しましょう」という言葉を何度か耳にしたことがあります。「品質を上げるには、テストでたくさんのバグを出せばよい」と信じている人もいます。しかし、ウォーターフォール型の開発手法では、上流工程（要件定義や基本設計）の品質こそ重要です。ここでいかに品質を上げ、設計品質を確保しておくかが、プロジェクト全体の品質を決めます。
なぜなら、開発工程は設計成果物をインプットにして進めるため、設計の品質が悪ければ、開発の品質も悪化します。手戻りが発生すれば、後工程になればなるほど「品質コスト（品質を確保するために必要なコスト）」が多く発生します。設計品質を確保する観点は、3つあります。
（1）プロジェクトの目的を達成するために必要なニーズを把握し、必要な要件や機能を満たせているか
（2）開発を担当する人々にうまく伝えられる内容になっているか
（3）機能だけでなく、運用や使い勝手まで設計されているか
これらを満たすために、どのような品質保証活動をしていくか。プロジェクトの特性を鑑みて、考えなければなりません。例えば、要件定義に書かれていることが全て機能として網羅されているかどうか、要件定義書と基本設計書の内容を突き合わせてみます。あるいは、担当者ごとにレビューの指摘傾向を把握して、業務内容の理解不足による間違いがないかを再検査してみます。機能ごとの整合性が設計書レベルで取れているか、有識者が集まってシミュレーションを行う、といったことも考えられます。
プロセス品質とプロダクト品質を区別する
品質管理をしていくなかでの基本は、「顧客満足」と「検査よりも予防」の2点にあります。顧客満足とは、お客様のニーズを満たしたり、お客様の問題を解決したりすることです。そういう意味において、お客様の本当のニーズや問題を正確に捉えられているかが重要になります。一方、検査よりも予防は、「プロダクト品質よりもプロセス品質」という言葉に置き換えられます。PMOは成果物を作り込んでいくプロセスにおいて、誤りが入り込む余地をなくす環境や仕組みを作ります。
設計工程で効果があるのは、レビュープロセスを仕組みとして組み込み、レビュープロセスの品質（決められた通りにレビューが実施されているか）をPMOとしてサンプリング（モニタリング）しながら改善していくことです。開発工程においてはバグの原因分析を行い、類似バグを徹底的につぶしていくプロセスを組み込み、開発プロセスの品質を高めていきます。
なお、プロダクト品質とは、実際に作られた成果物の品質です。ここは地道に、レビューの密度や精度、テストによるバグつぶしで品質を上げていくことが重要です。
品質は上を目指せばきりがありませんし、最初からバグがゼロというシステムも考えられません。最近はBRMS（ビジネスルール管理システム）の導入で、プログラミングでのバグをゼロにする（つまり、開発品質を保証する）ことが可能になってきていますが、設計品質についてはまだ途上です。上流工程において、顧客満足のために設計品質を確保することが最重要なのは言うまでもありません。