2008_04_22－仕様変更や故障対応によるデグレード対策。

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

分割ラインです

　《　品質管理編　》

　　
　仕様変更や故障対応によるデグレードの対策。
　　
　　
　　デグレードとは、
　　コンピューターソフトウェアのバージョンアップや故障対応に伴う
　　　　品質低下のことを指します。
　　
　　
　　ソフトウェア（プログラムなど）をどんな理由であれ変更を行うと
　　　　デグレードの危険は必ずついてきます。
　　
　　
　　既存修正だけでなく、新規作成においても故障対応によって発生します。
　　
　　
　　私も昔は、ユーザーに常駐して長年にわたって古いソフトウェアの
　　　　メンテナンスも多数行ってきました。
　　最近のものならともかく、当時でさえ古いと言われていたプログラムの
　　修正も行っていました。
　　　　もちろん仕様書なるものなど、まったくありません。
　　　　ソースも規約などない時代に作成されたものでした。
　　多分、どこの企業でもいまだに動作している古いプログラムは
　　　　　　　　　　　　　　　　　　　　　　　　　　あると思います。
　　
　　
　　
　　このような新旧入り混じったプログラムが存在する中で
　　　　　　　　　　どのようにデグレードを防いでいくのでしょうか？
　　
　　まず古いプログラムがなぜ、今も動作しているのでしょうか？
　　　　・仕様書もなく解析不能で修正できないプログラムだから。
　　　　・主に基幹システムに集中して、意味不明なロジックが多数あり、
　　　　　　新規作成するリスクより、そのままのリスクの方が小さいから
　　　　・作り直すことによる影響度が大きいから
　　　　・作り直す費用対効果が小さいから。
　　　　・作り直すに当たりどこまで影響するのか、見当がつかないから。
　　　　　　（ネットワークで多数に連携している場合など）
　　
　　
　　　　
　　対応方法（案）として
　　　　・基本は触らぬ神にたたりなし。です。この姿勢がいいのかは？です。
　　　　・意味不明なロジックは、本番と並行して動作させて
　　　　　　ロジックを通るデータを見つけ出します。
　　　　・テストデータを考えられるデータパターンをすべて洗い出し、
　　　　　　テストデータと検証結果を突合せ確認を行います。
　　　　・一定期間新旧を並行動作させ比較チェックを行います。
　　　　・それでも年に数回程度発生する処理パターンで異常となるでしょう。
　　　　・もし異常が発生しても、自動リカバリが機能する仕組みを作成して、
　　　　　　復旧に時間がかかるのを未然に防ぎます。
　　　　・新規作成分においても、故障対応後には、影響確認と横展開による
　　　　　　同一故障内容の検出確認や再テストは行わなければなりません。
　　
　　
　　
　　デグレートの発生要因となるプログラムは、
　　　　　　　　　　　　　　　　　使い続けるかぎり必ず生まれてきます。
　　何もソフトハウス企業だけでなく、
　　　　　一般企業においても、コンピュータを使う限り発生する問題です。
　　
　　
　　
　　仕様をしっかり把握していても、
　　　　データの発生上流部で変更したり、ネットワーク元で変更したりと、
　　　　　　技術の進歩により変更時の影響範囲は、ますます広がるばかりで、
　　　　　　　　　デグレートのリスクは高くなるばかりです。
　　
　　
　　また開発スタッフの変更に伴う引継ぎが、
　　　　十分に行われていない事も多々見かけます。
　　　　　　これはデグレートを誘引するリスクのもっとも大きな要因です。
　　
　　
　　
　　
　　急速に変化する環境化で、
　　　　　デグレードの抑制を限られた人員の中で行うことは、
　　　　　　　　ますます難しくなってきています。