保守をやっていると、
- この商品、扱わなくなったので、購入できないように関係する機能を止めてほしい。
- この機能、連携先との契約が終わるので、使えないようにしてほしい。
といったことがある。
後から付け足した機能だと、機能のon/offができるようになっていたりして、「削除するならoffにするだけで対応完了！」と思いがちなのだが、そんな簡単な話にはならない。on/offの設定を無視している部分があったりするのだ。
だから、設定を無視しているところがないか、コードを全部調べる必要がある。
調べて設定を無視しているところがないことを確認できたからと言っても、offにしてお終い！というわけにはいかない。そういった機能は外していかないと、使わない機能ばっかりのシステムになるし、使わない機能にセキュリティの問題があって、侵入されたりするのだ。「使っていない」と「機能がない」を区別できず、リスクを見落としてしまう。
また、後日他の改修をするとき、影響範囲や修正の必要な箇所を調べることになる。そのときに思い出さないと、削除した、もう使っていない部分まで調べてしまう。使われていないはずの機能の処理との依存関係(offにしたので処理としては呼び出されることはないものの、プログラムとしては使用している状態になっている)から、素直な(分かりやすい)改修方法を取れないこともある。
結局、問題を先送りすることで、次の改修を行うときの負担が増え、システムの技術的負債を増加させてしまうのだ。動いているシステムは、意外と長く使われる。現状維持は、新しいことを始めることと比べると、いろいろな意味で楽だからだ。
保守案件ということで請け負っている場合、このようなリスクの積み重ねを考慮して、費用を上げていくのは当然だと思う。折り合わなければ、請けないということでリスクを回避するのだ。一方、自社システムであれば、逆に、こういったことを早く解決して、長期的なコスト増加を事前に防いでいくべきだと思う。
プログラムを書く人ですら理解できない人はいるのだが、手を入れていかないと、プログラムは死んでしまう。泳ぎ続けるマグロのようなものなのだ。
常に水槽の水を回し続ければゴミは底にたまらず浮いてくるので、すくいだすのは容易だ。保守案件も、ちょくちょく手を入れるようにすれば問題点が浮き上がってきて、解決しやすくなる。続くシステム、続けるシステムであれば、「次どうなる」を考えて対応していくべきであろう。新規案件しかやらない、いわゆる「やり逃げ」の会社には関係ない話だろうけど。