私が現在関わっている開発プロジェクトの品質管理は、設計工程以降の成果物に対してのみ行われています。
しかし、単体テストで出た「うっかりミス」のバグ１件に対して結構な量のレポート（原因分析や再発防止策）を書かされるにもかかわらず、結果として出来上がったシステムが顧客のニーズに合っていないことが多々あります。
「品質＝顧客満足度」と考えると要件定義工程も含めて品質を考えるべきだと、上層部に問題提起していきたいのですが、具体的な手法が分かりません。ご存知の方や実践しておられる方がいらっしゃいましたら教えてください。
No.1
1728
320
100pt
ISO9001はシステム開発に特化されているわけではないので、システム要求定義や品質管理については概論的な内容となり、社内を説得する材料としては具体性を欠くかと思います。
そこで、実際のシステム開発に則したものとして、下記の資料がよくまとまっているのでご一読ください。
http://www.jaspic.org/event/2011/SPIJapan/session1B/1B1_ID021.pdf
とくに4ページの「上流工程の不具合混入は、数は少ないもののプロジェクトに莫大な手戻り工数を発生させている」というのは経済産業省の調査で明らかにされた数字ですので、説得力があるでしょう。
経産省による原文は下記にあります。
http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2009software_research/index.htm
解決策としては、5ページにある「V字モデル」で開発・テストを行い、とくに要件定義工程では顧客レビューを十二分に行うことが定石ということになります。
たしかに「品質＝顧客満足度」ではあるのですが、社内では往々にして、顧客満足度より開発工数の合理化の方が説得力を発揮することが多いです。
上述のような「開発の効率化」の線で説得を図るのが得策ではないかと思います。結果的に品質も上がり、顧客満足度が上がれば一石二鳥となります。
2
2
詳しい資料の提示、ありがとうございます。要件定義プロセスの重要性が分かります。
2012/03/02 18:04:57ただ、この工程の品質評価方法となると、なかなか難しいみたいですね。
少し古い資料のようですが、下記を見ると要件定義工程のメトリクス実施率は低いようです。
http://www.juse.or.jp/software/pdf/20_spc/1/1_a_report.pdf
また、メトリクスも「レビュー指摘件数」のような内向きの指標がメインで、顧客からのフィードバックが反映されていないように思えます。
ご回答ありがとうございました。