業務システムが問題なく動いていると、「今は変えなくてよい」と考えがちです。しかし、システムを支える基盤にはサポート期限があります。
動いているシステムでも、バージョンアップを放置するとリスクは高まっていきます。 一方で、システムの作り方を工夫すれば、バージョンアップの負担は減らせます。
なぜバージョンアップが必要なのか
業務システムは、フレームワークやプログラミング言語など、多くの部品の上に作られています。これらの部品には、開発元が更新を提供する期間が決まっています。
サポート期限が過ぎると、新しい脆弱性が見つかっても修正が提供されなくなります。
放置すると起こること
| リスク | 内容 |
|---|---|
| 安全性の低下 | 脆弱性の修正が受けられない |
| 作業の大規模化 | 差が開くほど、変更の量と確認の範囲が増える |
| 関連する部品の更新の連鎖 | 古い部品が新しい環境で動かなくなる |
| 計画の自由度の低下 | 期限や問題に追われて、急いで対応することになる |
バージョンアップは、先送りにしても不要にはなりません。後回しにするほど、1回の作業が大きくなりやすいです。
私が携わったシステムでも、サポート期限と脆弱性への対応のため、システムの基盤である Spring Boot を2系から3系へ、さらに4系へとバージョンアップしました。
負担が大きくなる原因
バージョンアップの負担が大きくなる主な原因は、次の2つです。
- 影響が広がる: 業務のルールを書いた部分が基盤に依存していて、基盤の変更がシステム全体に及ぶ
- 確認に手間がかかる: 変更後に、人が画面を操作してすべてを確認している
逆に言えば、この2つを解決すると、負担を大きく減らせます。
負担を減らす2つの作り方
1. 業務のルールを基盤から切り離す
業務のルールを書いた部分を、フレームワークに依存しない形にします。
すると、バージョンアップの影響を受ける範囲を、基盤に近い部分に局所化できます。
私が携わったシステムでも、業務のルールが基盤に依存していたため、切り離す形に作り直しました。あわせて、依存が元に戻らないように、ルールを自動の試験で確認しています。
2. 確認を自動化する
バージョンアップで大切なのは、変更の前後で結果が変わらないことです。
回帰試験を自動化すると、毎回同じ内容を確認できます。画面の操作の確認も、自動化できます。
自動化には最初の手間がかかります。しかし、試験は次のバージョンアップでも繰り返し使えるので、一度整えておくと、確認の工数を削減できます。
経営者が確認しておきたいこと
技術の詳細を理解する必要はありません。次の点を開発の担当者や委託先に確認してみてください。
- 主要な基盤のサポート期限はいつか
- 次のバージョンアップの予定はあるか
- 業務のルールと基盤は切り離されているか
- 変更後の確認は自動化されているか
- バージョンアップの費用は保守の計画に入っているか
社内に確認できる人がいない場合は、社内にIT担当者がいない会社のDXの進め方も参考にしてください。
まとめ
バージョンアップは、システムを安全に使い続けるために必要な作業です。業務のルールを基盤から切り離し、確認を自動化しておけば、影響の範囲と工数を減らせます。期限に追われる前に、計画に入れておきましょう。
