仕事：もう一歩先を考える

昨日の不具合の原因は、簡単に言うと他のプログラムとの連携ミスでした。 また、今日になって問題となったデータが他の処理に対しても影響を 与えていることがお客さんの連絡で発覚しました。 修正対象となったプログラム全てが単独（もしくは通常の運用）だと 正常に動きます。ただ、今回は年末/年始の忙しい時期に変則的な運用を したことにより発生しました。 確かに結合テスト・システムテストが十分じゃなかったことによる 障害かもしれません。 けれども過去の障害履歴を追うと、他の部分の連携や単独実行時に 同様の障害が発生していて、修正している形跡があります。 障害だけに限らず、仕様変更等である部分に不具合が発生した時、 スポットのみを修正してよしとすのではなく、一人でも 「他のPGで同じようなことをしていないか？」 「変更後のデータが流れていく先のPGで問題ないか？」のように もう一歩先を考えてくれていれば、未然に防げたのでは？と思います。 ■補足 やっつけ仕事でプログラム修正をされると、 ・ソースが汚い。 ・目の届く範囲での整合性しかとられない。 ・同一処理のはずなのに複数プログラムで複数の名前で存在する。 ・辻褄合わせに最後に値をセットし直すもんだから、ロジックを 　追っても、どれが正しいのかよく分からなくなる。 →下手に直すと二次災害が発生するので非常に保守し難いです。 ひどい奴なんかは、こんなことを言います。 「動いている箇所を修正するとテストがすごく大変なんで、 　元のソースはいじりません。」 実際に問題が発生したら、場合によっては不正なデータであろうが 登録済みのデータは削除できません。 本来あってはならない状態を認めた形で、今後は認めないように プログラムを修正しないとならないので、何十倍もコストが発生します。 （それ以前に、何処を修正すれば直るのかソースから判断できない 　プログラムにも問題はありますが。） …おかげさんで、明日は出勤です。（泣）