Amazon Web Services ブログ

エンタープライズ企業で全社クラウド化を目指す実践ガイド ~ リソース編

一般的なエンタープライズ企業は本部と複数の事業部で構成され、事業部ごとに異なるビジネスモデルを持っているケースが多いのではないでしょうか。そのため各事業部ごとに開発部や営業部などが機能しており、独立性が高いといえます。近年、多くの企業ではクラウド化による価値を実感し、さらに活用を推進するためクラウドファースト戦略をたて、全社システムのクラウド移行を決断するケースが増えてきました。しかし一方で、そのような事業部側の独立性の高さから、全社移行の検討は進めるものの、各事業部側ではクラウド移行に対して消極的でなかなか実際の移行が進まない、あるいは検討の結果 現行システムを維持する判断に至ってしまう、といったことも頻繁に発生しているようです。

こうした背景には、全社クラウド移行で得られるメリットが必ずしも各部署のメリットに繋がるとは限らない、若しくはテクニカルな課題に対する対処法が明確でない、といった理由により積極的にクラウド移行に取り組めない、といったことがあるようです。今回はこのようなエンタープライズ企業のお客さまで、全社移行をご検討されている方、若しくは既に決断したが実際の推進上で悩まれている方を対象に、事業部側でよく見られる課題と解決策をAWSの関連サービス、フレームワーク等を交えながらお話していきたいと思います。

課題やその原因は多様であるため、ここでは以下の図のように「ストラテジー」「リソース」「プロセス」「組織」4 つの分類にわけて、ご説明いたします。前回のブログではストラテジー編として事業部側でクラウド移行を推進するための戦略的な課題と解決策についてお話してきました。今回は第 2 弾として「リソース」にスポットを当てたいと思います。

全社移行での様々な課題とその対処法について

「リソース編」

クラウド移行による価値を追及することの必要性に関しては前回ブログ (ストラテジー編) でもお話してきました。想定される価値の中には、例えば資産管理から解放されることによる運用効率化や可用性の向上、コンピュータリソースの最適化など即効性が高いものも多く、移行の時期が遅れると、それだけそれら効果を得る機会損失につながってしまいます。したがって、企業として移行をすすめる決断に至った場合には、その効果を全社で早期に享受できるよう、人材・予算・スキル・システム情報など必要なリソースを素早く確保し、実行に移すことがとても重要だと考えます。今回のリソース編では、そういった必要なリソースを確保する際にありがちな課題を 3 つを取り上げて、それらの解決策についてお話していきます。

1.事業部側にクラウド移行の知識を持ったエンジニアがいない

クラウド移行を行うには、まずは移行計画を立てる必要があり、そのためには当然のことながらクラウド移行の知識を有する人材が必要です。しかし、そうした人材を事業部側で育てることは、通常の業務を考えると簡単なことではないと思います。そこで、全社で移行を推進する際には組織横断型のクラウド推進チームとして Central Cloud of Excellence (CCoE) の編成が望まれます。CCoE にはクラウド移行に関するナレッジが集約されるため、各事業部の移行を支援する存在として機能することができます。さらにこうした CCoE に事業部側からもメンバーをアサインし、事業部側のビジネスを理解した人材が基礎的クラウド知識を習得、CCoE の力を借りながら移行計画を立てていく、といったケースもめずらしくなくなってきました。AWS が考える CCoE の環境条件に関してはこちらのブログも参考にしてください。

移行計画が立案できれば、次は実際の移行作業を進めていきます。社内で十分な人材確保が難しい場合には、SI パートナーと協力し移行を推進することになると思います。その際、例えば現行オンプレの運用をお任せてしているSI パートナーに移行をお願いしたくても、クラウド移行に関する知識を十分に持ち合わせていない、といったケースも考えられます。こうした場合の対処法として、基礎的なトレーニングを受講頂く事も 1 つですが、本格的な移行に先立って計画される検証や PoC の実行を通して知識、経験を獲得いただく、といったアプローチも可能であると考えます。クラウド環境では、必要な環境をイニシャルコストを抑えながら、すぐに構築できる、また不要になればすぐに廃棄できるメリットがあります。また再構築も容易であることから、多くの下準備や調整、エンジニアの確保に時間を費やすよりも、必要な環境を素早く構築する、そして実際に移行を進める中でトライアルアンドエラーを繰返し感覚をつかむ、といった進め方の方がより効率的ではないでしょうか。失敗を許容し、原因を明確化して対策をとる、といったアプローチを想定することで、プロジェクト成功への近道をたどることができると考えます。また失敗原因の明確化を CCoE と密に連携しながら活動することで、CCoE 自体のノウハウ強化にもつながります。そこで獲得したノウハウや知見は、他事業部での、よりスムーズな移行推進に役立てることができるでしょう。

2.事業部側にクラウド移行の予算がない

全体の移行方針は固まったものの、特に事業部側では他の事業に直結するような大規模なイベントやアクティビティがあり、移行プロジェクトには予算がつきづらい、若しくは一旦予算がついても業績不振などによる見直しのため、来期まで確保が難しくなってしまう、といったケースも考えられます。こうした場合にはどのような対応がとれるでしょうか? 例えば予算がつくまでの間に、インベントリ情報収取や各種ご利用中のライセンスの確認・手配、移行方式検討といったシステム毎に発生する調整ごとや検討事項など、想定される事前タスクを可能な限りすすめておく、というのも選択肢としては検討できると思います。実際に多くのコストが発生する移行期をより効率的に推進するための準備を固めておくことができます。しかし、昨今では移行作業自体も内製ですすめるお客様が増えてきているようです。各種移行向けのツールが充実してきたことで、移行作業自体のハードルが下がっている事が 1 つの要因として考えられます。

全ての対象を内製で移行する、というのはハードルが高くても、システム情報の分析をすすめ、特定された移行パス (移行戦略) をベースに難易度を特定し、移行の難易度が低いシステムは内製で前倒しですすめる、といったアプローチもとることができます。難易度の分析は、例えばシステム構成や OS、保守期限などから移行ツールで容易に移行が実現するシステムを難易度低として特定する、一方でシステム全体の再構築を必要とするものや、OS やミドルウェアの変更を伴う事で構成変更やアプリケーション改修など、手を加える必要があるシステムは難易度高に分類する、といったように一定の基準を決め、現状の内製スキルで実行できる対象と、SI パートナーに依頼が必要なものの線引きを行います。そうすることで、限られた予算の中でも、追加予算の確保状況を考慮しながら計画性をもって移行作業を進める事ができるのではないでしょうか。

内製で対応可能なシステムを先行して移行することで、早期にその効果を享受することが可能になります。また難易度の高いシステムでは、冒頭でもご説明した事前タスクも内製作業と並行して取り組んでおくことをおすすめします。それにより、いざ予算が確保できたタイミングで、無駄なくスピード感をもって移行が推進でき、機会損失を最小限に抑えながら、目指すべきゴールに近づく事ができます。

AWS では各種移行を内製で進めていただく為の支援として、移行パスをワークショップ型で特定するプログラムや、AWS Application Migration Service (MGN) など各種移行ツールのハンズオントレーニング、また実際の移行作業を AWS のエンジニアと一緒に経験頂くことができる体験型ワークショップ (EBA) などをご提供しています。各種ご支援の詳細に関しては、以下の参考ブログを参照下さい。

  • 移行パス (クラウド移行戦略) をワークショップで策定する [blog]
  • クラウド移行をサポートする利用可能なAWSサービス [blog]
  • アプリケーションのモダナイゼーションを加速するEBA [blog] ※モダナイゼーション体験を想定した内容です。

3.他に優先度の高い業務がありクラウド移行に人が割けない

クラウド移行自体は進めたいが、他に優先度の高い業務があり、すぐにはクラウド移行プロジェクトに人を割くことができない、といったケースもあると思います。前回のブログ 、ストラテジー編 でもお話ししましたが、移行の本来の目的とビジネス目線での効果が明白であり、十分な説得材料となり得れば、その時点で全体業務の優先度を再考することも現実的かもしれません。しかしそうはいっても、既に動いている業務やプロジェクトの優先度を大きく入れ替えることは、多くの関連組織を巻き込んだ調整が必要となる場合もあり、容易ではありません。

クラウド活用を考える上では「まず始めてみる」ということが重要です。このような場合の策としては、はじめから全システムを対象とした大きな移行プロジェクトを立ち上げるのではなく、クラウドの特徴を生かし、初期段階では小規模で始め、その実際の効果が明らかになった段階から徐々に規模を拡張していく、といったアプローチも検討できるのではないでしょうか。小規模であれば技術的な課題も限られますので、少ない工数で移行を進める事ができます。専任の担当者が確保できなくても、まずは他業務と兼任でも移行に着手し実績を得ることが大切です。担当者が現状十分なスキルを持ち合わせていない場合には、前項と一部内容が重複しますが、まずはクラウドの基礎知識を取得し、実際の検証や PoC を通して経験値を獲得していきましょう。クラウド移行がどのようなものであるか、一連の流れを体験することで、全体移行に対する具体的なイメージがつかめ、プロジェクト完遂に必要な工数見積もりにも役立てることができます。

また、移行作業を進めるフェーズでは、テクニカルな課題に目が行きがちですが、ある一定のクラウド運用期間を経たタイミングで稼働実績を振返ることもとても重要です。事前に明確化した移行の目的や効果、例えばコストダウンやシステム柔軟性の向上といった期待効果 (評価KPI) が実際に享受できているかを計測、分析・評価を行います。それによりビジネスに対するクラウド移行の有効性に現実感が増し、優先度の向上にもつなげることができるのではないでしょうか。

まとめ

今回のブログでは全社移行を進める際の「リソース」に視点をおいて、よくある課題と解決策についてお話してきました。クラウド移行を成功に導く為には必要なリソース (人・予算・スキル・システム情報) を必要なタイミングで確保することが大切ですが、それらリソースの適用量や粒度を見定めるためにも、まずは進めてみて体験することが重要ではないでしょうか。また実績を積むことで投資対効果が明らかとなれば、更に大規模に進めるためのリソース確保が容易になる、といった考え方もできると思います。クラウドを利用する価値を最大限、全社で享受できるよう、問題を許容する文化の醸成といった点においても意識いただくといいかもしれません。今回のブログの内容が少しでも参考になれば幸いです。

次回は「プロセス編」をお届けしますのでご期待ください。

カスタマーソリューションマネージメント統括本部
カスタマーソリューションマネージャー (CSM) 鈴木, 上原

参考リンク