Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LiBRA 04.2019 / クラウド

519 views

Published on

https://libra.netcommerce.co.jp/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

LiBRA 04.2019 / クラウド

  1. 1. 最新のITトレンドとビジネス戦略 クラウド・コンピューティング編 2019年4月版
  2. 2. ご案内 2 知識の定着は、ネットを眺め、資料を読むだけでは不十分です。実際に第三者 を相手に自分の言葉で説明してみるのが最も効果的です。 また、本プレゼンテーションは、ロイヤリティ・フリーです。ご自身の資料と して、加工編集して頂いても構いません。 知識の確かな定着と仕事の生産性向上のために、ご活用下さい。 ネットコマース株式会社 斎藤昌義 http://libra.netcommerce.co.jp/ 最新のアップデートは、「ITビジネス・プレゼンテーション・ライブラリー/LiBRA」にて随時更新しております。
  3. 3. 3 クラウド・コンピューティング
  4. 4. クラウド・コンピューティング 知っておくべきITの基礎知識
  5. 5. コンピュータの構成と種類 5 サーバー・コンピュータ データセンターなどの専用設備に設置 複数のユーザーが共用 クライアント・コンピュータ 個人が所有する、あるいは交代で利用する 個人ユーザーが一時点で占有して使用する 組み込みコンピュータ モノの中に組み込まれている それぞれのモノの機能や性能を実現している ソフトウェア ゲーム ブラウザー ワープロ データベース 通信制御 認証管理 OS(Operating System) ハードウェア CPU(中央演算処理装置) メモリー(主記憶装置) ストレージ(補助記憶装置) ネットワーク機器 電源装置 コンピュータ
  6. 6. ITと情報システムの関係 6 交通費の精算生産計画の策定 取引履歴の管理 SNS ソーシャル・ネットワーク・サービス 電子メール オンライン ショッピング 災害の監視や通報鉄道や航空機の管制 建物の監視や 入退室管理 投資アドバイス 検査結果・画像から 病気の兆候を発見 販売傾向の予測 半導体 アルゴリズム コンピューター ストレージ ネットワーク 無線通信 データ記憶 ウイルス検知 不正侵入検知 人工知能 ロボット 業務の流れ(ビジネス・プロセス)を円滑にし効率を高める ITがなければ決してできないことを実現してくれる 私たちの安心や安全を支えてくれる 人間の能力や知識だけではとてもできないようなことを実現してくれる IT(Information Technology:情報技術) 情報システム ソフトウエア 技術 ハードウエア 技術
  7. 7. 情報システムの構造 7 業務や経営の目的を達成するための 仕事の手順 ビジネス・プロセス 情報システム ビジネス・プロセスを効率的・効果 的に機能させるためのソフトウエア アプリケーションの開発や実行に共 通して使われるソフトウエア ソフトウエアを稼働させるための ハードウェアや設備 アプリケーション プラットフォーム インフラストラクチャー 販売 管理 給与 計算 生産 計画 文書 管理 経費 精算 販売 管理 給与 計算 生産 計画 文書 管理 経費 精算 データベース プログラム開発や実行を支援 稼働状況やセキュリティを管理 ハードウェアの動作を制御 ネットワーク 機器 電源設備サーバー ストレージ
  8. 8. プラットフォームの変遷 8 オペレーティング・システム  ハードウェアを無駄なく・効率よく動かす  アプリケーションからハードウェアを簡単に使う ハードウェア ハード ウェア アプリケーションで共通に使う機能 ミドルウェア ハードウェア ハード ウェア ハード ウェア 共通で使う機能 オペレーティング・システム  ハードウェアを無駄なく・効率よく動かす  アプリケーションからハードウェアを簡単に使う ハードウェアを 制御する機能 1950年代〜 1960年代〜 1970年代〜 アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション
  9. 9. 回線交換方式とパケット交換方式 9 回線交換方式 パケット交換方式
  10. 10. インターネットとは 10 通信事業者A ネットワーク 通信事業者C ネットワーク IX 通信事業者B ネットワーク 通信事業者Z ネットワーク 通信事業者Y ネットワーク IX 通信事業者X ネットワーク IX IX IX IX Internet eXchange point Web サーバー ホームページ 世界各国の通信事業者が所有 するネットワークを相互接続 Inter-Network 世界各国の通信事業者が 共通の通信手順で データをやり取り
  11. 11. インターネットとWebサイト 11 <title>ネットコマース株式会 社</title><link rel="shortcut icon" href="http://www.netcomme rce.co.jp/cms/wp- content/uploads/2013/08/fav icon1281.png" /><link rel="apple-touch-icon" sizes="144x144" http://netcommerce.co.jp / document.html ウエブ・サーバーの名称 文書の名前 ウエブ・サーバー ハイパー・リンク インターネット ブラウザー 世界中のウエブ・サーバー Httpまたはhttps プロトコル HTMLファイルを送り届ける通信手順 URL uniform resource locator
  12. 12. インターネット VPN 12 データ 盗聴 改ざん 偽データ なりすまし データ 盗聴 改ざん 偽データ なりすまし 通常のインターネット通信 VPNによるインターネット通信
  13. 13. クラウド・コンピューティング で変わるITの常識
  14. 14. ネットワーク インターネットや専用回線 コレ一枚でわかるクラウド・コンピューティング 14 インフラストラクチャー プラットフォーム アプリケーション 計算装置 記憶装置 ネットワーク データ ベース 運用管理 プログラム 実行環境 プログラム 開発環境 認証管理 電子 メール SNS 新聞 ニュース ショッピング 金融取引 財務 会計 施設や設備
  15. 15. 「自家発電モデル」から「発電所モデル」へ 15 工場内・発電設備  設備の運用・管理・保守は自前  需要変動に柔軟性なし 電力供給が不安定 自前で発電設備を所有 工場内・設備 電 力 電力会社・発電所 大規模な発電設備 低料金で安定供給を実現  設備の運用・管理・保守から解放  需要変動に柔軟に対応 工場内・設備 送電網 データセンター 大規模なシステム資源 低料金で安定供給を実現  設備の運用・管理・保守から解放  需要変動に柔軟に対応 システム・ユーザー デ ー タ インターネット
  16. 16. 「クラウド・コンピューティング」という名称の由来 16 アプリケーション プラットフォーム インフラ クラウド(Cloud) =ネットワークあるいはインターネット ネットワークの向こう側にあるコンピュータ(サーバー)を ネットワークを介して使う仕組み クラウド・コンピューティング Cloud Computing
  17. 17. クラウドによる新しいIT利用のカタチ 17 スペース:設置場所の制約 コスト 利用量・使う機能 に応じた課金 アジリティ 追加・変更 の柔軟性 スケール 規模の伸縮 弾力性 クラウド・コンピューティング Cloud Computing システム構築・運用 の負担軽減 アプリケーション展開 のスピードアップ
  18. 18. クラウド・コンピューティング の価値
  19. 19. 歴史的背景から考えるクラウドへの期待 業務別専用機 業務別専用機 業務別専用機 業務別専用機 UNIXサーバー PC PCサーバー Intel アーキテクチャ 汎用機 メインフレーム IBM System/360 IBM System/360 アーキテクチャ ~1964 汎用機 メインフレーム PC 1980~ ミニコン オフコン エンジニアリング ワークステーション 汎用機 メインフレーム ダウンサイジング マルチベンダー 2010~ PC+モバイル+IoT 汎用機 メインフレーム PCサーバー PCサーバー PCサーバー クラウド コンピューティング データセンター
  20. 20. 社会的責任の担保 災害、セキュリティ・・・ 事業成長へのIT投資 グローバル、新規事業・・・ IT環境への対応 モバイル、ビッグデータ・・・ コスト削減への 継続的圧力 情報システム部門の現状から考えるクラウドへの期待(1)
  21. 21. 情報システム部門の現状から考えるクラウドへの期待 新規システムに投資する予算 既存システムを維持する予算 (TCO) 40% 60% 新規システムに投資する予算 既存システムを維持する予算 IT予算の増加は期待できない! 既存システムを 維持するための コスト削減  TCOの上昇  IT予算の頭打ち クラウドへの期待 「所有」の限界、使えればいいという割り切り
  22. 22. クラウドはシステム資源のECサイト 見積書 契約書 調達手配 導入作業 メーカー ベンダー サイジング 調 達 費 用 数週間から数ヶ月 数ヶ月から数年を想定 現物資産またはリース資産 従来の方法 セルフ・サービス・ポータル  調達・構成変更  サービスレベル設定  運用設定  ・・・ 数分から数十分 直近のみ・必要に応じて増減 経費・従量課金/定額課金 クラウド オンライン・リアルタイム
  23. 23. クラウドならではの費用対効果の考え方 システム関連機器の コストパフォーマンス リース コストパフォーマンスが 長期的に固定化 クラウド 新機種追加、新旧の入替えを繰り返し 継続的にコストパフォーマンスを改善 移行・環境変更に かかる一時経費 2006/3/14〜 50回以上値下げ
  24. 24.  徹底した標準化  大量購入  負荷の平準化  APIの充実・整備  セルフサービス化  機能のメニュー化 クラウド・コンピューティングのビジネス・モデル 24 クラウド・コンピューティング オンデマンド 従量課金 自動化・自律化 システム資源 の共同購買 サービス化 低コスト 俊敏性 スケーラビリティ SDI (Software Defined Infrastructure)
  25. 25. IT活用適用領域の拡大 難しさの隠蔽 システム資源 エコシステム クラウドが生みだすパラダイムシフト 25 クラウド・コンピューティング IT利用のイノベーションを促進 ビジネスにおけるIT価値の変化・向上 新たな需要・潜在需要の喚起 モバイル・ウェアラブル ソーシャル 人工知能 ビッグデータ IT利用者の拡大 IoT ロボット 価格破壊 サービス化
  26. 26. クラウドがもたらすビジネス価値 構築や運用からの解放 最新テクノロジーの早期利用 資産から経費へのシフト  アプリケーションの質的向上にリソースをシフトできる  ビジネス・スピードの加速に迅速柔軟に対応できる  試行錯誤が容易になってイノベーションを加速する  テクノロジーの進化をいち早くビジネスに取り込める  初期投資リスクが削減でき、IT活用範囲を拡大できる  ビジネス環境の変化に柔軟に対応できる
  27. 27. クラウドを使うことの狙い 27 構築や運用からの解放 最新テクノロジーの早期実装 資産から経費へのシフト  アプリケーションの質的向上にリソースをシフトできる  ビジネス・スピードの加速に迅速柔軟に対応できる  試行錯誤が容易になってイノベーションを加速する  テクノロジーの進化をいち早くビジネスに取り込める  初期投資リスクが削減でき、IT活用範囲を拡大できる  ビジネス環境の変化に柔軟に対応できる ビ ジ ネ ス の 成 果 に 直 接 貢 献 す る
  28. 28. SIビジネスの常識を覆す動き 28 オラクル「Oracle Autonomous Data Warehouse Cloud」正式公開。機械学習を用 いて全自動で運用、チューニング、パッチ適用な ど実現 2018年3月28日  機械学習によって人手を介さずにバックアップやパッ チの適用、チューニング、スケールイン/スケールア ウトなどの日常的な運用業務を自律的に行うクラウド サービス。  人手を介さず自律的に稼働することで運用にかかるコ スト削減だけでなく、ヒューマンエラーも起きない安 全な運用が可能になり、計画停止も含めたSLA 99.995%を約束。 日本ユニシスとマイクロソフト、「BankVision on Azure」実現に向け共同プロジェクトを開始 2018年3月23日 日本ユニシス株式会社と日本マイクロソフト株式会社 は23日、日本ユニシスのオープン勘定系システム 「BankVision」の稼働基盤として、Microsoft Azureを 採用するための取り組みを推進するため、共同プロ ジェクトを4月から開始すると発表した。
  29. 29. 銀行システムにおけるクラウド活用の動き 29 日本ユニシスとマイクロソフト、「BankVision on Azure」実現に向け共同プロジェクトを開始 2018年3月23日 日本ユニシス株式会社と日本マイクロソフト株式会社 は23日、日本ユニシスのオープン勘定系システム 「BankVision」の稼働基盤として、Microsoft Azureを 採用するための取り組みを推進するため、共同プロ ジェクトを4月から開始すると発表した。 いかに費用を抑え、最新技術も取り入れた上で短期間 でのシステム開発を行うかという課題に対応するため、 クラウドを選択。現在はクラウド最大手の米アマゾン ウェブサービスと組み、業務システムの一部から移行 を進めている。 5年間で100億円のコスト削減 1000超のシステムの約半分をクラウド化 週刊ダイヤモンド 2017.5.17 https://diamond.jp/articles/-/128045
  30. 30. クラウド・バイ・デフォルト原則 30 政府情報システムにおけるクラウドサービスの利用に係る基本方針 クラウド・バイ・デフォルト原則(クラウドサービスの利用を第一候補)  政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う  情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び経費等を基に検討を行う https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf Step0:検討準備 クラウドサービスの利用検討に先立ち、対象となるサービス・業務及び情報といった事項を可能な限り明確化する。 Step1:SaaS(パブリック・クラウド)の利用検討と利用方針 サービス・業務における情報システム化に係るものについて、その一部又は全部が SaaS(パブリック・クラウド)により提供されてい る場合(SaaS(パブリック・クラウド)の仕様に合わせ、サービス・業務内容を見直す場合も含まれる。)には、クラウドサービス提 供者が提供する SaaS(パブリック・クラウド)が利用検討の対象となる。 Step2:SaaS(プライベート・クラウド)の利用検討 サービス・業務における情報システム化に係るものについて、その一部又は全部が、府省共通システムの諸機能、政府共通プラット フォーム、各府省の共通基盤等で提供されるコミュニケーション系のサービスや業務系のサービスを SaaS として、当該サービスが利用 検討の対象となる。 Step3:IaaS/PaaS(パブリック・クラウド)の利用検討と利用方針 SaaS の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、民間事業者が提供する IaaS/PaaS(パブリック・クラウド)が利用検討の対象となる。 Step4:IaaS/PaaS(プライベート・クラウド)の利用検討 IaaS/PaaS(パブリック・クラウド)の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、 サーバ構築ができる政府共通プラットフォーム、各府省独自の共通基盤等を IaaS/PaaS として、当該サービスが利用検討の対象となる オンプレミス・システムの利用検討
  31. 31. クラウド・コンピューティング 3つの価値
  32. 32. クラウドにまつわる3つの誤解 32 ガバナンスが効かない。だからセキュリティも確保で きない。だから心配なので使えない。 調達の手段が変わるだけ。自分たちのやることは実質 変わらない。運用がある程度は任せられる程度。 コスト・メリットは期待できない。クラウドだって、 コストはかかり続けるのだから結局は同じ。 誤解1 誤解2 誤解3
  33. 33. 誤解1:調達の手段が変わるだけ? 33 +5年+5年5年 アプリケーション+業務対応 運用管理 移行作業 移行作業 移行作業 アプリケーション+業務対応 運用管理 クラウド アプリケーションや業務対応に人的資源を集中できる
  34. 34. 誤解2:ガバナンスが効かない? 34 インフラ プラットフォーム 運用管理 アプリケーション 業務対応 自社対応 クラウド 自社所有 IaaS PaaS SaaS 責任分界点が変わる:運用管理 × セキュリティ対応
  35. 35. ソフトウェア ハードウェア 附帯設備 誤解3:コストは下がらない? 35 ハードウェア 附帯設備 ソフトウェア 業務対応 業務対応 クラウドを使用する場合 固定資産の割合が高い ビジネス環境の変化に柔軟対応 リスクヘッジ効果が高い 自社所有の場合 経費の割合が高い
  36. 36. クラウド・コンピューティング とは
  37. 37. クラウド・コンピューティングの起源 ~ シュミットの対談 What's interesting [now] is that there is an emergent new model, and you all are here because you are part of that new model. I don't think people have really understood how big this opportunity really is. It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a "cloud" somewhere. And that if you have the right kind of browser or the right kind of access, it doesn't matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the cloud. There are a number of companies that have benefited from that. Obviously, Google, Yahoo!, eBay, Amazon come to mind. The computation and the data and so forth are in the servers. Eric Schmidt, 6.Mar.2006, “Search Engine Strategies Conference @ San Jose, CA “(新しいモデルは) データサービスとアーキテク チャはサーバー上にあるべきだという前提から 始まる。これをクラウドコンピューティングと 呼ぼう - 「クラウド」のどこかにあるべきなの だ。適切なブラウザ、あるいは適切なアクセス 手段があれば、PC、Mac、携帯電話、ブラック ベリー、その他あらゆるものから - あるいは、 まだ開発されていない新しいデバイス - クラウ ドにアクセスできる。” 「クラウド」上のサーバー 適切なアクセス手段 開発中の新しいデバイス
  38. 38. ネットワーク (インターネット) 巨大なコンピューター・システム群向 こ う 側 こ ち ら 側 クラウド・コンピューティングの起源とGoogleの定義 利用する側:自分専用のシステム 提供する側:世界中の複数拠点に分散配置 38 Google CEO エリック・シュミット 6.Mar.2006, “Search Engine Strategies Conference @ San Jose, CA データもプログラムも、サーバー群の上に置いておこう・・・そういったものは、ど こか “雲(クラウド)”の中にあればいい。必要なのはブラウザーとインターネットへ のアクセス。パソコン、マック、携帯電話、ブラックベリー、とにかく手元にあるど んな端末からでも使える・・・データもデータ処理も、その他あれやこれやもみんな サーバーに、だ。 http://www.google.com/press/podium/ses2006.html
  39. 39. クラウドの起源と定義 クラウド・コンピューティングは コンピューティング資源を 必要なとき必要なだけ簡単に使える仕組み 配置モデル サービス・モデル 5つの重要な特徴 米国国立標準技術研究所 「クラウドコンピューティングとは、ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの構成可能なコン ピューティングリソースの共用プールに対して、便利かつオンデマンドにアクセスでき、最小の管理労力またはサービスプ ロバイダ間の相互動作によって迅速に提供され利用できるという、モデルのひとつである (NISTの定義)」。
  40. 40. クラウドの定義/サービス・モデル (Service Model) アプリケーション ミドルウェア オペレーティング システム インフラストラクチャ PaaS Platform as a Service Infrastructure as a Service Software as a Service SaaS Salesfoce.com Google Apps Microsoft Office 365 Microsoft Azure Force.com Google App Engine Amazon EC2 IIJ GIO Cloud Google Cloud Platform アプリケーション ミドルウェア & OS 設備 & ハードウェア プ ラ ッ ト フ ォ ー ム IaaS
  41. 41. クラウドの定義/サービス・モデル (Service Model) アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 サーバー ストレージ ネットワーク アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 (必ずしも使わない) サーバー ストレージ ネットワーク アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 (必ずしも使わない) サーバー ストレージ ネットワーク アプリケーション(アドオン) IaaS PaaS SaaS ア プ リ ケ ー シ ョ ン 利 用 す る 企 業 の 責 任 ク ラ ウ ド 事 業 者 の 責 任 プ ラ ッ ト フ ォ ー ム イ ン フ ラ ス ト ラ ク チ ャ ー
  42. 42. クラウドの定義/サービス・モデル (Service Model) プラットフォーム 開発や実行に必要なソフトウエア 実行と運用管理 アプリケーション 業務遂行に必要なソフトウエア 実行と運用管理 インフラストラクチャー プロセッサー、メモリー、ストレージ、 ネットワークなどのシステム資源、施設 実行と運用管理 サービス 事業者 サービス 事業者 サービス 事業者 PaaS IaaSSaaS ユーザー 自社所有 ユーザー ユーザー
  43. 43. ふたつのタイプのIaaS (日本の個別事情) 運用管理  構築(作成)  起動/シャットダウン  バックアップ  仮想マシンの複製  リソースの変更や監視  運用サービス設定など システム資源  プロセッサー  メモリー  ストレージ  デスクトップ  ネットワーク  データセンター設備など サービス事業者 標準化されたシステム構成、運 用管理メニューを提供。調達・ 運用管理の自動化を徹底。 ユーザー セルフサービス・ポータルを 使って自社要員で必要な管理・ 設定を行う。 サービス事業者 ユーザーの個別の要望に応じて、 サービス事業者がシステムの構 築、運用設計を実施。それに応 じた運用サービスを提供する。 割安。継続的なサービスや機能 の拡充、コスト低減などを享受 できる。 割高。サービスや機能は固定化 または変更に手間はかかる。継 続的なコスト低減は難しい。 セルフサービス型 IaaS フルサービス型 IaaS AWS,SoftLayer,cloudnなど 国内SI事業者に多い NISTの定義に該当
  44. 44. ハイブリッド・クラウド 複数企業共用 パブリック・クラウド クラウドの定義/配置モデル (Deployment Model) プライベート・クラウド 個別企業専用 個別・少数企業 不特定・複数企業/個人 LAN LAN インターネット 特定企業占有 ホステッド・プライベート・クラウド 固定割当て LAN 専用回線・VPN LAN
  45. 45. マルチテナント方式の課題を解決する選択肢 45 アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS ハードウェア アプリケーション ミドルウェア OS 仮想マシン 仮想マシン 仮想マシン 仮想マシン 仮想マシン 仮想マシン A社 C社B社 A社 A社 仮想化 Hypervisor ハードウェア 仮想化 Hypervisor ハードウェア マルチテナント方式 シングルテナント方式 ベアメタル方式 ホステッド・プライベート・クラウド 【リスク1】クラウドベンダー都合でのメンテナンス停止が発生する(ユーザー側都合での調整はできない) 【リスク2】高可用性を担保するアーキテクチャ設計の難易度が上がる 【リスク3】性能を完全に保証するには懸念がある (同一ハードウェア内で他のユーザーの区画も動作しており、他ユーザーが大量にコンピュートリソースを消費するようなことがあると影響を受ける懸念がある)
  46. 46. プライベートクラウド(1) 46 http://www.idcjapan.co.jp/Press/Current/20150909Apr.html 国内プライベートクラウド市場 配備モデル別支出額予測 2014年〜2019年  オンプレミス・プライベートクラウド  ホステッド・プライベートクラウド  デディケイテッド・プライベート・クラウド  コミュニティ・プライベート・クラウド プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド  ユーザー企業構内に設置  自社資産  自社運用・管理  サービス事業者施設内に設置  サービス事業者の資産  定額利用料金/従量課金 パブリック・クラウドの一部を ユーザー(テナント)に占有使用 ユーザー(テナント)毎のプライ ベート・クラウドを管理・運用
  47. 47. プライベートクラウド(2) 47 プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ユーザー企業に システム資源を 占有・割り当て パブリック・クラウド ユーザー企業・自社構内 データセンタ・占有借用施設内 クラウド・サービス事業者 自社専用 クラウド環境 予め用意された 標準仕様を組合せ ユーザー企業毎に 個別仕様で クラウドを提供 ユーザー企業の資産 クラウド・サービス事業者の資産 運用管理責任は自社 運用管理責任は事業者 運用管理責任は事業者 リースまたは減価償却 サブスクリプション サブスクリプション+初期費用  OpenStack(OSS)  Microsoft Azure Stack  Vmware vSphere など  AWS Virtual Private Cloud  Microsoft Virtual Network  IBM Blumix Dedicated など  NTT コム Enterprise Cloud  NSSOL absonne  CTC CUVICmc2 など
  48. 48. ハイブリッド・クラウド モバイル連携 使い分け 災害対策 負荷調整 SaaS連携 ピーク対応 柔軟対応 PublicPrivate PublicPrivate PublicPrivate PublicPrivatePublicPrivate PublicPrivate PublicPrivate パブリックで モバイル・ア プリケーショ ンと連携 プライベート で基幹業務系 の処理 業務ごとに両 者を使い分け 通常時はプラ イベート 災害時にはパ ブリックに切 り替え プライベート で負荷をまか ないきれない ときにパブ リックを追加 リソースとし て使用 パブリックで SaaSを使用 そのデータを プライベート の業務システ ムで処理する 通常はプライ ベートで処理 するがピーク 時はパブリッ クにリソース を拡大する 業務状況に応 じて業務や データを両者 で柔軟に使い 分ける (単一リソース) 業 務 A 業 務 B 業 務 C 業 務 D 業務 業務 業務 業務 負荷調整 業務 SaaS 業務 業務 業 務 A 業 務 B 業 務 C 業 務 D 対象とする業 務アプリケー ションへのア クセス方法 業務の配置と 統合監視・管 理方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 ネットワーク 帯域・設定 振り分けが自 動か手動で難 易度が変わる SaaS/API連携 の方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 構築の難易度 低 低 中 高 高 高+ 高+
  49. 49. 経費精算サービス インターネット越しに経費精算 パブリック・クラウド ハイブリッド・クラウド(2) 49 プライベート・クラウド ERP 会計・小口請求処理 経費精算サービス 交通費やその他経費の精算手続き LAN 経理担当 カード会社銀行 (個人口座) インターネット
  50. 50. ハイブリッド・クラウド(3) 同一のアーキテクチャー リソース A リソース B リソース C パブリック・クラウド プライベート・クラウド クラウド基盤 仮想基板 セルフサービス・ポータル リソース A リソース B リソース C ユーザー・ビュー パブリックと プライベートが ひとつの リソース プール 標準化の主導権争い
  51. 51. ハイブリッド・クラウド 51 Cloud Stack AWS OpenStack Cloud Stack vCloud 各クラウドサービス・プロバ イダー vmware vCloud Suites Azure Azure Stack Google Cloud Platform なし Cloud Foundry Google App Engine Elastic Beans Talk Lambda など 互換API Open Stack Cloud Foundry IBM Bluemix Local プライベート・クラウド パブリック・クラウド PaaS IaaS PaaS IaaS IBMCloud IBM Cloud Dedicated
  52. 52. ハ イ ブ リ ッ ド ク ラ ウ ド ベンダーにて運用、ネット ワークを介してサービス提供 パブリック クラウド 自社マシン室・自社データセ ンターで運用・サービス提供 プライベート クラウド 5つの必須の特徴 人的介在を排除 無人 システム TCOの削減 人的ミスの回避 変更への即応 ソ フ ト ウ ェ ア 化 さ れ た イ ン フ ラ ス ト ラ ク チ ャ 調 達 の 自 動 化 運 用 の 自 動 化 オンデマンド・セルフサービス 幅広いネットワークアクセス 迅速な拡張性 サービスの計測可能・従量課金 リソースの共有 注:SaaSやPaaSの場合、絶対条件ではない。
  53. 53. クラウドの分類と関係 53 個別システム ホステッド プライベート クラウド SaaS(Software as a Service) PaaS(Platform as a Service) IaaS(Infrastructure as a Service) SaaS PaaS IaaS プライベート・クラウド パブリック・クラウド/クラウド事業者資産を使用 オンプレミス・システム/自社資産として所有 ハイブリッド・クラウド プライベートとパブリックの連係・組合せ マ ル チ ・ ク ラ ウ ド 複 数 の パ ブ リ ッ ク を 連 係 ・ 組 合 せ
  54. 54. ハイブリッド・クラウドとマルチ・クラウド 54 クラウド管理プラットフォーム Prime Cloud Controller (SCSK) / RightScale (RightScale) / vRealize Suite (Vmware) など オンプレミス(自社構内) データセンタ(自社設備) データセンタ(他社設備) コロケーション/ホスティング パブリック・クラウド パブリック・クラウド バーチャル プライベート クラウド ハイブリッド・クラウド マルチ・クラウド インターネット/VPN/専用線 (SDN : Software-Defined Network) 個別専用システム ハイブリッド・クラウド マルチクラウド
  55. 55. 仮想化とクラウド(IaaS)との違い 仮想化 運 用 管 理 調 達 インフラに関わるシステム資源を ソフトウェアの定義・設定により調達、構成変更 調達機能と 運用管理機能の 連携と自動化 個別対応 自動化/人的作業 システム資源の利用効率向上 人的作業の負担軽減 調達・変更の俊敏性と生産性向上 仮想化 クラウド(IaaS)
  56. 56. クラウドというイノベーションの特殊性 56 クラウドは、テクノロジー・イノベーションではない 基本技術特許や特定企業の絶対優位が存在しない 業界標準(De-Facto Standard)を追求 価格競争 開発・実行環境 優位性 アプリケーション 高付加価値 IaaS PaaS SaaS コモディティ化
  57. 57. クラウドのメリットを活かせる4つのパターン 負 荷 時間 OnとOff:キャンペーンサイトやバッチ処理などで一 時的負荷が増大する場合、固定的な設備では過剰投資と なってしまう可能性が高く、従量課金で使えることで、 費用負担を最適化できる。 負 荷 時間 急激な成長:新しいサービスやゲームなどでは、予め ユーザー数の増減を予測することが難しい。クラウドは 初期投資不要であり、必要に応じて継続的にリソースを 拡張できるスケーラビリティが行かせる。 負 荷 時間 予測不可能な使用量の増大:人気商品の発売や 期間限定セールなどで、トラフィックが急上昇し、ス ループットの低下や過負荷によるトラブルなどが予測さ れるとき、ダイナミックなリソースの増減で対応できる。 負 荷 時間 周期的な使用量の増減:旅行シーズンやお歳暮 シーズンなどでトラフィックが増加するサービスでは、 固定的な設備を持つことは割高となるため、柔軟にリ ソースを増減できることでコスト最適が図れる。 システム・リソースを確定・固定できない
  58. 58. PaaS
  59. 59. ASPからSaaSへ、ホスティングからIaaSへ オンプレミス アプリケーション ミドルウェア OS/ハードウェア サービスプロバイダ ASP Application Service Provider ネットワーク上のサー バーにパッケージソフトを 搭載してネットワーク越し に提供 Hosting/Housing データセンターの サーバーを ネットワーク越しに提供 クラウド SaaS IaaS SaaS Software as a Service (1999〜) マルチテナント対応アプリ ケーションを「サービス」と して提供し、従量課金 PaaS (2007〜) IaaS (2006〜) サービスとして 提供従量課金
  60. 60. データセンター データセンター ASPとSaaSの違い – マルチテナント サーバー サーバー サーバー アプリ アプリ アプリ サーバー サーバー 仮想化 顧客 顧客 顧客 アプリ アプリ アプリ データセンター サーバー アプリケーション 顧客 顧客 顧客 パッケージをそのまま使用 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い または マルチテナントDB ASP SaaS
  61. 61. PaaSの誕生 Salesforce (1999) Salesforce Database Workflow Other User App User App Salesforceの顧客から、Salesforce が持っているデータベース、ワーク フローなどの機能を使ってCRM以 外のアプリを作成したいという要望 が高まった APIを整備して公開 (2007.7) → Force.com (2007) → database.com (2010) マルチテナントDB
  62. 62. Force.comのターゲットマーケット 消費者 全社 部門 グループ コンテンツ データ プロセス トランザクション アプリケーションのタイプ ユーザーのタイプ Excel 以上、全社システム以下 全社規模の基幹システムであればコ ストをかけてシステムを開発できる 部門レベルでは、コストをかけられな い一方で変化の速度が速いため、改 修が頻繁に起こるため、IT部門もSIer も対応しにくい。 このためユーザーが自分で作る必要 があるが、一から作るのは大変なた め、何からのツールが必要。 → Notesのマクロ → Excel/Access
  63. 63. アプリ開発基盤としての Lotus Notes グループウェア=グループ内での情報共有、コミュニケーション、コラボレーションを支 援するソフトウェアスイート 様々なコミュニケーション機能をワンパッケージ化 電子メール BBS 電子会議室 ライブラリ スケジューラ ワークフロー (電子決裁) グループウェアのアイ デアは1960年代末か らあった PCの普及により情報量 が増大し、情報の効率 的共有へのニーズが 増した 1989=インターネット普及前 当時Lotus Notesが 大企業に受け入れ られた理由 細い回線でも効率的にレプリ ケーションを行うことができ、複数 の拠点を持つ大企業にとって使 い勝手が良かった 強力で柔軟なスクリプトにより、 ワークフローを比較的簡単に作り 込むことができた インターネット の商用利用開 始は1988年
  64. 64. XaaS = Webサービスの多様化 アプリケーション ミドルウェア OS ハードウェア SaaS IaaS Force.com 様々なXaaSが考案され、従来の分類に収まらなくなった BaaS AmazonRDS Database.com 仮想マ シン ベアメ タル
  65. 65. マルチテナントの効果 メモリ消費量に1,000倍の違い
  66. 66. データセンター データセンター ASPとSaaSの違い – マルチテナント サーバー サーバー サーバー アプリ アプリ アプリ サーバー サーバー 仮想化 顧客 顧客 顧客 アプリ アプリ アプリ データセンター サーバー サーバー サーバー アプリケーション 仮想化 顧客 顧客 顧客 パッケージをそのまま使用 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い または マルチテナントDB ASP SaaS
  67. 67. Oracle 12cのマルチテナントアーキテクチャ コンテナデータベース(CDB)上 にプラガブルデータベース (PDB)を作成 ひとつのインスタンスで複数の スキーマを運用 スキーマ統合を課題を解決
  68. 68. マッシュアップ開発の部品としてのWebサービス クラウドサービス API クラウドサービス API クラウドサービス API マッシュアップ開発 IT の深い知識がなくても、既存 のWebサービスAPIを組み合わ せて、短期間でアプリケーション 開発を行うこと。新しい開発技法 として注目されている。 様々なWebサービスやBaaSなど のサービス、豊富なOSSなどによ り、新たなプログラミングをせず にアプリケーションを開発するこ とが可能になってきた マッシュアップ 自社サービス Application Programming Interface 外部からプログラムの機能やデータにアクセス するための手順やデータ形式
  69. 69. Service Oriented Architecture
  70. 70. SOA SOA (2000年前後)  ビジネスプロセスをサービス化  クラウドへの対応 ビジネスプロセスを サービスとして実装 既存システムを相互接続して統合 EAI (1990年代末) ばらばらに開発された業務システ ムをプロトコル変換などで統合 従来は部分最適な業務システム  個別にシステム設計開発  現場の仕事をそのままシステム化  「その時点」での技術を使って開発  他システムとの連携は必要に応じて設計・ 実装  全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering ERP Enterprise Resource Planning
  71. 71. SOAは思想であり考え方 • SOAの定義(Wikipedia) – 業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、 その構成単位のことである。プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会 する」などの単位で一つのサービスとすることが求められる。どの程度の規模(粒度)を一つのサー ビスとするが良いのかについては様々な議論がある。 – オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従っ た呼び出し、応答が可能であること。その技術的基盤として、Webサービスの使用が事実上必須と なっている。 – サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。この段階にいたる までには、先の二つの条件が必須となる。さらに、サービスを単位として業務処理の流れを記述す る技術や、その記述通りにシステム連携を実行する技術も必要となる。 SOAとは、ビジネスプロセスに沿って業務システムを構築することであり、システム構築 の手法(思想)といえる。 SOAという製品は存在しない。SOAという考え方に基づいて、大規模なシステムを個々 のプロセスに対応するサービスの集まりとして構築する。 実装方法としてWebサービスが使われることが多いが、Webサービス=SOAではない。 WebアプリケーションサーバーやSOAPなどはSOAによるシステム構築のための技術的 要素に過ぎない。 クラウドと親和性が高い
  72. 72. サーバーとクライアントの関係の変遷 Windows クライアント・サーバー サーバー 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 管理コストの増大 ベンダーロックイン Webシステム ブラウザー サーバー Webサーバー 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム ブラウザの機能不足 マルチプラットフォーム対応 RIC/RIA ブラウザー + プラグイン サーバー Webサーバー 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム プラグインによる ブラウザの機能強化 マルチプラットフォーム対応 「Webサービス」の誕生
  73. 73. Webサービス (Web Service) XMLでデータ交換できるインターフェイスを持つアプ リケーション・システム。SOAを実現する技術とも言 える。インターネット上で、Webサービスが、XMLを 使って相互にデータを交換し、連携することで・・・  単体のWebサービスだけではできない、利便性 や機能の高いアプリケーションを構築できる  Webサービスの組合せを固定化させず、柔軟な アプリケーションを構築できる  組合により多様なアプリケーションが展開できる SOAとクラウドの関係 73 SOA (Service Oriented Architecture/ サービス指向開発) 業務全体のプロセスをこれ以上分解できない業務処理の単位(サービス) にまで分解し、そのプロセス単位毎に対応したプログラムを「標準部品」と して用意する。これを組み合わせ、ネットワーク上で連携させて、システム 全体を実現するシステム構築手法。 XML (eXtensible Markup Language /拡張可能なマーク付け言語) プラットフォームに依存しない、システム間でデータ交換を可能にするため の言語、または、データを記述する書式。 PaaS(Platform as a Service) IaaS(Infrastructure as a Service) 仮想化基盤は必須ではない SaaS(Software as a Service) アプリケーションをサービスとしてインターネット上で提供する仕組み  Webサービスとして構築され、他のWebサービスと相互連携が容易  カスタマイズ機能がある  オンデマンド(必要な時、いつでも)インターネット / ネットワークを介し)利用 1990年代 1998年 2000年頃
  74. 74. SOAとクラウドの関係 74 販売管理の業務に沿ったビジネス・プロセス 受注 請求 入金 出荷 SOAをベースにした販売管理プロセス 受注 請求 入金 出荷 ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷請求 入金  プロセスの各業務単位(サービス)に合わせて ソフトウェアを作ってあるので、後でプロセス が変わっても柔軟に対応できる  サービス間でやりとりするデータの種類、 フォーマットをXMLで決めて標準化  各ソフトをWebアプリ (Webサービス)にしておく と、柔軟性が高まる 従来型のシステム構築手法による販売管理システム 受注 請求・入金 出荷  ビジネス・プロセスに合わせてシステムを構築 していない場合、後で変更するのが大変  他のシステムとの連携を考えていない場合(イ ンターフェースの標準化が行われていない)、 後から付け加えるのは大変な作業になる 要求仕様 プロセス単位で サービス化 伝票のフローに沿ったシステム 情報のフローに沿ったシステム サービス 業務上の1処理に相当する機能
  75. 75. IaaS Webサービスを組み合わせてシステムを構築 SoftLayer Gmail ML Docs Google EC2 Aurora Lambda Amazon サービス 自社サーバー サービスの部品化により クラウドの活用範囲が拡大 クラウド上のサービスを 組み合わせてシステムを構築
  76. 76. SOAの実装としてのESB SOAをベースにした販売管理プロセス 受注 請求 入金 出荷 ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷請求 入金 受注 請求 入金 出荷 ESB その他のサービス レガシーシステムなど 小規模なシステムな らWebサービスベー スでも可 大規模なシステムで はESBが有効
  77. 77. モジュールをWebサービス化することのメリット プライベートクラウド パブリッククラウドハイブリッドクラウド SOAはクラウドと相性が良い
  78. 78. SOAの狙いと成果 業務プロセスを見直し、サービス単位に分割 サービス間のデータ交換ルールを決め、メカニズムを構築 サービス単位でプログラムを開発し、相互に接続 情報システムを分割し、疎結合させる 柔軟性の向上 管理の容易さ 迅速な開発
  79. 79. Googleのクラウド・セキュリティ対策 79 Denial of Service (DoS) Protection DoS攻撃の防御 マルチティア、マルチレイヤにわたるDoS攻撃からの防御によって、GFEの背後で稼働している サービスをDoSから守る。 バックボーンを通じて届く通信は、何層かのハードウェアおよびソフトウェアのロードバランサーを通 過する。ロードバランサーは通信の情報をインフラ上で稼働する中央DoSサービスへ報告。中央 DoSサービスがDoS攻撃の開始を検知すると、DoSの通信を破棄もしくは絞るようにロードバラン サーを制御する。 GFEインスタンスもアプリケーションレイヤにおける情報を中央DoSサービスへ報告し、ここでも DoSが検知されればGFEインスタンスが通信を破棄するように制御される。 User Authentication ユーザー認証 Dos攻撃からの防御に続いての防御は中央アイデンティティサービスによる。ユーザー名やパス ワードを確認した上で、同一のデバイスや同一ロケーションからのログインかどうかなどの追加情 報を基にしてユーザーからの脅威があるかどうかをインテリジェントに判断する。 Safe Software Development 安全なソフトウェア開発 中央コードリポジトリや関係者のレビューなどに加えて、開発者がXSSといったセキュリティ関連の バグを組み込まないよう、ライブラリを提供しており、またコードの静的解析ツール、Webセキュリ ティスキャナーなどを用意している。 最終チェックとしてマニュアルでのセキュリティレビューを行っている。これはWebセキュリティ、暗 号化、OSセキュリティなどの専門家による、些細なリスクの判断から深刻な設計や実装レビューま で行われている。 さらに脆弱性を発見したものに対する脆弱性報奨金プログラムを行っており、これまでに数百万ド ル(数億円)を支払った。 Keeping Employee Devices and Credentials Safe 従業員 のデバイスとクレデンシャルの安全性確保 従業員を対象にした洗練されたフィッシングがこれまで行われてきており、フィッシング可能なOTP second factors(ワンタイムパスワード2要素認証)をU2F-compatible Security Keys(ユニ バーサル2要素認証互換なセキュリティキー)に置き換えた。 従業員がインフラを操作するために用いるクライアントデバイスのモニタリングにも膨大な投資を 行っている。これらクライアントデバイスのOSに最新のセキュリティパッチがあたっているかを確認 し、インストール可能なアプリケーションを管理している。さらにインストールされたアプリ、ダウン ロードされたファイル、ブラウザ拡張、ブラウジングされたWebページなどをスキャンするためのシ ステムも備えている。 Reducing Insider Risk 内部リスクの低減 インフラにアクセス可能な従業員の行動はつねにモニタされ、同時に強く制限されている。またより 安全な作業を実現するために、徹底的な自動化によって特権的なアクセスを可能な限り排除する ようにしている。 Intrusion Detection 侵入検知 インフラの多数のデバイスからのモニタリング情報やシグナルから、ルールおよびインテリジェント な方法で侵入インシデントの可能性があった場合に警告が行われる。調査およびインシデント対応 チームが24時間365日、これに対応する。 Encryption at Rest 保存されるデータの暗号化  暗号化キーを用いてストレージのデータにアクセス  ハードディスクやSSDのレベルでの暗号化も利用 Deletion of Data データの削除 計画的な消去により、ユーザーの操作ミスあるいはバグやエラーなどによる意図しないデータ削 除にもデータの復旧が可能 Google Front End Service Googleのフロントエンド・サービス サービスがインターネットで利用可能になるために、サービスが自身をインフラが提供する Google Front End(GFE)に登録できる。GFEはTLSコネクションが適切に終了することや、 perfect forward secrecyといったセキュリティのベストプラクティスに沿った通信を実現する。 GFEはさらに、DoS攻撃からの防御も行う。
  80. 80. クラウド・コンピューティング の現実
  81. 81. クラウドで実現するガバナンス 81 ガバナンスを担保するためには・・・ 効率 利便性 コスト リスク ガバナンス Governance 状 況 が 見 え る 状 況 が 調 整 ・ 変 更 で き る  一元管理され、利用状況を計測でき、利用ログを把握できる。  必要な時に必要な機能/性能/資源をプロビジョニングできる。  管理の対象を減らすことができる。 クラウドで できること
  82. 82. クラウドによってもたらされる3つの価値 TCOの削減 バランスシート の改善 柔軟性 の向上 価 値 情 報 シ ス テ ム 部 門 経 営 者 ユ ー ザ ー TCO削減で ITの戦略投資 を拡大 ROAが改善 経営効率の高さ をアピール 変化に即応するシ ステム資源 調達の仕組み
  83. 83. 日米の企業文化の違いとクラウドへの期待IPA人材白書・2012/日経SYSTEMS 2012/8を参考に作成 ITエンジニア の人数 ユーザー 企業 ITベンダー企業 75% ユーザー企業 72% ITベンダー 企業 ITベンダー企業の生産性向上 + ベンダーがリスクを背負わされる ユーザー企業の生産性向上 + ユーザーが自らリスクを担保 エンジニアリング・ワークの生産性が劇的に向上 運用の自動化 + 調達の自動化 = エンジニアの調達・運用管理負担の軽減 約100万人 約300万人
  84. 84. クラウドの価値を引き出すための戦略 TCOの削減 変更変化への 柔軟性と迅速な対応 資産の削減 人員の削減 既存資産の償却 社会思想・企業文化の問題 ファイナンスの問題 スピード スケール アジャイル 戦略価値への期待 グローバル化の進 展 ビジネス・ライフサイ クル の短命化 顧客嗜好の多様化 効率・コストへの期待 ビジネス環境の変革に対応
  85. 85. パブリック・クラウド適用のリスク 85 管理主体の違い 事業者によるシステム設計と運営管理  投資の内容や優先順位の判断  セキュリティやサービスレベルの維持などの統制活動  障害や情報漏えいなどのインシデント発生時の情報連携  インシデントに関する情報開示範囲や原因究明作業に対するユー ザー関与に制約  インシデントの全体像や根本原因の特定が不十分な恐れ  自社のシステム環境の移植性の問題  サービス終了時にデータの引き継ぎに制約が生じる恐れ  サービス品質に対して実施するリスク管理の有効性について、 ユーザーが期待するレベルまで実施されていない、また、実施さ れていても情報開示の制約でユーザーが確認できない恐れ 情報開示の限界  セキュリティ管理ルールの十分性や運営実態について、情報開示 範囲に制約  契約で合意した内容の履行状況に関してユーザー側の確認が撮り にくい  ベンダーの情報開示情報と自社のセキュリティポリシーなどとの 整合性を十分の確認が困難 機能やサービス内容の制約 個別カスタマイズの制約  ユーザー固有のカスタマイズが実現できないため業務影響の見極 めや対策について検討が必要 サービスに関する意思決定権  事業戦略の変更や破綻などにより、一方的にサービスの終了や変 更、また、サポート停止により、ユーザーの業務継続や顧客への サービス提供に影響を及ぼす恐れ サービスの多様化・グローバル化 データの所在  データセンター設置国の法令への遵守  海外の現地規制当局の強制執行などによるデータ閲覧やデータ収 集、通信傍受により業務継続に支障、情報漏えいの恐れが ベンダーのグローバル化  本社拠点(各種意思決定機能)を海外に置くベンダーも多く、 サービス内容や提供価格、契約条件などの調整がスピード感を もって推進できない恐れ  ベンダーの本社が海外にあることで、係争時の管轄裁判所が海 外となり、海外の係争への対応が必要となる恐れ  インシデント発生時に時差や言語の問題から、ベンダー、ユー ザー間のコミュニケーションに支障をきたす恐れ 役割分担や責任範囲の多様化 責任や役割の固定化  ユーザーの個別要求事項を前提とした諸条件の調整が困難  自社のニーズをふまえた「融通」が利きにくく、ユーザー側で追 加の対応手続きやリソース手配などが必要となる恐れ  マルチベンダーで一つのITサービスを実現する場合情報連携に混 乱や支障をきたす恐れ 導入に伴うハードルの低下 簡単迅速なサービス導入  ユーザー部門が自社のセキュリティポリシーやシステム化方針な どへの影響確認を十分に実施せずに単独で導入してしまい、全社 的なシステム統制に影響を及ぼす恐れ http://japan.zdnet.com/article/35063430/
  86. 86. パブリック・クラウド 移行の勘所
  87. 87. パブリック・クラウドへ移行すればコストを削減できるか? 87 現行システム(オンプレミス)の構成や運用をそのままに移行しても コスト削減は難しい  サーバー台数  サーバー台数が多いとシステムが複雑になり、構築・インテグレーション費用が増加する  販売代理店(SI事業者など)に任せると台数に応じて販売マージンや手数料が必要となる  管理対象のサーバー台数が多いと保守・サポート費用が増加する  サーバー稼働時間  使わないサーバー・インスタンスが停止されずに動いている  割引が効くはずの年額一括にしたが、全てを使われずに無駄な費用を払ってしまう  常時稼働が前提のオンプレミスと同じ運用方法で料金が嵩んでしまう  サービス・レベル  パックアップ  冗長化構成  その他、サポートオプションの契約  データ転送コスト  ダウンロードデータ転送(外部へのデータ持ちだし)  外部ネットワーク回線費用(閉域網、国際回線等)  社員人件費  運用管理などに関わる社員の人件費はクラウドに機能が移管してもそのまま残存 SI事業者によっては、サーバー台数 を増やそうとする場合がある!
  88. 88. クラウドの見積り方(1) 88 必要だと思う 4コア リスク係数×1.5 +2コア 4+2=6コアはないので 仕方なく+2コア 8コア/1ソケットのCPU 本当に必要だった 2コア クラウド・サービス オンプレで調達する場合の構成 クラウドで調達する場合の構成 Microsoft Azure・東日本(2017年3月時点) 実需に応じ必要な能力を 調達すればいい オンプレと同じ 構成・見積は意味が無い CPUコア数の削減で1/4
  89. 89. クラウドの見積り方(1) 訂正版 89 必要だと思う 4コア リスク係数×1.5 +2コア 4+2=6コアはないので 仕方なく+2コア 8コア/1ソケットのCPU オンプレで調達する場合の構成 CPUコア数の削減で1/4 本当に必要だった 2コア クラウド・サービス クラウドで調達する場合の構成 実需に応じ必要な能力を 調達すればいい オンプレと同じ 構成・見積は意味が無い 削減
  90. 90. クラウドの見積り方(2) 90 夜間は使用しないので24時間→18時間でさらに2/3 「所有」では24時間が前提。これ稼働時間単位に変更(分単位で課金) データセンター使用料は無料 インフラの運用管理は自動化+お任せ クラウドならではのボトルネックや制約事項 オンプレ前提の見積ではなく、クラウドの特性を活かした見積でコストを下げられる可能性 CPUコア数の削減で1/4
  91. 91. クラウドサービスのコスト構造 91 アプリケーション ライセンス・構築(減価償却) 開発・実行環境 ライセンス・構築(減価償却) ハードウェア 調達・構築(減価償却/リース) データセンター・設備 設置費用・電気料金・賃借料金 IaaS PaaS SaaS 運用管理 サポート・ヘルプデスク 運用管理 運用管理 運用管理 社員が行っている場合 運用コストは削減されない
  92. 92. クラウドサービスのコスト構造 92 サーバー ストレージ データ転送 内部ネットワーク 外部ネットワーク 能力×時間 容量/月 転送量(GB) ダウンロード 定額/月 転送量 ポート速度100Mビット秒 オプション機能 FW、LBなど オプション単位 インスタンスの能力に よって料金は異なる。 外部へのデータ転送量 に応じて課金される。 サービスによって異な る。 セグメント数、外部 ネットワークとの接続 に伴うデータ転送量に 応じて課金される。 専用線などの閉域網、 海外DCとの国際回線の 費用などが必要となる。 サービスによっては標 準機能として提供され る場合もある。  冗長化構成を減らす  変動/固定を動的に組合せる  必要なインスタンスのみ稼働させる  運用を自動化する  ベンダーを通さず直接契約にする  データ・ライフサイクルを見直し ホット/コールドデータを分けて保管  容量無制限のファイルサーバーと組 み合わせる アクセス速度に応じて サービス・料金が異な る。  アプリケーション設計の見直し  同一セグメント内での転送  運用方法の見直し  セグメント内で完結するような設計  国際回線を多用する場合は回線料金 が組み込まれたサービスを選定  不要なオプションは設定しない オ ン プ レ ミ ス を そ の ま ま に 移 行 せ ず 構 成 ・ 運 用 を 再 設 計
  93. 93. 料金の削減のポイント(1) 93 必 要 能 力 調達するサーバー能力 必 要 能 力 調達するサーバー能力 運用自動化ツールの活用 よく似た運用パターン・グループ に集約しインスタンスを削減
  94. 94. 移管の考え方 94 IaaS PaaS SaaS オンプレミス・システム 1. コスト 5年間のTCO 2. BCP 遠隔多重化構成など 3. バックアップ/アーカイブ 電子メール、業務データなど 4. ユーザー利便性 応答時間、グローバル対応など 5. ガバナンス 見える化、管理機能など そのまま移行すれば  オンプレミスよりもコストが嵩む  運用管理負担が増える  機能面で利用部門のニーズに応えられない  サービスレベルが低下する  セキュリティが担保できない  上記、組合せの最適解を考える  クラウド前提のアーキテクチャーに見直す  情報システム部門の役割を再構築する
  95. 95. 移管に関する考慮事項 95 システム・アーキテクチャー変更にともなう  スループットやレスポンスなどの影響度 分析やリスク検証  投資を正当化するため、オンプレミスと の比較における投資対効果の明確化  非機能要件の見直し セキュリティポリシーや個人情報保護方針との適合性や システム監査への対応要件を満たすかどうかなど  運用方法の変更  パブリッククラウドの提供機能やセ キュリティポリシーなどの評価 既存業務システム (オンプレミス) パブリッククラウドへの移管 仮想サーバーの パブリッククラウドへの移管 パブリッククラウドでの 新規システム構築 海外システムのクラウド化  越境データ規制  個人情報保護規定  犯罪捜査権 など
  96. 96. システムデザイン勘所 96 Simple Design 物理的な制約を排除して、 追加や削除、変更が簡単に行えることを前提に構成を検討する 監視 Web: DB: 従来:コンパクトなシステム構成 クラウド:シンプルなシステム構成
  97. 97. システムデザイン勘所 97 Design of Failure 障害発生を前提とし、 障害が発生しても問題なく運用できるような設計を行うこと システム機器ではなくサービスとしての健全性を保つこと  全体の可用性の担保が最重要  SPOF(Single Point of Failur:単一障害点)を作らない構成 多様な監視方法を組み入れること  外からの監視:反応があるか、ないか  内からの監視:受けられるか、受けられないか  サービスからの報告:サービス自身の健全性の主張 データを収拾し、閲覧する体制を作る  いつでも、増やせる、削除できる仕組みとする  データを集積し、利用状況を分析する  分析結果を踏まえてブラッシュアップを継続する 自動化する  いつ起きるか分からないことへの対応を自動化で対処する  検知、報告、対応までの自動化を目指す 監視 ログ 収集 通知 復旧 改善 分析
  98. 98. クラウドへ移行するための3つの戦略 98 新しく作る システム 変えた方がいい システム そのまま残す システム クラウド・ネイティブ クラウド ネイティブ そのまま 移行 ベア メタル 連 係 リ フ ト シフト クラウド・サービス
  99. 99. クラウドへの移行を成功させるための7原則 99 1. 既存システムの移行をゴールとしない、クラウド・ネイティブの実現を目指す 2. 絶対に今まで通りでなければならない、という要件を排除する 3. クラウドならではの作法、考え方を許容する 4. ユーザー自身で運用管理する。そのためのスキル獲得予算を確保する 5. クラウド・インテグレーションにスキルのあるIT企業に参画してもらう 6. クラウドにあるサービスを割り切って使用する 7. ビジネスのデジタル化を実現する前提として、IT利用の在り方を見直す “なぜ「不毛なクラウド議論」がなくならない? 論外なIT部門7つの特徴”を参考に作成
  100. 100. クラウド移行の方向 100 リフト シフト シフト インテグレーション シフト クラウド クラウド クラウド 既存システムの一部移管 SaaSの利用 ハイブリッド・クラウド による連係運用・一元管理 オール・イン・クラウド への全面移行 Webスケール/クラウド技術 を使ったハードやソフト 各社HCI、Azure Stack、AWS Outposts、Google On-Premなど IoT/エッジ・コンピューティング リアルタイム・コンピューティング オンプレミス・コンピューティング 個別専用システム シフト ドロップ
  101. 101. クラウドへの移行が難しい場合 101 モノリシックなシステム:  オンプレミスで実行する必要のあるアプリケーションと緊密に結びついており、そのアプリケーション と関連するデータベースと統合され、特定のランタイムや特定のバージョンのデータベースサーバに合 わせてチューニングされている場合。  パフォーマンスや信頼性を確保するために、特定のプラットフォームの特定のバージョンのデータベー スにチューニングされている場合。 頻繁なデータ出力:  パブリック・クラウドは、データのアップロードは無料だが、出力には料金を課している。データ出力 が頻繁に発生する場合、課金が高額になる場合がある。 複雑なデータ構造:  データ構造が複雑で、公開されても構わないデータと外部に流出するリスクを冒すことが絶対に許され ないデータが混在している場合。 低レイテンシ:  オンプレミスとクラウド・データセンター間の回線の制約から、大量のデータをデータセンターからク ラウドに移動させるには、数時間、あるいは数日かかる場合。  リアルタイムのユーザーデータのやりとり、高速なアナリティクス、パーソナライゼーション、レコメ ンデーションなどを利用するモダンなアプリケーション。  モノのインターネット(IoT)。ローカルのIoTデバイスから速いペースでデータを収集しているので あれば、クラウドに直接データを送信するのでは時間がかかりすぎる可能性がある。オンプレミスデー タベースおよびエッジ・サーバーが合理的。 Zdnetの記事を参考に編集:https://japan.zdnet.com/article/35132951/
  102. 102. 異なる文化の2つのクラウド戦略 コスト削減のためのクラウド 競争力強化のためのクラウド 生産性向上・納期短縮・コスト削減  投資負担の軽減  運用管理負担の軽減  高い運用品質の維持 コスト削減  資産固定化の回避  最新技術の活用  俊敏性の実現 投資対効果 差別化・競争力・変化への即応力  既存システムのIaaS移行  運用管理の自動化  開発と運用の順次化  コンテナ×Kubernetes  PaaS×サーバーレス  開発と運用の同期化 クラウド・リフト 戦略 クラウド・ネイティブ 戦略 守りの文化 by 情報システム部門 攻めの文化 by 事業部門・経営直下 両者は異なるクラウドであることを前提に考える 予算と人材と戦略の一体化と適切な配分
  103. 103. パブリック・クラウド移行 企画書・計画書作りの勘所
  104. 104. クラウドを利用する目的 投資コスト(CapEX)の削減 運用コスト(OpEX)の削減 ベストミックスの実現 コスト削減から競争力の強化へ  保有(資産化)から利用(サービス化)  変更に伴うリスク回避  利用サービスの選別  自動化の促進  標準化・共通化(プラットフォーム化)  ハイブリットクラウド  マルチクラウド  サービス間の連携  守りのITから攻めのITへ  テクノロジーを活かした事業の差別化 自社で所有することの限界  ガバナンスとセキュリティ  災害対応(Disaster Recovery)  グローバル展開  利用状況の徹底した見える化  少ない投資コストでの災害対応  フラットなグローバルサービス
  105. 105. クラウドのメリットを経営層にどう伝えるか 105 自社で所有することの限界  ガバナンスとセキュリティ  災害対応(Disaster Recovery)  グローバル展開  利用状況の徹底した見える化  システム利用の状況やリスクを把握しやすい  必要な対策を事実に基づいて行える  高度なセキュリティ認証に対応している(高度なスキル・高額なコスト)  少ない投資コストでの災害対応  高度な災害対応を施した施設にて運用  複数の独立したアベイラビリティゾーン  国内外の分散レプリケーション可能、しかもアップロードコストは不要  フラットなグローバルサービス  世界中にデータセンター  世界中で同一のアーキテクチャ  マルチクラウド化によりさらなるリスク分散
  106. 106. クラウドのメリットを経営層にどう伝えるか 106 投資コスト(CapEX)の削減  保有(資産化)から利用(サービス化)  初期投資が抑制される  資産を経費化できる  変更に伴うリスク回避  使用量に応じた従量課金  アプリケーション機能の変更や負荷の変動に柔軟に追従できる
  107. 107. クラウドのメリットを経営層にどう伝えるか 107 運用コスト(OpEX)の削減  利用サービスの選別  低コストのデータセンターで運用されるためコスト削減が行いやすい  最適なサービスを選択し組み合わせることができる  目的や予算などの条件  利用スキルの習熟度  サービス・レベル  自動化の促進  広範な自動化ツールを利用できる  運用監視  構成管理  変更管理など  標準化・共通化(プラットフォーム化)  運用管理や開発・実行環境の運用コストが削減できる  システムの調達・構築や変更のコストが削減できる  PaaSを活用することで開発や保守のコストが削減できる
  108. 108. クラウドのメリットを経営層にどう伝えるか 108 ベストミックスの実現  ハイブリットクラウド  プライベートクラウド  コンプライアンス  レイテンシー  運用管理の自由度など  パブリッククラウド  コスト  サービス機能  グローバル対応 など  マルチクラウド  サービス機能やコストなどの特性に応じた使い分け  サービス間の連携  EBS(Enterprise Service Bus)による疎結合  セルフサービスポータルや統合管理ツール(オーケストレーター)
  109. 109. クラウドのメリットを経営層にどう伝えるか 109 コスト削減から競争力の強化へ  守りのITから攻めのITへ  最新のテクノロジーを活かした事業の差別化ができる  グローバル展開が容易に、迅速にできる  構築や保守のスピードが早く、ビジネス環境の変化に即応できる  テクノロジーを活かした事業の差別化  新しいサービスモデルを構築できる  最新のテクノロジーがクラウドから提供される
  110. 110. 予算はどう変わるのか 110 データセンター or 自社のサーバールーム 「資産」から「経費」への転換  プログラム・ライセンス(経費)  プログラム・サポート(経費)  運用管理/派遣(経費)  システム開発(資産)  ハードウェア資産(資産)  サブスクリプション(経費)  システム開発(資産)  マネージド・サービス(経費) 経費は工夫と改善で 継続的に削減可能
  111. 111. クラウド時代の情報システム人材の活かし方 111 戦略・企画 業務分析 システム設計 アプリケーション開発 インフラ プラットフォーム構築 保守 運用管理 ヘルプデスク 現場サポート 戦略・企画 業務分析 システム設計 アプリケーション開発 「攻めのIT活用」拡大 インフラ・プラットフォーム構築 保守 運用管理 ヘルプデスク 現場サポート  情報システム部門の機能と役割を再定義  経営企画や業務戦略スタッフとの人材交流  業務部門との人材交流  アジャイル開発  高速開発ツールやPaaSの活用  SaaSの活用  シチズン・デベロッパーの育成  ホステッド・プライベートクラウド  自動化  DevOps  高速開発ツールやPaaSの活用  SaaSの活用 システム・アーキテクト ビジネス・アーキテクト ビジネス価値を明らかにし、最適なビジネス・プロセ ス描き、それを実現するシステムをデザインする。 テクノロジーやサービスに精通し、それらを目利きで き、最適なシステムをデザインする。
  112. 112. 運用技術者からSREへ 112 ITの実務上の利用方法について問い合わせを受けて対応する 窓口業務 定められたオペレーションを繰り返し実施する定常業務 ITに関するトラブルに対応する障害対応業務 インフラ(ネットワークやOS・ハードなどの基盤部分)に関 する管理業務(構成管理やキャパシティ管理など) 積極的にソフトウェアで 置き換えていく  クラウド・サービス  自動化ツール ビジネスもアプリも要件がどんどん 変わっていくので、継続的に改善、 手作業をソフトウェアに置き換えて いく必要がある  変更への即応性や信頼性の高いシステム基盤を設計  運用管理の自動化/自律化の仕組みを設計・構築  開発者が利用しやすい標準化されたポリシーやルールの整備 運用技術者 Operator / Operation Engineer SRE Site Reliability Engineer 組織横断的なインフラ整備 作業者から ソフトウェアエンジニア への変身! http://japan.zdnet.com/article/35090649/ http://torumakabe.github.io/post/bookreview_site_reliability_engineering/ 参考になる記事:
  113. 113. クラウド・コンピューティング とWebスケール
  114. 114. クラウド・コンピューティングとWebスケール 114 ユ ー ザ ー 数 の 増 大 システム能力の増強 クラウドの登場 いつでもどこでも、ネットにつながれば 望むサービスを受けられるようになった Webスケール(Web Scale) 量的かつ質的に、従来とは桁違いに ユーザー/データ/システム資源が 継続的に増大する状況 スケールアウト(Scale-out) ユーザー インターフェイス ビジネスロジック データベース プレゼンテーション層 アプリケーション層 データ層 Webサーバーの分散 アプリケーション サーバーの分散 Map Reduceなど KVS、BigTabelなど NoSQLデータベース
  115. 115. クラウド・コンピューティング登場と発展の歴史 115 インターネット・クラウドの登場 エンタープライズ・クラウドへの派生 エンタープライズ・クラウドの自立 Webスケールの多数の一般ユーザーを対象として、 彼らにインターネットを通じて 大規模なサーバーおよびデータセンター・サービスを提供  コモディティ化したマシンを多数並べて並列動作させるという画期的なScale-outアーキテクチャ  GFS、MapReduce、BigTableというGoogleの大規模分散技術 エンタープライズ(企業ユーザー)を対象とする 大規模なサーバーおよびデータセンター・サービスの提供  ECサイト運営の経験から膨大なリソースを合理的に管理する方法を編み出す。  開発者が調達・運用管理・保守などから開放し、本来集中すべき仕事に集中させる仕組みを構築。 エンタープライズ(企業ユーザー)を対象とし クラウドとオンプレミスとの境界を取り払った シームレスなリソース・プールを実現  Windows Azure Platform と Windows Serverの互換性  両者を統一的に管理する「クラウドOS」の登場 http://thinkit.co.jp/article/1024/1 「クラウド創世記(丸山不二夫著)」を参考に作成 2004〜 2006〜 2008〜 ユ ー ザ ー 範 囲 年代 クラウド・コンピューティング =Webスケールに対応できるサービス
  116. 116. WebスケールIT 116 http://japan.zdnet.com/article/35054843/ WebスケールIT WebスケールITは、企業内のIT部門が大規模なクラウド・サー ビス・プロバイダーと同じ能力を提供する、グローバル・クラス のコンピューティングの一形態です。多くの企業・組織が AmazonやGoogle、Facebookのような大手Web企業と同じよう に考え、行動し、アプリケーションとインフラストラクチャを構 築するようになるでしょう。WebスケールITは短い期間に起こ るものではなく、商用ハードウェア・プラットフォームが新しい モデルを採用し、クラウド向けに最適化されたソフトウェア定 義型のアプローチが主流となる流れの中で進化・発展してい きます。多くの企業にとってWebスケールITの将来に向けた 最初のステップとなるのがDevOpsであり、調和が取れた環境 で開発と運用を統合することにより、アプリケーションとシステ ムの、迅速かつ継続的でインクリメンタル (増分追加型) な開 発を実現します。 http://www.gartner.co.jp/press/html/pr20141028-02.html サーバー ネットワーク ストレージ(SAN/NAS) CPU NW 機能 ソフトウェアによる管理機能 CPU NW 機能 CPU NW 機能 追加 拡張 スケール アウト 従来型インフラ 管理が複雑で ハードウェアの拡張性に ボトルネック Webスケール ハイパー・コンバージド・システム 独立サーバーを複数連結し 簡単・無制限に拡張
  117. 117. スケール アウト WebスケールITの条件 標準化されたモジュール サーバー、ネットワーク、ストレージで1単位のモジュール構成 全てをソフトウエアで設定・構成 システム全体の構成をソフトウエアの設定で行える 自己修復 障害の検知、切り分け、分散処理で自動的に修復 データとサービスを分散 データの管理とアプリケーション・サービスを分散処理 APIと自動化 アプリケーションや管理ツールと連携して運用や調達を自動化 CPU NW 機能 CPU NW 機能 CPU NW 機能 CPU NW 機能 CPU NW 機能 CPU NW 機能 CPU NW 機能 CPU NW 機能 追加 拡張 性能の 連続的拡張
  118. 118. クラウドによるコスト改善例
  119. 119. 評価対象としたアプリケーション 119 アンケート登録/集計システム
  120. 120. 120 店舗入力 ダウンロード イベント ログイン画面 店頭用入力画面 集計ファイル作成画面 ダッシュボード画面 イベント用入力画面 Write Write Read Read 認証されたユーザのみ アクセス可能なページ 評価対象としたアプリケーション/処理フロー よ く あ り が ち な webシステム
  121. 121. 構築事例:従来型のWebアプリケーション・アーキテクチャ 121 EC2 Internet クライアント Elastic Load Balancing EC2 冗長化 EC2 EC2 EC2 EC2 EC2 冗長化 冗長化EC2 EC2 Web AP DB死活監視 DNS DNSのセットアップが必要 APはそのまま移行。ただし、セッション管理等、一部改修が 必要な場合がある。 ミドルウェアが必要 (Oracle、 SQLServer、死活監視ソフト等の購入) DBMSのセットアップが必要 EC2:1台 365日24時間稼働:$175.2 EC2:9台 365日24時間稼働:$1576.8 ELB:1台 365日24時間稼働:$236.52+α ELB:2台 365日24時間稼働:$473.04+α リージョン:東京 <EC2> インスタンスタイプ:t2.micro (最少) 料金:$0.020/1時間 <ELB> 料金:$0.027/1時間 +$0.008/1GB 年間:約$2049.84 約254,980円 ※2015/3/20時点
  122. 122. 構築事例:AWSサービスを活かしたアーキテクチャ 122 EC2 Internet クライアント Elastic Load Balancing EC2 冗長化 EC2 EC2 冗長化 Web AP DB DNS Route 53に 設定するのみ 死活監視のソフトウェア不要 基本的に無料/アラーム設定でメール通知 DBMSはインストール不要  Oracle、SQLServer等のライセンス料込  EC2の接続先を変更するだけ 冗長構成はMulti-AZを選択するのみ EC2:4台 365日24時間稼働:$700.8 ELB:2台 365日24時間稼働:$473.04+α RDS: 365日24時間稼働:$455.52 Route53: 1年間:$26.4(最少) リージョン:東京 <EC2> インスタンスタイプ:t2.micro (最少) 料金:$0.020/1時間 <ELB> 料金:$0.027/1時間 +$0.008/1GB <RDS> インスタンスタイプ: t2.micro (最少) 年間:約$1655.76 約198,691円 Cloud Watch Route 53 RDS(Master) RDS(Slave) DynamoDB セッション 管理 ※2015/3/20時点
  123. 123. 構築事例:AWSサービスを最大限活かしたアーキテクチャ 123 Internet クライアント Cloud Front 画面表示は、 クライアント側 アプリ メールサーバー不要 冗長構成、拡張・データ再配置 はAWS任せ リージョン:東京 <S3> 料金:$0.0330/GB +リクエスト数+データ転 送量 <CloudFront> 料金:$7.2/年 (試算した結果) <Lambda> 料金:$0 <DynamoDB> 料金:$0 (試算した結果) 年間:約$7.56 約907円 Cloud Watch JavaScript 入力ページ(HTML) コンテンツ 非公開コンテンツ Log等 S3 DynamoDB Lambda Node.js テーブル Cognito Webサーバー機能 3箇所以上で自動複製、容量無制限 キャッシュ SSL証明書 任意のタイミングで処理実行 負荷分散、障害対策はAWS任せ AWS認証 アプリ認証 SignedURL発行 サーバ側アプリ ※2015/3/20時点 ※条件によって料金は異なります
  124. 124. 補足資料
  125. 125. IoT Internet of Things クラウドがもたらす本当の変化(1) リアルとネットの融合と日常化 クラウド + モバイル + IoT が一体となったIT基盤 これからのビジネス や生活の基盤 職場だけではない 日常生活や行動が ネットワークを介して 情報システムとつながる 新しい社会基盤 本質的 な変化 クラウ ド 常時接続 随時接続 ソーシャル パーソナル ビジネス モバイル Smart Mobile Device PC Personal Computer 従来の システ ム
  126. 126. クラウドがもたらす本当の変化(2) ネットにつながる デバイスやモノの数が増える 機械の操作やサービス利用の 難しさから解放される アクセス手段が多様化する 仕事のやり方が変わる 人との係わり方が変わる 価値観が変わる 常識が変わる = パラダイム・シフト 表面的 な変化 クラウド + モバイル + IoT が一体となったIT基盤 これからのビジネス や生活の基盤 職場だけではない 日常生活や行動が ネットワークを介して 情報システムとつながる 新しい社会基盤 本質的 な変化
  127. 127. クラウド・インテグレーターになるための要件(1) 127  まずは提案するサービスに精通する  従来型のSIと変わらない。クラウド・サービスについての各種トレーニング を活用し、全ての内容を知っておくこと  認定資格を設けているところもあるので利用すべし  「クラウドができます」だけでは仕事は来ない。自分たちならではの得意や 魅力の訴求は不可欠  短納期に慣れる  通常3ヶ月程度で案件クローズ。短い場合は1ヶ月の場合もある  日々の状況整理が重要  朝会、夕会、チケットなどでできるだけメンバーの負荷を軽減する  アジャイル型のプロジェクト運営に慣れる  契約は(定額)準委任契約または請負契約が一般的  ただしアジャイルでは緩すぎてお客様の不審を招く  従来SIのように定例会、成果物を意識しながら柔軟に要件の変化に対応
  128. 128. クラウド・インテグレーターになるための要件(2) 128  MS Officeを捨ててください  瞬時にドキュメントを共有できるGoogle AppsもしくはOffice 365 を 使ってください  社内のファイルサーバを捨ててください  Google Drive/BOX/Dropboxを使ってください  メールを捨ててください  Slackを使ってください  Excel/MS Projectのプロジェクト管理を捨ててください  Redmine/Atllasian Confluenceを使ってください  社内のソースコード管理サーバを捨てて下さい  GitHub/Bitbucketを使ってください  社内検証サーバを捨ててください  パブリッククラウドを使ってください  私用のスマートフォンやパソコンで”どこでも”仕事をさせてください  これはオフィスで、といった決まり事はなくしてください
  129. 129. 129 ネットコマース株式会社 180-0004 東京都武蔵野市吉祥寺本町2-4-17 エスト・グランデール・カーロ 1201 http://www.netcommerce.co.jp/

×