システムの更新に伴うプラットフォームバージョンアップ - インフラジスティックス・ジャパン株式会社Blog

2月: バージョンアップ

開発ローカル情報とは、インフラジスティックスが日々お客様と対話する中でよく耳にする、開発現場の小さな領域に限定したトピックを掘り下げて共有する特集です。

今月は、社内システムのバージョンアッププロジェクトをされている企業様数件とお話をしました。「バージョンアップ」は、年間を通してよく相談いただくトピックですが、依存するプログラムが多くて組織内の調整コストも嵩むので「そのうち対応しないといけないがまだ具体的には...」と、実際には腰が重い企業様も多いようです。

今月お話をした企業様は、プラットフォームはそれぞれ異なるものの、バージョンアップの前後で対象となるバージョンリリース時期には「約10年」の開きがありました。「基幹システムの寿命は10-14年」とはよく言われるものですが、弊社で相談をお受けするバージョンアップサイクルも同じ傾向の印象です。

プラットフォームのバージョンアップにおいて何にハードルを感じ、どのようなステップで進めることが多いのでしょうか。

システムバージョンアップの体制概要

着手のきっかけは現行システムの老朽化対応や、予算取りが今年叶ったから、プラットフォームのサポート終了に対応するため、など様々ではありましたが、開発者人数は3人程度であるケースが多く見られました。

バージョンアップにおいて課題となるポイント

多くの企業様で、As Is(現状)とTo Be(バージョンアップ後の状態)はおおむね決まっていました。例えば、最新ブラウザに対応してIEからは脱却する・プラットフォームは.NET 4.8から .NET8までバージョンを上げたい、などのマトリクスまで作成されている状態です。

しかし、バージョンアップ方針は固めたものの「さて、ここからどう進めるべきか...」と移行の具体的なステップを決めかねている企業様が多い印象です。

10年規模のバージョンアップは難易度が高い

10年前のプラットフォームバージョンから最新のものへ移行する場合、多くの障壁が伴います。レガシーなAPIに対応するために膨大なコード修正が必要であったり、何らかの機能が廃止されていることに伴い大幅な構造変更も求められます。

今はまだ動いているし社内の注目度も低いから・・と、「重要度は高いが緊急度が低い」プロジェクトとして長年に置き去りにされた結果、いざ本腰を入れて対応をする際には難易度がどんと高くなっている。IT部門を大いに悩ませるのが「バージョンアップ対応」なのです。

バージョンアップには、段階的移行が現実的

インフラジスティックスが今月お話しした企業様も、多くは10年前にリリースされたバージョンから最新バージョンへの移行を計画されていましたが、結果的には一足飛びに最新バージョンへの移行をせず、段階的移行を選択される傾向にありました。

10年の開きがあるバージョンへ直接ジャンプして対応するのは、移行中に既存のビジネスロジックが動かなくなる可能性や、パフォーマンスのボトルネックが発生する可能性など、予期せぬトラブルが想定されます。

安全に移行を完了するため、優先順位の低い機能から最新バージョンへ移行して社内に経験を溜めながら移行する、重要な機能はより変更範囲の少ない非最新バージョンへ移行して段階的に最新バージョンへの移行を目指す、など、現実的なステップに分解することがおすすめです。

バージョンアップの適切なステップは組織によって異なる

バージョンアップの段階的移行戦略に「このステップで進めれば必ず成功する！」という銀の弾丸は中々ありません。企業様のシステム状況やチームの移行経験値、プラットフォームに関する専門的知見などの諸条件を考慮し、組織に合うステップを設計する必要があります。インフラジスティックスは、企業様の状況をヒアリングし、伴走しながら最適な移行ステップを共に検討します。

例えば、とあるプラットフォームの最新バージョン移行を検討した結果、アプリケーションに使用されているコンポーネントがすでに廃止しており、再開発が必要になるケースがよくあります。再開発を防ぐには別のプラットフォームへ移行した方が早いのですが、その組織では別のプラットフォームを使った経験がない、というお悩みも頻出です。

そのような場合は、UIの再開発コストと新プラットフォームへの適応コストを比較した上で、システムが最も持続可能な方法を企業様と一緒に探っています。

企業様によってベストな方法は数年前のバージョンへ落として移行する場合であったり、プラットフォーム(フレームワーク)を別に切り替える場合もあります。