プロジェクトマネジメント研修：課題用ストーリーテリング資料

ストーリー5：品質管理

あなたはアプリケーション開発のプロジェクトマネジャー。
ユーザーとの業務要件定義で苦戦している。
プロジェクト計画書で合意したスコープが後から変更になることや、仕様確定後に業務要件の追加などの事象が発生した。
あなたのプロジェクトマネジャーとしての対応は間違っていない。あなたが的確にプロジェクト計画書を作成し、スコープ管理を行い、マスタースケジュールを明示したことで、ユーザーからの要求はすべて変更要求として認識され、プロジェクト目標のQCD条件の変更を伴って対処されてきた。
あなたはQ（品質）について不安を抱えている。スコープや要件の追加に伴って、要件理解不足や新たな要件不備が発生している気がしてならない。そこで、テスト工程のみならず設計工程の品質分析・製造工程の品質分析を丁寧に行うこととした。

シーン１　業務要件一覧と機能要件一覧と設計工程の品質分析
変更があった箇所、変更によって影響を受ける他の箇所について、改めて業務要件一覧と機能要件一覧の整合性を確認し、記載し直した。設計段階においても業務要件一覧と機能要件一覧を常に参照しながら、設計レビューでの指摘に漏れが生まれないように注意した。洗い出した問題点を設計に反映させることで製造工程も順調に進むこととなった。

シーン２　テスト工程の品質分析
製造工程が終了しテスト工程に入った。機能要件の確認は設計工程と製造工程の段取りがうまくいったことで比較的スムーズだった。非機能要件の確認により多くの工数を割く事とした。改めて業務要件を踏まえた際の非機能要件を確認し、不具合の確認を行った。結果、完成したアプリケーションはサクサク動くと評判となり、ユーザーの利便性向上に貢献することが出来た。

あなたはプロジェクト中に記録していた不具合（設計工程で指摘した不具合、製造工程で発見した不具合、テスト工程で対処した不具合すべて）のドキュメントをユーザーに報告した。
スコープ変更や業務要件追加によって発生する品質リスクや、増大したコスト金額を説明し、今後の開発においては初期のスコープ定義や要件定義で十分に要件を出し切っていただくようお願いした。
ユーザーは具体的なドキュメントや金額を見て、以後の改善に努めることを約束してくれた。
この一件であなたのプロジェクトマネジャーとしての信頼は高まった。