一般的な日本企業が、オンプレミスとクラウドの間にある「崖」を埋め、デジタルトランスフォーメーションを実現していくには：日本IBM 三澤智光氏×Publickey 新野淳一氏の対談で探る

クラウドが、PoC（実証実験）やSoE（Systems of Engagement）アプリケーションのインフラとしてだけではなく、基幹システムも含めた既存システムの移行先としても検討されるようになってきた。SoR（Systems of Record）領域の既存ビジネス／システムを安全、確実にモダナイズしながら、SoE領域の取り組みを推進するには何が必要か。クラウドに求められる要件とは何か。

[PR／＠IT]

　デジタルトランスフォーメーション（DX）が進展する中、クラウドに求められる要件もまた変化してきた。PoC（実証実験）やSoE（Systems of Engagement）アプリケーションのインフラとしてだけではなく、基幹システムも含めた既存システムの移行先としても検討されるようになってきたのだ。

　長らく日本経済を支えてきたさまざまな企業が、SoR（Systems of Record）領域の既存ビジネス／システムを安全、確実にモダナイズしながら、SoE領域の取り組みを推進するには何が必要か、そしてその中でクラウドに求められる要件とは何か――日本IBMのクラウド戦略をリードする三澤智光氏と、多数のクラウドプロバイダーの動向を追うITジャーナリスト 新野淳一氏の対談を通じて探っていく。

DX、そしてクラウドの本質とは

――DXのトレンドが進展していますが、企業を取り巻く昨今の経営環境をどう見ていますか。

日本IBM 取締役 専務執行役員 IBMクラウド事業本部長 三澤智光氏

三澤氏　猫も杓子もDXと言いますが、「なぜDXが必要なのか」というと、やはり企業が勝ち残り、生き残るためではないでしょうか。良いものを早く作って市場に投入するスピードを上げたい、良いものをより早くお客さまに認知してもらいたい――こうしたことを実現して激しい競争環境の中で生き残るには、テクノロジーを使う以外にあり得ません。これまでは企業戦略とITは離れていることが多いものでしたが、今や企業戦略とITが一体化しなくてはDXは成立しません。これを実現するテクノロジーがクラウドから利用できるようになってきた、という方程式なのだと思います。

これまでは企業戦略とIT企業戦略そのものを変革するにはITが欠かせず、そこで必要となるテクノロジーがクラウドから生まれてきた、という方程式なのだと思います。

新野氏　経営とテクノロジーが近くなってきているんでしょうね。小売業ならば電子決済を組み込んだり、飲食業ならWebサービスを活用して集客につなげたり、自動車産業でもアジャイル開発に取り組んだりという具合に、あらゆる企業がソフトウェアから逃れられない時代になりました。「ソフトウェアが世界を飲み込む」というマーク・アンドリーセン氏の言葉がそれを先取りしていましたが、モノ作りそのものがソフトウェア化し、いよいよ日本の企業にもリアリティーを持ってインパクトを与え始めています。その課題に応える選択肢として、アジャイルやDevOpsなどとともにクラウドも大きな比重を持ちつつあると思います。

三澤氏　「シェアリング」も一つのキーワードでしょう。「企業経営の中でシェアリングエコノミーにどう対応するか」「そしてエコシステムをどう形作るか」も必須の課題となってきました。

――ではその中で、クラウドとは何のために使うものなのでしょうか。その本質はどこにあるのでしょう。

三澤氏　「クラウド」には2つの意味があると思います。一つは、クラウドという「場所」で、もう一つはその中で使われているテクノロジーのことです。クラウドというビジネスモデルの中で作られたソフトウェアやインフラが、新しい時代のITに非常にマッチしているのだと思います。初期のクラウドでは、こうしたテクノロジーを使って新しいビジネスモデルを実現しようとしたときにその場所が限られていました。それが今では少しずつ、パブリッククラウドでもオンプレミスでも、場所を問わずに必要なテクノロジーを使えるようになってきたのではないでしょうか。

ITジャーナリスト／Publickeyブロガー 新野淳一氏

新野氏　クラウドには「オンデマンド」「スケーラブル」「自動化」といった要件が幾つかありますが、一番大事なのは「アウトソーシングできること」だと私は思っています。1960〜70年代は「Not Invented Here」という言葉に代表される通り、自社で技術を開発して提供する時代でしたが、1980年代以降、オープンソースの登場もあって、外部の知恵を利用し、顧客と協力しながら良いものを作る「協力」の時代に入ってきました。その延長線上にあるのがクラウドだと思います。

　クラウドを使うことは、自社が持つ専門性を一部手放すことでもあるため、抵抗があるのも理解できます。けれどその代わり、外部のエキスパートの専門性を活用してイノベーションを加速し、良いものを提供していく、そういう時代です。そこでは、例えばパートナー企業やコミュニティーも含めた、広い意味で外部のエコシステムと協力することが大事なポイントだと思います。

三澤氏　問題は、クラウドで実装されているテクノロジーと、お客さまがノウハウを持っているオンプレミスのテクノロジーがまるで異なり、その間に大きな崖があることです。テクノロジーの崖も問題ですが、それには解決方法があります。もっと重たい課題は、ガバナンス体系やセキュリティポリシーがまるで違うことでしょう。企業の組織やスキルに端を発した崖をどう埋めるか、これには企業として大きな変更が必要となるためなかなか実行できない。そこが難しいから多くの日本企業はクラウドの活用やDXが遅れてきたのだと思います。

　先ほど、クラウドは場所を指す言葉ではなくなってきたとお話ししましたが、パブリッククラウドとオンプレミスとで同じアーキテクチャ、同じテクノロジーで動くものがあれば、この崖をかなり埋めることができるのではないでしょうか。そのハードルはこの2年でだいぶ下がってきたように思います。

オンプレミスとクラウドの間にある「崖」

――一般的な企業が崖を埋め、DXを実現していくには何が必要なのでしょうか。

三澤氏　良くも悪くも、ある特定のクラウドで作ったアプリケーションはそのクラウドでしか動かないというベンダーロックインの問題に直面しています。それを避けるには、いろいろなクラウドやオンプレミスで同じように動く環境を採用するのがいいのではないでしょうか。今、Kubernetesのようなコンテナ技術がスタンダードになり、同じテクノロジーを使い、かつガバナンスやセキュリティポリシーもクラウド、オンプレミスを問わず、同じようにできるようになってきました。

　一般の企業にとって重要なのは、これまで運用してきたオンプレミスのシステムです。一般的な企業ならばオンプレミスのシステムが必ずあり、先ほど申し上げた崖に直面することになるでしょう。自社で管理するのは難しい。かといってパブリッククラウドとではギャップが大き過ぎる――そのような場合は、オンプレミスとクラウドのVMware環境を統合管理できる「VMware on IBM Cloud」をお薦めします。VMwareを使って抽象化し、崖を埋めていくのがトレンドです。オンプレミスベースのレガシーアプリケーションでもいったんクラウドに上げてしまえば、モダナイズするのも新しいサービスとつなぐのもスムーズに行えます。

「既存のVMware環境をそのまま移行」できるVMware on IBM Cloudを利用したオンプレミスとのハイブリッド環境の構成例

――一方で、クラウド移行後の安定運用を懸念する声もありますが。

三澤氏　2018年にIBM Cloudでは大きな投資をしています。3つのデータセンターで瞬時に切り替えられる仕組みを作ったのと同時に、関西にデータセンター開設を決定しました。止められないシステムを持つ企業の要望にお応えし、東京の地で並外れた高可用性を実現するアベイラビリティゾーンの提供を開始しました。IBM Cloudでは設計上、拠点間は毎秒1.2T（テラ）Bの広帯域ネットワーク複数本で接続され、リージョン間通信のレイテンシーは2ミリ秒以下に抑えています。さらに、東京リージョンの3つのデータセンターは、地盤の異なる関東近郊の3カ所に配置されています。クラウド自体でいかなる高可用性の要件にも応えられるように準備を整えてきました。

　

新野氏　僕が取材の中で面白いと思ったのは、クラウドに移行する前に、まずそのシステムを捨てられないか、捨てられないならSaaSに置き換えられないか、それがダメならPaaSにして楽にできないか――という具合に、とにかく持っていくものを減らすアプローチです。減らす過程でIT資産の棚卸しを行い、できるだけ柔軟性を保った形でクラウドに持っていくのがいい、という話を聞いて説得力があると思いました。

――棚卸しをしてどれを持っていくかを決めるのは難しそうですね。

新野氏　はい。エンジニアが決めるのではなく、やっぱり経営や現場（LoB）の人たちと話をして調整していかなければなりません。時にはパートナーの力を借りたり、コミュニティーの知恵や事例を参考にしたりと、いろんなアプローチをとらないといけないでしょう。現実的には、ベンダーでもパートナーでもいいので、クラウドでうまくいく方法論や実績を持った第三者のアドバイスを聞きながら進めるのが、一番効果があるのではないでしょうか。

三澤氏　もう一つ、クラウド移行に当たって気を付けなければいけないのは組織とスキルセットの話です。クラウドにひも付いている考え方はDevOpsです。一般的には、開発と運用はまだ分かれていると思います。そのため、オンプレミスの構造を保ったままクラウドに上げると、クラウドはDevOpsのアーキテクチャに基づいている一方で、お客さまの組織は開発と運用が完全に分かれたままで、組織が付いていきません。ですから、組織構造とその人員のスキルセットをどう変えるのかという課題にも取り組まないとクラウド移行はうまくいかないでしょう。それがオンプレミスのSoRシステムがクラウドに向かない原因でもあります。

　まず棚卸しをしましょう。そしてSoRのように変える必要がないものは「Just Lift」でひとまずリフトし、その後で「組織をどうするか」「上げたものをどうモダナイズするか」を検討するというのが、まっとうなクラウド化だと思います。DXを実現するにはクラウドのテクノロジーを使うことになりますが、その前提になる組織論となると簡単にはいかないでしょう。

新野氏　参考になるか分かりませんが、クラウドに移行してサブスクリプションで課金されるようになった結果、これまで原価に鈍感だったIT部門が、毎月どれだけ使ったかを把握し、「ここを最適化すれば、もっとコストが減らないだろうか」といった具合に事業部門とコミュニケーションをとるようになったケースがあります。クラウドのサブスクリプションモデルが、コスト意識を持って事業を変革する良い材料になるケースがあります。

ロックインを避けつつ崖を乗り越えるためのポイントは？

――リフトにはどんな要件が必要でしょうか。

三澤氏　最近ではリフト＆シフトに代えて、「Migrate、Modernize、Build、Manage」という言葉で表現することが増えています。既存の環境を移行し、モダナイズし、必要に応じて新しいものをビルドし、全体をマネージしていくわけですが、クラウドネイティブのスタンダードは間違いなくコンテナコンピューティングになると考えています。なぜなら可搬性があり、高速で、しかも多くの人が使っているオープンスタンダードテクノロジーだからです。

　一番多いパターンは、オンプレミスのSoRアプリケーションをVMwareを使ってIBM Cloudにそのままリフトし、リフトしたものをSoEとつないでいき、そしてリフトしたアプリケーションを徐々にモダナイズしていくというものでしょう。大きなSoRシステム全体をクラウドネイティブに書き換えていくのはハードルが高いでしょうが、例えば、アプリケーションサーバだけをコンテナにしてみるだけでも高速化することができます。こういったところからコンテナコンピューティングにチャレンジしていくのもいいかと思います。

新野氏　僕がお勧めするのは、できるだけマネージドサービスを活用することです。上物のアーキテクチャはコンテナでもマイクロサービスでも仮想マシンでも何でもいいですが、マネージドサービスを活用することで、運用エンジニアが24時間対応する緊張感から解放され、運用そのものの質も上がるでしょう。うまく活用すれば、クラウドならではのメリットを実感できる環境を作れるのではないでしょうか。

三澤氏　現在のクラウド上のマネージドサービス、先ほど申し上げたベンダーロックインの懸念は残ると思います。マネージドサービスやPaaSはまだブラックボックスで、作った資産はその上でしか動きません。Kubernetesやコンテナといったオープンスタンダードテクノロジーが普及し、これからの1年でそこに新たな選択肢を届けられる可能性があると思っています。IBMがRed Hat買収を発表した理由の一つも、そこにあります。

　また、Kubernetesにはアプリケーションプラットフォームとしての側面もあります。企業アプリケーションをKubernetes上で作り、企業で利用できるようにするには、ログやモニタリング、課金管理といった非機能要件の実装も非常に重要です。IBM Cloud Privateでは、Kubernetesによる共通の管理機能と従来ミドルウェアが独自に実装していた非機能要件を標準化して、一つのセットとして充実させて提供しています。さらにパブリッククラウドからは、マネージド Kubernetesサービス（IBM Cloud Kubernetes Service）を提供しており、コンテナ実行環境の運用管理の煩雑さを隠蔽（いんぺい）しながら企業アプリケーションをハイブリッドまたはマルチなクラウド環境で実行できるようにしています。

――マネージドサービスによって、運用管理の在り方も変わるでしょうか。

新野氏　運用管理者にとっては、自身の持つノウハウを生かし、どうしたら落ちにくいシステムを作れるか、落ちたらすぐ把握し復旧できるシステムを作れるかといった、システム設計やレビューが大切になると思います。最近、「NoOps」というキーワードを聞くようになりました。たとえ落ちても0.1秒で上げ直せば、落ちていないのと同じ、という考え方です。そのためには素早く立ち上がるコンテナ技術がすごく大事になりますし、時には開発チームの中に入っていって提案するのも大事な仕事になるでしょう。先進的な企業の中にはそうした取り組みを始めているところもあります。

三澤氏　勘定系のように絶対に落ちてはいけないシステムと、何かが落ちてもサービスが止まらなければいいシステムの2つが存在しています。DXは後者のシステムです。絶対に落ちてはいけない仕組みと、落ちてもいいけれどサービスが止まらない仕組み、この2つのパターンをどう定義付けし、マネージしていくかを考えなければいけません。まだそれに気付いていないCIO（最高情報責任者）や企業も多いですが、それを僕らのようなベンダーがちゃんとリードし、本質を理解してもらえるようにしないといけないと思います。

新野氏　今おっしゃった「リード」という言葉が象徴的ですよね。これはクラウドベンダー、ユーザーに加えて、パートナーやエコシステムがそろってはじめて解決に近づける性質のものだと思います。クラウドは全部入りの技術ですから、単独の組織でまかなえるはずがない。クラウドベンダーにリードしてもらいながらエコシステムと連携しつつ、自社のビジネスをより良い状態に近づけていく努力をする。そのためには、うまく外部と協力していくことが大事になります。技術責任者や経営者は、そのことを理解しておくことが重要ではないでしょうか。

三澤氏　オープンスタンダードテクノロジーの普及により、少し前では考えられなかったハイブリッドクラウドやマルチクラウドは現実的なものになってきました。これが既存のシステムとクラウドとの崖を埋めてDXを成功させるための最適解だと思います。それを現実のものにしていくとともに、テクノロジーだけではなく、整理整頓や組織論といったさまざまな観点からDXのお手伝いをしていくのがIBMの役割だと考えています。