ソフトウェアのサポート終了へいつ予算を付けるか。期限から移行を逆算する

ソフトウェアのサポート終了に備える予算は、終了年度より前に必要です。非エンジニアの経営者が押さえるべき結論は、利用中のランタイムとデータベース（DB）を別々に台帳へ載せ、先に対応が必要になる期限から、調査、互換性確認、移行方法の選定、検証、本番切替を逆算することです。その最初の工程を始める年度に、まず予算枠を置きます。

ただし、サポート終了日を並べただけでは予算判断に足りません。アプリケーションを動かすランタイムと、事業データを保持するDBでは、公式が示すライフサイクルも更新作業の性質も違うからです。期限までの長さに加え、移行可否と予算を決めるための未確認事項まで経営の判断条件にします。

ソフトウェアのサポート終了予算は、製品ごとの行に分ける

「基盤ソフトウェア更新」という一つの案件名に集約すると、期限の違いが見えなくなります。たとえば、WebサービスがNode.jsとPostgreSQLを使っているなら、少なくともランタイムとDBを別の行にします。同じベンダーへ作業を頼む予定でも、台帳まで一行にまとめてはいけません。

2026年9月21日時点で、Node.jsの公式リリース情報は、本番アプリケーションではActive LTSまたはMaintenance LTSのリリースだけを利用するよう示しています。一方、PostgreSQLの公式バージョニング方針では、各メジャーバージョンを初回リリース後5年間サポートし、その後に最終マイナー版を公開してサポートを終了する方針です。

両者を「あと何年」という一つの物差しへ無理に変換すると、判断を誤ります。Node.jsは利用中のリリース系列がどの状態区分にあるかを公式ページで確認し、PostgreSQLは利用中のメジャーバージョンについて公式のサポート終了日を確認します。特定バージョンの期限は変わり得る情報として扱い、予算を見直すたびに公式ページで確かめます。

僕なら、最初の台帳には導入版、公式の状態区分またはサポート終了日、確認日、公式URLを記録します。台帳は両公式が定めた共通書式や義務ではありません。上記のライフサイクル方針を、経営判断へつなぐための実務上の提案です。確認日を残すのは、後の会議で「いつ見た情報か」を区別するためです。

期限の違うランタイムとDBを、更新判断表で比べる

台帳に期限を写したら、予算化の条件を足します。次の表は、Node.jsとPostgreSQLを利用する構成を想定した非数値の記入例です。一次情報が示す違いを基に、僕が経営会議向けに組み立てた整理方法です。製品の公式分類とは位置づけが異なります。実際の導入版や期限は、自社の構成と公式ページを照合して記入してください。

二つの行を埋めると、期限だけで予算年度を決めるのではなく、期限までに何を確定させる必要があるかを判断できます。公式情報の欄が空なら、対象の特定と公式確認から始めます。公式の状態や期限は分かっていても互換性や移行方法が空なら、調査・検証を承認します。両方が埋まり、本番切替の条件まで合意できている場合に、実施予算を承認するという順序です。

Node.jsについては、2026年9月21日時点の公式EOL説明により、リリース系列がEOLに達するとセキュリティパッチを含む更新を受け取らなくなることを確認できます。したがって、表の期限欄は単なる予定表ではありません。「終了後も同じ系列を使い続ける前提でよいか」を経営が判断するための入口です。

PostgreSQLでは、更新の種類によって確認事項が変わります。2026年9月21日時点の公式バージョニング方針によれば、メジャーバージョン更新ではデータディレクトリの後方互換性が維持されず、データベースのダンプと再ロード、またはpg_upgradeが必要です。一方、マイナー版更新はダンプとリストアを必要とせず、サーバーの停止、更新済みバイナリの導入、再起動が基本です。ただし、追加手順の可能性があるため、リリースノートの確認が必要とされています。

「DB更新」という同じ言葉でも、メジャー更新ではデータ移行方法の選定が見積もりの前提に入り、マイナー更新ではリリースノートの確認が前提に入ります。表へ「更新が必要」とだけ書くと、この差が消えます。期限に加えて、EOL後に更新が止まるか、データ移行が必要か、追加手順を確認する必要があるかを分けると、何の調査へ予算を付けるのかが見えるようになります。この分け方は公式情報を予算会議で扱える形へ直した実務上の提案であり、公式所定の分類や義務ではありません。

予算年度は、先に来る制約から工程を逆算して決める

判断表が埋まったら、ランタイムとDBのうち、先に対応が必要になる側を起点にします。「両方を同時に更新するか」は、この段階ではまだ決めません。同時更新にすると検証範囲も一緒に変わるため、まず別々に必要条件を出し、その後にまとめるかを判断するほうが、経営者にも論点が見えます。

逆算する社内工程は、次の一つの流れで整理できます。

1. 対象調査：本番、検証、開発の各環境で実際に使う版と依存関係を特定する
2. 互換性確認：移行先の候補に対し、アプリケーションと周辺ソフトウェアの対応可否を確認する
3. 移行方法の選定：とくにDBのメジャー更新では、公式が示す方法のどちらを採るか決める
4. 検証：選んだ方法を本番以外で確かめ、リリースノートに追加手順がないか確認する
5. 本番切替：実施条件と担当を確定し、期限前に切り替える

この順番から、予算を二つの性質に分けて考えられます。ひとつは、対象調査と互換性確認を進め、移行案と見積もりを作れる状態にするための予算です。もうひとつは、選んだ方法を検証し、本番へ反映するための予算です。金額や工数は構成を調べるまで決められませんが、「調査を始める承認」と「本番移行を実施する承認」は先に分けられます。

たとえば、ランタイムの公式状態を先に見直す必要があり、DBの公式サポート終了日はその後だとします。この場合は、ランタイムの互換性確認がDB接続部分へ及ぶかを先に調べます。影響が分かれていれば別々に進められます。切り離せないなら、DB移行も含む検証範囲を作ってから、同時に実施する案と段階的に実施する案を比べます。

反対に、DBの対応が先で、DB対応がメジャー更新なら、データ移行方法を選べないまま実施予算だけを確定しないことです。まず調査と検証の予算枠を置き、ダンプと再ロードまたはpg_upgradeのどちらを採用できるかを技術担当に確認させます。公式情報は方法の存在を示しますが、自社にどちらが適するかまでは決めてくれません。ここが、仕様確認と経営判断の境目です。

予算会議へ持ち込む時点では、対象、公式上の期限または状態、未確認事項、次に承認する工程、決定担当が一枚で読めれば判断できます。「古いので更新したい」という要望だけの状態から、承認対象が特定された状態へ変えるわけです。技術用語を経営が決められる論点へ変える考え方は、経営と技術をつなぐ人がいないと、会議は決まらないでも整理しています。

「いつ付けるか」は、見積額より未確認事項で決める

ソフトウェアのサポート終了へ予算を付ける時期は、先に来る制約から逆算した最初の工程を始める年度です。ランタイムとDBを別の行に置き、公式の状態や期限を確認し、更新停止、データ移行、リリースノート確認という条件を表へ足します。そのうえで、対象調査から本番切替までを戻ってたどれば、今承認すべきものが調査なのか、検証なのか、実施なのかを区別できます。

見積額がまだ出ていないことは、予算の議題にできない理由にはなりません。むしろ、移行方法や互換性が未確認なのに実施額だけを求めると、前提の違う見積もりが並びます。最初の決裁は、未確認事項を減らして実施案を選べるところまで進めるための予算枠です。調査結果が出たら、採用する移行案、検証範囲、本番切替の条件を記録し、実施判断へ進みます。判断の理由を後から追える形にすることは、CTO代行を入れると、組織の意思決定はどう変わるのかで扱っている意思決定の分担にもつながります。

最初に二行の更新判断表を作り、精密な費用試算は必要条件を確かめた後に進めます。導入版が分からなければ対象調査へ、状態や期限が分からなければ公式確認へ、移行方法が分からなければ技術検証へ進みます。この条件分岐が読めれば、非エンジニアの経営者でも、期限を待たずに次の予算判断を始められます。