LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
•
4 gefällt mir•410 views
https://libra.netcommerce.co.jp/
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
Ähnlich wie LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け (20)
Mehr von Masanori Saito
Mehr von Masanori Saito (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
- 2. もくじ 最新ITトレンドを理解するために知っておきたい 基礎知識 ビジネスの前提を再定義する デジタル・トランスフォーメーション 変化に俊敏に対応するための ITインフラストラクチャー コンピュータ利用の常識を変える クラウド・コンピューティング デジタル時代の危機に対処するための サイバー・セキュリティ これからのビジネス基盤となる IoT／モノのインターネット デジタル時代のデータ連係基盤となる 5G （次世代移動体通信システム） 人に寄り添うITを実現する AI／人工知能 圧倒的なビジネス・スピードに対処するための 開発と運用 DXの実践といま求められる 人材
- 9. UI／UXとは何か UI 人とデジタルをつなぐ窓口 User Interface 直ぐに分かる 使い易い 迷わない など UX 人とデジタルがつながることで得られる体験 User Experience とても便利 もっと使いたい 感動した など UI UX
- 10. UI／UXとは何か UI 人とデジタルをつなぐ窓口 User Interface 直ぐに分かる 使い易い 迷わない など UX 人とデジタルがつながることで得られる体験 User Experience とても便利 もっと使いたい 感動した など 次へ 戻る 戻る 次へ ×良くないUI 〇良いUI ×良くないUI ケチャップだとは すぐに分からない。 ×良くないUX 口を汚しやすく、少なく なると使いにくい。 〇良いUI ケチャップだとすぐ 分かる。 ×良くないUX 口を汚しやすく、少なく なると使いにくい。 〇良いUI ケチャップだとすぐ 分かる。 〇良いUX 口を汚さず、最後まで 使い切ることができる。
- 11. データとUXとサービス データ とても便利 もっと使いたい 感動した など UX 体験価値 ファンを増やす 信頼を高める リピートさせる ビジネス機会の創出 高速に改善と アップデートを繰り返し 体験価値を維持する サービス 属性データ 体験データ 生活データ
- 12. デジタルとは何か
- 13. デジタル化とは何か アナログ Analog 連続量（区切りなく続く値を持つ量） 現実世界 私たちが生きている世界 身体を介して体験し、実感できる IT Information Technology：情報技術 コンピューターやネットワークを実現し それを活用するための技術 Physical World デジタル Digital 離散量（とびとびの値しかない量 ） サイバー空間 コンピューターとネットワーク で作られた世界 コンピューターやネットワークで扱える Cyber Space デジタル化 センサー・web・モバイル などを介し アナログをデジタルに 変換すること ICT Information and Communication Technology 情報通信 技術
- 14. デジタル化でできることと目指すこと 人間のやっていたことを、コンピュータでできるようにすること これまで1週間かかっていた申し込み手続きを5分で終わらせる 顧客の行動（いま、どこで、何をしているのか）が分かる 他のデジタル・サービスと一瞬にして連係できる 膨大なデータの中にビジネスに役立つ規則や関係を見つけることができる 業務の進捗、人の動き、ビジネスの状態が、リアルタイムに見える化される デジタル化で できる こと デジタル Digital 離散量（とびとびの値しかない量 ） サイバー空間 デジタル化で 目指す こと 顧客満足の向上 業績の改善 社員の幸福 アナログ Analog 連続量（区切りなく続く値を持つ量） 現実世界だけでは解決できない課題をデジタルを使って解決すること 現実世界 目的 自分は何をしたいのか？ 手段 うまい、やすい、はやい
- 18. デジタル化とデジタル技術の役割 複雑な業務プロセス 抽象化された要素へ分解 コンテナ マイクロサービス サーバーレス など レイヤ／要素の組み替えや新たな組合せが容易 アジャイル開発 DevOps クラウド など デジタル化 レイヤ構造化 レイヤ／要素の組み替え や新たな組合せを短期間 で実施して変化へ即応 プラットフォーム 疎結合／データハブ API連係など 単純化 抽 象 的 具 体 的 クラウド・サービス
- 20. 2つのデジタル化：デジタイゼーションとデジタライゼーション デジタイゼーション Digitization アナログ放送→デジタル放送 紙の書籍→電子書籍 人手によるコピペ→RPA 効率化 ビジネス・プロセス 改善・改良・修正 コストや納期の削減・効率化 ビジネス・モデル デジタライゼーション Digitalization 自動車販売→カーシェア／サブスク ビデオレンタル→ストリーミング 電話や郵便→SNS・チャット 変革 事業構造の転換 新しい価値の創出 既存の改善 企業活動の効率向上と持続的な成長 既存の破壊 新たな顧客価値や破壊的競争力を創出
- 24. DXが注目される背景
- 28. 時間感覚の変化がビジネスを変えようとしている ビジネス・モデル お客様との関係 働き方 情報システム 社会環境の変化が緩やかで中長期的な予測が可能 社会環境が複雑性を増し将来の予測が困難な状況
- 29. VUCAの時代の課題に対するアプローチ方法 VUCA／社会環境が複雑性を増し将来の予測が困難な状況 何が正解かは、分かはわからない 気がついたなら、直ちに行動しなければ、対応が遅れてしまい、 チャンスを逃してしまうから。 仮に間違ったとしても即座にやり直しが効き、大きな痛手に至るこ とを回避できるから。 スピードを追求すれば物事をシンプルに捉えて、本質のみに集中で きるから。 アイデアが湧いたら、やってみる。その結果から議論を展開すれ ば、より現実的な解に到達できる。 圧倒的なビジネス・スピードを手に入れること
- 30. DXの定義
- 32. DXの定義 デジタル・トランスフォーメーション 2004年、スウェーデンのウメオ大学教授であるエリック・ストルターマンの提唱した概念 ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させること デジタル・ビジネス・トランスフォーメーション 2010年代、マイケル・ウェイドらによって提唱された概念 デジタル技術とデジタル・ビジネスモデルを用いて組織を変化させ、業績を改善 すること 経済産業省の定義するデジタル・トランスフォーメーション 2018年、経済産業省が公表した定義 企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、 顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するととも に、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位 性を確立すること デジタル・テクノロジーの進展により産業構造や競争原理が変化し、これに対処できなけ れば、事業継続や企業存続が難しくなる 競争環境 、ビジネス・モデル、組織や体制を再定義し、企業の文化や体質を変革すること 変化に俊敏に対応できる企業へと変わること
- 34. デジタル 既存事業 デジタル・トランスフォーメーション DXの公式 業務プロセス のデジタル化 ビジネスモデル のデジタル化 対社外 対社内 リアルタイム データ ストック データ 事実の迅速な把握 現実の理解と未来の予測 AI、IoT、5Gなど 圧倒的なスピードの獲得 変化への柔軟性を獲得 クラウド、アジャイル、DevOpsなど レイヤ構造と抽象化 変化に俊敏に対応できる 企業に変わること 人間をエンパワーすること デジタルにできることは徹底してデジタルに任せて 人間にしかできないことに徹底して役割をシフトする スピード イノベーション
- 36. CXとEXを向上させるためのDX データ CX : Customer Experience お客様の事業の成果に貢献し お客様の社員の幸せを支える EX : Employee Experience 従業員のやり甲斐を与え 自己の成長の喜びを感じさせる 競争原理 収益構造 業務手順 組織・体制 意志決定方法 など DX デジタルを前提に ビジネス・モデルや ビジネス・プロセス を再定義する デジタル 技術 クラウド AI IoT など 変化に俊敏に対応できる 企業の文化や 風土への変革 UX ユーザーの 体験価値を 高める 業務プロセスのデジタル化 デジタル・ビジネス・モデル
- 39. インターネットに接続されるデバイス数の推移 億人 億台 台/人 2003年 2010年 2015年 2020年 世界人口 インターネット 接続デバイス数 一人当りの デバイス数 63 68 72 76 5 125 250 500 0.08 1.84 3.47 6.50
- 40. 「データの時代」とはどういうことか 加速度計センサー ジャイロセンサー 磁気センサー GPSセンサー 生体（指紋／顔）認証センサー 近接センサー 赤外線センサー Soli（レーダー）センサー LiDAR（レーザー・レーダー）センサー CMOS（カメラ）センサー ソーシャル・メディア オンライン・ショッピング オンライン英会話 など 現実世界のデジタルコピー デジタル・ツイン ビッグデータ 膨大・多様・加速度的増大 現実世界のものごとやできごとは 意図する／しないに関わらず デジタル・データに置き換えられ ネットに送り出される時代になった
- 41. サイバーフィジカルシステムとDX データ収集 モニタリング データ解析 原因解明・発見/洞察 計画の最適化 データ活用 業務処理・情報提供 機器制御 ヒト・モノ クラウド・コンピューティング 日常生活・社会活動 環境変化・産業活動 現実世界／Physical World サイバー世界／Cyber World Cyber Physical System／現実世界とサイバー世界が緊密に結合されたシステム 高速 × 最適 デジタル トランスフォーメーション 最適解 機器制御 指示命令 アドバイス ものごと・できごと データ ものごと・できごと データ
- 42. DXを支えるテクノロジー・トライアングル 現実世界／Physical World Cyber Physical System／現実世界とサイバー世界が緊密に結合されたシステム サイバー世界／Cyber World 予 測 最適解 ビジネス の最適化 データ解析 データ活用 AI・機械学習 クラウド 機械学習・深層学習 AIチップなど サーバーレス・コンテナ SaaS・PaaSなど データ収集 デジタル ツイン IoT センサー・モバイル 自律制御など 現実世界の デジタルコピー 5G 第5世代通信システム
- 48. 仮想 virtual 表面または名目上はそうでないが 実質的には本物と同じ 本来の意味 「仮想化」の本当の意味 本来の意味 仮想化 Virtualization 物理的実態とは異なるが、 実質的には本物と同じ機能を実現する仕組み 日本語での語感 虚像の〜 実態のない〜 It was a virtual promise. （約束ではないが）実際には約束も同然だった。 He was the virtual leader of the movement. 彼はその運動の事実上の指導者だった。
- 50. 物理資源・物理機械 サーバーの仮想化 ストレージの仮想化 Java仮想マシン データベースの仮想化 パーティショニング 分 割 アグリゲーション 集 約 エミュレーション 模 倣 仮想化 (Virtualization) ひとつの物理資源を 複数の仮想資源に分割 複数の物理資源を ひとつの仮想資源に分割 ある物理資源を 異なる資源に見せかける 仮想化の3つのタイプ
- 51. ソフトウェア化とはどういうことか（１） 掃除 機能 掃除 機械 レンジ 機能 レンジ 機械 テレビ 機能 テレビ 機械 作表 機能 文書作成 機能 会計管理 機能 汎用機械 オペレーティング・システム（OS） 家電製品 コンピュータ 専用一体 専用一体 専用一体 ソフトウェア Software ハードウェア Hardware
- 54. 仮想化 や ソフトウエア化 のための仕組み 使いたい機能や性能の組合せや変更の自由を実現 ソフトウェア化された情報システムの機能や性能を使うサービス 簡単・便利・いつでも／どこでもITの機能や性能をサービスとして使える仕組み 実質的に使える機能や性能 ネットワーク 専門的な スキルや ノウハウ 大規模・集中化・一元化・標準化 自動化などを駆使して、魅力的な コストパフォーマンスを実現する 物理的なハードウェアや設備 インフラストラクチャー プラットフォーム アプリケーション 運用管理者 特定の業務処理 を行うためのソフトウェア アプリケーションで共通に使う機能 を提供するソフトウエア オペレーティングシステム データベース管理システム など 販売管理システム 会計管理システム など ソフトウエアを動かすための ハードウェアや設備
- 58. 仮想化の種類
- 60. システム利用形態の歴史的変遷 OS OS AP AP AP AP AP AP 3 2 1 1950年代〜／バッチ 1960年代〜／タイムシェアリング メインフレーム メインフレーム ミニコン OS AP AP AP OS OS VM VM VM 1970年代〜／仮想化（仮想マシン） メインフレーム ミニコン OS AP AP AP OS OS 1980年代〜／分散化 ミニコン PCサーバー OS AP AP AP OS OS VM VM VM 2000年代〜／仮想化（仮想マシン） PCサーバー クラウド (IaaS) OS AP 設定 AP 設定 AP 設定 コンテナ コンテナ コンテナ 2015〜／コンテナ PCサーバー クラウド (PaaS) メインフレームの時代 オープン・システムの時代 クラウドの時代
- 61. 物理システム・仮想化・コンテナの比較 物理サーバー （ハードウェア） ミドルウェア アプリ アプリ アプリ ハイパーバイザー 仮想サーバー 仮想サーバー 仮想サーバー 物理システム 仮想化されたシステム ミドルウェア ミドルウェア 物理サーバー （ハードウェア） 物理サーバー （ハードウェア） ストレージ CPU メモリ ストレージ CPU メモリ ストレージ CPU メモリ 物理サーバー （ハードウェア） ミドルウェア アプリ アプリ アプリ ミドルウェア ミドルウェア OS コンテナ・システム 物理サーバー （ハードウェア） ミドルウェア アプリ アプリ アプリ ミドルウェア ミドルウェア ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 コンテナ管理システム コンテナ コンテナ コンテナ カーネル OS OS OS OS OS OS
- 62. サーバー仮想化とコンテナ OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ サーバー仮想化 ハードウェア コンテナ管理ソフトウエア OS ミドルウェア アプリ ミドルウェア アプリ ミドルウェア アプリ コンテナ コンテナ コンテナ コンテナ ライブラリ 環境変数 ライブラリ 環境変数 カーネル カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 隔離されたアプリケーション実行環境を提供（クラッシュの分離、独自のシステム管理とユーザー・グループ） 実行イメージのスナップショットをパッケージとしてファイルにして保存できる アプリケーションに加えて仮想マシン・OS の実行イメージを持つ必要がある アプリケーションとOSの一部 の実行イメージを持つ必要がある デプロイするサイズ 大きい 起動・停止時間 遅い デプロイするサイズ 小さい 起動・停止時間 早い 異なるOS 可 異なるOS 不可 メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い 構成の自由度が高い 異なるOS・マシン構成を必要とする場合など 軽量で可搬性が高い 実行環境への依存が少なく異なる実行環境で稼働させる場合など サンド・ボックス化 Sand Box
- 67. DockerとKubernetes の関係 67 コンテナの作成 コンテナの実行 コンテナ内でファイルシステ ムとして使われるイメージの 作成および管理 など 関連するコンテナのグルーピング コンテナに割り振られるIPアドレスの管理 コンテナ間ネットワークルーティング管理 複数のコンテナを利用した負荷分散 コンテナに割り当てるストレージの管理 コンテナの監視 など ネットワークのルーティングや複数コンテナの 連携、複数台のサーバーを対象にコンテナを横 断的に管理する機能などは提供されていない。 クラスタ環境でDockerを利用する場合は別途何らかの管理手法を用意する必要がある。 Dockerと連携して利用できるデプロイ/オーケストレーションツールのひとつ By Google Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops. Linuxコンテナのクラスタを単一のシステムとして管理して 開発を加速し、運用を簡素化します。 意味：ギリシャ語で「人生の道標」 読み方：クーベルネイテス（koo-ber-nay'-tace）
- 68. Twelve Factorsとの関係 68 Ⅰ. コードベース バージョン管理されている1つのコードベースと複数のデプロイ Ⅱ. 依存関係 依存関係を明示的に宣言し分離する Ⅲ. 設定 設定を環境変数に格納する Ⅳ. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う Ⅴ. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する Ⅵ. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する Ⅶ. ポートバインディング ポートバインディングを通してサービスを公開する Ⅷ. 並行性 プロセスモデルによってスケールアウトする Ⅸ. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する Ⅹ. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ Ⅺ. ログ ログをイベントストリームとして扱う Ⅻ. 管理プロセス 管理タスクを1回限りのプロセスとして実行する アジリティーの高いWebサービスを構築するための方法論 コンテナ Kubernetes https://12factor.net/ja/
- 69. Kubernetes Master 全体のコンテナの稼働 状況などを把握し、運用 管理者が指定したよう に、コンテナ配置、削除 などを指示 Kubernetes の全体構造 69 コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア Kubernetes Node Kubernetes Node Kubernetes Node Kubernetes Pod Kubernetes Pod Kubernetes Pod Kubernetes Pod コンテナ管理システム コンテナ管理システム が稼働しているマシン ／サーバーの単位 コンテナの まとまりの単位 Kubernetes Cluster Nodeの集まりの単位 物理マシン／仮想マシン yaml形式記載された設定 ファイル kubectlコマンドを使って、 設定をKubernetes Masterに反映 Kubernetes Masterは反 映された内容を元に、 NodeやPodを操作 マニフェスト 意味：ギリシャ語で「人生の道標」 読み方：クーベルネイテス 略称：K8s
- 70. デスクトップ仮想化とアプリケーション仮想化 ネットワーク 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 メモリー ストレージ ハイパーバイザー PC用OS （Windows7など） プロセッサー 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 クライアントPC 文書作成 画面表示 仮想PC サーバー PC用OS （Windows7など） 文書 作成 表 計算 プレ ゼン ・・・ 仮想PC メモリー ストレージ OS プロセッサー サーバー ターミナル・モニター 文書 作成 表 計算 プレゼン ・・・ 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 入出力操作 通信 クライアントPC 文書作成 画面表示 デスクトップ仮想化 アプリケーション仮想化
- 71. シンクライアント ネットワーク 入出力操作 通信 シンクライアント 文書作成 表計算 プレゼン ・・・ 画面表示 メモリー ストレージ ハイパーバイザー PC用OS （Windows7など） プロセッサー PC用OS （Windows7など） PC用OS （Windows7など） 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 シンクライアント 文書作成 表計算 プレゼン ・・・ 画面表示 仮想PC 仮想PC 仮想PC サーバー ストレージ 文書作成 表計算 プレゼン ・・・ 入出力操作 通信 アプリケーション PC / Windows・Mac OS など 画面表示 データとプログラムの保管 プログラムの実行 は、PC内にて処理 データとプログラムの保管 プログラムの実行 は、サーバー内にて処理 シンクライアントは 画面表示と入出力操作
- 72. Chromebook インターネット データ 文書作成 表計算 プレゼン ・・・ ブラウザ 画面表示・入出力操作 通信 画面表示・入出力操作 通信 オフィス・アプリ データ 文書作成 表計算 プレゼン ・・・ オフィス・アプリ クラウドサービス Google Apps for workなど ブラウザ 文書作成 表計算 プレゼン ・・・ PC / Windows・Mac OS など Chromebook / Chrome OS
- 74. ストレージ仮想化 2TB 実データ 3TB 実データ 5TB 実データ 10TB 10TB 10TB 仮想ストレージ ブロック仮想化 10TB 実データ 30TB ストレージ（ハードウェア） 8TB 7TB 5TB 未使用領域 20TB ボリュームの仮想化 10TB 10TB 10TB 仮想ストレージ シンプロビジョニング 10TB 実データ 30TB ストレージ（ハードウェア） 容量の仮想化 未使用領域 0TB 必要な時に 追加 2TB 実データ 3TB 実データ 5TB 実データ 8TB 7TB 5TB 仮想ストレージ 重複排除 ストレージ（ハードウェア） データ容量の削減 D A B C E F A B ファイル ２ ファイル１ D A B C E F 重複データ を排除
- 77. クラウドの使われ方と戦略
- 78. 異なる文化の２つのクラウド戦略 コスト削減のためのクラウド 競争力強化のためのクラウド 生産性向上・納期短縮・コスト削減 投資負担の軽減 運用管理負担の軽減 高い運用品質の維持 コスト削減 資産固定化の回避 最新技術の活用 俊敏性の実現 投資対効果 差別化・競争力・変化への即応力 既存システムのIaaS移行 運用管理の自動化 開発と運用の順次化 コンテナ×Kubernetes PaaS×サーバーレス 開発と運用の同期化 クラウド・リフト 戦略 クラウド・ネイティブ 戦略 守りの文化 by 情報システム部門 攻めの文化 by 事業部門・経営直下 両者は異なるクラウドであることを前提に考える 予算と人材と戦略の一体化と適切な配分
- 79. 銀行システムにおけるクラウド活用の動き 日本ユニシスとマイクロソフト、「BankVision on Azure」実現に向け共同プロジェクトを開始 2018年3月23日 日本ユニシス株式会社と日本マイクロソフト株式会社 は23日、日本ユニシスのオープン勘定系システム 「BankVision」の稼働基盤として、Microsoft Azureを 採用するための取り組みを推進するため、共同プロ ジェクトを4月から開始すると発表した。 いかに費用を抑え、最新技術も取り入れた上で短期間 でのシステム開発を行うかという課題に対応するため、 クラウドを選択。現在はクラウド最大手の米アマゾン ウェブサービスと組み、業務システムの一部から移行 を進めている。 5年間で100億円のコスト削減 1000超のシステムの約半分をクラウド化 週刊ダイヤモンド 2017.5.17 https://diamond.jp/articles/-/128045
- 80. クラウド・バイ・デフォルト原則 政府情報システムにおけるクラウドサービスの利用に係る基本方針（案） クラウド・バイ・デフォルト原則（クラウドサービスの利用を第一候補） 政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う 情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び経費等を基に検討を行う https://www.kantei.go.jp/jp/singi/it2/cio/dai77/siryou.html Step0：検討準備 クラウドサービスの利用検討に先立ち、対象となるサービス・業務及び情報といった事項を可能な限り明確化する。 Step1：SaaS（パブリック・クラウド）の利用検討と利用方針 サービス・業務における情報システム化に係るものについて、その一部又は全部が SaaS（パブリック・クラウド）により提供されてい る場合（SaaS（パブリック・クラウド）の仕様に合わせ、サービス・業務内容を見直す場合も含まれる。）には、クラウドサービス提 供者が提供する SaaS（パブリック・クラウド）が利用検討の対象となる。 Step2：SaaS（プライベート・クラウド）の利用検討 サービス・業務における情報システム化に係るものについて、その一部又は全部が、府省共通システムの諸機能、政府共通プラット フォーム、各府省の共通基盤等で提供されるコミュニケーション系のサービスや業務系のサービスを SaaS として、当該サービスが利用 検討の対象となる。 Step3：IaaS/PaaS（パブリック・クラウド）の利用検討と利用方針 SaaS の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、民間事業者が提供する IaaS/PaaS（パブリック・クラウド）が利用検討の対象となる。 Step4：IaaS/PaaS（プライベート・クラウド）の利用検討 IaaS/PaaS（パブリック・クラウド）の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、 サーバ構築ができる政府共通プラットフォーム、各府省独自の共通基盤等を IaaS/PaaS として、当該サービスが利用検討の対象となる オンプレミス・システムの利用検討
- 83. クラウド・サービスの「作り方」による費用の違い サーバー（物理マシン）×9台 ＋データベース等のライセンス ＋インフラ、DBなどの環境構築 ＋運用管理業務 ＋設置場所（場所+電源+空調等） 購入費用 ：数千万円 年間保守料 ：数百万円 年間運用量 ：数百万円 年間使用料 ： ー ハードウェアを所有 クラウド・サービスを使用 サーバー（仮想マシン）×9台 ＋データベース等のライセンス ＋インフラ、DBなどの環境構築 ＋運用管理業務 × 設置場所（場所+電源+空調等） 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：254,980円 ハードウェアを所有する場合と変 わらないシステム構成と運用方法 実行環境を移行しただけ システムの構成や運用方法などの設計・方式は同じ まったく異なる設計・方式 アンケート入力・集計・レポートのサービスとして、できることは同じ サーバー（仮想マシン）×4台 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：198,691円 × データベース等のライセンス △インフラ、DBなどの環境構築 △ 運用管理業務 × 設置場所（場所+電源+空調等） 無償のDNSや監視、低料金のデー タベースなどのサービスを利用 一部をクラウドのサービスに代替 サーバーの構築・運用は不要 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：907円 × データベース等のライセンス × インフラ、DBなどの環境構築 × 運用管理業務 × 設置場所（場所+電源+空調等） サーバーレス方式と言われるまっ たく異なる実行方式を採用 クラウド・ネイティブで再構築 ハードウェアを所有し、設置場所 とその運営も自社責任
- 84. 構築事例：従来型のWebアプリケーション・アーキテクチャ 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時点
- 85. 構築事例：AWSサービスを活かしたアーキテクチャ EC2 Internet クライアント Elastic Load Balancing EC2 冗長化 EC2 EC2 冗長化 Web AP DB DNS Route 53に 設定するのみ 死活監視のソフトウェア不要 基本的に無料／アラーム設定でメール通知 DBMSはインストール不要 Oracle、SQL Server等のライセンス料込 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時点
- 86. 構築事例：AWSサービスを最大限活かしたアーキテクチャ 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時点 ※条件によって料金は異なります
- 88. クラウド利用における責任の所在と狙い プラットフォーム アプリケーション インフラストラクチャー クラウド サービス 事業者 クラウド サービス 事業者 クラウド サービス 事業者 PaaS IaaS SaaS ユーザー 自社所有 ユーザー ユーザー 特定の業務処理 を行うためのソフトウェア アプリケーションで共通に使う機能 を提供するソフトウエア ソフトウエアを動かすための ハードウェアや設備 業務プロセス／処理 ユーザー ユーザー ユーザー ユーザー 機能や性能の改善 セキュリティ 運用管理 稼働監視 トラブル対応 バックアップ など Software as a Service Platform as a Service Infrastructure as a Service SaaS>PaaS>IaaS ユーザーの負担が減少 事業の効率化や競争力の向上 のために経営資源を積極配分 事 業 システムの構築や運用 管理、セキュリティな ど付加価値を生みださ ない負担を軽減する
- 89. クラウド・サービスの区分 自社所有 IaaS 仮想マシン CaaS PaaS FaaS ユーザー企業が管理 ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS SaaS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ IaaS ベアメタル クラウドサービス事業者が管理 連携機能 CaaS PaaS FaaS SaaS
- 92. ネットワーク インターネットや専用回線 コレ一枚でわかるクラウド・コンピューティング インフラストラクチャー プラットフォーム アプリケーション 計算装置 記憶装置 ネットワーク データ ベース 運用管理 プログラム 実行環境 プログラム 開発環境 認証管理 電子 メール SNS 新聞 ニュース ショッピング 金融取引 財務 会計 施設や設備
- 95. 徹底した標準化 大量購入 負荷の平準化 APIの充実・整備 セルフサービス化 機能のメニュー化 クラウド・コンピューティングのビジネス・モデル クラウド・コンピューティング オンデマンド 従量課金 自動化・自律化 システム資源 の共同購買 サービス化 低コスト 俊敏性 スケーラビリティ 仮想化とソフトウエア化の仕組み
- 96. クラウドの定義
- 98. クラウドの定義／サービス・モデル (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
- 99. ハイブリッド・クラウド 複数企業共用 パブリック・クラウド クラウドの定義／配置モデル (Deployment Model) プライベート・クラウド 個別企業専用 個別･少数企業 不特定・複数企業／個人 LAN LAN インターネット 特定企業占有 ホステッド・プライベート・クラウド 固定割当て LAN 専用回線・VPN LAN
- 102. クラウドの不得意を理解する 102 【低遅延】短い遅延時間が求められる業務は、 ネットワークの地理的距離の遠くなると不利 なので、同一場所で完結させた方がいい 証券市場においてデータ基に1秒で数千回の売買注文を行 うような高頻度取引（HFT:High Frequency Trading） 工場の製造現場で、直ちに良／不良を見分けて、不良品を 排除する品質管理工程の自動化 自動車の自動運転における事故の回避判断と回避行動の連 動 など データが発生する、あるいは処理を行う場所が同じ 場所／同じ装置の中で実行し、データを送る距離を 短くし、データが発生する現場でデータを処理する 【大量データ転送】現場で大量のデータが発 生し、それを保管、処理しなければならない 場合は、それらを全てクラウドに送り出すと、 回線料金が莫大になるため、同じ場所で保管、 処理させた方がいい 大量のセンサーからデータを取得し、それを利用して業務 を行う 工場の機械の動作履歴を検査や改善のために使う業務 な ど
- 103. クラウド利用の3原則 原則１：クラウド・ファーストで考える。 まずはクラウドを第１候補（クラウド・バイ・デフォルト）で考える。 自社で所有する場合をそのままに設計や運用をおこなうのではなく、クラウドにふさわし いお作法に則って、「使える」使い方を考えること。 同じ操作や同じ使い勝手を優先せず、それ以上の成果が得られることを優先する。 原則２：クラウド・ネイティブで考える。 システムを開発・構築することではなく、業務上の成果をあげられるかを考え、開発しな いクラウド利用（SaaS）を優先的に利用する。 開発しなければならない場合は、高速に開発でき、俊敏に改善できるサービスやツール （サーバーレスやローコード開発ツールなど）を積極的に利用する。 このような常識を持たないITベンダーとは組まない。新しい常識（クラウド・ネイティ ブ）を持つITベンダーに協力を求める。 原則３：クラウド・ローカルで考える。 ITは競争力の源泉と心得え、自分たちでできるスキルと体制を確保する。例え外部に委託 するにも、自分たちが使えるスキルがなければ、適切なパートナーの選択はできず、見積 や結果を評価できない。 ITを競争力の源泉にする前提は、高速な現場からのフィードバックと高速な改善を繰り返 すこと。それができる体制と人材確保を目指す。
- 104. クラウドに吸収されるITビジネス 104 アプリケーション・ビジネス • ビジネス開発 • システムの企画 • システム設計 • プログラム開発・テスト • 開発・テスト環境の構築 • 本番実行環境の構築 • セキュリティ対策 • 運用管理 • トラブル対応 ネットワーク・ビジネス • ネットワークの設計 • ネットワーク機器の導入・設定 • セキュリティ対策 • 監視・運用管理 • トラブル対応 インフラ・ビジネス • インフラの設計 • インフラ機器の導入・設定 • セキュリティ対策 • 監視・運用管理 • トラブル対応 クラウド・データセンター内 ネットワーク クラウド・データセンター間 バックボーンネットワーク 5G通信網のタイムスライス SIMによる閉域網 ローコード開発 Salesforce.com Lightning Platform Microsoft PowerApps AWS Honeycod サーバーレス／FaaS・PaaS コンテナ運用・管理マネージドサービス SaaS Oracle Dedicated Region @Cloud AWS Outposts Microsoft Azure Stack Hub オンプレミス型マネージド・システム アジャイル 開発 DevOps OutSystems Mendix GeneXus ローコード開発ツール
- 105. クラウド・ネイティブへのシフトが加速する Oracle Dedicated Region @Cloud AWS Outposts Microsoft Azure Stack Hub IBM Cloud Paks Google GKE on-prem Microsoft Azure Ark IBM Cloud Satellite Google Anthos オンプレミス環境にパブリック・クラウドと 同等の環境を構築する製品やサービス オンプレミスとパブリック・クラウドを 一元的に運用管理するサービス ハイブリッド・クラウド マルチ・クラウド
- 110. パスワード認証のリスク 110 ID／パスワードによる認証： 利用している本人が本人であることを証明するための仕組み ID/パスワードを搾取 ファイヤ ウォール 社内 ネットワーク VPN 1. 複雑なパスワードを使う 文字数を長くする。 文字の種類を増やす。英字（大文字、小文 字）、数字、特殊文字を組み合わせる。 2. 定期的に変更する 3カ月に一度変更する。 3. 一度使ったパスワードは使わない 過去3回までに使ったパスワードは使えない。 一度使ったパスワードは二度と使えない。 「複雑なパスワード」と「定期的なパスワード変更」は意味がない ID/パスワードが簡単にる 人間の記憶力に依存しまた再利用が可能なため 一人当たり平均27個のオンラインアカウントを保持 している それぞれのアカウントのパスワードを複雑化し、全 てのアカウントに紐づいているパスワードを違うも ので設定し、覚えておくということができない。 毎日アクセスするために、「覚えやすい簡単なパス ワードにする」「同じパスワードを使い回す」「メ モを書いておく」 ID/パスワード・VPN・ ファイヤウォールが役立たない
- 111. ゼロトラストという考え方
- 112. 攻撃サービスの低価格化と攻撃機会の増加 Ransomware: Zero-days: Breaching services on a per job basis: Exploit kits: Loads (compromised device): Spearphishing services: Compromised accounts: Denial of Service: Highest average price 大きなコストをかけて攻撃するのは 国家スポンサーのサイバーテロ攻撃のみ
- 113. 対症療法では問題は解決しない
- 119. Microsoftのセキュリティ・プラットフォーム Azure AD Azure Sentinel Azure Sentinel : SIEM（Security Information and Event Management）。Office 365 ATP、Windows Defender ATP、Azure AD、Azure ATP、Microsoft Cloud App Security、Azure Security Centerなどの脅威検知エンジンで収集したログ、サードパーティのセキュリティソリューションのログ、Deviceログ、Emailロ グなどを1つに集め、ビルトインされた機械学習モデルやAIを使って脅威の検知を行う Azure ADなどの様々なログから、機械学習モデル やAIを使って脅威の検知を行う ID およびアクセス管理サービス。様々なリソースへのサイ ンインとアクセスを管理し、シングルサインオン環境を提供 Azure AD : ID およびアクセス管理サービスであり、リソースへのサインインとアクセスを支援。Microsoft Office 365、Azure portal、その他何千という SaaS アプ リケーションなど、外部リソース。企業ネットワークとイントラネット上のアプリや、自分の組織で開発したクラウド アプリなどの内部リソース。 AD（オンサイト） Microsoft Defender ATP （オンサイト） Microsoft Defender ATP （モバイル） インターネット クラウド・サービス Microsoft Defender ATP（Advanced Threat Protection） : 企業のネットワークによる高度な脅威の防止、検出、調査、および応答を支援するために設計された プラットフォーム。 フェデレーション（認証連携） 同期
- 121. ゼロトラスト・アーキテクチャーの7原則 情報システムやサービスに於いて 正確なアクセス許可を行う際の不 確かさを低減・排除するために設 計された概念やアイデアの集合体 疑わしさを受け入れつつも できるだけ不確かさを排除 「ゼロ・トラスト」の考え方 リスクはゼロにはならない 1. 全データ・計算資源をリソースとして識別 2. ネットワークの場所に関係なく全ての通信の安全を確保 3. 個々のリソース・アクセスはセッション単位 4. リソースのアクセスは動的ポリシーにて決定 5. 全ての所有機器見・アプリの安全状態を常に監視・測定 6. アクセスを許可する前に動的・厳格に認証・認可 7. 機器・インフラ・通信状態の情報収集と安全面での改善 ゼロトラスト・アーキテクチャーの7原則
- 122. ユーザーに意識させない・負担をかけないセキュリティ Security Orchestration Automation Response SOAR セキュリティ製品間の連携 手動 → 自動 自動調査＆対処 自動化 いつでも／どこでも 安心・安全にITの利便性を享受 ユーザーに 意識させない・負担をかけない
- 124. サイバーフィジカルシステムとIoT データ収集 モニタリング データ解析 原因解明・発見/洞察 計画の最適化 データ活用 業務処理・情報提供 機器制御 ヒト・モノ クラウド・コンピューティング 日常生活・社会活動 環境変化・産業活動 現実世界／Physical World サイバー世界／Cyber World Cyber Physical System／現実世界とサイバー世界が緊密に結合されたシステム アナログな現実世界のものごとやできごとを デジタル・データで捉えデジタル・ツイン （現実世界のデジタル・コピー）を作る 狭義のIoT デジタルとフィジカルが一体となって 高速に改善活動を繰り返す状態を実現 ビジネスの最適化を維持する 広義のIoT
- 126. IoTが生みだす2つのループ 現実世界のデジタル・コピー デジタル・ツイン 規則や関係 の見える化 未来予測・最適解 インサイト・示唆 機器制御・指示命令・アドバイス 最適化ループ 効率・省エネ・生産性・時短・コスト削減など イノベーション 変革ループ UX(体験価値)向上、新たな連携、利便性向上、驚き・感動など センサー センサー・チップ センサーネットワーク センサー・フュージョン など クラウド データの収集・蓄積 計算処理能力の提供 アプリケーション など AI（機械学習） データの分析 最適解の導出 規則性や関係性の見える化 など 5G（第５世代移動通信システム） 高速・大容量 他端末接続 低遅延 など アジャイル開発・DevOps 現場のフィードバックをうけて高速に改善 ニーズの変化に俊敏な対応 バグフリー・高品質なソフトウエア開発 など AIチップ 自律制御 自律連携 リアルタイム処理 など
- 127. IoTの目指していること 調整や連携：打合せ 調整や連携：打合せ 調整や連携：打合せ Input ：人間→紙の書類 Output：紙の書類→人間 Input ：人間→コンピュータ Output：コンピュータ→人間 Input ：機械→コンピュータ Output：コンピュータ→機械 デジタル化前 人間が主体で行う仕事を 機械が支援する 機械が支援して人間が仕事をする 調整や連携：機械同士 Input ：機械→機械 Output：機械→機械 管理 ：コンピュータ 目標設定：人間 デジタル化後 自律制御 監視・指示 データ＋機械学習 機械にできることは 徹底して機械に任せ 人間しかできないことを 人間が行う 機械と人間が一緒に仕事をする 自律制御 H2H Human to Human M2H Machine to Human M2M Machine to Machine
- 129. デジタルツイン 電脳世界 （Cyber World） 現実世界 （Physical World） Cyber-Physical System スマートフォン 自動車 ウェアラブル 家電 スマートメーター 263 Kw ○×電力 様々なアクティビティ スマートフォン 自動車 ウェアラブル 家電 スマートメーター 263 Kw ○×電力 様々なアクティビティ データ 最適解 シミュレーション デジタル・ツインを使って最適解を導出
- 130. モノのサービス化 モノの価値は、 ハードウェアからソフトウェアへ、 そしてサービスへとシフト ハードウェア ソフトウェア サービス 機能・性能を随時更新可能 機能・性能の固定化 機能・性能を継続的更新可能 モノの価値を評価する基準がシフト 機構が複雑になり、部品の数も増えて、コストが嵩む 故障が多く、保守・サポートの体制やコストの負担が増える 機能追加には、設計や製造工程を変更を伴ひ、迅速対応は困難
- 131. 「モノ」のサービス化 自動車メーカー 航空機メーカー 工作機械メーカー アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア アナリティクス ソフトウェア改修 データ 収集 ソフトウェア 配信 新 規 開 発 制御ソフトウェア 運行データ 走行データ 作業データ 制御 制御 制御 遠隔からの保守点検・修理、自律化機能による自己点検や修復、ソフトウェア更新による機能・性能・操作性の改善 インターネット
- 132. 使 用 の現場 センサー コンピュータ ソフトウエア モノ・製品 モノのサービス化の本質 ものづくり の現場 開 発 製 造 保守 サポート ソフトウェア 改修・更新 インターネット 直 結 ・ 連 係
- 133. クラウド モノのサービス化がもたらすイノベーション 133 ソフトウェア ハードウェア ソフトウェア ハードウェア ソフトウェア 買ったときの機能 ＝全機能 買ったときの機能 +買った後に追加される機能 ＝進化する機能 進化するモノ タイムマシン化するモノ サービス サービス サービス サービス クラウド 過去 現在 未来 アナリティクス（統計／人工知能） ビッグデータ クラウドにつながることで 無限のリソースと 様々なサービスを 機器が手に入れる ビッグデータを分析することで 過去から原因・理由を探る 現在の出来事を知る 未来を予測する 賢くなるモノ
- 134. 「モノのサービス化」ビジネス コア・ビジネス 既存ビジネス 蓄積されたノウハウ 確実な顧客ベース 付加価値ビジネス 収益構造の多様化 既存ノウハウの活用 顧客ベースの囲い込み 新規ビジネス 顧客価値の拡大 ノウハウの創出 顧客ベースの拡大 製造・販売 製造・販売 製造・販売 走行距離に応じた 従量課金サービス Pay by Mile 出力×時間に応じた 従量課金サービス Pay by Power 工事施工 自動化サービス Smart Constriction 建設機械 遠隔確認サービス KOMTRAX 安全・省エネ運転 コンサルティング 予防保守・交換 燃料費節約 コンサルティング 予防保守・交換
- 135. ビジネスス・モデルの変革 VISION-S Prototype WOVEN City e-palette エンターテイメント・デバイス エンターテイメント空間として サービスを提供するためのデバイス サービス・プラットフォームとして コネクテッドな時代の 社会・生活空間として コネクテッドな時代のビジネスの可能性・新たな生き残り戦略の模索
- 136. 顧客価値 価値実装 体験 更新 心地良い・使い易い もっと使いたい ずっと使い続けたい 継続的な改善 最適を維持 顧客の期待を先回り UX ソフトウエア 「モノのサービス化」の構造 機能 仕様 モ ノ づ く り ハードウェア UI サービス・ビジネスとは、コトの価値を提供し続けるビジネスのこと コ ト づ く り
- 138. ビジネス価値の比較 ハードウェア 車両本体 ソフトウェア 制御系 サービス 保守・点検・修理 自動車メーカー ハードウェア 車両本体 ソフトウェア サービスの実装 制御系のスマート化 サービス モビリティ・サービス 生活サービス など 保守・点検・修理の価値向上 ソフトウェアによって実装 汎用部品化 モジュラー化 機能・操作の ソフトウェア化 サービス価値を高めて ビジネスを差別化 モビリティ & X サービス事業者 ビジネス・プロセスの ソフトウェア化 高速 改善 欠陥 ゼロ 要求 品質
- 139. 属性データと行動データ 性別・年代・結婚・職業・・・ 女性・20代・独身・事務職・手芸が好き・・・ 属性に応じて最適化された 機能・性能・品質の提供 属性データ 属性（静的）データ ✖️ 商品（モノ） 商品力向上＝調査✖️技術開発✖️製造技術 個 人 場所・時間・体験・感情・・・ 競技場・夏の夕方・サッカー観戦・勝利の喜び・・・ 状況に応じて最適化された 感動・楽しさ・共感の提供 行動データ 行動（動的）データ ✖️ UX（体験） 共感 デジタル接点・取得頻度の 増加によって解像度が上昇 UX向上＝多接点✖️高頻度✖️高速改善 状況 主義主張・人生観・価値観・悩み・生活圏・・・
- 140. データとモノ／コト・ビジネスの関係 属性データ 商 品 販売代金 属性に最適化された 商品の作り込み 魅力的な商品を作る 属性理解→商品設計→商品開発 行動データ UX サブスク 従量課金 状況に最適化された UXのアップデート 魅力的な体験を作る 状況理解→UX設計→UX開発 体験を継続したいという想いへの対価 商品を手に入れることへの対価 行動データ 商 品 販売代金 うまくいかないビジネス 行動データを取得する意味がない 商品の機能や性能を アップデートできなければ意味がない アップデートのコストをまかなえない
- 141. IoTの仕組みと使われ方
- 142. IoTの機能と役割の4段階 142 モニタリング Monitoring 制御 Control 最適化 Optimization 自律化 Autonomy センサーと外部データ ソフトウェア アナリティクス 人工知能（機械学習） 製品の状態 外部環境 製品の稼働、利用状況 製品機能の制御 パーソナライズ 製品機能・性能の向上 予防診断 サービス、修理 製品の自動運転 他製品やシステムとの自 動的連携 自己診断と修理・修復 製品の自動改良とパーソ ナライズ センサー、CPU、メモリーな どの小型化・低コスト化 ソフトウェアやクラウドの進 化とネットワークの低コスト 化 モデリングやシミュレーショ ンのアルゴリズムの進化と ビッグデータ 人工知能アルゴリズムの進化 製品への組み込み
- 144. 機能階層のシフト 144 データの生成 状況判断・制御 モノの集合体 データの収集・集約 短期での分析 深い分析 サービス連携 データの蓄積 データの生成 状況判断・制御 モノの集合体 データの収集・集約 短期での分析 深い分析 サービス連携 データの蓄積 状況判断・制御 個別のモノ クラウド エッジ モノ データ発生源に、できるだけ近いところで処理する 「深い分析」の前に、リアルタイムで処理・分析する データの変化に追従して迅速にアクションを起こす 高度な機能をエッジやモノにシフト
- 145. 学習と推論の役割分担 145 学習 推論 学習 推論 大規模な計算能力 専用プロセッサー 長時間演算 比較的小規模な計算能力 専用プロセッサー・省電力 短時間演算 学習モデル 学習モデル 学習 推論 学習モデル 学習モデル クラウドでモデルを作り、 そのモデルをエッジのデバ イスに送りリアルタイムの 現場のデータから予測や判 定を行う。 リアルタイム性が重要な処 理は、できるだけ現場に近 い場所で処理できたほうが 有利。また、機器の個体差 にも対処できる。 クラウドで完結するサービ スに適用。 学習 推論 推論モデル（予測や分類などの ルール）を大量のデータから作る 推論モデルを使って現場データ から予測や分類、判断／判定を行う AISing,HACURUS, SOINN など ARAYA,LEAPMIND, IDENなど ABEJA,Microsoft,Google, Facebook,Amazon, Preferred Networkなど NVIDIA,Intelなど
- 146. デバイス側のAIチップ（エッジAIチップ）の必要性 電力消費量の増加 世界の電力消費量は伸び続けており、環境問題 としても取り沙汰されている。 デバイスが増加し、データのやり取りが増加す るとさらに世界の電力消費量が大きくなる可能 性が高い。 リアルタイム性への対応 データ転送などによる通信遅延の発生は，遠隔 医療や産業ロボット、自動運転では通信遅延は 命取りになる場合がある。 自動運転で認識が遅れてブレーキが遅れるなど 即時応答が必要な分野は多い。
- 147. 超分散の時代 147 インターネット 専用ネットワーク インターネット 専用ネットワーク 専用ネットワーク テキスト テキスト+ 画像 マルチメディア（テキスト×画像×動画） マルチメディア + センサー 全てのデータ保管・処理は集中 大規模なデータ保管・処理は集中 小規模なデータ保管・処理は分散 大規模なデータ保管・処理は集中 小規模なデータ保管・処理は分散 大規模なデータ保管・処理は集中 小規模なデータ保管・処理は分散 高速な処理・応答・制御は超分散 集中コンピューティング 分散コンピューティング クラウド・コンピューティング 超分散コンピューティング 通信経路上の エッジサーバー 分散サーバー 分散サーバー ローカル エッジサーバー 1960年代〜 1980年代〜 2000年代〜 2015年〜 組み込みコンピューター
- 148. IoTの目指していること 調整や連携：打合せ 調整や連携：打合せ 調整や連携：打合せ Input ：人間→紙の書類 Output：紙の書類→人間 Input ：人間→コンピュータ Output：コンピュータ→人間 Input ：機械→コンピュータ Output：コンピュータ→機械 デジタル化前 人間が主体で行う仕事を 機械が支援する 機械が支援して人間が仕事をする 調整や連携：機械同士 Input ：機械→機械 Output：機械→機械 管理 ：コンピュータ 目標設定：人間 デジタル化後 自律制御 監視・指示 データ＋機械学習 機械にできることは 徹底して機械に任せ 人間しかできないことを 人間が行う 機械と人間が一緒に仕事をする 自律制御 H2H Human to Human M2H Machine to Human M2M Machine to Machine
- 149. IoT World Forumのリファレンス･モデル 149 物理的なデバイスとコントロー Physical Devices &controllers モノと設備・モノの周辺に配置される制御機器類 接続 Connectivity ネットワークや機器との通信 エッジコンピューティング Edge Computing モノの周辺でのデータ分析や変換処理 データ抽象化 Data Abstraction データ集約とアクセス アプリケーション Application データ活用（業務処理・分析・レポート） 協働とプロセス Corroboration & Processes 人と業務プロセス データの蓄積 Data Accumulation データの蓄積と管理
- 151. 1G 2G 3G 4G 5G 音声 テキスト データ 動画 あらゆるモノがつながることを前提とした 社会課題の解決 通信・コミュニケーションの性能向上 移動体通信システムの歴史 1979〜 1993〜 2001〜 2012〜 2020〜 9.6Kbps 28.8〜384Kbps 2.4〜14.4Mbps 0.1〜1Gbps 10Gbps〜