バックナンバーはこちら→#1(はじめに)
→#2(管理)
→#3(納期)
前回は「納期」についてでした。今回は管理要素の一つ、「品質」
についてです。
■品質
情報システム構築における「品質」とは、何でしょうか。作業標準
や開発標準を制定し、それに準拠してプロジェクトを進め、作業状況
をセルフ・チェックや第三者チェックにより点検することはできます。
製品の出来栄えについては、個々の作業や各工程におけるレビューを
工夫し徹底することによってチェックできるとしています。前者は、
「作業品質」、後者は「製品品質」のことを指しています。
作業品質については、ISO9000シリーズの導入により「品質
システム」を制定し運用しているシステム・ベンダーが1995年あたり
から増加しています。ユーザー企業がシステム・ベンダーを選定する
条件のひとつに「作業標準」「開発標準」を保有し、「品質システム」
に準拠しながらプロジェクトを進めることができることをあげている
ことも珍しくはありません。
品質上の問題は、その内容が誤謬に基づくものであれ、改善に基づ
ものであれ、直前の工程まで戻ることは許容範囲だとしても、それを
越える前まで遡って作業をやり直さなければならなくなると、納期・
コストに大きな影響を及ぼすことになります。一般的に、「要件定義
工程」や「外部設計工程」などユーザー企業の利用者部門が参画する
割合が大きい上流工程では、「作業品質」を正しく評価することは、
経験上難しいことです。また「製品品質」については、超上流工程を
踏まえ、上流工程のレビューにより「合意形成を図った」場合でも、
利用者部門にリリースする段階で、「あれ、これじゃ使えないなぁ」
と不満が露呈するケースもあります。
品質管理の基本は「当該工程で作りこむ」と言われています。作業
標準に頼りすぎず、当該工程での作業計画や手段を徹底的に検討する
ことが必要です。作業標準はあくまでも「ひとつの雛形」として捉え
今、自分が携わっているプロジェクトの特性を鑑み、作業標準を基に
一歩踏み込んで考えることが必要だと思います。それが足りないプロ
ジェクトがいかに多いことでしょうか。
「製品品質」は、システム構築の場合、大きく分けて「機能」に関
する品質と「性能」に関する品質があります。また、工程からみると
「設計品質」と「製造品質」(プログラム品質)から成り立ちます。
設計品質では、いかにして正しい設計書、換言すれば「瑕疵の無い設
計書」を作成するかということと、いかにして「性能保証」をするか
という問題です。
製造品質で重要なことは、「隠れた瑕疵」すなわち、テストデータ
で発見・修整されない瑕疵の発生をいかに予防するかということです。
テストでは100%の検証はできません。それどころか、60%程度
検証できればよい方であるといえます。このために、プログラム構造
設計と机上デバッグが重要になるのですが、昨今の構築スタイルでは
このあたりが軽視されているような感があります。
最後になりますが、品質管理で申し上げておきたいことは、「過剰
品質」にならないことです。多くのプロジェクトで、永久に使用しな
いドキュメントを作り続けてきたことはないでしょうか。また個々の
部品動作テストを意味のない形で実施し続けてきたことはないでしょ
うか。
次回はQCDの一つ、「コスト」についてです。
↑If this article is quite good, will you please click?
→#2(管理)
→#3(納期)
前回は「納期」についてでした。今回は管理要素の一つ、「品質」
についてです。
■品質
情報システム構築における「品質」とは、何でしょうか。作業標準
や開発標準を制定し、それに準拠してプロジェクトを進め、作業状況
をセルフ・チェックや第三者チェックにより点検することはできます。
製品の出来栄えについては、個々の作業や各工程におけるレビューを
工夫し徹底することによってチェックできるとしています。前者は、
「作業品質」、後者は「製品品質」のことを指しています。
作業品質については、ISO9000シリーズの導入により「品質
システム」を制定し運用しているシステム・ベンダーが1995年あたり
から増加しています。ユーザー企業がシステム・ベンダーを選定する
条件のひとつに「作業標準」「開発標準」を保有し、「品質システム」
に準拠しながらプロジェクトを進めることができることをあげている
ことも珍しくはありません。
品質上の問題は、その内容が誤謬に基づくものであれ、改善に基づ
ものであれ、直前の工程まで戻ることは許容範囲だとしても、それを
越える前まで遡って作業をやり直さなければならなくなると、納期・
コストに大きな影響を及ぼすことになります。一般的に、「要件定義
工程」や「外部設計工程」などユーザー企業の利用者部門が参画する
割合が大きい上流工程では、「作業品質」を正しく評価することは、
経験上難しいことです。また「製品品質」については、超上流工程を
踏まえ、上流工程のレビューにより「合意形成を図った」場合でも、
利用者部門にリリースする段階で、「あれ、これじゃ使えないなぁ」
と不満が露呈するケースもあります。
品質管理の基本は「当該工程で作りこむ」と言われています。作業
標準に頼りすぎず、当該工程での作業計画や手段を徹底的に検討する
ことが必要です。作業標準はあくまでも「ひとつの雛形」として捉え
今、自分が携わっているプロジェクトの特性を鑑み、作業標準を基に
一歩踏み込んで考えることが必要だと思います。それが足りないプロ
ジェクトがいかに多いことでしょうか。
「製品品質」は、システム構築の場合、大きく分けて「機能」に関
する品質と「性能」に関する品質があります。また、工程からみると
「設計品質」と「製造品質」(プログラム品質)から成り立ちます。
設計品質では、いかにして正しい設計書、換言すれば「瑕疵の無い設
計書」を作成するかということと、いかにして「性能保証」をするか
という問題です。
製造品質で重要なことは、「隠れた瑕疵」すなわち、テストデータ
で発見・修整されない瑕疵の発生をいかに予防するかということです。
テストでは100%の検証はできません。それどころか、60%程度
検証できればよい方であるといえます。このために、プログラム構造
設計と机上デバッグが重要になるのですが、昨今の構築スタイルでは
このあたりが軽視されているような感があります。
最後になりますが、品質管理で申し上げておきたいことは、「過剰
品質」にならないことです。多くのプロジェクトで、永久に使用しな
いドキュメントを作り続けてきたことはないでしょうか。また個々の
部品動作テストを意味のない形で実施し続けてきたことはないでしょ
うか。
次回はQCDの一つ、「コスト」についてです。
↑If this article is quite good, will you please click?
※コメント投稿者のブログIDはブログ作成者のみに通知されます