【基幹システムのクラウド化】移行方法や、オンプレミスと比較したメリットまで解説

基幹システム問題点

企業としての業務を遂行するのに欠かせないはずの基幹システムは、導入後から更新されず古い状態のままであることが多く、そのため次に挙げる3つの問題点を抱えています。

システムの老朽化

現存する多くの企業が利用している基幹システムは、「レガシーシステム」という、古い技術で構成された基幹システムに依存しています。これは経済産業省が平成30年に公表した「DXレポート」内で「2025年の崖」と表現している問題であり、国内の7割もの企業が少なからず老朽化したシステムが原因で業務上の支障をきたしているようです。

古いままのシステムが刷新されていかない背景には、現存のシステムに多少の影響が出ることが関係しています。

新しいシステムへ移行する際のデータ連携がうまくいかなかったり、一度古いシステムを止めてしまうと、現存の生産システムや配送システム、在庫管理システム等にも大きな影響が出ることで、多くの企業が二の足を踏んでいる状況が続いています。
（参考：経済産業省「DXレポート　～ITシステム「2025年の崖」の克服とDXの本格的な展開～」）

システムの複雑化

既存の基幹システムには刷新こそされていないものの、さまざまな機能が後から追加されていくことで、当初のシステムから大きく複雑化してしまい、簡単に大元のシステムが刷新できなくなっています。

これはシステムの肥大化も引き起こしています。新しい機能を追加したは良いものの、それによりもはや必要がなくなった古いプログラムを「削除したら問題が発生するかもしれない」という理由で放置されたまま残り、見直されないまま時が過ぎてしまうことが影響しています。

システムのブラックボックス化

基幹システムは人の入れ替わりによるブラックボックス化も深刻です。システム管理を任されていた古い技術者が退職する際に、新しい管理者への引き継ぎが正しく行われないと、「見えない部分」が放置されることとなり、問題点が洗い出されないまま放置されてしまいます。

企業が大いに依存している基幹システムにも関わらず「誰もその中身を知らない箱」となってしまい、さらにその箱の中で老朽化と複雑化も同時進行していくため、もはや社内の誰も正しくマネジメントできない状態に陥ってしまいます。

このような状態では、基幹システムを刷新するどころではありません。

基幹システムの刷新を検討すべきケース

古い基幹システムをそのまま使用し続ける問題点について把握できたところで、次は早急に基幹システムの刷新を検討するべきケースについて解説していきます。

　システムの保守性の低下

基幹システムのブラックボックス化が進むと、保守性も低下します。保守性とはシステムを安定運用させられる難易度の低さのことであり、トラブルが発生したときも迅速に対応できなくなります。

例えば基幹システムに障害が起こった際に、担当者が「どこから手をつければ良いのか分からない」ような状態は、すでに保守性が危険な領域にまで低下しています。原因究明から復旧までの時間が大幅に長くなり業務上にも大きな悪影響を及ぼしかねないため、早急に基幹システムの刷新に取り組むべきです。

　事業拡大に対応出来ていない

事業拡大に伴って従来の基幹システムに新しい機能を追加しようとする場合、すでに発生している基幹システムの複雑化をさらに悪化させてしまいます。結果的に基幹システムを正しく運用できなくなり、結局はいくつかの業務を手作業で行う必要が発生するなど、業務効率も悪化します。

基幹システムを刷新するには当然ながら多くのコストが発生しますが、継ぎ接ぎだらけの基幹システムを使用し続けたことで運用コストが余計に発生することを考えれば、基本的には事業拡大と同時に基幹システムの刷新も行うべきです。

　外部システムと連携する必要がある

基幹システムが老朽化していると、システムを動かしているOSのバージョンが古いために外部システムとの互換性がなくなる可能性があります。

実際、基幹システムのOSが古くなっても、OSと連携するミドルウェアが稼働していれば業務上何ら問題ないように見えてしまうことがあります。しかし、いざ外部システムと連携させようとしても連携できず、だからといって従来のミドルウェア上で動作していたアプリケーションを、OSを更新するために急に止めるわけにもいきません。

このような問題を避けるために、外部システムと連携させる必要が生じたなら、導入から数年経過して保守期限ギリギリのOSおよびミドルウェアで対応させようとするのではなく、思い切って基幹システムの刷新を検討すべきです。

オンプレミスと比較したクラウドのメリット

まずは、クラウドとオンプレミスについてどのような差があるのか、下記の4項目で比較し、クラウド移行のメリットについて考えます。

コスト

クラウドの大部分のサービスは、従量課金制であり、使用した分だけ料金を支払うことができます。オンプレミスの場合は、データセンターの区画契約から、サーバーの購入を行う必要があるため、コスト効率の観点ではクラウドのほうが優れています。

ただし、クラウドは非常に高価なサービスコストもあるため、場合によってはオンプレミスのほうが安価になることもあります。

調達速度（デリバリー）

オンプレミス環境では、システムを稼働させる場合自社内のサーバーをゼロから設計・開発していく必要があります。しかし、クラウドのサービスはIaaSやPaaSなど、数クリックで利用開始できるものが大半であり、調達速度はオンプレミスと比較して圧倒的に優れています。

クラウドサービスは、既に用意されている機能を利用するためオンプレミスと比較しても検討から運用開始までの期間を短縮することが可能です。構築に時間が掛からないため、重要度の高い他の業務に注力することができ、結果的に企業の成長速度を上げることが可能です。

品質（クオリティ）

クラウドの品質面の特徴として、マネージドサービスの利用が挙げられます。マネージドサービスとは、サーバーを管理するために必要な回線やハードウェア、OSの設定などの作業をAWSやGCPなどのクラウド業者が行い、利用者に提供しているサービスのことです。

マネージドサービスでは、サーバなどが正常に動いているか、といった状態の監視や、パッチ・ファームウェアの適用といった運用をクラウド業者が高いレベルで日々行っています。

そのため、大抵の場合はオンプレミスで同様のサービスを構築するよりも品質が高くなっています。また、オンプレミスと比較して複数のデータセンターを容易に利用できるという点で、可用性についても優れていると言えるでしょう。

セキュリティ

パブリッククラウドサービスを利用する際には、セキュリティに関する懸念が生じるでしょう。しかし、AWSやGCPは、各種公的な認証を取得しており、高いセキュリティレベルで運営がされていることがわかります。一方で、データセンターの査察等ができないといったデメリットもあり、データセンターの監査等、特殊な要件が必要な場合にはオンプレミスが向いている場合もあります。

クラウド移行のメリット

上記4つの観点に鑑み、クラウド移行のメリットは特殊な場合を除き、ITシステムにおける品質やコスト、デリバリー、セキュリティの改善に大きく貢献するということが言えます。また、副次的なメリットではありますが、クラウド移行により削減したコストは他の部門や取り組みに移転することで、他事業の強化や競争力の向上につなげることが可能です。

クラウド移行によるDXがもたらすメリット

クラウド移行によるDX（デジタルトランスフォーメーション）を行うことで、IT部門の余力確保に大きく貢献できます。

具体的には、ITシステムの運用におけるProcessとPeople面での負荷を大きく削減できます。例えば、オンプレミスのサーバーを運用する場合は、ハードウェアからアプリケーションまでの障害監視を実施し、ハードウェアの増築や保守切れを迎えた場合はベンダーとの追加契約やシステム更改を実施する、といった作業が必要になります。

一方で、PaaSやSaaSを利用する場合は、IT部門はハードウェアやOSレイヤの障害監視業務から解放されます。また、ハードウェアの増築といった業務も不要になります。このようにクラウド化を実施すると、業務プロセスの改善だけでなく、業務そのものをなくすことができるため、IT部門の余力確保が可能になります。

オンプレミスからクラウドへの移行方法

クラウド移行を実施していくためには、スキルがあるメンバーの確保とナレッジの蓄積が重要です。したがって、Webサイトなどの単純なシステムから移行を開始し、情報系、基幹系といった高難度なシステム移行に徐々にシフトしていく、といった流れが推奨されます。

移行方法の種類

オンプレミスからクラウドへの移行方式は、主に以下４つの方式があります。

このうち、リフト、リホストはシステムの構成やアプリケーションをそのままにしながらクラウド上へ移行する方式で、取り進めを行う上でスキルが比較的不要であり、もっとも安価で簡単な移行方式です。

しかしながら、この方法ではOSのパッチ適用やログ監視といった運用はそのまま残ることになります。クラウドのメリットは、水平・垂直への自動的なスケーリングによる自動化や、SaaS、PaaSを利用することによる運用の軽減が主な特徴ですが、リフト、リホストでは自動化や運用の軽減といったクラウドのメリットを十分に享受できません。

クラウドのメリットを生かすためには、リプラットフォームやリファクタリングといった、いわゆる「クラウドネイティブ」のアーキテクチャを採用してくと、十分にクラウドのメリットを享受できます。

ただし、リプラットフォームやリファクタリングは一定以上のクラウドに関するスキルが必要となるうえに、システム再構成に係るリスクの考慮や、追加のコストも必要になります。したがって、ノウハウがないうちはリフト・リホストを実施し、要員のスキルレベルが向上すれば、リプラットフォームやリファクタリングを実施するという流れを検討するのも良いでしょう。

基幹システムをクラウド移行プロセス

次は、基幹システムをクラウドへ移行させる際の3つのプロセスについて解説していきます

ステークホルダーへの説明

経営層への合意が得られなければ、クラウド移行は進めることができません。ただし、経営層はITに関する知識が乏しい場合が少なくありません。したがって、まずはQCDにフォーカスした、社内のITシステム開発・運用における課題を整理するところから始めるということが考えられます。

課題を明確にしておくことで、クラウド移行にむけたKPI、KGIを明確に定めることができます。次に、定めたKPI、KGIを経営者や経営層にもきちんと説明し、共有しましょう。また、ITシステムを利用するエンドユーザーやその責任者とのへの連絡や説明も必要です。

PoC

計画の前段階として、クラウド移行における技術的な懸念点の洗い出しを行い、解消を進めるPoCの実施が考えられます。具体的な項目としては、オンプレミスで利用しているミドルウェアやアプリケーションがクラウドにも対応しているか、といった内容や、I/Oなどの性能面、他システム連携などの方式についてが挙げられます。

PoCのメリットとしては、無駄な工数削減が挙げられます。新規サービスを立ち上げる際に初めから全体を進めるとトラブル時に大きな後戻りが発生します。しかしPoCを行うことで限定的な範囲で修正や稼働を行うことができ、早い段階で実現可能かどうか判断できます。

移行

技術的な懸念点の洗い出しを完了したら、移行プロジェクトをスタートさせます。移行におけるクラウド側のシステム構築は問題なく行われることが多いですが、システム切り替え時には問題が起きる可能性が高いです。アプリケーションの特性を考慮し、移行日や移行方式、切り戻しの基準、連絡体制などを関係者間で十分に確認してから、移行日を迎えることが推奨されます。

 クラウド移行する際の注意点

クラウド移行における注意点を記載していきます。

クラウド移行の制約事項に注意

移行対象のシステムにおいて、クラウド側で具備していない機能・性能が要件となっていないかを確認します。例えば、EV-SSL証明書という、最上級に厳格なSSL証明書はクラウドベンダーによっては利用できません。

このような要素は、システム移行プロジェクトに大きな影響を与えかねないため、こういった内容は、PoCやクラウドサービス提供者への問い合わせで事前に明らかにしておくことが重要です。

クラウドのサービスを使い倒してITシステム運用を変える

クラウドに移行したシステムの運用は、クラウドで提供される様々なサービスを組み合わせて、自動化を検討できます。例えば、AWSではOSのパッチ適用はSystems Managerというサービスを利用することで自動的に行うことが可能です。

従来まで手作業で行っていた運用・保守作業を、これらのサービスを利用することで運用フェーズにおけるコストを大幅に削減することができます。逆に、運用を手作業のまま残しておくと、クラウド移行によるメリットを享受できず、他のプロジェクトに影響が出てDXの足かせになります。

基幹システムをクラウド移行する際のポイント

基幹システムをクラウドに移行する際に、重要なポイントについて解説していきます。

 　社内のリソース確認

最初に確認すべきポイントは、基幹システムをクラウドに移行する際に必要な社内リソースが十分にあるかという点です。これにはクラウド移行に伴う資金だけでなく、運用に必要な人的資源や管理体制も含まれています。

また、クラウドへの移行が必要になっている現状を正しく理解しておくことも重要です。従来のシステムがどれだけ老朽化しているのか、それによりどれだけ業務に支障が出ているのか、また刷新することでどれだけ業務効率を改善できるのか必ず把握します。

　システムの可用性

オンプレミスの基幹システムをクラウドに移行する際も、可用性の問題がまったくなくなるわけではありません。クラウドはベンダーが提供するクラウドに何らかの問題が発生するとすべての業務が停止します。

クラウド特有の可用性の問題に対処するためには、緊急時に一時的にオンプレミスで運用できるような体制を整えておくか、サーバーに問題が発生した際に、一時的に待機システムの方で継続運用が可能なベンダーを選ぶことができます。

　QCD（品質、費用、納期）

クラウドサーバーを提供するベンダーを選択する際は、「QCD（品質・費用・納期）」を基準に決定します。この基準はどれか一つを優先してクリアすれば良いのではなく、業務に直接関わる「Q（品質）」を最大の優先事項として、さらにその品質が達成されるための「C（費用）」と「D（納期）」のバランスが取れている必要があります。

品質だけを優先してしまうと費用が莫大になったり納期が大幅に遅くなる可能性がありますし、低コストや納期だけを優先すると予定していた品質を達成できず、基幹システムを刷新する意味がなくなってしまいます。ベンダー選びは実績や専門性を考慮しながら慎重に行うべきです。

　セキュリティやコンプライアンス

クラウドを提供しているベンダーが公開している、セキュリティ要件やコンプライアンスにも注意を払います。EPRでは販売管理情報や顧客情報、在庫情報など業務にかかわるすべてを一元管理することになるため、暗号化や24時間監視などのセキュリティ体制を満たしていることが必要不可欠です。

基本的には、自社が策定しているセキュリティ要件を全て満たすベンダーを選ぶべきです。クラウドサービスはコースによってセキュリティの堅牢性が異なる場合があり、低コストでの運用を重視するとセキュリティリスクが高くなる可能性があるからです。

 基幹システムのクラウド化の事例

住友化学

基幹系システムとして1997年から導入されていたSAP ERPをクラウド移行した事例です。5年おきに発生したハードウェア更新の業務をなくすだけでなく、バッチ処理時間の大幅な削減を達成しています。
（参考：AWS 導入事例：住友化学株式会社）

ふくおかファイナンシャルグループ

移行中の事例ですが、クラウド基盤としてGCPを採用し、構築を進めています。分散型データベースであるCloud Spannerを活用し、データの可用性向上を達成するだけでなく、コンテナを中心としたアジリティの高いシステム構築の実施が進められています。
（参考：ふくおかFG、次世代バンキングシステムをGCPで構築へ）

日本通運

日本通運は2013年に自社の基幹システムのクラウド化を完了させ、さらに運用面のコストや業務を効率化させるために、OSからハードウェアまでコアとなる部分をすべて仮想化できるパブリッククラウド（IaaS）へ移行しました。

これにより、リソースの管理やセキュリティの保全業務などで多大な労力を要したり、ユーザーへの回答に多くの時間を割かれる、といったオンプレミスにおける問題の多くが解決しました。同社は現在も、基幹システムの全てをクラウド化できるように最適化を進めています。

（参考：AWS 導入事例：日本通運株式会社）

まとめ

今回の記事では、基幹システムのクラウド化についての移行方法やメリットを解説しました。コンサルティング案件などを探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。