Contenu connexe Similaire à LiBRA 08.2021 / 総集編#01 (20) Plus de Masanori Saito (20) LiBRA 08.2021 / 総集編#019. UI/UXとは何か
UI
人とデジタルをつなぐ窓口
User Interface
直ぐに分かる
使い易い
迷わない など
UX
人とデジタルがつながることで得られる体験
User Experience
とても便利
もっと使いたい
感動した など
次へ 戻る 戻る 次へ
×良くないUI 〇良いUI
×良くないUI
ケチャップだとは
すぐに分からない。
×良くないUX
口を汚しやすく、少なく
なると使いにくい。
〇良いUI
ケチャップだとすぐ
分かる。
×良くないUX
口を汚しやすく、少なく
なると使いにくい。
〇良いUI
ケチャップだとすぐ
分かる。
〇良いUX
口を汚さず、最後まで
使い切ることができる。
12. プラットフォーマーと言われる企業の略称
GAFA
Google,Amazon,Facebook,Apple
FANGAM
Facebook,Amazon,Netflix, Google,Apple,Microsoft
GAFAM
Google,Amazon,Facebook,Apple,Microsoft
BAT
Baidu,Alibaba,Tencent
BATH
Baidu,Alibaba,Tencent,Huawei
米国系企業
中国系企業
FAANG
Facebook,Amazon,Apple, Netflix,Google
デジタル技術を駆使し、ビジネスでの圧倒的な支配力を持つ企業を、下記のように
まとめて呼ぶことがあります。
34. 時間感覚の変化がビジネスを変えようとしている
3年間の中長期計画
1年に一度の年度計画
半年に一度の設備投資
月例の定例役員会
週次の部門会議
ビジネス・モデル お客様との関係 働き方 情報システム
階層化された
ビジネス・プロセス
機能分化した組織
段階的意志決定
社会環境の変化が緩やかで中長期的な予測が可能
戦略を動かし続ける
現場に権限委譲する
現場での判断を重視
結果を迅速に事後報告
対話の頻度を増やす
圧倒的な
ビジネス・スピードで
変化に俊敏に対応する
社会環境が複雑性を増し将来の予測が困難な状況
デジタル化された
ビジネス・プロセス
自律したチーム
大幅な権限委譲
VUCA
中長期的な計画を元に
PDCAを回し
確実に目標を達成する
39. デジタル・トランスフォーメーション 2つの解釈
社会や経済の視点/社会現象
2004年、エリック・ストルターマン(ウメオ大学)の定義「ITの浸透により、人々の生活が根底
から変化し、よりよくなっていく」に沿った概念
デジタル・テクノロジーの発展によって社会や経営の仕組み、人々の価値観やライフ・スタイルが
大きく変化し、社会システムの改善や生活の質の向上がすすむという社会現象を意味する
経営や事業の視点/企業文化や体質の変革
2010年以降、ガートナーやマイケル・ウェイド(IMD教授)らによって提唱された概念
デジタル・テクノロジーの進展により産業構造や競争原理が変化し、これに対処できなけれ
ば、事業継続や企業存続が難しくなるとの警鈴を含む
デジタル・テクノロジーの進展を前提に、競争環境 、ビジネス・モデル、組織や体制の再定
義を行い、企業の文化や体質を変革することを意味する
デジタル・ビジネス・トランスフォーメーション
“デジタルを使うこと”ではなく “ビジネスを変革すること” が目的
デジタル技術とデジタル・ビジネス・モデルを用いて、組織を変化させ、業績を改善すること
1. 企業業績を改善することが目的。
2. デジタルを土台にした変革であること。組織を絶えず変化しているが1つ以上のデジタル技術が大きな影響を及ぼしているものでなければ、デ
ジタル・ビジネス・トランスフォーメーションには分類されない。
3. プロセスや人、戦略など、組織の変化を伴うものであること。
“ デジタル・ビジネス・トランスフォーメーションには、テクノロジーよりもはるかに多くのものが関与する ”
「DX実行戦略(マイケル・ウェイドら)」 p.27
41. リアルが最も貴い
デジタルはビジネスの手段である
価値の源泉はリアルにある、デジタルはリ
アルの付加価値に過ぎない
リアルとデジタルは別の仕組み、デジタル
はリアルを補間するもの
DXの常識とDXの実現
デジタルが前提
デジタルはビジネスの基盤である
デジタルとリアルが一体となって価値を創
出する
デジタルとリアルを分けることなく、デジ
タルが統合する1つの仕組みとして捉える
「DXの実現」とは
「デジタルが前提」を当然のことと考え、実践する
企業の文化や風土を実現すること
DXは 既存の常識の転換が前提
デジタルにできることは徹底してデジタルに任せ
人間にしかできないことに人間の役割をシフト
新しい常識
新しい価値
の創出を実現
43. CXとEXを向上させるためのDX
データ
CX : Customer Experience
お客様の事業の成果に貢献し
お客様の社員の幸せを支える
EX : Employee Experience
従業員のやり甲斐を与え
自己の成長の喜びを感じさせる
競争原理
収益構造
業務手順
組織・体制
意志決定方法
など
DX
デジタルを前提に
ビジネス・モデルや
ビジネス・プロセス
を再定義する
デジタル
技術
クラウド
AI
IoT など 変化に俊敏に対応できる
企業の文化や
風土への変革
UX
ユーザーの
体験価値を
高める
業務プロセスのデジタル化
デジタル・ビジネス・モデル
64. DXとPurpose
企業は、利益のためだけに存在してるので
はない。
企業の最大の目的は、永続的に成長し続け
る過程で社会的責任を果たすことだ。
利益は、企業や事業の目的ではなく、条件
である。
purpose beyond profit
企業の存在意義は利益を超える
2018年・IIRC(国際統合報告委員会)レポート「purpose beyond profit」
利益は、企業が自らの存在意義を追求した結果としてもたらされる
その存在意義を貫くために、企業は存続し成長しなくてはならない
IIRC(International Integrated Reporting Council/国際統合報告評議会)
企業などの価値を長期的に高め、持続的投資を可能にする新たな会計(情報開示)基準の確立に取り組む非営利国際団体で、業績などの財務情報だけでなく、社会貢献
や環境対策などの非財務情報をも一つにまとめた統合報告(integrated reporting)という情報開示のルールづくりやその普及に取り組んでいる。
73. 共創パートナー戦略: After DXは受託開発は無理
人間とITが一体となってビジネスを動かす
即応力・破壊的競争力・新たな価値の創出
After DX
事業を変革するIT
達成基準と手段を予め決定できない
高速な試行錯誤と改善を繰り返し
最適解を探索しなければならない
要求を”あいまいさなく”定義することが難しい 試行錯誤が不可避
要件全体を定義することが困難なのに、定義したこととして発注しなければならない
手続きの効率化のため発注単位を大きくまとめる 変化に即応できない
実際に動く成果物を確認するまでに、かなりの時間がかかる(開発作業中は変更できない)
作業量(工数)の見積を作る そもそも工数が見積もれない
作業量の見積が困難であるにもかかわらず、人月単価×期間(月数)による見積を作る
要求する人とシステムを作る人は遠く離れている 現場感覚がない
一連の作業は分業化、伝言ゲームで現場の現実を理解できず、臨機応変な対応もできない
78. 共創パートナー戦略:株式会社フジテレビジョン
数万人が同時に視聴できる配信環境を 3 週間ほどで構築
AWS Elemental MediaStore と Amazon CloudFront は、CMAF-ULL の超低遅延配信に必要な技術と
大規模配信に対応し、それをマネージドサービスとしてすぐに利用できる環境や、配信規模に応じたス
ケーリング、障害発生時の切り替え対応などの煩雑な運用業務からの解放してくれた。
https://aws.amazon.com/jp/solutions/case-studies/fuji-tv/?fbclid=IwAR3bdoRp-sdBrOe_1I6JcALo5vHFzzO-tBTQ1wL4us1FLhcOIpzXax7bY3o
81. 共創パートナー戦略:受発注型取引と共創型取引
受発注型取引
どうなれば成功なのかを予め決められる
既存の業務プロセスの改善
既存システムの改修や機能の追加
既存業務の効率化や利便性の向上のための社内
ユーザーを対象としたシステム など
主従関係
ルールや手順に従う
効率を追求する
失敗は許さない
横並び・同質性を求める
リーダーの指示に従う
言われたとおりやりました
言われなかったのでやりませんでした
仕様書通りに作りました など
管理者が進捗や成果を管理する
ローコード開発、自動化やクラウド化で
誰もができるようになろうとしている
共創型取引
どうなれば成功なのかを予め決められない
新しいビジネス・モデルの立ち上げ
新しい業務プロセスのための新規システム
新規顧客の獲得や売上/利益の拡大のための社
外ユーザーを対象としたシステム など
チーム関係
ビジョンの達成を目指す
事業の成果を追求する
トライ&エラーを評価する
多様性を認め・補完しあう
対話や議論をして答えを探す
こうした方がいいと思います
事業の成果に貢献するには、こちらですよ
状況が変わったのでこちらにしましょう など
権限を委譲し自分たちで進捗や成果を管理する
専門家としての経験の蓄積と
最新トレンドへの体験的理解がなければできない
85. コロナ禍後を見据えた3つの変革施策
既存事業 戦略事業
従業員
働き方
高収益化
標準化・効率化のためのプロセス・リ・デザイン
モダナイゼーション・クラウド化・自動化
データ・ドリブン・マネージメント
試行錯誤・非連続な探索
投資・M&A
既存事業からの分離(組織・評価・場所など)
成長基盤の確立
自律と自発の醸成
HRTと心理的安全性
ジョブ型雇用
現場への権限委譲
変革
謙虚(Humility)
世界の中心は君ではない。君は全知全能ではないし、
絶対に正しいわけでもない。常に自分を改善しよう。
尊敬(Respect)
一緒に働く人のことを心から思いやろう。相手を一人
の人間として扱い、その能力や功績を高く評価しよう。
信頼(Trust)
自分以外の人は有能であり、正しいことをすると信じ
よう。そうすれば仕事を自分以外の誰かに任せること
ができる(ただし無能な人には任せるのは難しい)。
HRT
謙虚(Humility)、尊敬(Respect)、
信頼(Trust)のそれぞれの頭文字三文
字をとった言葉。読み方は「ハート
(heart)」。
87. ベンダー企業の目指すべき方向性
(1) ユーザー企業の変革を共に推進するパートナー
新たなビジネスモデルを顧客と共に創出する
DX の実践により得られた企業変革に必要な知見や技術を広く共有する
レガシー刷新を含め、DX に向けた変革を支援する
(2) DX に必要な技術・ノウハウの提供主体
最先端のデジタル技術等を習得し、特定ドメインに深い経験・ノウハウ・技術を有
する専門技術者を供給する
専門家として、技術、外部リソースの組合せの提案を行い、デジタル化の方向性を
デザインする
(3) 協調領域における共通プラットフォーム提供主体
中小企業を含めた業界ごとの協調領域を担う共通プラットフォームをサービスとし
て提供する
高度なソフトウェア開発(システムの構築技術・構築プロセス・体制)を核にした
サービス化とエコシステムの形成を行う
(4) 新ビジネス・サービスの提供主体
ベンダー企業という枠を超え、デジタル技術を活用して新ビジネス・サービスの提
供を通して社会への新たな価値提供を行う
DXレポート2 / p.16
91. テクノロジーを実装する3つのステップ
解決すべき課題をあきらかにする
放置できない脅威
これさえ解決できれば突破できること
是非とも実現したいこと など
課題を解決するための戦略を描く
課題の原因と解決方法についての仮説
解決方法に至る総合的な物語
事業への影響や効果 など
戦略を実践するための手段を組む
ビジネス・モデルとビジネス・プロセス
組織や体制、業績評価基準や報酬制度
技術やITサービス、製品や店舗 など
デジタルが前提を知るため
人々の振る舞いや価値観の変化
社会が要求する時間感覚の変化
技術の進化による最適解の変化
課題の存在に気付く感性
戦略を描く視点の多様化
最適な手段を選ぶ目利力
事業の成果に貢献
DXの実践とは、デジタルが前提の社会に、企業が適応できる能力を獲得すること。
Purpose/存在意義を貫くため
なぜDXやトレンドを知る必要があるのか
108. 仮想化 や ソフトウエア化 のための仕組み
使いたい機能や性能の組合せや変更の自由を実現
ソフトウェア化とクラウド
簡単・便利・いつでも/どこでもITの機能や性能をサービスとして使える仕組み
実質的に使える機能や性能
ネットワーク
専門的な
スキルや
ノウハウ
大規模・集中化・一元化・標準化
自動化などを駆使して、魅力的な
コストパフォーマンスを実現する
物理的なハードウェアや設備
インフラストラクチャー
プラットフォーム
アプリケーション
運用管理者
特定の業務処理
を行うためのソフトウェア
アプリケーションで共通に使う機能
を提供するソフトウエア
オペレーティングシステム
データベース管理システム など
販売管理システム
会計管理システム など
ソフトウエアを動かすための
ハードウェアや設備
114. システム利用形態の歴史的変遷
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)
メインフレームの時代
オープン・システムの時代
クラウドの時代
115. 物理システム・仮想化・コンテナの比較
物理サーバー
(ハードウェア)
ミドルウェア
アプリ アプリ アプリ
ハイパーバイザー
仮想サーバー 仮想サーバー 仮想サーバー
物理システム 仮想化されたシステム
ミドルウェア ミドルウェア
物理サーバー
(ハードウェア)
物理サーバー
(ハードウェア)
ストレージ
CPU
メモリ
ストレージ
CPU
メモリ
ストレージ
CPU
メモリ
物理サーバー
(ハードウェア)
ミドルウェア
アプリ アプリ アプリ
ミドルウェア ミドルウェア
OS
コンテナ・システム
物理サーバー
(ハードウェア)
ミドルウェア
アプリ アプリ アプリ
ミドルウェア ミドルウェア
ライブラリ
環境変数
ライブラリ
環境変数
ライブラリ
環境変数
コンテナ管理システム
コンテナ コンテナ コンテナ
カーネル
OS
OS
OS OS
OS
OS
121. DockerとKubernetes の関係
121
コンテナの作成
コンテナの実行
コンテナ内でファイルシステ
ムとして使われるイメージの
作成および管理 など
関連するコンテナのグルーピング
コンテナに割り振られる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)
122. Twelve Factorsとの関係
122
Ⅰ. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
Ⅱ. 依存関係
依存関係を明示的に宣言し分離する
Ⅲ. 設定
設定を環境変数に格納する
Ⅳ. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
Ⅴ. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
Ⅵ. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
Ⅶ. ポートバインディング
ポートバインディングを通してサービスを公開する
Ⅷ. 並行性
プロセスモデルによってスケールアウトする
Ⅸ. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
Ⅹ. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
Ⅺ. ログ
ログをイベントストリームとして扱う
Ⅻ. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
アジリティーの高いWebサービスを構築するための方法論
コンテナ Kubernetes
https://12factor.net/ja/
126. Chromebook
インターネット
データ
文書作成 表計算
プレゼン ・・・ ブラウザ
画面表示・入出力操作
通信
画面表示・入出力操作
通信
オフィス・アプリ
データ
文書作成 表計算
プレゼン ・・・
オフィス・アプリ
クラウドサービス Google Apps for workなど
ブラウザ
文書作成 表計算
プレゼン ・・・
PC / Windows・Mac OS など Chromebook / Chrome OS
135. クラウド・サービスの「作り方」による費用の違い
サーバー(物理マシン)×9台
+データベース等のライセンス
+インフラ、DBなどの環境構築
+運用管理業務
+設置場所(場所+電源+空調等)
購入費用 :数千万円
年間保守料 :数百万円
年間運用量 :数百万円
年間使用料 : ー
ハードウェアを所有 クラウド・サービスを使用
サーバー(仮想マシン)×9台
+データベース等のライセンス
+インフラ、DBなどの環境構築
+運用管理業務
× 設置場所(場所+電源+空調等)
購入費用 : ー
年間保守料 : ー
年間運用量 : ー
年間使用料 :254,980円
ハードウェアを所有する場合と変
わらないシステム構成と運用方法
実行環境を移行しただけ
システムの構成や運用方法などの設計・方式は同じ まったく異なる設計・方式
アンケート入力・集計・レポートのサービスとして、できることは同じ
サーバー(仮想マシン)×4台
購入費用 : ー
年間保守料 : ー
年間運用量 : ー
年間使用料 :198,691円
× データベース等のライセンス
△インフラ、DBなどの環境構築
△ 運用管理業務
× 設置場所(場所+電源+空調等)
無償のDNSや監視、低料金のデー
タベースなどのサービスを利用
一部をクラウドのサービスに代替
サーバーの構築・運用は不要
購入費用 : ー
年間保守料 : ー
年間運用量 : ー
年間使用料 :907円
× データベース等のライセンス
× インフラ、DBなどの環境構築
× 運用管理業務
× 設置場所(場所+電源+空調等)
サーバーレス方式と言われるまっ
たく異なる実行方式を採用
クラウド・ネイティブで再構築
ハードウェアを所有し、設置場所
とその運営も自社責任
137. 構築事例: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時点
146. セルフ・サービス・ポータル
調達・構成変更
サービスレベル設定
運用設定
・・・
数分から数十分
直近のみ・必要に応じて増減
経費・従量課金/定額課金
クラウド
システム資源のECサイト
見積書
契約書
メーカー
ベンダー
サイジング
調 達
費 用
数週間から数ヶ月
数ヶ月から数年を想定
現物資産またはリース資産
従来の方法
調達手配
導入作業