Microsoft 自身がどのように自社ワークロードを Azure へ移行していったのか。実は SAP ユーザーでもあるユーザーとしての Microsoft の経験とそこから見出した価値について、情報をとりまとめてご説明させていただきます。

1. *本資料の内容 (添付文書、リンク先などを含む) は de:code 2020 における公開日時点のものであり、予告なく変更される場合があります。
#decode20 #
Microsoft 自身の事例から学ぶ
クラウド移行の価値
A34
佐藤 壮一
日本マイクロソフト株式会社
Azure ビジネス本部 プロダクトマネージャー

2. 本セッションについて
対象者
課題
ゴール
• クラウド移行を検討中の方
• クラウド移行後、効果の最大化にお悩みの方
• “クラウドのコストメリット” がよく謳われるが、どうすればそのメリットが
最大化できるかがあまり知られていない
• Microsoft IT Showcase として公開されている情報からクラウド移
行の価値を最大化するためのヒントをお持ち帰りいただく

3. Who am I ? / スピーカー紹介

4. セッションアジェンダ
• クラウド移行の一般的な方法論
• Microsoft 自身の事例から学ぶ、クラウドのメリット最大化
のポイント

5. クラウドへの移行
どう進めるべきか？

6. SaaS で全て解決できる世界が理想（でも難しい）
オンプレミス IaaS PaaS SaaS
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
仮想化
データ
アプリ
ランタイム
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
仮想化
データ
アプリ
ランタイム
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
仮想化
データ
アプリ
ランタイム
ストレージ
サーバー
ネットワーク
OS
ミドルウエア
仮想化
データ
アプリ
ランタイムユ
ー
ザ
ー
管
理
ユ
ー
ザ
ー
管
理
ユ
ー
ザ
ー
管
理
ベ
ン
ダ
ー
管
理
ベ
ン
ダ
ー
管
理
ベ
ン
ダ
ー
管
理
仮想基盤
(VMware/Hyper-V)
Microsoft Azure
Office 365,
Dynamics CRM

7. まずは棚卸・カテゴライズから…

8. 3,500 以下の
アプリケーション

9. アプリケーション
• フローチャート
• アーキテクチャー
• データ モデル
• ビジネス ルール
• コード複雑性とドキュメン
ト
プラットフォーム
• アプリケーション インフラ
• テクノロジー スタック
• ハイブリッド コンポーネン
ト
ワークフローの維持とアップ
デート
ビジネス バリュー
• 事業機能サポート能力
• 既存技術サポート能力
• リスク レベル
• 技術の成熟度と脆弱性
コスト
• 維持コスト
• セキュリティ コスト
• アップデート コスト
ビジネス
• 事業機能
• 依存性
IT
• インフラ
• 技術
• データ資産
人・組織
• スキルとナレッジ
• 実行能力
Retire
Retain
Replace
Migrate
Modernize
Rebuild
New
アプリケーション ポートフォリオ評価

10. Cloud Adoption Framework for Azure (CAF)

11. Microsoft 自身の事例から
学びを探してみる

12. Microsoft 自身の事例？
https://www.microsoft.com/en-us/itshowcase

13. どの事例から学ぶか？

15. • プロジェクト開始時ではすべてがオンプレ上の物理
• まずは仮想化に着手
• 仮想化は進むも Azure 移行は当初は想定より進まず

17. • Azure Resource Manager の登場で
展開の自動化が加速
• 移行が一気に加速し最終的には想定
よりも早く進捗
• “クラウドの旨味を活かす” ことの重要性

18. Tight-Sizing – ピークに備えるのでは
なく、需要に応じて変動させる
Snoozing – 使わないときは起動し
ない
Right-Sizing – 将来ではなく今
必要なサイズを見積もる
ZzZ

19. Tight-Sizing – ピークに備えるのでは
なく、需要に応じて変動させる
システムサービスの需要とシステムの実際のサイズを同
期させる
多くの需要変動は予測可能である(四半期締めや
年度末など)
必要に応じてクイックにサイズ拡張が可能と認識する
常にコストをモニタリングし、コントロールする
(安全のために常にバッファを持つという) IT部門のカル
チャーを変革する
Snoozing – 使わないときは起動し
ない
使わない間、システムは「一時停止」させておける
サンドボックスや開発、テストシステムは常時起動の
必要はない
PowerShellを用いて、システムを起動停止できるよ
うにしておく
簡単なシステム起動停止のセルフサービスツールを提
供する
Right-Sizing – 将来ではなく今
必要なサイズを見積もる
ZzZ

20. Tight-Sizing – ピークに備えるのでは
なく、需要に応じて変動させる
Snoozing – 使わないときは起動し
ない
使わない間、システムは「一時停止」させておける
サンドボックスや開発、テストシステムは常時起動の
必要はない
PowerShellを用いて、システムを起動停止できるよ
うにしておく
簡単なシステム起動停止のセルフサービスツールを提
供する
Right-Sizing – 将来ではなく今
必要なサイズを見積もる
今必要なサイジングの見極めによる事前コストの抑制
クイックサイザー、稼働状況からのサイジングによる初期
サイズの決定
サイジング期間の短縮 – 数年後ではなく6ヶ月後に必
要なサイズを見積もる
まず単純にLift & Shiftするサイズを見積もる
後でサイズアップするのは容易だと認識する
オンデマンドインフラという考え方にIT部門のカルチャー、
マインドシフトを行う
ZzZ

21. Tight-Sizing – ピークに備えるのでは
なく、需要に応じて変動させる
システムサービスの需要とシステムの実際のサイズを同
期させる
多くの需要変動は予測可能である(四半期締めや
年度末など)
必要に応じてクイックにサイズ拡張が可能と認識する
常にコストをモニタリングし、コントロールする
(安全のために常にバッファを持つという) IT部門のカル
チャーを変革する
Snoozing – 使わないときは起動し
ない
Right-Sizing – 将来ではなく今
必要なサイズを見積もる
今必要なサイジングの見極めによる事前コストの抑制
クイックサイザー、稼働状況からのサイジングによる初期
サイズの決定
サイジング期間の短縮 – 数年後ではなく6ヶ月後に必
要なサイズを見積もる
まず単純にLift & Shiftするサイズを見積もる
後でサイズアップするのは容易だと認識する
オンデマンドインフラという考え方にIT部門のカルチャー、
マインドシフトを行う
ZzZ

22. Azure 移行による進化 – コスト最適化
Data Deletion – データ削除Data Archiving – アーカイブ Get creative – 工夫できるところを見つ
ける

23. Azure 上でのさらなる最適化…

24. マインドシフト
この事例から学べるポイント

25. Wrap-up | まとめ

26. IT Showcase SAP on Azure YouTube video
https://www.youtube.com/watch?v=SSYlrd-jCss
IT Showcase Library
Migration: https://www.microsoft.com/en-us/itshowcase/search?Text=Migration
SAP: https://www.microsoft.com/en-us/itshowcase/search?Text=sap
How Microsoft IT migrated its entire SAP landscape to Azure
https://info.microsoft.com/rs/157-GQE-382/images/Thur_1pm_SAPPHIRE%20Inbooth_Elke%20and%20Hans.pdf
関連コンテンツ

27. © 2018 Microsoft Corporation. All rights reserved.
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
© 2020 Microsoft Corporation. All rights reserved.
本情報の内容 (添付文書、リンク先などを含む) は、公開日時点のものであり、予告なく変更される場合があります。
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。