日本の情報システムにとって最適なクラウド化とそのためのクラウド基盤の要件

要旨

クラウドサービスは出自が海外であることと、IT発展途上国を含むグローバル展開を前提にしているため、20世紀にはシステム化を達成している日本の情報システムにとって必ずしも最適とは言えない。
本記事では、日本の情報システムにとって、クラウド化の最適解はどのようなものであるかについて述べる。

1. オンプレミスの受け皿としてのクラウドサービスの不十分性

現在のクラウドサービスは、オンプレミスに設置された情報システムの全面的な移行先として見た場合、必ずしも適切でない。

これは、クラウドの出自に依存する課題である。具体的には、クラウドサービスの多くが、初めからクラウドの上にシステム構築するケースや、システムのうち、特定機能(対外サーバ等)だけを切出して利用する事を目的に開発され、発展してきたからであり、既存のシステム全体の受入れ基盤として作られたものではないからである。このために、オンプレミスシステムがクラウドの長所を活かそうとすると、システムの機能設計や運用設計を大幅に修正する必要があり、これが、既存システムのクラウド化に大きなハードルとなっている。

本記事では、既存オンプレミスシステムをクラウドの利点を生かすことを目的にクラウド化するという視点で、クラウドサービスに必要な要件を纏めている。

2. オンプレミス業務システムのクラウド移行を阻む要因

現在、オンプレミスシステムのクラウド化には、機能設計、運用設計の変更という高い障壁がある。これは事実上のシステムの作り直しであり、ユーザ企業、システムインテグレータ両者にとって非常にリスクが高い。基幹業務の停止や動作不整合の発生を考慮すれば、安易にシステム改造はできない。

クラウド移行がシステムの設計変更を強いる理由は、クラウドサービスが各種仮想化技術の上に立脚しているためである（図1）。 IaaS型クラウドは「サーバ仮想化」、「ストレージ仮想化」、「ネットワーク仮想化」といった仮想化技術の組み合わせで造られているため、クラウドサービスを利用するために仮想化することが前提条件となる。

一方、オンプレミスシステムにおける仮想化はサーバ仮想化程度に留まり、システムの多くは物理機器で構成されている。ストレージ仮想化は、メーカ独自実装を利用している場合が多く、ソフトウェア・デファインド・ストレージの利用は一般的でない。

特に、オンプレミスで普及したネットワーク仮想化技術はVLANに留まり、その後登場したソフトウェア・デファインド・ネットワークは普及しているとはいいがたい。

図1 既存システムクラウド化の障壁は設計面と情報統制の2面性オンプレミスシステムをクラウドに移行する障壁は、大きく分けてアーキテクチャの変更を強いられることと、情報資産が統制範囲外に配置されることである。

このため、オンプレミスシステム全体をクラウドに移行する場合、まず、物理機器で構成されている部分を仮想化しなければクラウドに移行できないという課題に直面する（図2）。
前述のとおり、ストレージとネットワークを仮想化する必要があるが、これらが普及していない以上、仮想化設計を行える技術者は少なく、最適設計(ベストプラクティス)も少ないため、設計がしにくいという課題がある。

仮に、システムを再設計できたとしても、再設計のコストが発生するのはもちろん、実績の少ないストレージ仮想化、ネットワーク仮想化を前提に適切な、性能、信頼性、セキュリティ設計を施すことは難しい。

仮想化は操作インタフェースの変更となるため、運用手順が変わる。企業の場合、運用業務をアウトソーシングしている場合が多いため、手順変更はアウトソーサ側での運用再設計となりコストを増加させる。

図2 オンプレミスは物理・仮想ハイブリッド構成オンプレミスの情報システムは仮想化、クラウド普及以前にIT化されているため完全仮想化アーキテクチャではなく仮想化困難な機器を多数抱えている。このような事情が既存の情報システムのクラウド化を困難にしている。

システム全体を移行する以上、データもクラウドの上に移動させる必要があり、それが情報資産の外だし問題を引き起こす懸念もある（図3）。クラウドサービスは自組織の統制範囲外に存在するため、自社ルールをそのまま適用できず、ルール改変、妥協をする必要性がある。

クラウド移行後にオンプレミスや別のクラウドへ再移行することが現実的かも注意する必要がある。クラウドサービスによってはインバウンド通信（クラウド外部から内部）は無料だが、アウトバウンド通信（クラウド内部から外部）は課金される場合がある。クラウドに長期間、累積的にデータを蓄積する場合、引越が可能か、あらかじめ考慮しておく必要がある。

図3 データ統制とポータビリティの課題クラウドにシステムを移行した後、他の基盤に移行できなくなる可能性がある。特定クラウドサービスへのロックイン懸念と、データ統制権確保という観点で評価する必要がある。

3. オンプレミス業務システムをクラウド化する意義

既述のとおり、オンプレミスシステム全体をクラウド化することは、各種の障壁がある。しかし、クラウドを全く利活用しないことは、クラウド普及期以降に登場した新しい選択肢を放棄することであり、今後の発展を減速させる。

3.1 クラウドが持つ長所と便益

ここではクラウドが持つ便益とは何か、特にオンプレミスに比べて優位な点とは何かに焦点を当てて述べる。クラウドサービスの利点には以下のように「オンプレミスでは実現困難な機能を得ること」と、「自組織の負担のオフロード先としての期待」という２種類がある（図4）。

図4 クラウド利活用とはオンプレのクラウド化ではないクラウドサービスが持つ機能にはオンプレミスで同じ機能を実装できるものと、それが現実的でないものの２種類に類別される。オンプレミスシステムをクラウド上で稼働するように再設計しても、オンプレミス以上に機能が強化されず、再設計に伴うリスクを抱えるだけではクラウド化する意義がない。

最初に、クラウドサービスでなければ実現困難な長所について述べる。

1番目は、所有コストが非常に高額なシステムを利用したい場合であり、これは古くから共同利用型サービスの名称で認知されている。例えば、スーパーコンピュータは、個人はむろん、一組織で所有することも困難な程のコストが発生するため、共同利用形態をとり、時間課金で提供される。これはクラウドサービスの一例と言える。

2番目は、クラウドサービス普及期（日本では、概ね2013年）以降に登場、または普及した新技術を利用する場合である。これらは、登場時にクラウドという基盤が存在したため、クラウドをシステム基盤として採用し、PaaS、SaaSとして提供されているものが多い。このような提供形態をとる機能をオンプレミスに実装するのは難しい。　

これら新技術（モダンサービスと呼ばれる）の代表例として機械学習、人工知能、ビッグデータ解析、バーチャルリアリティ、複合現実などがある。これらの技術は黎明期で発展途上であるため、現在の最新技術も数年後には陳腐化する。このようなライフサイクルが短い技術を所有型で実装すると、資産償却が終わる前に陳腐化してしまうという課題もある。

3番目は、需要に応じ資源の増減（スケールイン・スケールアウト）がしやすいことである。この特性は需要変動が少ないシステムには重要でないが、業務システムには本番系と別に、開発、試験に利用されるシステムが存在する。これらは、年度によって繁忙期、閑散期があるため、買取り型構成の場合、遊休期間が生じてしまう。このため、クラウドサービスを利用する価値がある。

次に、オンプレミスでも実現可能だが、クラウド利用により便益が得られる点について述べる。

4番目は資産管理の負荷である。買取り型システムの場合、固定資産税の関係から資産管理が必要となるが、現物確認などかなりの負担がかかる単純作業である。ソフトウェアもサポート切れ、電子証明書の期限など管理雑務が多い。これらをクラウドサービス事業者に委託できるという点において、クラウドサービスの利用は価値がある。

5番目はクラウド事業者をシステム構成部品の供給者と見た場合の利点である。メガクラウドのPaaS部品相当の機能をフルスクラッチで開発するのは多くの時間がかかる。これらの多くはモダンサービスであるため、開発能力を持つ人材確保も困難が伴う。このため、既成部品を組み合わせることは、システム開発期間短縮という観点で効果的である。

6番目は利点と欠点を併せ持っている。上記のPaaS部品もクラウド基盤を構成するハード、ソフトもクラウドサービスを利用すればライフサイクル管理をクラウド事業者にオフロードでき、雑務を回避できる。一方、自社で統制をとってバージョンを管理することができないという問題が起きる。具体的には、クラウドプロバイダ提供部品はユーザ企業の都合を無視してバージョンアップされ、仕様変更される。結果的に、それを利用する業務システムがある日突然動作しなくなったり、結果不正を生じる可能性がある。

3.2 クラウドの長所と便益を活かすための注意点

このように、クラウドサービスの利用には便益とリスクの両方がある。このため、リスクを最小化しつつ、便益を享受できる使い方をするクラウド化が望ましい。具体的には、以下のような注意が必要である。

クラウドの上で稼働させるためだけに既存システムを改造するのは避ける。
クラウドプロバイダ提供の（ライフサイクルの短い）部品を、従来の（ライフサイクルの長い）基幹系システムの一部として組み込まない。
基幹システムが持つ業務情報をモダンサービスで活用する形態が望ましい。
開発系、試験系をクラウドサービスで構成する。ただし本番系とアーキテクチャ互換性を維持できるクラウドサービスでないと意味がない。
SaaS活用など、従来システムと独立した機能強化と位置付けられる部分はクラウド利用が望ましい。ただし、オンプレミスとSaaSのハイブリッド利用ではSaaSを利用するためにインターネットトラフィックが増加する点に注意が必要。

図5 クラウドは既存オンプレミスをリプレイスするために使うべきではないクラウドサービスにはそれならではの特色があるため、その利活用に着目してクラウド化を進めることが効果的である。

このように、既存システムのクラウド化とは、クラウドの仕様に合わせて既存システムのアーキテクチャを再設計することではなく、クラウドの便利な点を活かすために必要最小限度のことを行うことが最良の策であると言える。この「必要最小限度のこと」とは、

クラウドならではの長所（*1）を持つクラウドネイティブサービスとの連携がしやすい場所に既存システムを移動させる。
クラウドネイティブサービスとの連携にあたり発生するトラフィック量をさばける帯域を持つアクセスリンクを持つ場所に既存システムを移動させる。
既存システムを移動させるにあたって、極力アーキテクチャ変更、運用変更を伴わない。

*1: モダンサービス提供、PaaS等の部品提供、柔軟なスケール性など

4. ブロック組み合わせ型クラウドサービス

本章では、IDCフロンティア（以下、IDCF）のクラウドサービスを例にとり、IaaSクラウドで部品の組み合わせでシステムを構成する事の効果を説明する。移行後のクラウド利活用については5章で述べる。

IDCFは、共有型パブリッククラウドサービス以外に、専有型プライベートクラウド、占有型ベアメタルサーバサービスなどのクラウドサービスと、それらを相互接続するネットワークサービスを提供している。同時にデータセンタサービスの一環としてハウジングサービスも提供している。

IDCFのクラウドサービスの特色は単品で稼働するものがほとんどなく、複数サービスを組み合わせ、ネットワークサービスを介して相互接続し、全体としてひとつの情報システムを作り上げる、システムインテグレートが必要な部品群であるということである（図6）。

この「組み合わせてシステムを作る」というコンセプトによって、部品の組み合わせ方を変えることで、色々な構成を作り出すことができ、ユーザ要件に最適化されたシステム設計がしやすいようになっている。

サービスは仮想化基盤タイプのものと物理機器を利用したものの二本立てであるため、既存システムを全て仮想化しなければクラウド移行できないというハードルを回避できる。
さらに、顧客がハウジングラックに持ち込む機器とIDCF提供のサービス（部品）を相互接続することもできるため、既存部品だけではシステム要件をカバーしきれない場合にも対応ができる。

この、「部品の提供、自由度の高い組み合わせ、持込対応」というコンセプトにより、オンプレミスの複雑なシステムを、できる限り、アーキテクチャ変更、運用変更なしに、クラウド基盤に移行することができることが特色である。

このコンセプトは一般的なクラウドサービスのコンセプトと一線を画するものであるが、オンプレミスからの移行において、リスクを最小化しつつ、クラウドを利活用しやすい場所にシステムを移動することができるという利点を提供できる。

一般にIaaS型クラウドサービスは、それ単体でモノリシックな自己完結型構造を持つことが多く、システム構成設計の自由度は高くないため、構成が複雑なオンプレミスシステムを再現するのが困難である。

図6 システム構成部品としてのクラウドサービスモノリシックな自己完結型構造でなく、システム構成部品と相互接続機能を各種取り揃えて提供することで、ユーザは部品の組み合わせにより多様な構成を作れる。

4.1 組み合わせコンセプトを構成するサービス群

IDCFのクラウドサービスは、複数部品を選び、相互接続することが基本原則となっている。ここでは、部品の概要と組み合わせ例を紹介する。

部品として用意されている主要サービスを図7に示す。これらを組み合わせ、相互接続することで、ユーザ企業、システムインテグレータは、業務要件に合わせて任意にシステムを作ることができる。

プライベートクラウド、ベアメタルサービス、IDCFクラウドがコンピュートとストレージ機能を提供する部品であり、マネージドネットワークサービス、バーチャルブリッジサービスがこれらを相互接続するネットワーク機能とネットワーク機器である。インターネット接続用には、クラウドネットワークコネクト、サーバコネクションの2種類の選択肢がある。

これら部品で機能が足りない場合、利用者が自身の所有機器を持込み、バーチャルブリッジなどを介して、クラウドサービス部品群と接続することができる。

図7 クラウドサービスとはシステムを構成する部品 IDCFのクラウドサービスは単体で自己完結して動作するサービスは少なく、システム構築上必要な部品として提供される。これらの部品をネットワークサービスでつなぐことでひとつのシステム基盤を作れる。

サービス部品は「占有型」、「共有型」の二種類に分類できる。占有型はサービスを構成するハード、ソフトが、原則としてユーザ個社専用であり、他のユーザと共有しないものである。占有型は、自社で想定できず、統制もできない、他テナントの影響を排除できるため、オンプレミス同等の性能設計、サイジング設計を行えることが特色である。占有型サービスは以下の３種類がある。

プライベートクラウド（レンタルvSphere基盤）
ベアメタルサービス（レンタル物理サーバ）
マネージドネットワークサービス（運用代行付きレンタルネットワーク機器）

次節では、これらの部品を組み合わせる組み合わせる構成例を紹介する。

4.2 組み合わせ構成例1 小規模な仮想化基盤のクラウド化

図8はオンプレミスの小規模システムに多い、仮想化基盤と物理ネットワーク機器を組み合わせたシステムを作る例である。

図8 小規模な仮想化基盤中心のシステムの構成例 VMware vSphere🄬 基盤上で業務システム単位に別々のVLANを作り、VLAN間ルーティングや対外アクセス制御を仮想化基盤外部の物理ネットワーク機器で実現する構成例

プライベートクラウド内部のVLAN(IPセグメント)をルーティングするために、マネージドネットワークサービスを使い、プライベートクラウド内部のVLANをL3スイッチへ延伸するためにL2接続サービスであるバーチャルブリッジサービスを利用する。この構成例はユーザ買い取り機器が必要ないという点でクラウドサービスであるが、同時に仮想機器と物理機器のハイブリッド構成である。

この構成例は、サーバは仮想化されているが、ネットワークは物理構成であるという、オンプレミスで一般的なシステムアーキテクチャーをそのまま継承してクラウド化している。この利点は、システム設計、運用設計がオンプレミスと大きく変わらないため、オンプレミスからのクラウド移行で発生しがちな、「アーキテクチャ・システム設計・運用設計の一新」という問題を回避できる点にある。

この構成だけでは、仮想化できない、または不向きな機材を抱える情報システムを受け入れるには不十分な場合は、次節で紹介する構成で受け入れが可能である。

4.3 組み合わせ構成例2 複数サービスと持込機器を連携させたクラウド化

図9は業務要件に応じて、各種のサービスをネットワーク連携させ、システムを作る例である。この例では、仮想化基盤、ベアメタルサーバ、パブリッククラウド、ハウジングラック内のユーザ所有機器を組み合わせている。

図9 適材適所で部品を選び、相互連携させる構成例 Webフロントエンドをスケールアウトが容易なパブリッククラウドに、アプリケーションサーバをプライベートクラウドに、物理サーバが望ましいDBサーバをベアメタルサーバに、業務データ蓄積用大規模ストレージを持込機材で構成するハイブリッド構成

この例では、業務システム要件に合わせパブリッククラウド、プライベートクラウド、ベアメタルサーバ、持込機器を組み合わせてシステムを構成している。

パブリッククラウドは短時間でスケールイン、スケールアウトが可能な一方で、共用型サービスゆえに性能の担保が困難。ベアメタルサービスやプライベートクラウドはスケール性が低いが、占有型のため性能担保がしやすい。また、大型ストレージの性能と信頼性をクラウドサービスで実現するのは困難な場合もある。
このようにサービスが持つ特性を生かし、組み合わせ、不足部分は持込機器を併用して業務要件に合わせたシステム設計を行うことができる。

4.4 ネットワーク構成にこだりのあるシステムのクラウド化

図10の例では、ネットワーク機器を、ユーザ所有機器で構成している。対外接続境界点に設置される防御システム（UTM）やリモートアクセス用システム（VPN）の運用はユーザのセキュリティポリシーに依存するため、マネージドサービスの定型メニューに合わせることは難しい。

主拠点をコアに、国内外の支拠点を専用線、インターネットVPNで集約するスター型トポロジを形成するシステムをクラウド化する場合、WAN回線の引き込みが課題となる。これらネットワーク面の課題は、クラウドサービスがユーザ機器やキャリア回線の引き込みを許容すれば解決する。　

図10 複雑かつこだわりのあるネットワーク構成日本の情報システム基盤の多くはハブ・アンド・スポーク型の広域システムを専用線で形成する。この構成をメガクラウドに移行するのはコスト、技術(BGPの設計、運用が必要)の両面でハードルが高い。

オンプレミスシステムを不要な改造リスクを避けてクラウド化するためには、一般的なクラウドサービスのように、クラウドの仕様に合わせてシステムを改造するのではなく、クラウド側に設計上の柔軟性を許容する仕組みが必要となる。このためにクラウド側に必要な機能が以下の三点である。

物理と仮想のハイブリッド構成が可能であること。
利用型（クラウドサービス）と所有型（持込機器）のハイブリッド構成が可能であること。
サービスが部品群として提供され、組み合わせを変えることで多様な構成を実現できること。

5. オンプレミスのクラウド化の次にある段階

5.1 システムのモダン化のための施策

オンプレミスシステムをクラウド化するうえで、クラウドに必要な要件は、オンプレミスシステムを、不必要な改造リスクを回避できるだけではない。クラウド化後のシステムに以下のような、クラウドならではの便益をもたらす機能を容易に付加できることが重要となる。

所有するには高コストすぎる機能の利用
クラウドネイティブ(モダン)サービスの利用
需要変動に合わせた規模の拡大、縮小

多くの場合、クラウド化する動機は、上記のうち、クラウドネイティブサービスの利用である。このような期待値に応えるため、IDCFでは以下の取り組みを行っている（図11）。

クラウド移行後の基盤に、モダンサービスであるコンテナを配備できるサービスの提供
メガクラウド連携にも活用できるインターネット広帯域アクセス回線の提供

図11 クラウド移行後の基盤にモダン機能を付加 IDCFコンテナサービスは移行後の基盤を構成する各種部品（プライベートクラウド、パブリッククラウド、持込機器、オンプレミス機器）に広くコンテナを配備できるため、移行後の基盤が持つ資源を利用し、順次コンテナ化を進めてゆく、段階的モダン化アプローチを取りやすい。

IDCFコンテナサービスを利用すると、ユーザはIDCFの各種クラウドサービス（パブリッククラウド、プライベートクラウド、ベアメタル）に加え、持込機器、オンプレミス機器の上にk8s™によるコンテナクラスタを配備することができるようになる。

モダン化は一気に行えるものでないため、サブシステム単位での順次改修、新規追加業務を対象にコンテナベースのアプリケーションへシフトさせるなど、段階的に行うのが望ましい。 IDCFコンテナサービスは多様な基盤に対応しているため、移行後の基盤の資源の余剰を利用してPOC(概念検証)を行い、本格採用となった際に基盤を増強するなどの使い方ができる。

海外クラウドのSaaS系サービスを利用する場合、インターネット回線に想定以上の大きなトラフィックが流れることになる。強力なネットワークインフラを持つデータセンタ事業者のクラウド基盤にシステムを移行することは、その後のSaaS利活用の進展にともない発生するあい路を回避できる基盤に移行することも意味している。

5.2 相互接続されたデータセンタ基盤

物理と仮想（クラウド）のハイブリッド構成では、物理機器とクラウドサービスを接続するネットワークが重要になる。このネットワークはひとつのデータセンタ内で閉じる（同一データセンタに物理機器とクラウドサービス機器が設置される）場合と、そうでない（複数データセンタに跨る）場合がある。特に複数データセンタに跨ったシステムの構成容易性は重要である。既存情報システムを移設すらせず、ネットワーク経由でクラウドサービスを利用できる事は、重要であるからである。

既存システムを移設しない利点として、保守ベンダとの調整が不要である点も見逃すべきではない。物理機器保守は担当保守ベンダの地域拠点が行うため、移設先の近傍に保守拠点がない場合、保守対応が低下する。システムエンジニア（SE）による立会いや変更作業の観点からも、クラウド連携のためだけに、SE拠点から遠く離れた場所にシステムを移設するのは、不利益が多い。

このような事情を考慮すると、クラウドサービスが提供されるデータセンタと物理システムを設置可能なデータセンタが同一か、異なっていたとしても、相互に安定した遅延のばらつきが少ない広帯域ネットワークで接続されているか、ということが重要になる。

ネットワーク経由でクラウド機能を利用する場合、既存業務システムとクラウドの密結合はネットワークがあい路となる可能性があるため、好ましくないが、疎結合の場合へ現実的である（図12）。

図12 クラウドと既存システムを疎結合すればネットワークのあい路を回避しやすいオンプレミスシステムにDBサーバ、クラウドにWeb, APフロイントエンドという構成はネットワークあい路によって、システムスループット低下が起きるが、ビッグデータ解析などの用途などは疎結合構成を取れればあい路回避がしやすい。

IDCFの各データセンタは相互にネットワークで接続されており、その上に形成されたバーチャルブリッジサービスによって、ハウジング機器やクラウドサービス（IDCFクラウド、ベアメタルサービス、プライベートクラウド）と接続、連携できる。

このようなデータセンタ間ネットワークを介した連携を使えば、エンドユーザの主たるシステムを地理的に大きく離れた場所に移動することなくクラウドサービスと連携させ、良さを利用することができる。閉域網であるため、インターネット経由の接続に比べ、安定した広帯域接続が可能であり、業務スループット予測が可能となる。

図13 相互接続されたデータセンタとクラウド基盤クラウド利活用では、クラウドサービスとデータセンタ設置システム、オンプレミス設置システムにまたがる相互連携が容易な基盤であることが重要である。

ここまでで、クラウドサービスの良さを利活用するためにどのような基盤を利用するべきかを述べたが、その内容を整理すると以下のとおりとなる。

既存システムの根本的改造を避ける仕組み(アーキテクチャ、運用の継承)があるか
オンプレミスシステムのアーキテクチャを再現できる仕組みがあるか
上記仕組みで不十分な場合に補完する仕組みがあるか
移行後のシステムのモダン化のためにマルチベンダのクラウド利活用が可能か
複数拠点・クラウドにまたがるシステムを形成した場合に安定稼動できる基盤の提供が可能か

6. クラウド基盤の利用例

前章までに、既存のシステムのクラウド化とは、クラウドの技術的仕様、制約に合わせてシステムを改造することではなく、改造を避けて、クラウド独特の長所を取り込む事であるという点、ならびに、クラウドの長所を活かしやすい基盤とはどのようなものであるべきかについて述べた。

本章では、これら基盤上で、複数クラウドの機能を利用して構成される業務システムの実現イメージについて述べる。

第一は、企業の事務系基盤をクラウド移行する例である。従来は企業の事務所に設置されていたOA事務基盤、基幹業務系基盤であるが、ワークスタイル変革に伴う、業務形態の変化によって、事務所以外の場所からシステムを利用したり、業務データにアクセスするスタイルが増えている。このような形態では、データの分散に伴うセキュリティリスクが懸念される課題である。

データの集約とユビキタス性の高いアクセスの両立のために、VDI（仮想デスクトップ）や、SaaS（オンラインストレージなど）の利用が有望な選択肢である。

VDI化を行う場合、VDI上の仮想PCと業務データ、サーバシステムは三位一体の密結合となる。同時にこれらシステムは業務システムにおける物理サーバ、大型ファイルサーバがあるため、VDIを除き、完全仮想化が困難である。このような物理、仮想混成の基盤をリフトアップ（アーキテクチャ変更を避けた移行）によって、まず、低リスクでクラウド化する。その上で、必要に応じ、コンテナベースのアプリケーションを配備などモダン化してゆくことで、比較的容易にクラウドへの離陸を果たすことができるようになる。

また、SaaSとの連携もクラウドの長所だけを付加するという考え方においては重要である。ただし、SaaSはインターネット上の別拠点のシステムを利用するため、インターネットアップリンクに大きな通信負荷がかかる。安定したアップリンクを提供できるという点でも、オンプレからクラウド基盤にシステムを移動させることは意義がある。

図14 オンプレミス事務系、基幹系システムのクラウドリフトアップとモダン化クラウド以前のシステムであり、クラウドアーキテクチャに対応していないシステムは、まず、改造を避け、クラウド利用しやすい場所へとリフトアップ、その後、モダンサービス化やSaaS連携によりマルチクラウド連携システムへシフトさせるのが望ましい。

第二は、データ利活用を目的としたデータパイプライン基盤を形成する場合である。情報システムはその名のとおり、情報の処理（すなわち分析）を行うものであるが、この情報分析を多角的に行うためには、情報の二次、三次の利活用が必要となる。これは、同じ情報を異なる複数の解析システムが複数の観点から解析を行うために、データが解析に必要な場所に適宜流通される必要があるということを意味している。これがデータパイプラインと記述するゆえんである。

従来、情報処理は事務系（OA系）、事業系（基幹業務系）、製造・制御システム系（FA系）と別々に構成され、それらの相互連携は存在しなかった。しかし、今後はインダストリー4.0やソサイエティー5.0といった概念に基づき、横断的に情報連携と分析が必要になる。

このような背景を考慮すれば、各種データを発生場所から解析場所へと流すパイプラインが必要であり、そのパイプライン上にデータをストアする機能（すなわちストレージ）、データを分析する機能（すなわち、コンピュータ）、データそのものを移動させるネットワークが必要とされる。

データの機密性に応じて、最終的に格納されるストレージの設置場所も変わる必要がある。これは、機密データを組織の統制範囲外へ移動させることを避けるためである。自組織以外の組織がデータを利活用する場合も組織外にデータを移動させずに利活用する必要がある。

データを解析するコンピュータ資源はデータの実態に比べれば配置場所の柔軟性が高い。解析時にデータを参照するだけであれば、解析用コンピュータ自身はネットワークを介してデータを参照さえできれば、任意の場所に配置できる。つまり、データを自組織や他の組織に利活用させる場合、そのデータ本体は自組織の統制が及ぶ範囲に配置し、解析に必要なコンピュータ資源はメガクラウドなどの豊富で伸縮性に富んだコンピュータリソースを利用するという利用形態が予測される。