2008_09_29－悪い品質を引き継ぐ。

２００８年９月２９日発行

分割ラインです

　《　品質管理編　》

　　
　悪い品質を引き継ぐ。
　　
　　
　　大型プロジェクトになると、約１割～２割程度はどうしようもない
　　品質にもかかわらず、ぎりぎりセーフという状態で本番にのせることが
　　多くある。
　　
　　みんな承知の上ですが、やむを得ないのです。
　　
　　完璧なプロジェクトというのも存在しません。
　　大きなプロジェクトになると、無事に本番稼動できる方がめずらしく
　　なります。
　　
　　それは品質が均一ではないからです。
　　プロジェクトマネージャーの性格によるのですが、
　　　　完璧主義ではプロジェクトは成功しないのです。
　　
　　プロジェクト内には、どうしようもない品質のものが必ず存在します。
　　
　　
　　
　　どうしようもない品質とは、
　　　　　・製造工程のメンバーが入れ替わりが多く、ＰＧ内にムダが多い
　　　　　・故障が完全に出し切れていない。
　　　　　・少しでもイレギュラー試験を行うと必ず故障が発見される。
　　　　　・修正は、作成者本人しかできない。
　　　　　・標準化がぜんぜん守られていない。
　　　　　・故障検出件数も予定よりかなりオーバーしている。
　　　　　・品質対策を行っている時間もなかった。
　　　　　・ぎりぎり他のメンバーとスケジュール歩調をあわせている。
　　　　　・報告書に矛盾が多く、あやしい内容である。
　　
　　
　　こんな状態でも、なんとか運用に耐えられる状態までもっていくのです。
　　でも、中身の品質はかなりひどいのす。
　　
　　
　　　　正常運用しか耐えられないシステムが出来上がるのです。
　　
　　
　　こんなシステムでも引継ぎが行われ、メンテナンスも発生します。
　　引継ぎを行ったとき、ドキュメントやＰＧの一部を検証すれば
　　なんとなく不安がよぎることってあります。
　　
　　その勘は、間違いなく当たっているのです。
　　
　　悪い品質のシステムだって引き継がなければなりません。
　　
　　
　　
　　じゃ、メンテナンス対応策は、
　　　　・引き継いだシステムが悪いとわかった時、範囲を確定しましょう。
　　
　　　　・メンテナンス見積りには注意する。修正リスクは高い。
　　
　　　　・ドキュメントの不備は、メンテナンス効率も悪くなります。
　　　　　　少しでも、タイミングを見つけて修正する癖をつけましょう。
　　
　　　　・修正内容が正しいとは、多くの場合言えません。
　　　　　　パイロットで修正して試験を行って初めて修正内容が正しいと
　　　　　　言えるのです。
　　　　　　よくあるのですが、「まさかこんな所に余分な細工があるなんて」
　　　　　　というセリフです。後の祭りですが。
　　
　　　　・処理内容が同じだから、すべて同じ修正内容で通るとは思わない。
　　　　　　設計者や製造者が入れ替わっているとロジック内容も違います。
　　
　　　　・作成者のクセをみつけて、ドキュメントに記載しておく。
　　　　　　プログラムには、作成者の思想が入り込みます。クセを理解する
　　　　　　と対応もはやくなる。
　　
　　　　・中には、修正不能なその場限りのＰＧもある。
　　　　　　新規作成したほうが早いのではと思うＰＧは結構多い。
　　　　　　しかし、ロジックセンスの問題で新規作成するのは大間違い。
　　
　　　　・修正効率よりも、品質向上の確実修正に重きをおく。
　　
　　　　・試験は修正内容だけでなく、一通り試験を実施する。
　　　　　　思わぬしっぺ返しを食らうことがある。
　　
　　　　・故障対応記録は、残しておく。今後のメンテナンス対応に役立てる。
　　
　　
　　
　　
　　なんでこんなことを、俺たちがしなければならないのか？
　　　その気持ちもよくわかります。
　　
　　しかし、一定確率で不良品が発生するのも自然の摂理なのかも知れません。
　　その反対に１割は、すごく優秀でメンテナンスも容易なシステムも存在する
　　のです。
　　
　　
　　　　　　規模に応じて一定割合で必ず存在します。