2008_06_23－デグレードと先祖帰りを防ぐ戦い。

２００８年６月２３日発行

分割ラインです

　《　品質管理編　》

　　
　デグレードと先祖帰りを防ぐ戦い。
　　
　　
　　試験工程で、故障が多発することで起きるデグレードと先祖帰り。
　　どちらも担当者の不注意や確認モレから発生します。
　　
　　
　　　デグレードとは
　　コンピューターソフトウェアのバージョンアップや故障対応に伴う
　　品質低下のことを指します。以前に直した故障がよみがえったり、
　　修正した覚えのない機能まで満足に動作しなくなったりします。
　　
　　　先祖帰りとは
　　最新のプログラムやデータ・設定ファイルを用いず古い版に対して
　　修正を行ったために、古い機能や修正済み故障がよみがえることです。
　　
　　
　　　　デグレード　＞　先祖帰り　を含みます。
　　
　　
　　先祖帰りは、ライブラリ管理ミスや管理不徹底により発生します。
　　特に故障が多発して、多くのメンバーが、故障対応している時に
　　危険度が高まります。
　　なぜなら、ルール違反をする輩が現れるからです。
　　つまり自分のローカルＰＣのソースに修正を行うなど単純な原因です。
　　
　　　これに
　　　　　・バックアップの世代管理が正しく行われていない
　　　　　・先祖帰りしているのに気づくのが遅れてしまい、
　　　　　　　バックアップ保存世代を超えてしまった。
　　　が加わると、復旧は困難になります。
　　
　　
　　　　　試験工程といえども、いつどのような故障対応を行ったのか
　　　　　履歴が取っていなければさらに復旧を困難にします。
　　
　　　　　故障対応履歴はしっかり残しておきましょう。という教訓です。
　　
　　
　　
　　
　　デグレードの場合は、先祖帰りに加えてさらに複雑なミスが絡みます。
　　
　　修正箇所の間違いです。
　　　古いプログラムの機能追加修正について
　　　　　修正内容したロジックには、予想外のデータも流れていており
　　　　　データに対応した処理ロジック記入モレによる故障です。
　　　　　これは本番移行後でもデータが発生しなければ発覚しません。
　　　故障対応
　　　　　修正内容に不具合があり新たな故障をつくりこんでしまった。
　　　　　修正内容が不完全で一部は修正したが、故障が残ってしまった。
　　　　　修正後における試験で判明しますが、どこまで試験パターンの
　　　　　範囲を行うのかによって発覚しない場合が出てきます。
　　　　　後工程の総合試験や本番で発覚するケースも多いのです。
　　
　　　　　故障箇所の横展開対応モレなどもデグレードと呼んでいいと
　　　　　思います。
　　
　　
　　
　　
　　先祖帰りを防ぐには、
　　　　ライブラリ管理のルールを徹底してしっかり行うことでです。
　　　　つまり、ソースプログラムや設定ファイルなどの貸出・返却を
　　　　漏れなく行うことです。
　　　　特に２重貸出や２重返却を絶対に行わせないことです。
　　　　ローカル保存のソースに修正しないことです。
　　　　
　　　　となると故障対応が遅れるという批判が上がります。となると、
　　　　貸出後、担当者どうしで２重修正することも発生します。
　　　　その場合の担当者間の連携を密にしてもらうほかありません。
　　　　
　　　　ルールを厳しくすると現場が回らなくなるので、さじ加減が必要です。
　　　　
　　　　ライブラリ管理とともに、返却時には修正履歴も必ず一緒に提出して
　　　　下さい。いつの世代にどんな修正を行ったのかリンクしなければ
　　　　もし先祖帰りが発生した時に復旧が困難になります。
　　　　
　　　　
　　
　　
　　デグレードを防ぐには、
　　　　修正箇所を複数メンバーによる目視確認です。
　　　　手間がかかりますが、一番確実な方法と考えます。
　　　　その場合、
　　　　　　修正者が修正箇所の説明を、確認者と対話しながら行うことです。
　　
　　　　横展開対応には、ソースプログラムの単純文字列検索と
　　　　ロジックの設計書検索を行い、対応すべき箇所を見つけることが
　　　　主です。また頭の中で思い出すこともあります。
　　　　しかしこの検索キーワードが、正しくない場合がありますので、
　　　　キーワードの確認をとる必要もあります。
　　　　
　　　　横展開は、会社間やプロジェクト間をまたいで検索が必要な場合も
　　　　あります。展開範囲も確認しなければなりません。
　　　　
　　
　　
　　
　　
　　さらに、本番稼動中の故障修正には、
　　　　ライブラリ管理やデグレードの複数メンバー確認、横展開確認以外に
　　　　故障対応した内容
　　　　　　　・故障報告書
　　　　　　　・修正前と修正後ソースリスト（修正内容に付箋・マーカ）
　　　　　　　・修正後における試験項目
　　　　　　　・テストデータ
　　　　　　　・試験結果のエビデンス資料
　　　　の資料をもとに
　　　　　　　試験項目のモレや試験結果、修正箇所の確認を複数メンバーで
　　　　　　　行うことです。
　　
　　
　　
　　
　　これだけ手間がかかる作業を行って、
　　　　　　　　　　　　　　　　はじめて修正時の品質が保たれるのです。
　　
　　故障が多いシステム担当者は、このような点について
　　　　　　　　　　　　　　　　再考してみなければなりません。