Webサイトリニューアル手法(3)「じわじわとリニューアル型」の課題と対策
前回からの続きです。
この「徐々にリニューアル型」というのは、たいていの場合、バグが発生すると、手探りで問題解決に当たらなくては成りません。
例えば開発した会社の担当が「これなら1,2時間で直せるな」というものが、
それを知らない会社が引きうけると、普通に半日、場合によっては丸1日かかる事が少なくありません。
というか、ほぼ例外なくそうなります。
これはある意味当然で、勝手知ったる自分の庭、家なら当然話は早いわけですが、 よそ様の家ではゴミ袋一つとってもどこにあるのか、ちょっとしたことで全部手探りになってしまうからです。
そういう点で、この「徐々にリニューアル型」というのは時間がかかるのはある程度避けられない形になります。
また、あるところでバグが発生した、ということで修復にかかると、実はこの変数はあちらからも参照していて、 それに気づかず(気づくのは相当困難です)、 あちらをいじれば今度はこちらが表示されなくなったなどの「連動トラブル」がかなりの高確率で発生します。
これもWebサイト主催社はある程度覚悟する必要があります。
つまり、「徐々にリニューアル型」というのは、ある程度対応に時間がかかる、バグがおきてしまうという事はある程度最初から覚悟する必要があります。
その代わり、全部作り直すわけでは無いので、初期に負担に耐えられないようなコストはかからず、 現実的にサービスを提供し続ける事が出来るわけです。いわばメリットとデメリットがバーターの関係です。
多少のバグであれば、致命傷では無い限り目をつぶり、おきないようにするより、おきてしまったらすぐに迅速に対応するでいこう、 という今目先の稼働と改善を優先する、という点では、「徐々にリニューアル型」はかなり現実的な考え方なのです。
また、そうやって対応を進めていくと、時間の経過と共に、プログラムソースを把握出来るようになり、またソース自体を入れ替えて行くことが出来ます。
そうすると、劇的に問題が起こりにくくなってきます。
時間が経てば立つほど落ち着いて安定稼働が出来るのも、「徐々にリニューアル型」の大きなメリットです。