多くの移行プロジェクトは、ある決定から始まります。Oracle Java SEからOpenJDKへの移行、サポート終了（EOL）を迎えたLinuxディストリビューションの置き換え、あるいはサーバーのプライベートクラウドへの集約です。計画は、机上ではたいてい単純に見えます。ところが実際に進めると、プロジェクトチームは誰も把握していなかったJavaランタイム、管理者のいないサーバー、古いバージョンにひっそりと依存しているアプリケーションに直面します。その結果、スケジュールは遅れ、予算は膨らんでいきます。

これを避けるには、まず現状調査（ディスカバリー）から始めることです。つまり、実際に何がインストールされているかを、事実に基づいて漏れなく棚卸しします。本記事では、収集すべき情報、WindowsとLinuxでの収集方法、想定しておくべき「想定外」、そして結果を移行計画に落とし込む方法を解説します。

なぜ移行より先に現状調査なのか

移行の質は、その前提となる情報の質で決まります。インベントリがなければ、記憶や古いスプレッドシート、ライセンス記録をもとに範囲を見積もることになりますが、いずれも現在実際に稼働しているものを反映していません。

しっかりしたインベントリからは、次の3つが得られます。

• 範囲：影響を受けるマシン、ランタイム、アプリケーションの数。これにより、工数とコストを現実的に見積もれます。
• リスク：どのシステムがサポート対象外やパッチ未適用のバージョンで稼働しているか、どれが業務上重要か。
• 責任の所在：各システムの責任者。テストと承認の責任者が明確になります。

ライセンスに関する協議でも役立ちます。ベンダーからインストール数を尋ねられても、最新のインベントリがあれば、推測ではなく事実で回答できます。

収集する情報：バージョン、ベンダー、パス、担当者

Javaのインストールごとに、少なくとも次の情報を収集します。

• ホスト：マシン名、IPアドレス、およびサーバー、仮想マシン、デスクトップPCのいずれであるか。
• バージョン：「Java 8」や「Java 17」だけでなく、1.8.0_202や17.0.10のような完全なバージョン文字列。
• ベンダー：Oracleや各種OpenJDKディストリビューションなど、そのランタイムのビルド元。これはバージョンだけでは判断できません。
• 種類とパス：完全なJDKか、JREのみか。あわせてインストール先のディレクトリ。
• 用途：特定できれば、そのランタイムを使用しているアプリケーションやサービス。
• 担当者：そのマシンまたはアプリケーションに責任を持つチームや担当者。

Linuxサーバーについては、ディストリビューションとそのバージョン、カーネルバージョン、主なインストール済みパッケージ、稼働中のサービスも収集します。これにより、Javaの移行だけでなくLinuxの移行の対象にもなるサーバーがどれかがわかります。

Windows、Linux、デスクトップPC：環境ごとのアプローチ

環境ごとに、少しずつ異なる方法が必要です。以下のコマンドは出発点です。実際には、これらをスクリプトにまとめ、既存の管理ツールを使って全マシンで実行するのが一般的です。

Windowsサーバー

インストールされたJavaランタイムは、WindowsのレジストリキーHKEY_LOCAL_MACHINE\SOFTWARE\JavaSoftに登録されることが多いものの、すべてがそうとは限りません。ファイルシステムを検索するほうが確実です。

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

アプリケーションサーバーは別のデータドライブにインストールされていることが多いため、C:だけでなくすべてのドライブを確認してください。

Linuxサーバー

Linuxでは、パッケージマネージャーとファイル検索を組み合わせます。多くのJavaランタイムは、パッケージとしてインストールされるのではなく、アーカイブから展開されているためです。

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

DebianやUbuntuでは、rpmの代わりにdpkg -l | grep -i -E 'jdk|jre'を使用します。見つかったjavaバイナリをそれぞれ-version付きで実行すると、バージョンと、通常はベンダーも表示されます。また、ほとんどのJDKディレクトリには、実装元（implementor）を記載したreleaseファイルがあります。

デスクトップPC

デスクトップは、インベントリの中で最も見落とされやすい部分です。開発者は自分でJDKをインストールしますし、業務アプリケーションがJavaランタイムを利用者の知らないうちにインストールすることもあります。デスクトップは台数が多いため、可能な限りエンドポイント管理ツールのソフトウェアインベントリを活用し、その情報が不足している場合にのみ軽量なスクリプトを実行します。

よくある「想定外」（同梱JRE、忘れられたサーバー）

ほぼすべての現状調査プロジェクトで、誰も予想していなかったものが見つかります。よくあるのは次のようなものです。

• 同梱ランタイム：多くの商用アプリケーションは、インストールディレクトリ内に専用のJavaランタイムを同梱しています。これはレジストリにも、どのパッケージ一覧にも現れないことがあります。
• 1台に複数のバージョン：新しいランタイムをインストールしても古いものが削除されることはまれなため、1台のサーバーに3つも4つも存在することがあります。
• 忘れられたサーバー：廃止されないまま残っているテストマシン、古いバッチサーバー、仮想マシンなど。古く、パッチ未適用のバージョンで稼働していることがよくあります。
• 担当者不明：誰も管理者として名乗り出ないマシン。たとえ結論が停止であっても、移行開始前に扱いを決めておく必要があります。

インベントリから移行計画へ

データを収集したら、1か所に集約し、システムの担当者と一緒に確認します。そのうえで、インストールを次のカテゴリーに分類します。

グループ	対象	対応
削除	現在は使われていないランタイム	リスクとライセンス上の影響を抑えるため、今すぐアンインストールする
置き換え	自社で管理しているランタイム	テストを行ったうえで、サポートされているOpenJDKビルドへ移行する
調整	サードパーティ製アプリケーションに同梱されたランタイム	まずアプリケーションベンダーのサポート見解を確認する
調査	担当者や目的がはっきりしないもの	担当者を特定するか、停止を判断する

これらのグループをもとに、現実的なスケジュールを組めます。まずリスクの低いシステムから始めて手順を検証し、その後、テスト済みのロールバック手順を用意したうえで業務上重要なシステムに進みます。

LOGIQによる支援

LOGIQは、JavaとLinux環境の現状調査および移行プロジェクトを実施しています。使用するスクリプトと手順は、Windowsサーバー、Linuxサーバー、デスクトップPCを対象とした実際のお客様プロジェクトで磨き上げてきたものです。インベントリの作成や、それを移行計画に落とし込むための支援が必要な場合は、LOGIQにお問い合わせください。