プログラムを組んでいると
いつも頭によぎるのは「納期」。
納期を意識してプログラムを組むのはエンジニアの宿命ではあるものの
この納期を守るために
残っている修正を納品の後に持って行く事はしてはいけない。
当たり前に思うかもしれないが。
プログラムの中には
納品時には修正していなくても大丈夫なポイントの思える所があったりする。
しかし、それはどんな内容であってもそれは「バグ」なのである。
絶対に後で直さなければいけない部分。
後回しにすることで起こる問題が増えてしまう
まず、
納品後に発生するバグと一緒に直さなければいけない。
納品後に発生するバグは「重要度」が高く、残してあるバグより先に直さなければならない。
納品前のバグは後回しになり、場合によっては埋もれてしまうこともある。
残してあったバグも絡んでの事だと事態がややこしい方向に進む。
複数のバグを同時に修正しないと行けなくなった場合、修正した事で起こった事の
原因と結果がわかりにくくなり、問題が無いはずの残したバグまで疑わなければいけなくなる。
原因がアバウトな状態でのプログラムの修正は困難を極める。
修正はなるべく少ない状態であることが、後々の修正効率を上げる事に繋がる。
もう一つは
納品後に見つかったバグはすべてお客さんからすると１カウントになる。
それほど問題の無い修正もやっていない状態で納品すればお客様が見つければ「不具合」
それは表示する文字が１文字違うものでも。
これはお客様の評価が下がる。
リリースする前に分かっていない内容だった場合は仕方ないが、
リリース前に分かっていて直していない分までマイナスになると非常に後がやりづらくなってくる。
これだけで終わればいいが、
前者の問題は、修正に時間がかかる事で他の修正の精度が下がり、それが原因でさらにバグが出るような問題。
後者の問題は、バグの多さからお客様の立場が強くなってしまい、理不尽な要求が増える様な問題。
に繋がることになる。
こうなってくると、どんどん状況が悪化し立て直しが厳しくなるので（立て直しはマネージャーの仕事になるが）
リリース前のバグや問題は絶対に解消しておくべきである。
