【レポート】エンタープライズシステムのモダナイゼーション〜 成功の鍵は「組織」が握っている 〜(AWS-03) #AWSSummit
みなさんこんにちは、杉金です。
今回は 2022 年 5 月 25 - 26 日の 2 日間開催された AWS Summit Onlineのセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されておりますので、詳細が気になった方は是非そちらをチェックして下さい。
セッション概要
本セッションでは、 エンタープライズシステムをモダナイゼーションする意義と、 成功の 2 つのポイント「組織変革」 「クラウド推進組織」についてご説明します。 また、モダナイゼーションをご支援する体験型ワークショップ「Experience-Based Accleration(EBA)」を始めとするAWSご支援プログラムをご紹介します。
スピーカー
AWS マイグレーション&モダナイゼーション事業開発本部 シニアマイグレーションスペシャリスト 足立 慎也 氏
セッションレベル
ビジネス層向け
アジェンダ
- モダナイゼーションとは
- モダナイゼーション推進ポイント
- モダナイゼーションに向けたAWSご支援
レポート
1.モダナイゼーションとは
- モダナイゼーションとは何ぞや
- 既存のアプリケーションやインフラを変換して以下を実現するプロセス
- 新しいビジネス機能の実装
- イノベーションの加速
- 技術的負債の低減
- 実際のアクション
- コンテナやサーバーレスなどを活用してシステムを再構築(リファクタリング)
- 目指す部分としてはデジタルトランスフォーメーション
- 既存のアプリケーションやインフラを変換して以下を実現するプロセス
クラウド移行におけるモダナイゼーションの対象範囲
- 移行の最初のステップ:リホスト(リフト&シフト)
- モダナイゼーション(大きく以下の2パターンに分かれる)
- リプラットフォーム
- アプリケーション自体は変更しないがコンテナ化やマネージドサービスを活用
- リファクタリング
- オープンソース、サーバーレス、クラウドネイティブなどを使った作り替え
- リプラットフォーム
モダナイゼーションの効果
- VMC on AWS への移行や単純なリフト&シフトと比較するとモダナイゼーションは実現までの期間や費用がかかる
- それでもモダナイゼーションを行う意義としてはその効果が挙げられる
- モダナイゼーションの効果
- リプラットフォーム
- 直接コストの削減
- 運用のオーバーヘッド(IT運用にかかる人の生産性の向上)
- セキュリティ
- 柔軟性向上
- リファクタリング
- ライセンスコストの削減
- スケール
- 俊敏性
- リプラットフォーム
- コストの部分はモダナイゼーションをするワンタイムコストも加味してビジネスケースを図る必要がある
- モダナイゼーションをして常にROIが見込めるとは限らない
- すべてのシステムをモダナイゼーションする必要はない
- 効果を享受したい領域、例えば顧客接点のシステムなどについてはモダナイゼーションを推進すべき
モダナイゼーションの事例
- ニュースの配信で知られるトムソン・ロイター社の事例
- ニュースが流れるとトラフィックが数倍になる
- トラフィックのイベントを処理してデータの分析を行うという要件
- 対応としてAWSのサーバーレス コンピューティングを活用
- イベントの取り込み
- ストリーミングデータ処理
- 具体的にはELBやAmazon Kinesis Streams、AWS Labmdaなどを活用して構築
- 対応としてAWSのサーバーレス コンピューティングを活用
- 効果として200%生産性向上
- 秒間2000件のイベント処理の目標が4000件処理できるようになった
- データ収集の開始後1つのイベントも喪失せずに高スループットと堅牢性を両方実現
AWS Migration Hub Refactor Spaces
- AWSでもモダナイゼーションの新サービスを発表
- AWS Migration Hub Refactor Spaces
- 2022年2月から一般提供開始
- Strangler Fig(ストラングラーフィグ)と呼ばれる、本番稼働しながら段階的に作り替えを行う手法
- より簡単に実現することを目的としており、リファクタリングの期間は通常数ヶ月以上かかるケースが多いが数日に短縮することも可能
- AWS Migration Hub Refactor Spaces
2.モダナイゼーション推進のポイント
- 新規のクラウド利用と既存資産の移行、時間軸とビジネス価値をグラフで表現
- 既存IT資産のマイグレーションやモダナイゼーションは簡単ではない
- 足踏みのポイントが2つある
- 1つ目の足踏みポイントは初期段階
- 初期段階でクラウド導入のプロジェクトそのものが予定通り完了しないケース
- 人的なリソースの不足、プロジェクトマネジメント能力、ナレッジ不足など様々な要因がある
- 初期段階でクラウド導入のプロジェクトそのものが予定通り完了しないケース
- 2つ目の足踏みポイント
- クラウド化は実現したものの期待したほどのコスト低減やスタッフの生産性が改善されなかった
- 既存のインフラをそのままクラウドに持っていったが、それを使いこなす組織や業務プロセスが従来のまま
- なかなか本来のクラウドを使い倒せていない、本当のクラウドの効果を享受しきれていないケースがある
- 既存のインフラをそのままクラウドに持っていったが、それを使いこなす組織や業務プロセスが従来のまま
- クラウド化は実現したものの期待したほどのコスト低減やスタッフの生産性が改善されなかった
- 1つ目の足踏みポイントは初期段階
マイグレーション&モダナイゼーションの阻害要因
- AWSでは世界中のお客様を支援してきた実績から、クラウド推進の主な阻害要因というのをヒアリング等を通じて特定
- 課題に対して解決策をマッピング
- 課題の半数以上が組織に起因
- 例えば...
- ガバナンスが機能せず、セキュリティ面でのリスクが散在する
- 部門横断の取り組みというのが組織の壁によってクラウド化が進まない
- 運用フェーズでの改善が行われずクラウド化した、作りっぱなしになっている状態
- 例えば...
- モダナイゼーションはインフラに閉じた話ではない、組織構造の見直し
- 組織のモダナイゼーションや推進組織を起因としたモダナイゼーション展開の2つが大きなポイントになる
デジタルトランスフォーメーションで目指す姿
- DXとはテクノロジーを使うだけではなくテクノロジーを活用して高速に高頻度に仮説と検証を回していき、意思決定を早める
- その結果、顧客価値を最大化していくのがDX
- これを実現するにはマイクロサービスや疎結合などのアーキテクチャの変革だけでなく、機能横断的にスピード感を持って動くような組織、オペレーションの変革も必要
- 組織の変革とアーキテクチャの変革を両輪として機能していくことで初めてDXが実現できる
組織・アーキテクチャの変化が事業変革に寄与する
- 従来型とクラウドネイティブ型
- 従来型
- ユーザーの声をIT企画で受け取りそこから設計開発へ進めていく
- 別々のチームが担うことが一般的(サイロ型、縦割り型)
- 大規模なシステムを構築する上では機能を細分化することで効率的に進められる利点がある
- 弊害としては縦割りであるがゆえに
- 情報連携のスピード低下
- 顧客やユーザーの声を反映しづらい
- クラウドネイティブ型
- 小規模のプロダクトチーム、企画から設計、開発、運用まで担当するため、求められるスキルが非常に広範囲
- プロダクト開発自体のスピードアップが見込める
- ユーザーのフィードバックを改善に活かせる
- 従来型
プロジェクトvsプロダクト
- ITプロジェクトの進め方の違い
- ウォーターフォールとアジャイル
- ウォーターフォール
- 定義されたスコープを予算内、期限内にデリバリーすることに主眼が置かれる
- ユーザーの要件を要件定義で確定し、設計・開発と順を追って進めていく。その後に単体テスト、結合テストと徐々に検証の範囲を広げていくことで障害を徐々に除去していく
- 一般的にはプロジェクト期間が長くなる(数ヶ月、数年)
- ユーザー視点では、要件定義をした後に実際に出来上がったものを見るのがテストの最終段階(ユーザー受け入れテスト)になるため、想定と違ったというギャップが発生するリスクがある
- アジャイル
- 小さく産んで大きく育てるというアプローチ
- 開発と改善を繰り返しながら(イテレーション)、ブラッシュアップを図っていく
- ユーザーとのギャップを最小化して、認識齟齬は小さくなる
- その後のシステム改修や改善も結果的に速くなる
- ユーザーとのギャップを最小化して、認識齟齬は小さくなる
- ウォーターフォールとアジャイルどちらが優れているということではなく、両者にメリット/デメリットがある。
- スピード感や柔軟性を重視するシステム:アジャイル向き
組織のモダナイゼーション事例:Amazon
- Amazonはインターネットの書店から始まり、お客様の声をもとに様々なサービスを世に生み出してきた
- 例えば
- Amazon Robotics:人工知能や機械学習を用いて、配送センターの効率化や自動化を実現するサービス
- Amazon Prime Air:GPS情報をもとに荷物をドローンで配達する
- Amazon Alexa:音声認識
- Amazon Go:レジなしコンビニ
- 例えば
- Amazonのイノベーションを支える仕組みとは
- イノベーションを支える仕組みとして、カルチャー、メカニズム、アーキテクチャ、組織の4つの要素がある
- 4つの要素を掛け合わせることでイノベーションを起こせると考えている
- 各要素を少し紹介
- カルチャー
- 地球上でお客様をもっとも大切にするという理念
- 社員全員がリーダーであるという考えに基づくOLPと呼ばれる規範
- メカニズム
- Working Backwardsと呼ばれるお客様起点で物事を考えていく逆からの思考プロセス
- アーキテクチャ
- マイクロサービスと疎結合が大原則で、それにより急激な成長や変化に対応していく
- 組織
- 2 Pizza teamに代表されるような小さくて権限委譲されたチーム
- カルチャー
- この例からもDXはテクニカルな部分だけではなく組織やメカニズムといった点がポイント
コンウェイの法則
- システム設計は組織構造を反映したものになる
- 例えばモノリシックな組織、いわゆる一枚岩の大きな組織においては、それを使うシステムもモノリシック寄りになる
- Amazonはマイクロサービスパターンで、組織が2Pizzaと呼ばれる少人数で権限委譲されるチームが複数あり、アーキテクチャもチームごとに細分化あれたマイクロサービス(小さな単位で疎結合するシステム構成)
- この法則は逆も言えて、最適なアーキテクチャに合わせて組織をデザインする、というアプローチもある。
クラウド推進組織(CCoE)
- 推進組織の重要性
- 組織やメカニズムの変革を定着させることも必要
- それを担うのもクラウド推進組織の役割
- 組織やメカニズムの変革を定着させることも必要
- クラウド推進組織はCCoE(Cloud Center of Excellence)とも呼ばれる
- CCoEの立ち位置
- 社内のエグゼクティブから組織設立・活動のお墨付きをもらう
- クラウド導入現場に対して知見や環境を提供
- クラウド導入の初期段階ではクラウド導入チームがCCoEになることもあるが、CCoEは啓蒙活動や推進を担う役割もある。最終的には現場どっぷりではなく、現場のよき理解者として全社のクラウド化推進や人材育成、社内のステークホルダとの連携を担っていく
- CCoEの立ち上げ方
- 立ち上げ方は色々あるが、クラウド移行と並行して立ち上げることが一般的
- まずはスポンサーからCCoE設置の承認をもらい、できるだけ様々な経歴のメンバーで設立する
- クラウド推進はインフラに閉じた話ではなくアプリチームやセキュリティチーム、運用保守チームにも関連があり、社内の各ステークホルダーとの調整が必須となるため、様々なバックグラウンドを持ったチームが望ましい
- CCoEの中核となるメンバーは内製化もかねて専任が望ましい
- 難しい場合は兼業であったり、パートナー企業に入ってもらい徐々にスキトラをしながら大きくしていく方法もある
- CCoE組織の拡張
- 移行が進むとCCoEも拡大していく
- 最終的には各移行チームやインフラ組織もCCoEの一員となって全社展開やクラウドリフト化の次のモダナイゼーションを促進していく
- CCoEの立ち位置
クラウド推進組織の事例(ファミリーマート社)
- コストや人的リソースの課題解決としてAWSをメインとしたクラウド化を決めた
- 推進組織も立ち上げ
- 最初は担当者一人でスタート
- リソースやナレッジの他のために以下のメンバーとチームを組閣
- AWSのコンサルティングサービス プロフェッショナルサービスのメンバー
- メインベンダーのメンバー
- チーム結成後にまずは社内の方針説明、ガイドラインから着手して徐々に活動を広げていった
- 推進組織も立ち上げ
3.モダナイゼーションに向けたAWS支援
- これまで説明したモダナイゼーションのポイントである、組織変革とクラウド推進組織の設立についてAWSでどのような支援ができるかを紹介
- モダナイゼーションに向けた課題と解決策
- 組織構造の見直し、実験のトライアルユース(まずはやってみて成功体験を得る)
- 「EBA(体験型ワークショップ)」で支援
- クラウド推進組織の展開
- 「CCoE立ち上げ推進プログラム」で支援
- 組織構造の見直し、実験のトライアルユース(まずはやってみて成功体験を得る)
- 上記2つの支援プログラムは「ITXパッケージ2.0」と呼ばれるマイグレーションやモダナイゼーションのトータル支援プログラムに包含されている
- モダナイゼーションに向けた課題と解決策
EBAとは(体験型ワークショップとは)
- EBA(Experience Based Acceleration)
- ハンズオンやアジャイルのワークショップを通じて能力を高め、マイグレーションやモダナイゼーションを加速するという変革手法
- 体験型とあるように実際にアプリケーションのモダナイゼーションやアジャイルな働き方を経験する
- 組織間の壁を打破
- 迅速な動きを習慣で身につける
- ノウハウを蓄積
- DXは組織とアーキテクチャの両輪が必要。EBAではどこを支援するか
- 実際にアプリケーションのモダナイゼーションを体験してリファクタリングの実力を蓄積するアーキテクチャ面の支援
- 様々なクラウド移行を繰り返し実施して、仮説検証を繰り返しやっていくサイクルを実体験
- 様々なステータクホルダに参加してもらいワークショップを通じて組織のモダナイゼーションについても実体験をもとに知見を蓄積することができる
- EBAのポイントとしては、あくまでテクニカルなワークショップだけではなく組織変革のきっかけを体験できるワークショップでもある
- EBAには様々なワークショップの型がある
- 型をパーティーと呼ぶ
- プラットフォームパーティー:クラウド基盤構築
- マイグレーションパーティー:アプリケーションのクラウド移行
- モダナイゼーションパーティー:アプリケーションモダナイゼーション
- ポートフォリオパーティー:移行全体計画費用効果策定
- ピープルパーティー:クラウドネイティブ対応組織への変革
- 型をパーティーと呼ぶ
- 本セッションで紹介したのはモダナイゼーションパーティーとピープルパーティーでその他のパーティーも活用できる
- まずはクラウド化の第一歩として経験を蓄積したいという観点ではプラットフォームパーティーでランディングゾーンを作成
- 実際にアプリケーションをクラウドに移行していくマイグレーションパーティー
- 現在地点に応じたワークショップが利用可能
クラウド推進組織(CCoE)立ち上げ支援
- クラウド推進組織関連では2つの支援プログラムがある
- 支援プログラム1つ目:AWSプロフェッショナルサービスによるCCoE組織の立ち上げ支援
- CCoE立ち上げに必要な4つのアプローチ
- アプローチに従って実際のセッションのリードやアウトプット作成を支援
- CCoE立ち上げに必要な4つのアプローチ
- 支援プログラム2つ目:AWS標準化ガイドライン作成支援
- AWSプロフェッショナルサービスコンサルティングチームによる提供
- 標準化のガイドラインは初期段階で作るべき。各部門でバラバラのルールでクラウドを立ち上げるとセキュリティ事故のリスクが高まる
- どうやってガイドラインを作成するか
- AWSが持つ過去の知見をもとにガイドラインの中ではアーキテクチャ、セキュリティ、運用など14の標準化検討項目がある
- 状況をヒアリングして検討項目から必要なものを選択してワークショップを通じてCCoEガイドラインを決定・更新する際に必要な考え方をディスカッションしていく
- ディスカッション後に実際のガイドライン作成に入る(作成そのものの支援も行っていく)
- AWSプロフェッショナルサービスコンサルティングチームによる提供
- 支援プログラム1つ目:AWSプロフェッショナルサービスによるCCoE組織の立ち上げ支援
ITXパッケージ2.0
- クラウド化を検討する評価段階から、移行決定後の準備段階、本番移行や運用定着、さらなるモダナイゼーション段階とクラウド移行すべてのフェーズで直面するであろう課題の解決プログラムが用意されている
- 2021年にリリース後、多くの活用があって2022年3月にオファリングを強化してバージョン2.0としてリリース
- ITXパッケージ2.0に興味を持った方はSummitのクラウド移行トータル支援プログラムのセッションを視聴するかAWS担当営業まで問い合わせ
感想
組織変革とクラウド推進組織の重要性が改めて理解できました。加えてEBAやITXパッケージをこんなに分かりやすく伝えていただけて感謝しかありません。セッション視聴前まで曖昧な理解だったのですが、セッションを通じて完全に理解できました。クラウド化やDXを進める意義ってなんだろうと疑問を持たれている方に是非おすすめしたいセッションです!