クラウド移行の失敗・成功を分かつもの～そもそも運用管理とは何か～：特集：百花繚乱。令和のクラウド移行（1）

クラウド移行は企業の“花”。雲の上で咲き乱れるのは、果たして「花」か「徒花」か――技術の進展を受け、大幅にハードルが下がったクラウド移行だが、多数の成功事例には、どのような共通点があるのだろうか。移行の鉄則を探る。

» 2019年07月05日 05時00分公開

[編集部,＠IT]

クラウドで成果を獲得する企業と、そうでない企業の「差」とは？

　およそ全てのビジネスをITが支え、ビジネスがテクノロジーの力を使った「体験価値の競争」に変容して久しい。ニーズの変化も早く、先を予測することが難しい中で、いち早くニーズを察知しビジネスに落とし込む「スピードと柔軟性」が、最大の差別化要素となっている。

　こうした中、必要なとき、必要なだけ使えるクラウドを進んで利用するクラウドファーストという概念はすっかり当たり前のものとなり、以前はSoE（Systems of Engagement）領域の新規アプリケーションの開発・運用基盤として使われることが多かったが、二年ほど前からSoR（Systems of Record）領域も含めた既存システムの移行先としての活用が急速に進んでいる。

　クラウド移行のハードルも大幅に下がった。以前は、例えば可用性を担保する仕組みをアプリケーション側で用意するなど、クラウド基盤に即した仕組みに改修する必要があったり、システムの特性やSLA（サービスレベル契約）などに応じてクラウドに移行すべきシステム、オンプレミスに残すべきシステムを慎重に仕分けする必要があったりと、それなりの準備が必要だった。

　しかし近年は、既存のVMware vSphere環境をそのままクラウドに移行できるパブリックIaaSが複数登場している他、既存システムを移行した上で段階的にクラウドネイティブな仕組みに作り替える「リフト＆シフト」のアプローチも浸透しつつある。移行の課題として頻繁に挙げられていた「セキュリティが心配」という誤解も一時よりは払しょくされた他、「ネットワークの遅延」という懸念についてもサービスプロバイダー側で解決するなど、技術的なハードルはかなり解消された。

　だが、そうした状況にあっても、クラウドを使いこなし成果を上げている企業と、成果を出せていない企業に二極化する傾向は数年前から変わっていない。＠IT読者調査に限らず、他社の調査を見ても、ほぼ同じ傾向が読み取れる。むしろ、前者と後者の差は年々拡大しつつあるように見受けられる。

移行のハードルが下がっても、嫌でも気付かされる従来型スタンスの問題点

　では両者の違いとは何か？　クラウド特有のスキル・知識不足も挙げられるが、それ以前にクラウド活用に対するスタンスが違うことだろう。例えば、「クラウドは攻めの活用に使うものであり、コスト削減の手段ではない」と言われ続けているが、これは決して“コスト削減というビジネス目的”を否定するものではない。実際に、多くの企業が目的として「コスト削減」を挙げている。だが失敗する企業と成功する企業には大きな違いがある。

　象徴的な例が、移行しただけでプロジェクトを終えてしまうパターンだ。確かに移行すればハードウェアコストは削減できる。だが、IT運用で最もコストがかかっているのは人件費だ。運用コストを削減するためには、運用プロセスを棚卸しして、無駄な作業・プロセスを見極め、人がやるべきこと／システムに任せるべきことを仕分けた上で自動化を取り入れるなど、運用設計そのものを見直す必要がある。場合によっては、システムの構成・設計そのものを見直す必要もある。「そのまま」移行できるようになったとはいえ、オンプレミスと全く同じ運用をしていては、スピード、コストといったクラウドならではのメリットは限定的となる。

　オンプレミスの慣習を引きずってしまうパターンも挙げられる。例えば、全てのシステムに高度なSLAや特殊な要件を求めたりすればコスト増に直結してしまう。基本的に、パブリッククラウドは標準化されたサービスだ。システムの重要度に応じて求めるSLAを見極め、それに応じて利用するパブリッククラウドを使い分けることが求められる。従来のように自社に合わせたカスタマイズを求めれば、クラウドではなく、アウトソースやマネージドサービスに近づき、それだけコストもかさんでしまう。

　すぐ利用開始できる点にも注意が必要だ。利用しやすいだけに、全体観がないまま場当たり的にシステムを構築・拡張した結果、システムが複雑化し、無駄なコストがかかる、問題原因の特定に時間がかかる、システムがサイロ化するなど、オンプレミスの仮想環境と同じ問題が起こり得る。例えば、クラウドストレージの容量を場当たり的に拡張した結果、オンプレミス側にデータを取り出す際に転送料金がかさんでしまう、といったことなどは全体観がない故の分かりやすい失敗例の一つだ。

NoOps時代、運用管理とは何か。中堅以上の運用管理者は何をすべきなのか

　以上のような傾向から大きく2つのことがうかがえる。1つは、「クラウド利用に対する企業としてのビジネス目的」が明確ではない、もしくはIT部門に浸透していないことだ。移行そのものが目的化してしまい、それ以降どう使いこなすかが視野に入っていない。これは移行した際のシステム全体のアーキテクチャやその後のロードマップを考えず、個別最適に陥ってしまう問題にもつながる。

　もう1つは、クラウド利用に対する半ば受動的なスタンスだ。セルフサービスを軸とするパブリッククラウドは、従来のようにベンダーやパートナーSI（システムインテグレーター）に要件を丸投げし、RFP（提案依頼書）を書いてもらうようなスタンスではメリットを享受しにくい。ビジネス目的を達成するためにはインフラに何を求めればよいのか、どうすればクラウドのメリットを引き出せるのかなどを、主体的に考えなければ使いこなすことは難しい。

　そうしたスタンスが必要なのは、クラウド利用に限らないことは言うまでもないだろう。2025年に保守サポート切れが迫った「SAP ERP」についても同じことが指摘されている。「SAP S/4 HANA」に乗り換えるなら、今度こそ本当に必要なライセンスを見極め、丸投げによるコスト増を避けながらメリットを獲得しなければならない。

　経済産業省が2018年に発表した「DXレポート」で主張しているポイントの一つも、インフラの可視化と主体的なコントロールにある。市場変化が激しい中では、ビジネスとそれを支えるインフラを状況に応じて変えていかなければならない。（ベンダー「マネジメント」ではなく）ベンダー管理が中心で、中身がブラックボックスのままでは到底そうしたビジネスの下支えはできない。今のタイミングは、ITへの取り組み方を切り替える大きなチャンスともいえるだろう。

　そしてこのことが、運用管理者に重要かつ切実な課題を突き付けているのは周知の通りだ。運用自動化が進む中、運用管理者の間では「自身の立場が脅かされるのでは」といった見方も広がる一方で、ビジネスに近い開発側には社会全体からスポットライトが当てられている。事実、コンテナやコンテナ管理、サーバレス、マイクロサービスアーキテクチャなどを取り入れ成果を収めた事例は華々しいものばかりだ。だが同時に、そうした事例には必ずインフラ側の工夫が隠されている。

　そこに通底するのは、「“ビジネス価値”を届けるまでのリードタイムをいかに短縮するか」という考え方だ。システムが社外向けであれ社内向けであれ、ビジネス部門や開発者の観点も持ち、「事業部門、開発者、エンドユーザーの期待にスピーディーに応える／応えられる仕組みを整備する」――すなわち「ビジネス展開を支える仕組みの設計・開発」こそが、現時点ですでに運用管理者の重要な役割になっているといえるのではないだろうか。

　その意味では、Web系ではない一般的な企業のIT部門においても、SRE（Site Reliability Engineer）の観点を持つことが重要なポイントになっていくはずだ。ちなみに、過去に取材したGoogle SREディレクターのトッド・アンダーウッド（Todd Underwood）氏は次のように語っている。

全てに対して「No」としか言わないような、純粋に消極的なエンジニアは役に立ちません。反対に、常に全てのデータセンターが機能し、ネットワークに帯域があり、ディスクスペースに余裕があるという前提で行動するような、楽観的なエンジニアも好ましくありません。

Googleの膨大な規模を踏まえると、他社のような割合で運用管理に人員を割くことはできません。そこで、私たちはプロダクトエンジニアやSREチームに自動化システムを作り出す権限を与えることで、一般的な企業よりも運用業務の量を減らす方法を選択したのです。

私たちは運用スタッフの数を減らしているのではなく、将来的に運用スタッフが無制限に増え続ける状況に歯止めをかけているわけです。

多くの運用管理スタッフは、“繰り返しではない、取り組みがいのある業務”に大きな関心を持っています。

◇

　本特集では次回以降、「Amazon Web Services」「Microsoft Azure」「Google Cloud Platform」などさまざまな移行事例を紹介していくが、「主体的に考える」とは具体的にはどういうことなのか、多数発見できるはずだ。クラウド先行企業と、大半を占めるこれからの企業との違いはどこにあり、何を目指すべきなのか、ぜひ参考にしてほしい。