システムの廃棄
IT業界でシステム開発に携わって、かれこれ15年が経ちました。
大規模システムの保守や機能拡張もやってますが、どちらかというと新しいシステムを一から作る事が多かったです。小規模なシステムだと、納品後数ヶ月くらいで安定運用できてくるので、それ以降クライアントからは音沙汰なし、というケースも多々あります。
最近、5〜6年前に私が開発したシステムを運用終了するという話を、偶然耳にしました。クライアントの当時の担当者が定年退職を迎えた事がきっかけのようです。
ソフトウェアは賞味期限付きのナマモノなのだなぁと、改めて実感しました。
ソフトウェアの経年劣化とは
表面的には、ソフトウェアに経年劣化はありません。今日でも、100年後でも、全く同じように動きます。ソフトウェア本体は不変でも、周囲の環境が変わるため、相対的に賞味期限切れになるのです。
例えば、昔のWebアプリは、WinXP + IE6のPCでのみ動作保証する事が当たり前でした。今、このPCを調達するのはまず無理です。業務ニーズが変わり、従来のシステム仕様のままでは使えないケースもあります。
結局、ソフトウェアを長く使おうとするなら、保守が欠かせないわけです。では、保守できているかどうかは、なにで決まるのでしょう？過去の経験を振り返って考えてみました。
イニシャルコストだけでは長く使えない
IT業界でよく言われている、設計書などの開発ドキュメントの有無というのは、実は直接関係ないのかなと思います。そうではなくて、”ランニングコスト”をきちんと払っているかどうかです。
システム開発は、クライアントから見るとイニシャルコストです。開発が終わって運用が始まると、そこから先がランニングコストです。
クライアントが開発ベンダーと保守契約を結んでランニングコストを払っている場合、仮にある開発者が離任することになっても、保守責任を全うするために「引き継ぎ」という作業が必ず発生します。逆に、保守契約がなければ、ベンダーには引き継ぎしたくなるモチベーションがありません。開発ドキュメントが整備されていようがいまいが、同じことです。開発ベンダーが個人事業主でも大企業でも、同じことです。
開発ベンダーに頼らず、クライアントがプログラミングのできる社員を保守担当に据えるケースもあります。これも、ランニングコストの支払い先が開発ベンダーから自社社員に変わるだけで、本質的には同じことです。
長く運用されているシステムは、どれも相応のランニングコストをかけています。