Contenu connexe
Similaire à クラウド検討の進め方 (20)
クラウド検討の進め方
- 1. クラウド検討の進め方
コシキ・バリューハブ株式会社
2011/06/20
http://www.koshikivaluehub.jp/ Copyright © 2006-2011 KOSHIKI ValueHub Corporation. All rights reserved. 無断複製、転載を禁ず
- 2. 1. クラウドの定義 #1. クラウドへの期待
『クラウド』の言葉の由来は、ネットワーク経由でのサービス提供です。今日『クラウド』が注目を浴びているのは、
① 災害対策として
② 『クラウド』の仕組みを利用することで、企業ＩＴ部門のミッションに対する効果が期待できる
『クラウド』とは 企業ＩＴ部門のミッション
ネットワーク上に存在するサーバが提供するサービスを、それらのサー No ミッション
バ群を意識することなしに利用できるというコンピューティング形態を
表す言葉です。 1 システムの安定稼働（災害時の早期業務復旧、継続）
2 顧客（利用者）満足度の向上
ネットワークを図示するのに雲状の絵を使うことが多いことからきた
表現です。 3 コストの適正化
雲の中にはハードウェアやソフトウェアの実体があるが、その中身は
見えない（気にしなくてよい）というイメージです。
『クラウド』への期待
災害への対応（ＢＣＰ）
顧客満足度：利便性向上への期待
コストの適正化への期待
1
- 3. 1. クラウドの定義 # 2. クラウドの特徴
『クラウド』のメリットとして、種々のキーワードが語られています。「システムの安定稼働（ＢＣＰとしての業務継続性の確保）」「顧客
満足度/利便性向上」「コストの適正化」という観点で整理すると、本質は以下の通りであると考えます。
あるサイトでのクラウド紹介文
Webブラウザさえ備えていれば、どんな端末も利用可能。
日本はもとより、海外からもアクセス可能。
システム構築に伴う初期費用の削減。
サービスを利用した分だけ支払う従量課金。
機器やソフトの更新作業や故障対応など、メンテナンスコストが丌要。
現状の規模に合わせた、無駄のないシステム利用が可能。
サービス利用者の急増など、システムの増減にもすばやく対応。 所有から利用への変化に伴うコスト適正化
サービスからネットワークを含めた、柔軟な構成を選択可能。
利用量に応じた合理的なコスト負担
アメリカ国立標準技術研究所 (NIST)による定義 機能追加、利用増減に迅速に対応できる
クラウドコンピューティングとは、コンフィグレーション可能な計算機資源（ネットワー 災害対策が施されたサービサー側インフラの利用
ク、サーバ、ストレージ、アプリケーション、サービスなど）の共有プールへの簡便で
オンデマンドなネットワーク経由でのアクセスを、最小限の管理手順もしくはサービ
ス提供者とのやりとりで迅速に供給することを可能にするモデルである。
このクラウドモデルは5つの特性、3つのサービスモデル、4つの配置モデルから構
成され、可用性を高めている。（特性、サービスモデル、配置モデルは補足資料
参照）
2
- 4. 1. クラウドの定義 #3. クラウドの定義
『クラウド』の定義はサービサー、ベンダにより様々に行われています。弊社では、前述のメリットを踏まえ「利用者視点に立ち」、
「本来の目的」を明確にする形で、『クラウド』を定義します。
『クラウド』：コストの適正化、利便性の向上を実現可能な以下の特徴を持つソリューション
4．利用量や機能の増減に、迅速に対応できるソリューション
3．利用者に対して、利用量に応じた費用体系をもつソリューション
2．利用量を測定することができるソリューション
1．ＩＴリソースの一部機能をネットワーク経由のサービス利用とすることでコストの適正化を実現で
きるソリューション
3
- 5. 1. クラウドの定義 #4. クラウドの形態
前述の「ＩＴリソースの一部機能をサービス利用する」について、そのサービス化範囲によって、『クラウド:』の形態を定義し
ます。
従来型システム利用形態 クラウド ＢＰＯ
自社運用 ハウジング IaaS PaaS SaaS
ＢＰＯ
自社資産を自社センターで運用 機器を預けて運用委託 （Infrastructure （Platform （Software
As a Service) As a Service) As a Service) （ﾋﾞｼﾞﾈｽ・ﾌﾟﾛｾｽ・
マシン資源をインターネット上の システム基盤をインターネット上の ソフトウェア機能をインターネット上の ｱｳﾄｿｰｼﾝｸﾞ）
「サービス」として利用 「サービス」として利用 「サービス」として利用
業務ロジック 業務ロジック 業務ロジック 業務ロジック 業務ロジック 業務ロジック
アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション
ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア
基本ソフトウェア 基本ソフトウェア 基本ソフトウェア 基本ソフトウェア 基本ソフトウェア 基本ソフトウェア
ハードウェア ハードウェア ハードウェア ハードウェア ハードウェア ハードウェア
データセンター データセンター データセンター データセンター データセンター データセンター
自社専用/他者との共用かで
プライベートクラウド/パブリッククラウドに分けられる。
自社資産 ｻｰﾋﾞｽ提供
4
- 6. 2. クラウド検討の進め方 #1 クラウド導入の目的（1)
アジアにおけるクラウドの導入目的を以下に示します。日本における主要なクラウド導入目的は「コスト削減」となっています。
他国おいては、主要目的として「戦略投資」（新規ビジネス立上げ時などのビジネスニーズに応じた柔軟な投資の実現）が
高くなっています。
出典：ヴイエムウェア社「クラウドコンピューティングに関する企業意識調査」2010/11/9(※アジアと対象とした調査）
5
- 7. 2. クラウド検討の進め方 #1 クラウド導入の目的(2)
日本における、クラウド導入目
的の詳細を左記に示します。
規模の大きな企業ではコスト
面だけではなく、クラウドの迅
速性も評価されています。
出典：日本情報システム・ユーザ協会「企業ＩＴ動向調査2010」 6
- 8. 2. クラウド検討の進め方 #2 理想と現実(1)
これまでの『アウトソーシング』と『クラウド』の違いを以下に整理しています。『クラウド』の特集や紹介記事等では、『アウトソー
シング』で発生した、いくつかの課題について、技術進歩やサービス内容の見直しにより解決されたと言われています。
『アウトソーシング』の課題 『クラウド』における解決策の課題
①コスト算出方法のブラックボックス化 (A)費用算出方法の提示
②運用費の高止まり傾向 (B)従量課金
(C) 技術の進歩による共有性の向上（シェアリングによる
③資産追加/拡張のコスト増加 低コスト化）
(D)仮想化技術の進歩による拡張性の確保
④ＩＴ資産の保全性（保守切れ対応が曖昧）
(E)仮想化技術によりＨＷリプレイスが容易
(Ｆ)アプリケーション基盤のサービス提供形態
⑤他ベンダへの移行が難しい 課題として残ったまま
⑥ＩＴ資産のブラックボックス化 サービス提供であるため、資産を意識しなくなる
7
- 9. 2. クラウド検討の進め方 #2 理想と現実(2)
各サービサーとも『クラウド』に力をいれ、各種サービスを提案しています。しかしながら、『クラウド』においても、これまでのアウト
ソーシングと同様の課題、およびクラウド特化の課題が存在します。
分類 課題 補足
利用者数やディスク容量以外の課金体系は
クラウド＝『利用量に応じた課金』のイメージが先行しているが、課金体系がユーザにとって適切な体
1 従量課金 まだまだ尐ない。利用者課金ではユーザ数に
系となっていない。
よってはコスト高となる。
利用量の変動にどんな時間間隔で対応できるかを見極めないと、ユーザの目的に合致しない恐れ
2 1ヶ月単位で変更可能など。
がある。
自社でHW,SWの稼働などをコントロールできないため、サービスレベルの合意が、まずます重要にな
3 サービスレベル
る。
4 運用 利用形態によって、運用や監視、保守の役割分担が曖昧になりやすい 例:IaasやPaaS時の障害切り分け
緊急対応が必要な場合に、サービサー側の対応、復旧作業が遅れる可能性がある。（自社でコント
5
ロールしている場合と比べ）
6 ＢｌａｃｋＢｏｘ化が進む（⇔サービス利用とのトレードオフ）
回線速度やＨＷ資産を共有する他利用者の
7 性能/機能 専用システムと比べ、レスポンスが低下する恐れがある
との負荷競合
専用システムと異なり、カスタマイズ可能範囲が制限されるため、現行業務の見直しが必要となる恐
8
れがある。
業務パッケージのＦＩＴ＆ＧＡＰ同様、
業務をクラウドサービスに合わせていく必要あり
汎用的なコンピュータ言語、ＭＷを利用していない場合、カスタマイズ対応できる技術者が丌足する
9
恐れがある。また、カスタマイズのために必要な情報も丌足がちとなりやすい。
クラウド化により特に顕在化する課題
8
- 10. 2. クラウド検討の進め方 #2 理想と現実(3)
分類 課題 補足
サーバを共有しているため１つの設定ミスで他
10 セキュリティ ＨＷ資産を共有するための設定ミスによる他ユーザへの情報漏洩
者に情報がもれる。
11 通信経路での漏洩、なりすましの恐れあり
12 セキュリティパッチの適用がサービサー任せとなる
13 新たな脅威に対する解決策の適用がサービサー任せになる
解約後に本当にデータが削除されているか証
14 サービス解約後のデータ削除が証明されていない/ユーザが確認できない
跡を出せるサービサーは尐ない
どこでもアクセスできるため、退職者が利用しや
15 インターネット経由のサービスでは、ＩＤ管理を厳密にしないと退職者が簡単にデータにアクセスできる
すい。
16 業務継続性 サービス終了により、業務ができなくなる恐れ有り サービサーの体力に影響される。
17 他のサービサーへ移行が難しい 移行ツール等の丌備
データセンタ設置国の法律に従うため、日本国の法律と異なる理由にて、情報が強制的に閲覧される
18 コンプライアンス データセンター立地の法律に従う。
可能性がある
19 ＩＴガバナンス 利用者が内部監査を行う場合に、必要な監査証跡をクラウド事業者が提供できない場合がある
9
- 11. 2. クラウド検討の進め方 #2 理想と現実(4)
前述の課題は、クラウドの提供形態によっても異なります。重要データを扱うなど重要な業務については、クラウド化への検討要
素が多くなり、おすすめしません。
分類 課題
クラウド＝『利用量に応じた課金』のイメージが先行しているが、課
1 従量課金 初期投資は抑えられても、利用条件によっては全ライフサイクルをみ
金体系がユーザにとって適切な体系となっていない。
利用量の変動にどんな時間間隔で対応できるかを見極めないと、 るとコスト高に
2
ユーザの目的に合致しない恐れがある。
自社でHW,SWの稼働などをコントロールできないため、サービスレ
3 サービスレベル 提供形態により、課題に差がある
ベルの合意が、まずます重要になる。
利用形態によって、運用や監視、保守の役割分担が曖昧になりや
4 運用 パブリック プライベート
すい
緊急対応が必要な場合に、サービサー側の対応、復旧作業が遅 ＩaaS PaaS SaaS ＩaaS PaaS SaaS
5
れる可能性がある。（自社でコントロールしている場合と比べ）
6 ＢｌａｃｋＢｏｘ化が進む（⇔サービス利用とのトレードオフ） やや やや やや
迅速性 速 速 最速
7 性能/機能 専用システムと比べ、レスポンスが低下する恐れがある 速 速 速
専用システムと異なり、カスタマイズ可能範囲が制限されるため、 サービスレベル合意
8 難 難 難 難 難 難
現行業務の見直しが必要となる恐れがある。 の難しさ
汎用的なコンピュータ言語、ＭＷを利用していない場合、カスタマ
9 イズ対応できる技術者が丌足する恐れがある。また、カスタマイズ 運用の難しさ やや やや
易 易 易 同
のために必要な情報も丌足がちとなりやすい。 （通常） 易 易
10 セキュリティ ＨＷ資産を共有するための設定ミスによる他ユーザへの情報漏洩 運用の難しさ やや やや
11 通信経路での漏洩、なりすましの恐れあり 難 難 最難 同
（緊急対応の早さ） 易 易
12 セキュリティパッチの適用がサービサー任せとなる
13 新たな脅威に対する解決策の適用がサービサー任せになる 性能確保の難しさ 難 難 最難 同 同 同
サービス解約後のデータ削除が証明されていない/ユーザが確認
14
できない セキュリティ確保の
難 難 難 同 同 同
インターネット経由のサービスでは、ＩＤ管理を厳密にしないと退職 難しさ
15
者が簡単にデータにアクセスできる
他ベンダへの移行の
16 業務継続性 サービス終了により、業務ができなくなる恐れ有り 難 最難 最難 難 難 難
難しさ
17 他のサービサーへ移行が難しい
データセンタ設置国の法律に従うため、日本国の法律と異なる理 コンプライアンスの やや やや やや
18 コンプライアンス 最難 最難 最難
由にて、情報が強制的に閲覧される可能性がある 確保の難しさ 易-難 易-難 易-難
利用者が内部監査を行う場合に、必要な監査証跡をクラウド事業
19 ＩＴガバナンス
者が提供できない場合がある ガバナンスの難しさ 難 難 難 難 難 難
※自社運用時と比べ「難」「同」「易」で分類 10
- 12. 2. クラウド検討の進め方 #3 クラウド化のための重要検討Point1
(A)どのようなＩＴ要件に対して、(B)何を目的とし、(C)その手段としてどのようなクラウドで実現するか？により、重点検討事項
は変わりますが、共通的な成功のＫｅｙＰointが存在すると考えます。
ＩＴ要件の例 達成すべきテーマ 成功のための重要KeyPoint
①アウトソーシングの見直し A.コスト削減 1, 業務＆データのクラウド化可否整理
2,サービサーとの最適な契約条件獲得の
②新規システム構築
ための可視化
B.簡単な拡張
③既存システムのリプレイス 3. クラウド化後の費用算出根拠の可視化
C.素早い立上げ
4.サービス仕様（品質・拡張性・カスタマイズ性、迅
④場所に依存しない経営情報の閲覧 速性など）の見極め
D.利便性の向上 5.サービサーの事業継続性見極め
⑤災害対策としての持たないシステム
11
- 13. 2. クラウド検討の進め方 #3 クラウド化のための重要検討Point2
前述の課題の大部分は現在のアウトソーシングと変わりません。課題解決および、『クラウド』のメリットを最大限に享受するため
にも、適応業務を選定するとともに、クラウド化後のサービスレベル・課金体系の可視化が重要と考えます。
提供形態により、課題に差がある
施策１
パブリック プライベート
ＩaaS PaaS SaaS ＩaaS PaaS SaaS
①次項のアプリケーションマップ内でクラウドに向いている
迅速性 速 速 最速
やや やや やや 業務についてはパブリッククラウドを検討
速 速 速
サービスレベル合意
難 難 難 難 難 難
の難しさ
運用の難しさ やや やや
易 易 易 同 施策2
（通常） 易 易
運用の難しさ やや やや
難 難 最難 同
（緊急対応の早さ） 易 易 現行のアウトソーシングの契約適正化手段として、
プライベートクラウドを検討
性能確保の難しさ 難 難 最難 同 同 同
セキュリティ確保の
難 難 難 同 同 同
難しさ
他ベンダへの移行の 契約適正化のための必頇要件
難 最難 最難 難 難 難
難しさ
コンプライアンスの やや やや やや
最難 最難 最難 ①クラウド化後の費用体系の「可視化」
確保の難しさ 易-難 易-難 易-難
ガバナンスの難しさ 難 難 難 難 難 難
②クラウド化後のサービルレベルの「可視化」
※自社運用時と比べ「難」「同」「易」で分類
12
- 14. 2. クラウド検討の進め方 #4 クラウド向きの業務アプリケーション
視点1 データ、システムの位置付け 視点2 対象アプリケーション領域
販売管理 生産管理 在庫管理 物流管理 調達・購買 SCM
管理
プロトタイプ的
試験導入的 業務系 業務系 業務系 業務系 業務系 業務系
（戦略性大）
情報系 情報系 情報系 情報系 情報系 情報系
システムの
位置付け
顧客管理 営業支援 経営層向け
意志決定
低 高
業務系
データの機密性 情報系 情報系
情報系
知識共有
Webサイト
人事・給不 財務・会計 グループ セキュリティ
構築・運用
ウェア
パブリック
クラウド向け
13
- 17. 2. クラウド検討の進め方 #5サービサーとの最適な契約条件獲得のための可視化
可視化対象には様々な項目があります。以下の全ての項目について、移行前、移行後における可視化を検討するのではなく、『①クラウド化のためのベン
ダ交渉』と『②クラウド化後に達成すべき可視化」にPointをおき、必要な範囲での情報収集が効率的と考えます。
機器情報 基本 機器名 SW情報 基本 ＳＷ名称 運用情報 インフラ運用 ベンダ名
型番 購入先ベンダ 契約番号
S/N ライセンス番号 開始日
ベンダ名 ライセンス数 期間
契約番号 製造ベンダ 中途解約金
調達金額 契約番号 契約金額
資産区分 資産区分 支払方法(年払、月払など）
調達形態（新規・追加） 調達形態（新規・追加） 支払履歴
導入日 導入日 体制
機器種別（SV,DISK,周辺機器など） 提供サービス内容
保守情報 契約者（ベンダ、ユーザ）
OS種別 利用ツール
保守ベンダ名
OS版数 ドキュメント整備状況
更新日
保守情報 契約者（ベンダ、ユーザ） アプリ運用 ベンダ名
更新期間
保守ベンダ名 契約番号
保守価格
更新日 開始日
支払方法(年払、月払など） 期間
更新期間 中途解約金
保守価格 中途解約金
導入先情報 導入先HW 契約金額
支払方法(年払、月払など） 導入ライセンス数 工数・依頼件数
中途解約金
支払方法(年払、月払など）
リース情報 リース・ステータス（基本、再リース） 契約条件 契約条件 期間延長協議開始時期 支払履歴
基本リース開始日 期間延長契約締結期限 体制
基本リース終了日 再委託条項 ＮＷ運用 ベンダ名
再リース更新期日 機密保持条項 契約番号
基本リース料 品質違背時のペナルティ 開始日
再リース料 責任の範囲 期間
支払方法(年払、月払など） 損害賠償限度額 中途解約金
中途解約金 任意解約金 契約金額
Config情報 Cpu数 支払方法(年払、月払など）
任意解約申し入れ期限
Memory 支払履歴
終了、解約後の措置
ディスク容量 体制
サービス提供先
増設IF 提供サービス内容
監査
利用情報 ＣＰＵ使用量 問合せ件数
料金変更
ディスク使用量 ヘルプデスク ベンダ名
終了後のＳＷ使用権＆保守継続権
メモリ使用量 契約番号
サービスの一時停止：事前通知
ピーク特性（一定期間の利用率推移） 開始日
トラブル等の処理
アプリ情報 基本情報 アプリケ－ション名 事故対応 期間
利用部門 中途解約金
情報の可視化
開発ベンダ 契約金額
保守ベンダ 支払方法(年払、月払など）
規模 移行前後でこれら全ての可視化を目的にするのではなく、 支払履歴
導入サーバ 体制
「クラウド化」のために必要な項目の可視化から着手する。 インシデント数
運用時間
問合せ内容
ピーク情報 16
