なんらかの作業をプログラムなどで自動化する仕組みを作ったとします。
作業効率が何十倍にもなり、めでたしめでたし。
と、言いたいところですが、そうではありません。
システムにはメンテナンスが必要です。
作ったシステムが動かなるケース
例えば、使っているプラットフォームにセキュリティに関する問題が発生した場合、不正アクセスやウイルス感染を防ぐためにアップデートが必要になります。
ただ、アップデートしたために、作ったプログラムと整合性が取れず、システムが動かなくなる場合があります。
セキュリティに関する問題を放置することはできないため、アップデートは必須。
それに対応するようにプログラムの修正も必須となります。
また、作成したプログラムが、外部のサービスやアプリと連携して動く場合、それらの仕様変更により、プログラムが動かなる可能性があります。
サービスやアプリをバージョンアップして、仕様が変更されたり機能が削除されたりすると、作ったシステムと整合性が取れなくなるためです。
特に、ウェブサービスは、特にバージョン番号などはなく、サービス側が行った変更をユーザーで知ることはできないので注意が必要です。
ビジネスをストップさせないシステムメンテナンス
こういった問題が発生すると、せっかく自動化した作業を自動でできなくなってしまいます。
自動化しているので、その分の工数は予定外の工数になります。
残業や休日出勤で対応できればまだよいのですが、その作業が、人力で行うには時間がかかりすぎて現実的でないような作業であれば、ビジネスはストップしてしまいます。
そのシステムが生産性に貢献している度合いが高いほど、早い復旧が求められるのです。
ビジネスをストップさせないためには、頼れる有識者とすぐに連絡が取れるとよいですね。
こうした問題が発生した時のために、相談したり問題を解決してくれるビジネスパートナーと普段から関係を築いておくことが重要になります。
メンテナンスしやすいシステム
作ったシステムがどのように作られているか、によって復旧のスピードも変わってきます。
「ただ動けばよい」という思考で作られたシステムと、「後々のメンテナンス性も考えられたシステム」では、正常時の動作は違いが見られないかもしれません。
しかし、メンテナンスが必要になったり機能を拡張する時には、対応に必要な工数や時間が大きく違ってきます。
システムの中身を見て、その作りのよさを判断するのは、プログラミングや IT システムの知識や経験がないと難しいです。
だから、信頼でき、腕のよいシステム屋さんを見つけて仲良くなるしかないのですが。。
お医者さんを見つけるのと同じですね。
終わりに
システムは作って終わり、ではありません。
システムにはメンテナンスが必要なことを認識しておくこと。
メンテナンスには費用がかかるので、システムを作ることだけに予算全額を突っ込まないこと。
問題が発生した時に、相談したり問題を解決してくれる信頼でき、腕のよいシステム屋さんと普段から関係を築いておくこと。
こういったことも必要になってきます。