ソフトウェアはなぜバージョンアップしなければならないのか

はじめに

社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。
特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。
そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。
この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。

ソフトウェアの有効期限は2-5年

まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。

なぜ動かなくなるのかには様々な理由があります。ソフトウェアを動かすミドルウェア、プログラミング言語のランタイム、コンテナ、OS、はたまた外部サーバのAPIや認証サービス、それぞれが常に変化し続けており、古いバージョンを使い続けているといずれどこかが動かなくなります。

たいていのソフトウェアはLong Term Support (LTS) バージョンがあり、それらの変化にマイナーパッチを出してくれますが、古いバージョンを永久にサポートしてくれるわけではありません。おおむね２年から長くても５年で保守サポートが切れます。そのため、遅くとも２年に一回程度はバージョンアップをしなければならないのです。

IT業界は転職が多い業界ではありますが、２年といえば多くの社員にとって自分の在籍中に少なくとも一回以上バージョンアップを経験するということになります。先送りにして責任から逃れられる問題ではないのです。

バージョンアップは先送りにすればするほど難易度が上がる

さて、バージョンアップは逃げられるものではないということを理解いただけたかと思いますが、これはどのくらいの頻度で行うべきでしょうか。バージョンアップは面倒だからLTSが切れるギリギリまで先送りにした方が良いのでしょうか？

バージョンアップはなぜ面倒なのか

その答えを考えるまえに、なぜバージョンアップが面倒なのかを考えてみましょう。

「UIの変更になれるのが大変？」確かにそれは一つの側面としてありますが、人間は慣れる生き物なので、UIの変更程度で業務が止まることはありません。多少の不満は出ますが、１か月もたてば大きな問題ではなくなります。

実際に困るのは「機能が変わってこれまでの業務が回らなくなった」「APIの仕様が変わって連携ツールやプラグインが壊れた」といった場合です。これらに対しては、代替機能を見つけて業務フローを変えたり、連携ツールを修正したりバージョンアップしたり、といった保守工数が発生します。

業務で使用しているソフトウェアの場合、単体で利用するということはまずありません。別のソフトウェアとデータ連携したり、業務自動化のためにAPIが利用されていたりします。
大規模なソフトウェアの場合、どの業務が壊れるかを事前に把握しきることは現実的ではありません。試しにバージョンアップしてみて、問題が発生したら業務が長期間止まらないように死ぬ気で直すか、できなければロールバックするという泥臭い方法しかありません。
この確率的な工数スパイクがバージョンアップが面倒である理由です。

バージョンアップ頻度が低いとバージョンアップは失敗する

さて、この保守工数はバージョンアップの頻度によってどう変わるでしょうか？ある業務がバージョンアップで壊れた場合、その次のバージョンで元の仕様に戻っている、なんて都合のいいことはありません。次のバージョンアップでも壊れたままです。それを踏まえて考えてみましょう。

• バージョンアップ頻度が低い場合: 保守工数の発生頻度は低くなりますが、一回に多くの業務が壊れ、工数スパイクは大きくなります。保守人員はそれほど確保されているわけではないので、対応しきれずバージョンアップが失敗する可能性が高くなります。
• バージョンアップ頻度が高い場合: 保守工数の発生頻度は高くなりますが、一回当たりの工数スパイクは小さくなります。壊れた業務を短期間で直すことができ、バージョンアップが失敗する可能性が低くなります。

すなわちバージョンアップ頻度が低いとバージョンアップが失敗する確率が高くなり、同じバージョンアップを何度も行う必要が出てきます。さらに厄介なのはもたもたしている間に次のバージョンがでて、また別のところが壊れるという負のループです。これが積み重なるとLTSが切れて誰も保守できない化石ソフトウェアになってしまいます。

LTSが切れたソフトウェアはダンジョン化する

さて、バージョンアップ頻度が低いとLTSが切れてしまうことがあります。一度こうなってしまうと悲惨な現実がやってきます。

• まず脆弱性対応が止まります。セキュリティリスクを抑えるためにサーバの外側に防壁を作る必要があり、メンテナンスのためにサーバにアクセスするのが大変になります。封印された状態です。
• 次に徐々に他の連携ソフトウェアがそのバージョンをサポートしなくなります。新規で連携ソフトウェアを増やすことはもちろんできませんし、逆に連携している他のソフトウェアのバージョンを上げられなくなります。ほかのソフトウェアのLTSが切れるともう泥沼状態です。
• じきに内製化している連携ツールの保守人員がいなくなります。なぜなら「バージョンアップしない＝保守業務があまり発生しない＝その業務要らないよね」なので別の部署に異動になったり、転職したりします。その結果、ソフトウェアがどこをつついたら何が起こるかわからない状態、すなわちダンジョン化します。
• 古いソフトウェアは使い勝手が悪く、データが増えて動作が重くなったりします。それに嫌気がさした数々の冒険者がそのダンジョンを攻略しようしますが、9割方は闇にのまれます。貴重な工数とやる気が失われていきます。

最終的には偉い人の鶴の一声でダンジョン攻略クエスト（＝リプレイスプロジェクト）が始まるかもしれません。業務フローの洗い出し、次のソフトウェアの選定、連携ツールの再実装などなど、大量の工数が投入されて、あまたのトラブルを乗り越えてリプレイスされます。その工数は定期的にバージョンアップさえしていれば不要だったはずです。

ダンジョンを生み出さないために

さて、バージョンアップを先送りすることの怖さを理解していただけたかと思うので、どうしたらこの悲惨な未来を避けることができるのかを考えていきましょう。

最低１年に一回はバージョンアップする

まずは定期的にバージョンアップすることです。理想的には３か月に一回程度、遅くても一年に一回程度はバージョンアップするようにしましょう。バージョンアップ頻度を高くすることで一回に壊れる箇所が少なくなり、バージョンアップが成功しやすくなります。定期的にバージョンアップすることでバージョンアップ手順が定型化され、各部署も慣れてきて、どこを確認したらいいかがわかってきます。
慣れてきたら検証環境に連携ツールもデプロイして動作確認する運用フローを整備したりするのもよいでしょう。

バージョンアップに必要な工数を計測し、振り返る

バージョンアップを定型業務にできたなら、次にその業務にかかった工数を計測してみましょう。バージョンアップにどの程度の工数がかかるのかが予測できれば、各部署に事前に工数の確保を依頼できます。案外、事前に工数が予測できていれば現場はすんなり受け入れてくれたりします。

継続的にバージョンアップできていれば、バージョンアップ自体の作業はほとんど問題になりません。工数がかかるのは連携ツールの保守です。バージョンアップを無限に先延ばしにすることはできないので、これらに工数がかかるのはバージョンアップの頻度が高いからではなく、ソフトウェア自体の品質の問題か、あるいは連携ツールのメンテナンス性や安定性の問題です。

あまりに工数がかかりすぎる場合は、連携システムや業務自動化の見直しをしましょう。RPAベースの自動化ツールをAPIベースに置き換えたり、過剰な業務自動化をやめたり、そもそもソフトウェア自体の安定性が低かったり互換性を軽視しているようならSaaS移行やリプレイスを検討するのも一つの手かもしれません。

まとめ

• ソフトウェアをバージョンアップする理由は「新規機能がリリースされたから」ではない。
• ソフトウェアには2-5年の有効期限があり、それを過ぎたソフトウェアは徐々にダンジョン化する
• バージョンアップ頻度が低いとバージョンアップ難易度があがり、失敗する可能性が高まる
• １年に一回以上のバージョンアップを行い、バージョンアップを定型化し、継続的に業務を見直すことで安定した価値提供ができる

最後に

新規ソフトウェアの導入やリプレイスに比べると、バージョンアップは地味な仕事に見られがちです。
しかしバージョンアップを確実におこなうことは、ソフトウェアのダンジョン化や大規模なリプレイスを回避するために大切な仕事なのです。バージョンアップを担当する方はその仕事に誇りを持ってください。
ソフトウェアが継続して動作しているのは当たり前ではありません。運用担当者が様々な保守作業をしているからです。現場の方はたとえほしい新規機能がリリースされていなくても、業務が当たり前に継続していることの価値を理解していただくようお願いいたします。