脆弱性になってしまう、あまり使わないシステムを“内製”でクラウド移行するための現実解：オンプレミスのままでは無駄なリソースでコストが増えるだけ

基幹システムと比べて、使用頻度や利用度が低いシステムのクラウド移行には予算が付きにくい。それでも、できる限り“内製”で対処することによって低予算での移行は可能だ。ただし、自社だけのクラウド移行で心配になるのが、実装作業だろう。外注せずにクラウドに移行したいシステムについては、どうすればよいのだろうか。

[PR／＠IT]

クラウド移行が進まない非中核システムをどうするか

日本マイクロソフト
コーポレートソリューション事業本部
インテリジェントクラウド営業統括本部
統括本部長 小杉 靖氏

　新規のサービスやシステムをクラウド上に作るのはもちろんのこと、現在稼働中のシステムについてもオンプレミスからクラウドに移行するのは今や当たり前となった。

　企業がクラウド移行に踏み切る主なきっかけとして挙げられるのは、「コストの最適化」「アプリケーションの革新」「ITキャパシティーの制約」「ソフトウェアのサービス終了」など。さらに、日本マイクロソフトの小杉 靖氏（コーポレートソリューション事業本部 インテリジェントクラウド営業統括本部 統括本部長）は「IT人材不足」と「システムボリュームの増加」の2点を加える。

　これら2点の解決にクラウド移行が効果的なのは、移行によって、少ない人数でより多くのシステムを運用管理できるからだ。「クラウドには自動化された便利なサービスがたくさんありますし、システムそのものを可視化するためのアドバイザーも用意されています」と小杉氏は説明する。オンプレミスのサーバ管理ツールやIT資産管理ツールでは見えなかったセキュリティスコア、コストスコア、可用性スコアなども、例えば「Microsoft Azure」（以下、Azure）に備わっているアドバイザーを利用すれば容易に知ることができる。CPUやメモリの使用率、ユーザーのアクセス頻度などについても同様だ。

　ただ、企業経営者の立場からすると、全てのシステムを同じようにクラウドに移行できるわけではない。どうしても“後回し”になってしまう中小規模のシステムが存在する。

　ERP（Enterprise Resources Planning）のような業務パッケージソフトウェアの多くはクラウドにも対応しており、ベンダーやシステムインテグレーター（SIer）に依頼すれば、クラウド側のシステム構築とデータ移行を企業に代わって実行してくれる。それには相当な費用がかかるが、基幹システムのような中核システムであれば出費を正当化することはできるだろう。

　では、月に1回しか実行しないシステムや、実務で本当に使われているのかどうかが分からないレポート作成システムなどはどうだろうか。そのような“非中核システム”をクラウドに移行しても投入した費用に見合う効果が得られるはずはない、と経営陣は考えるに違いない。

　しかし、経済的合理性がないからといって、非中核システムをいつまでも“塩漬け”の状態にしておくわけにもいかない。アプリケーションやOSのサポート終了（EoS）がいつか必ず訪れ、脆弱（ぜいじゃく）性となり得るからだ。そして、セキュリティ対策のためのシステム再構築やクラウド移行は遅かれ早かれ発生する。

内製なら低予算でクラウドに移行できる

　では、どのようにすれば、非中核システムを限られた予算でクラウドに移行できるのか。

　そのための有力な方法となるのが、企業が自らの力でクラウドに移行する“内製”だ。

　日本では、システムを構築、更改する際にベンダーやSIerから見積もりを取って選定、発注するのが一般的。しかし、ITにある程度詳しい人が社内にいれば、自力で構築、更改することも十分に可能だ。小杉氏は「海外では、クラウド移行作業などは社内のエンジニアがやってしまいます。日本にそういう文化はないのかもしれませんが、やればできると我々は考えています」と話す。

　内製によるクラウド移行については、それを推進するプラスの材料と、企業がためらいを感じるマイナスの材料がある。

　プラス材料としては、クラウドがそもそもDIY指向で作られており、移行作業も1〜2日で完了することがあることだ。「Azureでは、移行ツールについて、ハードルを低くして、誰もが簡単に使えることを目指してきました。Web画面に簡単な設定をするだけで、すぐに実行できる仕組みになっています」（小杉氏）

　一方、マイナス材料としては、「どの工程で何をすればよいか」が未経験者には分かりにくいことだ。クラウド移行に限ったことではないが、システム開発の大まかな工程は「計画」→「検証」→「実装」の3ステップから成る。それぞれの工程でどのような作業が必要で、何を確認できたら次の工程に進むことができるのか。その知見と経験を有していることこそがプロフェッショナルの証しであり、“ながら情シス”のような人がDIYでやろうとすると高い壁として立ちはだかることになる。

クラウド移行を支援するプログラムの在り方とは

　このような背景から、日本マイクロソフトは自力でクラウド移行に挑戦する企業に対する技術支援に力を入れ始めた。それが下記の支援となる。

• ソリューションアセスメント（現状把握）
• Azureハンズオンワークショップ（学習）
• Fast Track for Azure（設計指針）
• CSU Migration Factory（移行作業）
• MICUG（情報共有、企業間連携）

　また、やはり自力での移行が難しくベンダーやSIerと連携しての移行を検討している顧客を支援するための、「Azure Migrate and Modernize Program」（移行およびモダナイゼーションプログラム）や「Azure Innovate」（データ分析とAI導入支援プログラム）も用意している。2つのプログラムの違いは、“Azure上に何を構築するか”にある。Azure Migrate and Modernize Programはクラウド移行の支援であり、オンプレミスで稼働している既存のアプリケーション、データ、インフラをAzureに載せ替えるためのもの。一方、Azure Innovateは、新規サービスをクラウドネイティブで開発、構築するためのものだ。

Microsoft Azure支援プログラム（提供：日本マイクロソフト）《クリックで拡大》

　この中で自力でのクラウド移行に挑戦する企業向けに支援範囲を広げリリースされたのが、2022年7月から「Microsoft SQL Server」向けに始まった「CSU Migration Factory」（以下、CMF）だ。CMFのポイントは、評価／移行／実装工程における実作業について、日本マイクロソフトがツールを提供し、エンジニアが支援してくれることにある。企業の情報システム部門のエンジニアがAzureの操作に慣れていなくても、クラウド移行を短期に済ませられるという利点がある。

　CMFの対象となる移行シナリオは、その後も着実に増え続けている。2023年10月の段階で対象になっているのは、下表の7種類。その多くはMicrosoftが開発したツールによって移行処理が自動的に行われるが、場合によっては、手動バックアップ／リストアなどの方法が採られる場合もある。Windows Serverを移行する場合は移行元サーバのバージョンの“古さ”によって、「同一バージョンで移行」「バージョンアップしてから移行」「移行してからバージョンアップ」を選択可能だ。

	対象ソフトウェア	オンプレミス	Azure
	Windows	Window Server	Azure VM
			Azure Arc 有効化 Windows Server
			拡張セキュリティ更新プログラム（ESU）by Azure Arc
	Linux	Linux Server	Azure VM
			Azure Arc 有効化 Linux Server
	SQL Server	SQL Server	SQL Server on VM
			Azure SQL Database
			Azure SQL Managed Instance
			Azure Arc 有効化 SQL Server
	OSS Database	MySQL	Azure Database for MySQL Flexible Server
		PostgreSQL	Azure SQL Database for PostgreSQL Flexible Server
	Cassandra	Cassandra	Cassandra Managed Instance
	Lakehouse	data lake	Azure Databricks
	Azure Virtual Desktop	Remote Desktop Services	Azure Virtual Desktop
CMFの対象となる移行シナリオ（2023年10月現在）

　なお、CMFでは、日本マイクロソフトは移行／実装工程を支援する。企業側であらかじめ済ませておかなければならないのは、移行対象となるスコープ（どのIT資源をAzureに移行するか）の決定とプロジェクトマネジャーの人選。CMFの完了後に、アプリケーションテスト（システムテストや運用テスト）を行い、カットオーバー（本番移行）するかどうかを決めるのも企業側の仕事だ。

　この他、CMFを依頼する前に企業が満たしておかなければならない前提条件も定められている。移行対象スコープの決定とプロジェクトマネジャーの人選については、既に説明した通り。さらに、移行先Azureランディングゾーンを用意してあるか、または用意する計画があることも条件に含まれる。

CMFの利用前提条件（提供：日本マイクロソフト）《クリックで拡大》

　また、日本マイクロソフトのエンジニアに移行作業を支援してもらうには、「Unifiedサポート」か「CMFプログラム契約」を結んでおく必要もある。ただ、移行作業を実施するのではなく、技術的なアドバイスを受ける形で支援してもらうのであれば契約は不要だ。内製での作業に加えて、パートナーに移行を依頼する場合でもマイクロソフトの専門家からアドバイスを得られる。「CMFの実績の中では『Microsoft Teams』を利用したリモートでの移行支援が多くを占めています」と小杉氏は明かす。

200台程度のサーバなら30営業日での移行も可能

　このように、CMFは移行先Azure環境の準備が整ったところからアプリケーションテストの直前までをカバーする。では、移行対象を決めるところからはどの程度の期間がかかるのだろうか。

　日本マイクロソフトが見込み客への説明に使っている資料によると、200台程度のサーバをAzureに移行するモデルケースでは30営業日（約1.5カ月）かかるとされている。

200台程度のサーバ移行におけるCMFのモデルケース（提供：日本マイクロソフト）《クリックで拡大》

　前半の15営業日は、移行計画の検討から承認まで。プロジェクトマネジャーと移行対象スコープは企業側が事前に決めておき、その後に日本マイクロソフトのエンジニアが参画するというシナリオだ。移行前提条件の検証、実施と移行計画の準備は移行プロジェクトとしての共同作業になる。

　後半の15営業日は、確定した計画を基に移行作業を実施し、アプリケーションテストをして不具合を修正して、本稼働を決断するところまでになる。アプリケーションテストと最終承認するのは企業側だ。

　ここまではあくまでもモデルケースについてだが、一方で実際のクラウド移行では、オンプレミスにある既存アプリケーションの構築や運用保守に携わったベンダーやSIerがプロジェクトに参画するケースも往々にしてある。「その場合、ベンダーやSIerの方々には、システム設計やテスト、ドキュメント作成などを担当していただくことになります」と小杉氏。そのベンダーやSIerにソリューションパートナー認定（旧、コンピテンシー）は特に求めないという。

　このようにCMFを例にできる限りベンダーやSIerに頼らない内製によるクラウド移行と、その支援プログラムの在り方を見てきたが、あらためてシステムをクラウドに移行することの主な利点は、情報システム部門にとってはシステム運用管理が楽になり、エンドユーザーにとっては設定変更などがセルフサービスでできるようになることだ。基幹システムやERPパッケージだけでなく、非中核システムもクラウドに移行することによって、効果もそれだけ大きくなる。

　「我々は、CMFの対象となる移行シナリオを迅速に拡充しており、例えば、Oracle DatabaseをAzure上で稼働させる『Oracle Database@Azure』などもやがてCMF対応になることでしょう。また、Azureへの移行にCMFを使われるお客さまも増えてきました。CMFの最新状況については、ぜひ弊社の担当営業にお問い合わせください」（小杉氏）