LiBRA 09.2021 / DXの本質とビジネス戦略 SI事業者向け
4 likes•423 views
https://libra.netcommerce.co.jp/
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〜
- 152. 5Gのビジネスの適用領域 データ量超増大 × 即時性向上 1通信あたりのデータの嵩が増える リッチ化する：高精細や高音質になり臨場感、没入感 が増す 多角化する：同時に取り扱える情報の選択肢が増える 1通信あたりのデータの種類が増える 制御用の情報（センサーやカメラからの情報）が増え る：自動○○が実現する 参考可能な情報（ログ情報）が増える：パーソナライ ズのパターンが増える、レコメンドの精度が向上する、 対象への理解が深まる タイムラグがほぼ無くなる 距離の制約が消える：各地に散らばる人たち同士で同 時に何かやる、今やった/起きたことをすぐに取り込 んですぐ活かす 社会（利便性）向上系 医療分野 超高信頼低遅延通信の実現で移動中や遠隔地の高度診療が可能になり、 医療格差が解消される 農林水産分野 超大量端末同時接続の実現で作物や家畜などの状況を把握するセン サーと散水・薬剤散布や給餌を実施するロボットやドローンの制御が 可能になり、減少する従事人口を補える 土木建築分野 超大量端末同時接続と超高信頼低遅延通信の実現によって遠隔制御が 可能になり、危険度が高い高所・鉱山・災害地などの現場での安全な 作業が確保でき、またドローンの活用による高精度測量などの精度が 向上する 生活分野 自動運転と遠隔制御によって、細分化された公共交通が実現する センサー情報を駆使して状況を把握する店舗運営が可能になる 遠隔授業や家庭教師の実現によって、学習格差が解消される 大量センサーと自動判定AIによって、防災・防犯・減災力が向上 VRオフィスとテレワークが実現する コンテンツ向上系 スポーツの場合⇒体験が深くなる 自動制御が可能になってカメラ台数を一気に増やせることで、多地 点・ドローンなどによる多角度撮影ができるようになる 取得データの種類が増え分析できる情報が増えることで、選手のバイ タルデータ・顧客のバイタルデータ・環境データが取得できるように なる AIが発達することでデータの有効活用レベルが上がり、多角的な分析 結果を提示できるようになる エンタメの場合⇒現実を超える仮想実現へ 即時性が向上することで出演者の居場所を問わない制作環境を実現さ せることや、同時多人数対応の参加型体験の提供ができるようになる スポーツ＆エンタメに共通 1通信あたりの送信データの嵩が増え、高画質・高音質・8K360°リ アルタイムな高臨場感映像が提供できるようになり、また視聴者に合 わせた多種多様な映像・情報を提供できるようになる 生活者データ・ドリブン・マーケテイィング通信より https://seikatsusha-ddm.com/article/10129/
- 153. 5Gの3つの特徴 先送り 高速・大容量 大量端末接続 超低遅延・高信頼性 100万台/k㎡ 1ミリ秒 20Gビット/秒 1Gビット/秒 10万台/k㎡ 10ミリ秒 20 倍 5G 4G URLLC： Ultra-Reliable and Low Latency Communications mMTC： massive Machine Type Communications eMBB： enhanced Mobile Broadband リアリティの再現 光ファイバーの代替／補完 高精細／高分解能な デジタル・ツインの構築 時空間の同期 リアルタイム連携
- 154. 第５世代通信の適用例 高速・大容量データ通信 10G〜20Gbpsのピークレート どこでも100Mbps程度 大量端末の接続 現在の100倍の端末数 省電力性能 超低遅延・超高信頼性 1m秒以下 確実な通信の信頼性担保 5G 多様なサービスへの適用を可能にする 異なる要件のすべてを1つのネットワークで実現する。 各要件をに応じてネットワークを仮想的に分離して提供する（ネットワーク・スライシング）。 2020年代〜 ２時間の映画を ３秒でダウンロード ロボット等の 精緻な遠隔操作を リアルタイムで実現 自宅内の約100個のモノ がネットに接続 (現行技術では数個) 現在の移動通信システムより 100倍速いブロードバンドサー ビスを提供 利用者がタイムラグを意識 することなく、リアルタイ ムに遠隔地のロボット等を 操作・制御 スマホ、PCをはじめ、身の 回りのあらゆる機器がネッ トに接続
- 155. 参考:5Gの社会実装に向けたロードマップ
- 156. 5Gの普及段階 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 4G（LTE） 4Gコアネットワーク LTE 基地局 4Gコアネットワーク LTE 基地局 NR 基地局 マクロセル スモールセル 既存周波数帯 新しい周波数帯 NSA NSA: Non-Standalone 5Gコアネットワーク LTE NR 基地局 既存周波数帯 新しい周波数帯 SA SA: Standalone マクロセル スモールセル NR ユーザー情報 制御情報 ユーザー情報 ユーザー情報 制御情報 SA LTE: Long Term Evolution NR: New Radio 5G初期 5G普及期 2010〜 2020〜 2022〜
- 159. 第５世代通信におけるネットワーク・スライス 高速・大容量データ通信 大量端末の接続 超低遅延・超高信頼性 5G ネットワーク・スライシング SIM SIM SIM 閉域網 閉域網 閉域網 SIM SIM SIM(subscriber identity moduleもしくはsubscriber identification module/SIMカード)とは、電話番号を特定するための固有のID番号が記録された、 携帯やスマートフォンが通信するために必要なICカードのこと。
- 162. 人間の知能と機械の知能
- 164. 特化型人工知能（AI）と汎用型人工知能(AGI) 顔認証 音声認識 囲碁 特定の領域に特化した 知的処理を行うプログラム 自動運転 人間がテーマを与え 人間が能力を拡張させる 特化型人工知能 AI : Narrow Artificial Intelligence AI AI AI AI 何を知るべきか を見つける どうすればいいか を探す 疑問や興味を持ち 目的やテーマを 設定する能力 家事 医療診断 研究 カウンセ リング 全ての領域をカバーする 知的処理を行うプログラム 自律的にテーマを探し 自律的に能力を拡張させる 汎用型人工知能 AGI : Artificial General Intelligence AGI AGI
- 165. 知能・身体・環境とAI 生物／生存と繁殖 自己概念 信念、欲求、感情、理性、自己意識 感覚器 運動器官 骨格、関節、筋肉、靭帯、腱 環境／ガイア仮説 身体 影響 受容 相互作用・適応 エネルギー循環 誕 生 死 滅 進化 遺伝・淘汰・絶滅 IoT ロボティクス 地球と生物が、相互に 関係し合い環境を作る 認識 判断 運動構成 AI/人工知能 繁 殖 長く生き延び 子孫を残す 内分泌系
- 167. 人工知能 機械学習 ディープラーニング
- 169. 人工知能と機械学習の関係 人工知能 Artificial Intelligence/AI 機械学習 Machine Learning ニューラル・ネットワーク Neural Network 深層学習 Deep Learning 人間の”知能”を機械で 人工的に再現したもの 強いAI:コンピュー タに人間と同様の知 能を持たせた仕組み 弱いAI:コンピュー タに人間と同様の知 的な振る舞い・処理 をさせる仕組み データからグループ分 けのためのルール（モ デル）を作る仕組み 脳の仕組みを参考に作 られた機械学習の手法 従来よりも精度の高いモ デルを作ることができる ニューラル・ネットワー クの手法 遺伝アルゴリズム、エキスパートシステム、音声認識、画像認識、感性処理、機械学習、 ゲーム、自然言語処理、情報検索、推論、探索知識表現、データマイニング、ニューラル ネット、ヒューマンインターフェース、プランニング、マルチエージェント、ロボット データ プログラム モデル
- 170. なぜいま人工知能なのか インターネット アルゴリズム GPU（Graphics Processing Unit） 脳科学の研究成果を反映 高速・並列・大規模計算能力 人工知能（Artificial Intelligence） ビッグデータ IoT モバイル・ウェアラブル ソーシャル・メディア ウェブサイト WWW
- 171. 機械学習
- 173. 機械学習がやっていること モデル レントゲン写真から 「癌」の病巣を 識別するルール 入力 出力 癌 データ分析で ルールを作る 機械学習 癌の病巣が写っている 大量のレントゲン写真 ある患者のレントゲン写真 「癌」の病巣を表示 レントゲン写真から 「癌」の病巣を見つける「モデル」
- 174. 機械学習がやっていること：分ける／分類する 入力 出力 推論 Inference 入力を特徴の組合せ／ルールに照合 して、最も一致度が高いグループに 分類する計算処理 学習 Learning うまく分けるための特徴の組合せ／ ルールを、大量のデータの中から見つ け出す計算処理 動物 乗り物 楽器 学習 データ／学習データ 推論 入力 “X” 動物 入力 “X” の特徴は、「動物」の モデルと最も一致度が高いので、 動物のグループに分類する モデル 入力をどう処理して 出力するかのルール モデルとの照合 未分類 推論の結果＝動物 特徴が似たグループ
- 175. モデルとは何か 175 動物 座標空間 実際には多次元の座標空間 特徴1 特徴2 特徴3 楽器 乗り物 モデル 特徴の組合せが 似通っているグループ 機械学習 データからモデルを 生成する仕組み
- 176. 機械学習がやっていること モデル 推論モデル／学習モデル 入力 出力 Y＝f(X) X Y f 関数 学習：大量のXとYの関係を調べ、統計的に最も確からしい関数 f を見つける計算 推論：関数 f に入力Xを与え、出力Yを導く計算 学習データ 大量のデータを処理するため の計算資源が必要 学習ほどの計算資源は不要
- 177. 教師あり学習と教師なし学習 イヌ イヌ イヌ ネコ ネコ モデル 特徴の組合せを使って 違いを見分けるルール イヌ ネコ 教師あり データ 教師なし データ 判別 分類 教師あり学習 教師なし学習
- 184. 一般的機械学習とディープラーニングとの違い 184 耳 27% 目 48% 口 12% 特徴量 「特徴量」とは、猫と犬を識別・分類するために着目すべき特徴 正しく認識 82% 誤った認識 18% 認識結果 耳 27% 目 48% 口 12% 特徴量 学習 ディープラーニング 学習 推論 ディープラーニング 推論 正しく認識 82% 誤った認識 18% 認識結果 人間が認識結果が 最適になる組合せを 見つける 機械が認識結果が 最適になる組合せを 見つける 学習データ 教師付きデータ 学習データの一部 評価データ
- 185. 機械学習の仕組み IoT Web Mobile データ モデル 推論 機械学習 Machine Learning 識別 予測 判断 ゾウ or カバ？ 正常 or 異常？ 晴れ or 雨？ データ(学習データ)を分析して 特徴が共通するグループに分ける ための基準／ルール(モデル)を作る モデルを使ってグループ分けする 音声認識 顔認証 自動運転 創薬支援 天気予報 画像診断 人材採用 故障予測 機械翻訳 競技アドバイス 惑星探査 ヒビ割れ点検 製品品質検査 機械学習アプリケーション 推論モデル／学習モデルという 学習データという
- 187. 自動化ツール Google Cloud AutoML Microsoft Azure ML AWS SageMaker など AIと人間の役割分担 データを準備 意志決定 学習方式の選択 パラメーターの調整 推論 問いを生みだす 解決したいこと・知りたいことを決める 膨大なデータの中から、人間 の経験に基づく先入観なしに 規則、相関、区分を見つける 新たな問いを生みだす 判断・制御 モデル
- 188. 深層学習が前提となったシステム構造 深層学習フレームワーク 学習処理実行基盤 画像解析 動画認識 音声認識 話者認識 言語理解 文章解析 機械翻訳 知識表現 検索 コールセンター 顧客応対 営業支援 提案活動支援 医療 診断支援 創薬支援 その他 その他 文献データ 社内業務 データ 概念体系 辞書 音響データ 言語データ 画像データ 動画データ その他 アプリケーション ソリューション 認識系 サービス 学習基盤 知識ベース 学習データ Ａ Ｉ プ ラ ッ ト フ ォ ー ム
- 189. 人工知能の可能性と限界
- 190. 機械翻訳の現状とそのプロセス 音声認識 Speech Recognition 機械翻訳 machine translation 音声合成 Speech synthesis 2016：人間並み 2018〜19：人間超え 2018〜19：人間との区別困難 プロの逐次翻訳に匹敵（状況による） 60 50 40 30 20 10 一般の人が翻訳した場合よりも高品質であることが多い 非常に高品質で適切かつ流暢な翻訳 高品質な翻訳 理解できる適度な品質の翻訳 主旨は明白だが文法上の重大なエラーがある 主旨を理解するのが困難 ほとんど役に立たない BLEUスコア 19851990 1995 2000 2005 2010 2015 2020 統計的機械翻訳 SMT(Statically Machine Translation) ニューラル機械翻訳 NMT(Nural Machine Translation) BLEU: BiLingual Evaluation Understudy
- 193. 人間と機械の役割分担 WHY HOW What テクノロジーにより 置き換えられる領域 AI、ロボット、クラウド、自動化など 人間でなければ できない領域 なぜ、なんのために、何をしたいかなど
- 194. データサイエンス
- 196. データ取得のためのプロセス設計 ステップ１：目的から仮説を導く 事業目的を明確にする その目的を達成する上での事業課題を洗い出す 事業課題を解消できるソリューション／事業の仮説を設定する ステップ２：データ項目とモデルを設定する 仮説の有効性を検証するために必要なデータ項目を決定する 必要なデータ項目が取得できる状況や条件を洗い出す 仮説を裏付けるプロセス・モデルを考える ステップ3：データの取得とフィードバック 必要なデータ項目を含むデータとその取得方法を考える ユースケースやペルソナを設定しデータ取得のストーリーを設計する ソリューション／事業を開発・実践しフィード・バックを手に入れる 評価・改善
- 198. データサイエンティストの業務 後藤真理絵／リクルートマーケティングパートナーズ Data Scientist、Quipper Data Scientist
- 201. システム開発とDX
- 202. デジタル・トランスフォーメーションのBefore/After 支援 人間主体でビジネスを動かしITが支援する 生産性向上・コスト削減・期間短縮 ITはコスト、削減することが正義 クラウド化＋自動化 モダナイゼーション Before DX 人間とITが一体となってビジネスを動かす 変化への即応力・破壊的競争力・価値の創出 ITは競争力の源泉、投資対効果で評価 新規性と俊敏性の確保 アジャイル+DevOps プラットフォーム After DX 省力化とコスト削減 事業を支えるIT 事業を変革するIT 外注 主導 内製 主導 何をするか予め決めることができる 試行錯誤を繰り返し何をするかを見つける
- 204. ビジネス・スピードの加速を支える開発と運用 アジャイル開発 Agile Development ビジネスの成果に貢献するコードだけを 変更に柔軟・迅速に対応して バグフリーで提供する DevOps Development & Operation 運用の安定を維持しながら 本番環境への迅速な移行と 継続的デリバリー クラウド Cloud Computing 最新・高速・俊敏な開発実行環境の調達 経費化による不確実性への担保 運用やセキュリティから解放と人材の再配置 デジタル・トランス･フォーメーション
- 207. 気付きからサービスに至る全体プロセス 共感 定義 アイデア創出 学び・気付き デイリー スクラム スプリント レビュー 振り返り スプリント プランニング ビルド ピボット or 継続？ 実証実験開始 顧客の課題 ソリューション デザイン思考 リーンスタートアップ アジャイル開発 気付き・問題意識 タスクリスト 運 用 デプロイ 運用 監視 DevOps サービス フィードバック SRE Site Reliability Engineer アップデート データ収集
- 209. コード管理 コード確認 登録 構築 リリース 議事録・ガントチャートなど 情報はバラバラで リアルタイムに進捗や状況が分からない 誰がやっているのかが分からない 伝言ゲームで現場の空気が伝わらない タイムリーに検証ができない リリースに時間かがかかる 開発と運用 現状
- 210. コード管理 コード確認 構築 リリース 開発と運用 これから タスク の共有 進捗や課題などのをリアルタイムに共有 開発する現場と利用する現場が一体となる フィードバック・アップデート・リリース のサイクルを高速で回す
- 211. アジャイル開発
- 212. アジャイル開発のプロセス 開発 開発 開発 イテレーション／反復#1 イテレーション／反復#2 イテレーション／反復#3 開発 イテレーション／反復#n 業務上の重要度に基づいて優先順位を決めて業務プロセスを積み上げてゆく。 リリースされるプロセスは実行可能であり、ユーザーがそれを使って検証できる。 現場のフィードバックを受け入れ、次のイテレーションで統合してリリースする。 リリース フィード バック 最も重要度の高い 業務プロセス 業務上の成果があげられる と判断されて完成とする 重要度の高い順番に 業務プロセスを追加 追加されたプロセスは既にリリースした プロセスと統合し品質を確認する ウオーターフォール開発 要 件 定 義 外 部 設 計 内 部 設 計 プ ロ グ ラ ム 設 計 プ ロ グ ラ ミ ン グ 統 合 テ ス ト 結 合 テ ス ト リリース
- 214. ウォーターフォールとアジャイルの違い 用意されたプロセスやツール 全てを網羅したドキュメント お互いの妥協点を探る契約交渉 一度決めた仕様や計画に従うこと システムを納品すること 計画通りに完成させること 「計画通り」が正義という信念 自律的な判断と行動 実際に使う動くソフトウェア 顧客との対話と協調 変更や変化への柔軟な対応 ITサービスを提供すること ビジネスを成功させること 「計画通り」は無理という現実
- 215. ウォーターフォールとアジャイルの違い ユーザーと開発者はプロジェクトを通して、日々一緒 に働く ユーザの満足を優先し価値あるソフトウェアを早く継 続的に提供する 要求の変更はたとえ開発の後期であっても歓迎する 動くソフトウェアをできるだけ短い間隔（ 2〜3週間 あるいは2〜3ヶ月）でリリースする 動くソフトウェアこそ進捗の最も重要な尺度 技術的卓越性と優れた設計に対する普段の注意が機敏 さを高める シンプル（無駄なく作れる量）に作ることが基本 最良のアーキテクチャ・要求・設計は自己組織的な チームから生み出される チームが最も効率を高めることができるかを定期的に 振り返り、それに基づいて自分たちのやり方を最適に 調整する アジャイルな思想 ユーザと開発者はいつもは別の場所にいてプロジェク トを通して定例ミーティングを行う ユーザーの満足や価値のあるなしではなく、とにかく ソフトウェアを提供する 要求の変更を開発の後期に出すの勘弁して欲しい パワポ、エクセル、ワードの仕様書を丁寧に清書して （ 2〜3週間あるいは2〜3ヶ月）納品する 動くソフトウェアこそ進捗の最も重要な尺度 技術的卓越性と優れた設計に対する普段の注意が機敏 さを高める 仕様書通り（間違っていようが）に作ることが基本 最良のアーキテクチャ・要求・設計は自己組織的な チームから生み出される チームがもっと稼働率を高めるように監視し、それに 基づいて自分たちへの批判や不満を回避するために、 念のため納期を厳しめに設定する ウォーターフォールな思想 https://speakerdeck.com/kawaguti/flipped-agile-manifest Yasunobu Kawaguchi氏 資料を参考に作成
- 220. アジャイル開発 ウォーターフォール開発 最初に要件をあらかじめ 全て決めてから開発 要件 設計 コーディング 単体テスト 結合テスト ウォーターフォール開発とアジャイル開発（３） リリース ビジネス上の重要度で要件 の優先順位を決め、これに 従って必要機能を順次開発 反復（イテレーション）1 反復 2 反復 3 反復 4 リリース リリース リリース リリース Continues Integration 品質の作り込み
- 221. ウォーターフォール開発とアジャイル開発（５） ◎ 〇 △ Ｘ 反復 １ ビジネス価値 ◎ 反復 ２ ビジネス価値 〇 反復 ３ ビジネス価値 △ 反復 ４ ビジネス価値 Ｘ 「MVP（Minimum Viable Product：仮説を検証することができる最低限のプ ロダクト）」かつ、ビジネス価値の高い機能・プロセスを優先して開発する。
- 222. ウォーターフォール開発とアジャイル開発（６） プラン ドリブン型 バリュー ドリブン型 リソース アジャイル 納期 リソース 納期 実現仕様 ウオーターフォール 要求仕様 要件 設計 コーディング 単体テスト 結合テスト リ ス ク 時間 反復1 リ ス ク 時間 反復2 反復3 反復4 前提条件 原理的に 不良が起きない 納期が守られる コストと納期を 守ること 機能と品質を実 現すること ゴールは何か？
- 223. アジャイル開発の目的・理念・手法 223 高品質で無駄がなく、変更要求に対応できるきるソフトウエアを作成する為 適切な一連の手順に従う 高い協調と自律的なプロジェクト関係者によって実施される イタラティブ(反復/周期)、インクリメンタル（順次増加部分を積み上げていく)方式 ダイナミックシステムズ開発技法(Dynamic Systems Development Method) Dane Faulknerほか アダプティブソフトウェア開発(Adaptive Software Development) Jim Highsmith クリスタルメソッド(Crystal Methods) Alistair Cockburn) スクラム(Scrum) Ken Schwaber、Jeff Sutherland エクストリームプログラミング(XP/eXtreme Programing) Kent Beck、Eric Gammaほか リーンソフトウェア開発(Lean Software Development) Tom and Mary Poppendieck フィーチャ駆動開発(Feature-Driven Development) Peter Code、Jeff DeLuca アジャイル統一プロセス(Agile Unified Process) Scott Ambler 反復(周期)的(Iterative) --- 定期的なリリース 漸進的(Incremental) --- 徐々に機能を増加 適応主義(Adaptive) --- 変化に対応(即応) 自律的(Self-Organized) --- 学習する組織 多能工(Cell Production) --- 一人多役(SE、プログラマー、テスター) 目的と理念 手 法 共通する要素
- 224. 自律型の組織で変化への柔軟性を担保する 224 さまざまな専門性を持った人がチームを組み、最初 から最後まで一緒に働く。 人とチームを重視し、彼らが自律的に働ける環境を 与えることでブレークスルーが起こりやすくなり、 同時に製品化までの時間が短くなる。 リーダーは、自律するチームの障害を取り除くこと が仕事であり管理しない。 日本で行われている 新製品開発のプロセスを 米国のやり方と比較した論文 1986,Harvard Business Review Scrum（スクラム） 1990年代、Jeff Sutherlandらが ソフトウェア開発のに適用 アジャイル開発 不安定 高い自由裁量と困難なゴールを持つ 自己組織化 情報ゼロから相互交流し自律的に仕組みを作る 全員多能工 分業を共有しメンバーがプロジェクトの責任を自覚する イノベーションを 生みだす方法論
- 225. スクラム：特徴・3本の柱・基本的考え方 225 システム開発のフレームワーク（1995）／ Ken Schwaber & Jeff Sutherland 特徴 軽量 理解しやすい（シンプル） 会得するのは比較的難しい 三本の柱 Transparency （透明性） Inspection （視察、検査） Adaptation （適応、順応、改作） 基本的考え方 タイム・ボックス（Time Box） 時間を区切って、その時間内に目的を果たす仕事を行う仕事の仕方 機能横断的な固定化されたチーム チーム内で役割分担を決めず、全員が必要な仕事をこなす多能工（T型人間のチームででき るだけチームメ ンバーを固定化した方がよい 持続可能なペース 徹夜や残業を排除して安定した持続可能な一定のペースで開発し、定期的にリリースを行う
- 226. スクラム：スクラム・プロセス 226 イテレーション（反復） 4 1〜4週間 イテレーション（反復） 3 1〜4週間 イテレーション（反復） 2 1〜4週間 イテレーション（反復） 1 1〜4週間 納品 納品 納品 納品 プロダクト・オーナー プロダクト・バックログ 1. -------------------- 2. -------------------- 3. -------------------- 4. -------------------- 5. -------------------- 6. -------------------- スプリント･プラン イテレーション毎の 内容区分 2時間程度の単位 スクラム･マスター タスク･リスト スプリント・バックログ 1. -------------------- 2. -------------------- 3. -------------------- 4. -------------------- 5. -------------------- 開発チーム バーンダウン チャート デイリー スクラム 開発・テスト インテグレーション To Do On Going Done Keep Problem Try スタンドアップミーティング & スプリント･レビュー・振り返り
- 227. スクラム：プロダクト・オーナー 227 ミッションと責任 プロダクトの完成図と方向性を示す プロダクトに必要な機能の詳細を決める リリースの内容と日程を決める 市場価値に基づくプロダクト･パックログの優先順位を決める スプリント毎に優先順位を変更できる権限を持つ プロダクトの収益性(ROI)の責任を持つ プロダクト･オーナーが行う事 プロダクトのビジョンを作成し、関係者に示し、共有する 対象プロダクトのビジネス要求(ビジネス環境)の説明 エピック、ユーザーストーリーの確定とペルソナの作成 ユーザーストーリー毎の受け入れ基準の承認 プロダクト・バックログの優先順位付けとプロジェクト期間中の維持管理 開発チームへのユーザーストーリーの説明 開発チームのDoD(完了の定義)作成の支援 リリース計画の承認 稼働環境の定義 EOL(プロダクトの終焉)条件の設定
- 228. スクラム：スクラム・マスター 228 チームの機能や効率化を支援する チームが最大パフォーマンスを発揮できる環境を作る ＝ 妨害からチームを守る チームがスクラム・プロセス通りに作業を実施できる様に支援する チームに気付きを与える チームの自律を支援する チームの能力をユーザーに売り込む プロジェクト関係者間の信頼感を醸成する お客様(ユーザー)第一の思想 ジャスト・イン・タイムの徹底 カイゼン活動の促進 チームのモチベーションの向上 スクラム･マスター
- 229. スクラム：開発チーム 229 自己組織的なチームである 自律性 メンバーが自ら日々の仕事を管理する 自己超越 常に目標を達成するように自らを追い込み、常に自身のプラクティスを改善する 相互交換作用 機能横断的かつ定めた役割がない 目標にコミットする義務がある チームはスプリント計画ミーティングでコミットした目標を達成する責 任 を持つ 目標達成につながるならば方法を限定しない チームは全ての決断を下す権限、必要なことを何でも行う権限、あらゆる障 害の除去を依頼する権限を持つ 争議はチーム内で解決する 作業規約を作る
- 230. エクストリーム･プログラミング（XP） 230 テスト駆動開発（Test-Driven Development：TDD）＝テストファース ト・プログラミング 実装する機能をテストするプログラムを書く コードを書いてテストする デザインを見直す 信号が青になる（テスト・コードが成功する）まで繰り返す リファクタリング 完成したコードの見直し（実装された機能を変えずに、コードをシンプルに、 見やすくする） 任意の作業（全員が行う&時間が空いたら行う） ペアプログラミング ドライバー（コードを書く人） ナビゲーター（コードをチェックする人、ナビゲーションをする人） この役割を1日の中でペア間で、途中で交代する ペアの組み合わせを毎日替える 10分間ビルド 自動的にシステム全体をビルドして、全てのテストを10分以内に実行させる Kent Beck（1999年）によって提唱された開発手法
- 231. アジャイル開発で品質が向上する理由 231 ムダ取りの原則を徹底する。 作業にムラがあるから、ムリをするようになる。 ムリな作業をした結果、ムダが生じる。 ムラを防止するのは、一定の作業リズム（タクトタイム＝タイムボックス） タスクの粒度を小さくする。 作業手順（工程設計）を考えなければタスクは小さくできない。 タスクが小さくなれば、ミスを容易に発見できる。手戻りも小さい。 タスクを小さくするとムダが見えてくる。 正味（本来の価値を作り込む）作業、付帯（事前、事後の）作業、ムダな作業 タスクを小さくすることで、整流化が容易になる。（ボトルネックの解消： 一個流し生産） 全員での作業で透明性が高まる。 一人で抱え込む仕事がなくなる。 事前に他人の目が届く（チェック） トヨタ生産方式（ＴＰＳ）の自働化の思想をプロセスに組み込める。 不良作業をしない。不良品を流さない。不良品を受け取らない。（自工程完結） 不良が起こったらラインストップをして、関係者全員が異常に気づく。（見える化） 作業者（開発者）に直接フィードバックする仕組みが構築できる。 『擦り合わせ』をしながら作業が進む。
- 232. アジャイル開発で品質が向上する理由 232 タスクの粒度を小さくすることはＴＰＳにおける小ロット化と同様 「流れ」を作り、負荷を平準化し、柔軟性を高める タスクの粒度は小さいほど良い １日以内、理想は１時間 責任を持って見積ができる バグを作り込まない（簡単にテスト可能） 他のペアと同期がとれる ダイナミックなプロジェクト運営が可能となる（チーム編成の増減、分散開発など） タスクが小さくできないのは、作業対象の内容把握に問題が存在するのではないか？ タスクを小さく分割するという事は、作業指示書を作成する事。 Statements of Source code Test Cases Test Coverage 1 1 100.00% 10 2 100.00% 100 5 95.00% 1,000 15 75.00% 10,000 250 50.00% 100,000 4,000 35.00% 1,000,000 50,000 25.00% 10,000,000 350,000 15.00% Application size, Test Cases, and Test Coverage. Logical source code statements By Caper Jones
- 233. DoD (Definition of Done) 完了の定義 233 各作業の完了基準 閾値（標準値）を決める。 作業経過、結果を計測する。 自工程完結の基本的な姿勢（現場での意思決定） 仁＝他人の努力を無駄にしない思いやり 検 査 検 査 検 査 発生防止 流出防止 プロセス プロセス プロセス 検 査 納入 検査 検査 検査 DoD
- 234. DevOps
- 236. ビジネス 開発 運用 アジャイル開発 DevOps アプリケーション開発環境 マイクロ･サービス、ルールエンジン、AI、APIなど ITインフラストラクチャー IaaSなどのクラウド アプリケーション実行環境 コンテナ・オーケストレーション・ツール サーバーレス・FaaS Infrastructure as Code 運用の自動化 SRE Site Reliability Engineer アイデアの創発 デザイン思考 リーンスタートアップ トライ･アンド･エラー のサイクルを高速で回す ビジネス･スピードを加速する方法 ビジネスの成果に貢献するコードのみ 現場のニーズにジャストインタイム バグフリーと変更への迅速･柔軟な対応 開発されたコードを直ちに本番移行 安定稼働の維持 変更やスケールへの迅速･柔軟な対応
- 237. 開発と運用の協調・連携を実現するDevOps 237 情報システムに求められること システムによってビジネスの成功に貢献すること ビジネスの成功のための貢献を確実、迅速にユーザーに届けること ユーザーの求める貢献の変化に迅速・柔軟に対応すること 開発チーム（Development） システムに新しい機能を追加すること 運用チーム（Operation） システムを安定稼働させること 迅速にアプリケーションを開発・更新し すぐにユーザーに使ってもらいたい 確実に本番システムに安定させ 安心してユーザーに使ってもらいたい 対立 アジャイル開発 SDI/IaaS（インフラのソフトウエア化） ツール と 組織文化 の融合 開発チーム（Development）と運用チーム（Operations）が、お互いに協調し合い 「情報システムに求められること」を実現する取り組み いますぐ変更を 反映したい！ 安定運用したい！
- 238. DevOpsのメリット ソースコードを変更してすぐデプロイとテストができるため、早い段階で問題を発見できる。 テストやビルド、デプロイなども、自動化・省力化することで、ヒューマンエラーを防げる。 いざ本番環境になって動かない！というリスクが低い。 開発と運用が稼働状況を共有することで、問題点や修正のステータスを把握しやすい。 新しい機能で問題が起きた時の対応についても、フィードバックがスムーズ。 運用はリリースの信頼性が高まることで、システムの変更を承認しやすくなる。 継続的インテグレーション（Continuous Integration） 開発者が自分のコード変更を頻繁にセントラルリポジトリにマージし、その度 に自動化されたビルドとテストを実行します。小さなサイクルでインテグレー ションを繰り返し行い、インテグレーションのエラーを素早く修正することに よりチームは統合されたソフトウェアをより迅速に開発できるようになります。 コミット ビルド テスト 結合 Continuous Integration CI フィードバック 後工程 コミット ビルド 失敗 変更 コミット ビルド 変更 原因究明 変更 ビルド 失敗 変更 ビルド 変更 ビルド 変更 ビルド
- 240. サーバー仮想化とコンテナ OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア サーバー仮想化 ハードウェア コンテナ管理ソフトウエア OS ミドルウェア アプリ ミドルウェア アプリ ミドルウェア アプリ コンテナ コンテナ コンテナ コンテナ ライブラリ 環境変数 ライブラリ 環境変数 カーネル カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 隔離されたアプリケーション実行環境を提供（クラッシュの分離、独自のシステム管理とユーザー・グループ） 実行イメージのスナップショットをパッケージとしてファイルにして保存できる アプリケーションに加えて仮想マシン・OS の実行イメージを持つ必要がある アプリケーションとOSの一部 の実行イメージを持つ必要がある デプロイするサイズ 大きい 起動・停止時間 遅い デプロイするサイズ 小さい 起動・停止時間 早い 異なるOS 可 異なるOS 不可 メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い 構成の自由度が高い 異なるOS・マシン構成を必要とする場合など 軽量で可搬性が高い 実行環境への依存が少なく異なる実行環境で稼働させる場合など サンド・ボックス化 Sand Box アプリケーション アプリケーション アプリケーション
- 241. 仮想マシンとコンテナの稼働効率 ハードウェア 仮想マシン ミドルウェア OS 仮想マシン OS 仮想マシン OS ミドルウェア ミドルウェア ハードウェア OS コンテナ管理機能 カーネル ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 コンテナ 仮想マシン アプリケーション アプリケーション アプリケーション ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ
- 242. 仮想マシンとコンテナの稼働効率 1/2 242 仮想マシン ハードウェア 仮想マシン ミドルウェア OS 仮想マシン OS 仮想マシン OS ミドルウェア ミドルウェア カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 アプリケーション アプリケーション アプリケーション OSの維持コストが高いので １つのOSに複数のアプリケーションを同居させる あるいは基盤更改などで移行する時も分離できず 再構築することもおおい ライブラリが共通で依存関係があり アップグレードもパッチ適用もできず塩漬けになりがち 仮想マシンごとに OSを稼働させとハードウェア・エミュレーションがあり ハードウェアとOS起動+運用が必要となり オーバーヘッドが大きい・起動は分単
- 246. DevOpsとコンテナ管理ソフトウエア オペレーティング システム サーバー （ハードウェア） コンテナ管理 動 作 保 証 オペレーティング システム サーバー （ハードウェア） コンテナ管理 動 作 保 証 オペレーティング システム サーバー （ハードウェア） コンテナ管理 アプリケーション 開発・実行環境 ミドルウェア コンテナ 動 作 保 証 Build,Ship and Run Any App,Anywhere アプリケーション開発者は、OSやインフラを意識することなくアプリ ケーションを開発し、どこでも実行できるようになる 開発しテストが完了したアプリは、すぐに本番環境で実行させることができる 本番環境 テスト環境 開発環境
- 249. DockerとKubernetes の関係 249 コンテナの作成 コンテナの実行 コンテナ内でファイルシステ ムとして使われるイメージの 作成および管理 など 関連するコンテナのグルーピング コンテナに割り振られる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）
- 250. Twelve Factorsとの関係 250 Ⅰ. コードベース バージョン管理されている1つのコードベースと複数のデプロイ Ⅱ. 依存関係 依存関係を明示的に宣言し分離する Ⅲ. 設定 設定を環境変数に格納する Ⅳ. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う Ⅴ. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する Ⅵ. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する Ⅶ. ポートバインディング ポートバインディングを通してサービスを公開する Ⅷ. 並行性 プロセスモデルによってスケールアウトする Ⅸ. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する Ⅹ. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ Ⅺ. ログ ログをイベントストリームとして扱う Ⅻ. 管理プロセス 管理タスクを1回限りのプロセスとして実行する アジリティーの高いWebサービスを構築するための方法論 コンテナ Kubernetes https://12factor.net/ja/
- 251. Kubernetes Master 全体のコンテナの稼働 状況などを把握し、運用 管理者が指定したよう に、コンテナ配置、削除 などを指示 Kubernetes の全体構造 251 コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア コンテナ ライブラリ 環境変数 アプリや ミドルウェア 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
- 252. マイクロサービス（Micro Service） 252 ユーザー・インターフェイス 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 共有データ 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 個別データ ユーザー・インターフェイス 個別データ 個別データ 個別データ モノリス型アーキテクチャ マイクロサービス型アーキテクチャ マイクロ サービス 巨大な１枚岩のような 複数の独立した機能（マイクロサービス）を 組み合わせることでひとつの処理を実現する 大きな単一の機能によって ひとつの処理を実現する 単一の機能 独立した機能 内 部 は 複 数 の 機 能 で 構 成
- 253. マイクロサービス（Micro Service） 253 ユーザー・インターフェイス 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 共有データ 顧客管理 注文管理 在庫管理 出荷管理 Webブラウザ Webブラウザ Webブラウザ 個別データ ユーザー・インターフェイス 個別データ 個別データ 個別データ モノリス型アーキテクチャ マイクロサービス型アーキテクチャ マイクロ サービス 巨大な１枚岩のような 単一の機能 独立した機能 内 部 は 複 数 の 機 能 で 構 成 マイクロサービス単位でマシンが必要 各機能の単位でマシンが必要 ＊「マシン」とは物理マシンだけではなく仮想マシンやコンテナも含む。
- 254. マイクロサービス・アーキテクチャの6つのメリット 修正 修正 リリースの同期は必須 個別にリリース可能 Java Java Java Java Java Java Java Ruby php C++ Java Script C# 言語は統一 機能にふさわしい言語を選択 影響？ 影響？ 影響？ 影響？ 変更 影響？ 一部機能変更・全体テスト 一部機能変更・対象機能のみテスト 変更 全体で拡張 個別に拡張 正常 正常 正常 正常 障害 正常 正常 正常 正常 正常 障害 正常 一部障害で全体停止 一部障害でも正常箇所は稼働 流用 流用 特定の機能流用は困難 特定機能の流用は容易 １．機能の独立性 ２．言語の独立性 ３．保守の容易性 ４．拡張の柔軟性 ５．障害時の可用性 ６．再利用の容易性 「これなら分かる！ マイクロサービス（入門編）〜モノリスと比較した特徴、利点と課題（CodeZin）」を参考に作成
- 255. マイクロサービス・アーキテクチャの3つの課題 255 機能間で通信は発生しない 機能間で通信が行われる 全体をひとつのチームで行うので 人の入替えやノウハウ共有が容易 各機能個別に組織が分かれるの 人の入替えやノウハウ共有が困難 過剰分割の影響は内部に留まる 一貫したユーザー体験を提供 過剰分割はパフォーマンスを劣化 機能別に異なるユーザー体験のリスク １．機能間の通信によりパフォーマンスが出にくい ２．人の入れ替えやノウハウの共有が難しく”人”や”知見” の活用効率が低くなる ３．プログラム構造次第でパフォーマンスやユーサー体験に悪影響 通信により組み合わせるという仕組みから、パフォーマンス を出しにくい。 性能向上のため各機能間は非同期通信とし、機能をまたがっ たトランザクション保証はしないため、正常終了した後に後 続処理がエラーとなることも想定した設計が必要。 個人ユーザー向けの決済処理のような再試行が難しい業務の 場合は、実装が難しい。 マイクロサービスを適用したアプリケーションを作るには、 個々の機能と同じように独立し完結した組織でなければなら ないが、それができる保証はない。 チームごとに独自文化が形成されチーム間でスキルの共用が 難しい。 文化の違いから人的ローテーションも難しくなる。 マイクロサービスの利点を生かすには、機能の境界を適切に 設定することが必須となるが、分ける範囲を誤れば機能間の 通信が大量に発生する。 分けるべきであった機能を一つにしてしまえば保守性や再利 用性などのメリットが満たせない。 独自性がすぎるとユーザー体験がちぐはぐになってしまう。 「これなら分かる！ マイクロサービス（入門編）〜モノリスと比較した特徴、利点と課題（CodeZin）」を参考に作成
- 256. 「クラウド･ネイティブ」とは 256 開発者は他社と差別化できるビジネスロジックに集中したいのに 付加価値を生み出さない作業で負担を強いられる ミドルウェアの設定 インフラの構築 セキュリティ・パッチの適用 キャパシティ・プランニング モニタリング システムの冗長化 アプリケーションの認証・認可 APIスロットリング など この負担から開発者を解放 DevOps マイクロ・サービス アーキテクチャ コンテナ サーバーレス／FaaS(Function as a Service) アプリケーションを継続的・高速にアップデートし ビジネス・ニーズに即座に対応
- 257. ノーコード開発 ローコード開発
- 259. ローコード開発ツール インフラ・プラットフォーム構築 手組によるアプリケーション開発 クラウド 手組によるアプリケーション開発 クラウド ローコード 開発ツール ビジネスニーズの変化に即応 新規アプリケーションの開発期間の短縮 日々改善に対応できる保守・改修の実現 業務プロセス可視化による属人性の排除 経営視点を持ち、ビジネスゴールを設定できる能力 業務を分析・整理して、業務プロセスを描ける能力 現場のニーズを引き出せるファシリテーション能力
- 260. ローコード開発ツール 要件定義 概要設計 詳細設計 単体テスト 結合テス ト プログラミング 結合テスト 従来型 開 発 要件定義 運用・保守 （高速化・効率化） 結 合 テスト ローコード 開 発 ローコード開発 人手による作業 ツールによる 自動化 プログラム生成型 統合環境型 プラットフォーム型 画面や業務ロジック、データ構造などセグメント 毎に機能が独立 アプリケーション層よりも上位に特化、システム を統一的に構築、抽象化モデルを使いGUIで開発 システム開発だけではなく、ライフサイクル全体 を統一的に管理・支援 NTTデータ・TERASOLUNA NEC・SytemDirector Enterprise FUJITSU・Software Interdevelop Designer など GeneXus キヤノンITS・Web Performer 住友電工情報システム・楽々Framework3 ジャスミンソフト・Wagby SCSK・FastAPP など OutSystems ServiceNow Mendix AppPlatform サイボウズ・kintone Microsoft PowerApp/Datahlex Salesforce・Lightning Platform AWS・Honeycode Google・AppSheet など 運用・保守
- 261. 自動生成 ローコード開発ツールの 基本的な構造 要件定義 概要設計 詳細設計 単体テスト 結合テス ト プログラミング 結合テスト 設 計 リポジトリ 画 面 業 務 ロジック データ 構 造 アプリケーション データベース 運用・保守 アプリケーション 実行基盤 運用管理 ツール 運 用 レポート プラットフォーム型 ローコード開発ツール 人手による 作業 ツールによる自動化 GUI 画面・業務ロジック ・データ構造を管理 クラウド・サービス オンプレミス
- 262. デジタル・ビジネス戦略
- 263. DXを実践するための 内製化と共創
- 264. 作らない技術を前提としたシステム 自動車の 配車サービス 地図情報 代金決済 セキュリティ ID認証 損害保険 マイクロサービス、REST/AP|I クラウド・サービス クルマと人 マッチング
- 268. 作らない技術のスタック アジャイル開発 Agile Development ビジネスの成果に貢献するコードだけ 変更に柔軟・迅速に対応 バグフリーで提供 DevOps Development & Operation 運用の安定を維持 本番環境への迅速な移行 高速な改善 クラウド Cloud Computing 最新の機能やリソースの調達 経費化による不確実性への担保 構築や運用、セキュリティから解放 高品質で無駄なく変更要求に即応できるソフトウエアの実現 安定稼働と高速なデリバリーの両立 最新機能の調達と構築・運用からの解放 デザイン思考 XP（エクストリーム･プログラミング） スクラム など CI（継続的インテグレーション）/CD（継続的デリバリー） コンテナ マイクロ・サービス など サーバーレス／FaaS PaaS／SaaSとAPI リポジトリー・サービス など 心理的安全性と自律したチーム ゼロトラスト・ネットワーク
- 270. SI事業者の3つの戦略オプション 選択1 共創パートナー戦略 顧客の事業開発やそのための内製チー ムの一員として、顧客と共通の事業目 的／ビジョンを共有し、高い技術力を 提供で、この取り組みを支援する。 ユーザー企業の事業部門（内製チーム） モダンITのスキルやシステム・アーキテクト力、IT と事業をつなげるビジネス・デザイン力、先端技術 の知識など、高度な専門性を持つ人材 人材の確保、ビジネスのスケール 既存業務と異なる業績評価基準を持つ別会社の設立、 短期的なスケールは難しいが、中長期的に人材を育 成し、対応能力を高める 選択3 ビジネス・ソリューション戦略 自らのITスキルを活かして、自らが事 業主体としてビジネス・サービスを提 供する。 ⇒ IT企業からデジタル企業への転換 エンド・ユーザー（B2CとB2B） 対象業務に精通、あるいは想い入れの強い人材、IT についての知識は前提ではあるが、事業開発やマー ケティングについての常識を持つ ビジネス・ノウハウ、初期投資リスク システムの開発や運用だけではなく、業務プロセス も含めた組織・体制を構築し、独立した事業採算の 実現を目指す 顧客： 人材： 課題： 対策： 顧客： 人材： 課題： 対策： 選択2 プラットフォーム戦略 顧客のビジネス・モデルやビジネス・ プロセスの変革を支援／加速するため の機能やプロセスをAPIサービスとし て提供する。 ユーザー企業の事業部門（内製チーム） 対象業務に精通、必要な機能や業務プロセスについ ての知識、幅広い人脈を持つ人材。当然、役割分担 は可能 ビジネス・ノウハウ、初期投資リスク 1からプラットフォームを作る選択もあるが、既存 のプラットフォームを活かし、独自性の高い付加価 値をアドオン提供する方法は現実的。 顧客： 人材： 課題： 対策：
- 271. 共創パートナー戦略：ITの役割の変化 支援 人間主体でビジネスを動かしITが支援する 生産性向上・コスト削減・期間短縮 ITは合理化の手段、コスト削減で評価 目的と達成基準を明示すれば 専門家に任せることができる Before DX 人間とITが一体となってビジネスを動かす 即応力・破壊的競争力・新たな価値の創出 ITは競争力の源泉、投資対効果で評価 新規性とスピード 事業部門が責任をもって主導し 内製化 と 共創 で対処する After DX 省力化とコスト削減 事業を支えるIT 事業を変革するIT 達成基準と手段を予め決定できる 達成基準と手段を予め決定できない
- 272. 共創パートナー戦略： After DXは受託開発は無理 人間とITが一体となってビジネスを動かす 即応力・破壊的競争力・新たな価値の創出 After DX 事業を変革するIT 達成基準と手段を予め決定できない 高速な試行錯誤と改善を繰り返し 最適解を探索しなければならない 要求を”あいまいさなく”定義することが難しい 試行錯誤が不可避 要件全体を定義することが困難なのに、定義したこととして発注しなければならない 手続きの効率化のため発注単位を大きくまとめる 変化に即応できない 実際に動く成果物を確認するまでに、かなりの時間がかかる（開発作業中は変更できない） 作業量（工数）の見積を作る そもそも工数が見積もれない 作業量の見積が困難であるにもかかわらず、人月単価×期間（月数）による見積を作る 要求する人とシステムを作る人は遠く離れている 現場感覚がない 一連の作業は分業化、伝言ゲームで現場の現実を理解できず、臨機応変な対応もできない
- 274. 共創パートナー戦略：内製化×共創の必要性 人間とITが一体となってビジネスを動かす 即応力・破壊的競争力・新たな価値の創出 After DX 事業を変革するIT 達成基準と手段を予め決定できない 高速な試行錯誤と改善を繰り返し チーム一丸となり正解を探索する 相互信頼に裏打ちされたオープンなコミュニケーション ビジョンや課題、ノウハウや知識の完全な共有 自律したチームによる継続的な改善 内製化 共創 insourcing co-creation 責任の所在を明確にする 開発や改善のスピードを担保する 実践的な知識やノウハウを持つ 圧倒的な技術力を手に入れる 異なる価値観や視点を手に入れる ノウハウやスキルの不足を補う
- 275. 内製化の事例：アフラックの「ウェブ面談」 対面なしで生保契約、アフラックが先陣 半年で開発 アフラック生命保険は保険の提案から説明、契約 までネットで完結できるシステムを稼働させ、10 月末から全国展開する。開発は、わずか半年。 2020年9月30日 ビデオ会議を通じて年齢や病歴などに合わせて商品をカスタマイ ズし、最後は顧客がスマホ画面を指でなぞって署名する。営業担 当者と直接対面せずに保険契約を完了させられる。10月末からは 全国の代理店でも運用を始める。がん保険や終身保険、就業不能 保険など、代理店が手掛ける商品群を全てオンラインで提供。 狙い 1 ：データ活用の推進 保険の内容は加入者によって千差万別で、様々な特約も商品の複 雑さに拍車をかける。ウェブ面談を通じて定量データを収集して 解析すれば、顧客ニーズに即した商品開発や提案が可能になる。 データ収集範囲が広がれば、保険に加えて遺伝子検査や人間ドッ クなど、予防分野への本格進出にも道が開ける。 狙い 2：営業手法の刷新 代理店に属する「募集人」が戸別訪問などで保険内容を説明し、 契約するのが一般的だった。人手不足も広がり、デジタル化で手 間を減らしながら成約率の向上も狙う。
- 276. 共創パートナー戦略：クレディセゾン「お月玉」 開発費用：6人×3ヶ月＝人件費 約1000万円 スピード：アップデート 10分〜 事業成果：利用者数・利用金額ともに劇的増加 1億円以上？ 最低でも数日 コミットなし
- 277. 共創パートナー戦略：株式会社フジテレビジョン 数万人が同時に視聴できる配信環境を 3 週間ほどで構築 AWS Elemental MediaStore と Amazon CloudFront は、CMAF-ULL の超低遅延配信に必要な技術と 大規模配信に対応し、それをマネージドサービスとしてすぐに利用できる環境や、配信規模に応じたス ケーリング、障害発生時の切り替え対応などの煩雑な運用業務からの解放してくれた。 https://aws.amazon.com/jp/solutions/case-studies/fuji-tv/?fbclid=IwAR3bdoRp-sdBrOe_1I6JcALo5vHFzzO-tBTQ1wL4us1FLhcOIpzXax7bY3o
- 278. 共創パートナー戦略：受発注型取引と共創型取引 受発注型取引 どうなれば成功なのかを予め決められる 既存の業務プロセスの改善 既存システムの改修や機能の追加 既存業務の効率化や利便性の向上のための社内 ユーザーを対象としたシステム など 主従関係 ルールや手順に従う 効率を追求する 失敗は許さない 横並び・同質性を求める リーダーの指示に従う 言われたとおりやりました 言われなかったのでやりませんでした 仕様書通りに作りました など 管理者が進捗や成果を管理する ローコード開発、自動化やクラウド化で 誰もができるようになろうとしている 共創型取引 どうなれば成功なのかを予め決められない 新しいビジネス・モデルの立ち上げ 新しい業務プロセスのための新規システム 新規顧客の獲得や売上／利益の拡大のための社 外ユーザーを対象としたシステム など チーム関係 ビジョンの達成を目指す 事業の成果を追求する トライ&エラーを評価する 多様性を認め・補完しあう 対話や議論をして答えを探す こうした方がいいと思います 事業の成果に貢献するには、こちらですよ 状況が変わったのでこちらにしましょう など 権限を委譲し自分たちで進捗や成果を管理する 専門家としての経験の蓄積と 最新トレンドへの体験的理解がなければできない
- 280. プラットフォーム戦略：成功させる3つの要件 ビジネス価値の明確化： テクノロジーではなく、Purpose 魅力的なVisionによる求心力 エコシステムの構築： 調整力より、リーダーシップ 囲い込みからオープン・イノベーション 圧倒的ビジネス・スピード： 外注ではなく内製 アジャイル開発×DevOps×クラウド Purpose Vision Speed プラットフォーム・ビジネス ビジネス・モデル × ビジネス・プロセス × 事業戦略
- 282. コロナ禍後を見据えた3つの変革施策 既存事業 戦略事業 従業員 働き方 高収益化 標準化・効率化のためのプロセス・リ・デザイン モダナイゼーション・クラウド化・自動化 データ・ドリブン・マネージメント 試行錯誤・非連続な探索 投資・M&A 既存事業からの分離（組織・評価・場所など） 成長基盤の確立 自律と自発の醸成 HRTと心理的安全性 ジョブ型雇用 現場への権限委譲 変革 謙虚（Humility） 世界の中心は君ではない。君は全知全能ではないし、 絶対に正しいわけでもない。常に自分を改善しよう。 尊敬（Respect） 一緒に働く人のことを心から思いやろう。相手を一人 の人間として扱い、その能力や功績を高く評価しよう。 信頼（Trust） 自分以外の人は有能であり、正しいことをすると信じ よう。そうすれば仕事を自分以外の誰かに任せること ができる（ただし無能な人には任せるのは難しい）。 HRT 謙虚（Humility）、尊敬（Respect）、 信頼（Trust）のそれぞれの頭文字三文 字をとった言葉。読み方は「ハート (heart)」。
- 284. ベンダー企業の目指すべき方向性 (1) ユーザー企業の変革を共に推進するパートナー 新たなビジネスモデルを顧客と共に創出する DX の実践により得られた企業変革に必要な知見や技術を広く共有する レガシー刷新を含め、DX に向けた変革を支援する (2) DX に必要な技術・ノウハウの提供主体 最先端のデジタル技術等を習得し、特定ドメインに深い経験・ノウハウ・技術を有 する専門技術者を供給する 専門家として、技術、外部リソースの組合せの提案を行い、デジタル化の方向性を デザインする (3) 協調領域における共通プラットフォーム提供主体 中小企業を含めた業界ごとの協調領域を担う共通プラットフォームをサービスとし て提供する 高度なソフトウェア開発（システムの構築技術・構築プロセス・体制）を核にした サービス化とエコシステムの形成を行う (4) 新ビジネス・サービスの提供主体 ベンダー企業という枠を超え、デジタル技術を活用して新ビジネス・サービスの提 供を通して社会への新たな価値提供を行う DXレポート2 / p.16
- 285. 事業戦略を考える 自分たちの事業モデルを 破壊するものは何か？ 自分たちの事業モデルを どのように変革すればいいのか？ 事業戦略 DX、共創、クラウドネイティブなど 自分たちの未来は どうあるべきか？
- 286. DXの実践
- 287. DXという魔法の杖はない 社会の空気に迫られた 漠然とした不安 情報のつまみ食いによる 浅い考察 上からの何とかしろよの 追い詰められた感 はやり言葉 で拙速に解決しようとする 自分たちは、何を解決したいのか、何をしたいのか？ それらをはっきりとさせることが、全てに優先する。 DXが流行だから乗り遅れてはいけないと焦る事業会社 このブームに乗じてビジネスのチャンスを拡大しようとするITベンダー そんな世の中の流れに乗じて視聴率や購読者を増やそうとするメディア DXの本質から離れ ムダにヒートアップ させている AI 5G DX サブスク IoT プラットフォーム サービス化 AIで何ができるでしょうか？ 5Gはどんな分野で使われるようになるのでしょうか？ DXに取り組むには、何から始めればいいのでしょうか？ 予め用意された正解はない 自分が何をしたいかによって 答えは変わってしまう
- 288. テクノロジーを実装する3つのステップ 解決すべき課題をあきらかにする 放置できない脅威 これさえ解決できれば突破できること 是非とも実現したいこと など 課題を解決するための戦略を描く 課題の原因と解決方法についての仮説 解決方法に至る総合的な物語 事業への影響や効果 など 戦略を実践するための手段を組む ビジネス・モデルとビジネス・プロセス 組織や体制、業績評価基準や報酬制度 技術やITサービス、製品や店舗 など デジタルが前提を知るため 人々の振る舞いや価値観の変化 社会が要求する時間感覚の変化 技術の進化による最適解の変化 課題の存在に気付く感性 戦略を描く視点の多様化 最適な手段を選ぶ目利力 事業の成果に貢献 DXの実践とは、デジタルが前提の社会に、企業が適応できる能力を獲得すること。 Purpose/存在意義を貫くため なぜDXやトレンドを知る必要があるのか
- 289. テクノロジーを受け入れる前提条件 （１） 289 1900 1913 米・ニューヨーク 五番街 なぜ、短期間のうちに、これほど劇的に変わってしまったのでしょうか？ 製品：新しい技術を使い馬車をしのぐ利便性とコスト・パフォーマンスが実現できたから インフラ：既に馬車のための道路が整備されていて、そのまま自動車の通行に使えたから
- 290. テクノロジーを受け入れる前提条件 （２） 290 なぜ、両者にこれほど大きな差が生まれてしまったのか？ Google Glass Apple Watch 一般消費者向けの販売中止 世界で一番売れている時計 製品：両製品共に新しい技術を使い、これまでには無い機能や利便性を実現した Google Glass：あきらかに不自然（統制環境／工事現場や整備工場などならおかしくない） Apple Watch：違和感なく自然。腕時計の習慣は元々あって、時計が変わっただけ
- 291. ビジネスを生みだすための着眼点 このテクノロジーを使って、 何かできないだろうか？ 社会課題を解決すること 新規事業を実現すること 業務を効率化すること など この課題を解決するために どのテクノロジーが使えるだろうか？ 解決すべき社会課題は何か？ 実現すべき新規事業は何か？ 効率化すべき業務は何か？ など 手段から考える 思考法 課題から考える 思考法
- 294. デジタル・リテラシーの3段階 294 レベル 3 レベル 2 レベル 1 デジタルの役割や価値を理解し ている 専 門 実 践 基 礎 自分でシステムを作れるスキル を持っている ITの専門的なスキルを持ち、設 計や開発、運用などができる
- 295. DX人材 デジタル・リテラシー 経営や事業の現状を俯瞰、整理して、 課題と原因を定義できる。 経営者や事業部門が示した事業課題 を考察し、課題の精緻化や明確化を 支援できる。 デジタル技術やデジダル・ビジネ ス・モデルについての広範な知見を 有している。 デジタルについての知見を生かして、 事業課題を解決する戦略を描ける。 描いた戦略の実践を主導、または事 業責任者の伴走者として支援できる。 ビジネス レベル3 専 門 レベル2 実 践 レベル1 基 礎 デザイン データ 課題の発見と定義 戦略策定 コミュニケーション プレゼンテーション リーダーシップ など データ戦略 データモデル データ分析 など デザイン思考 ビジネス設計 UX設計 など