Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」

IBM Cloud Festa Online 2022 Summer
UX Ops(Design Ops)、Data Ops、
ML Ops、DevOps、GitOpsで実現する
オペレーショナルエクスペリエンスな世界
2022年 7月 29日
IBM クライアントエンジニアリング本部
エンジニアリングマネージャー平山毅
テクノロジーエンジニア米坂武士
データサイエンティスト鵜飼裕紀
デザイナーヒョンミン

© 2022 IBM Corporation
3
全体Agenda
発表者一覧
エンジニアリングマネージャー
データサイエンティスト
デザイナー
コンサルタント
エンジニア

4
後編 15:00 ～
https://ibm-developer.connpass.com/event/254726/

5
全体Agenda
1 オペレーショナルエクスペリエンス (5 min) 平山毅
2 DevOpsとGitOps （15 min ) 米坂武士
3 Data OpsとML Ops （15 min ) 鵜飼裕紀
4 Design OpsとUX Ops （15 min ) ヒョンミン

6
自己紹介
Name: 平山毅 (ひらやまつよし)
Company: IBM Japan
Dept: IBM Client Engineering
Role: Engineering Manager
Joined: 2021年 from Other IBM Department
Skills: Solutions Architecting ,Cloud Engineering,
Data Science, Design , Consulting
東京都立日比谷高等学校卒業。東京理科大学理工学部卒業。早稲田大学大学院経営管理研究科ファイナンス専攻修了
（MBA）。北陸先端科学技術大学院大学先端科学技術研究科情報科学専攻在籍。GMOインターネット、サイバーエージェ
ント、東京証券取引所、野村総合研究所、アマゾンウェブサービス、を経て2016年2月日本IBM入社。クラウド事業、
Red Hatアライアンス事業、Data AI 事業、を歴任後に、2021年7月より前身のテクノロジーガレージ本部ガレージマネ
ジャー、2021年10月よりクライアントエンジニアリング本部エンジニアリングマネージャー、で主にFintech等の金融イ
ノベーション領域のプロジェクトに従事。チームスクワッドで要するコンサルティング、ソリューションアーキテクティ
ング、クラウドエンジリアリング、データサイエンス、デザイン、5つ全ての領域での経験と専門性を有する。著作「絵
で見てわかるクラウドインフラとAPIの仕組み」他7冊。エバンジェリストとして海外含めた公演多数。産業技術大学院大
学、早稲田大学大学院、事業構想大学院大学、神奈川大学での講師も担当。IBM Technical Experts Council of Japan
Steering Committee Member

7
オペレーション（Ops）
Dev Ops
Git Ops
Data Ops
ML Ops
Design Ops
UX Ops
開発スタイルの変更
アジャイルアプリ
ビックデータAIの普及
AIアプリケーション
エクスペリエンス重視
業務寄りのUI/UX重視
Red Hat OpenShift Container Platform (Cloud & Agile)
Carbon
Design
Systems
Designer Data
Scientist
Engineer
ML /
AI
Front
JS
Application
Backend
API / SDK
Application
UI/UX Modeling
Bisiness
Consultant
Business
Model
Cost Reduction
Using Data AI Automation

8
オペレーショナルエクセレンスとは
DX（アジャイル体制＆AI活用＆高いデザイン性）
＝成⾧している企業の共通点
現場の業務改善を徹底することで競合他社に差をつけること
＝日本企業の競争力の原泉だった。。
DX活用後のオペレーション力が企業の変化
スピードにそのまま企業成⾧力に影響していく

9
２．DevOpsとGitOps （15 min ) 米坂武士

10
自己紹介
Name: 米坂武士
Company: 日本アイ・ビー・エム
Role: Technology Engineer
Joined: 2021年
Skills: CI/CD、IaC
前職からKubernetes NativeなCI/CDの
構築・運用に携わっており、現職でも社内で
CI/CD関連研修の講師も務めております。

11
2. DevOpsとGitOps Agenda
1 DevOpsとは
2 CI / CD
3 GitOpsとは
4 まとめ

12
DevOpsとは
DevOpsの勘違い
• DevOpsとは開発チームと運用チームを単純に統合するものではない
• DevOpsとは独立したチームではない
• DevOpsとはツールではない
• DevOpsとは万能な戦略ではない
• DevOpsとは自動化ではない

13
DevOpsとは
DevOpsの目的
Dev
開発チームは新しいものをリリースしたい
新しい機能の追加や不具合改修を行い、迅
速なアプリケーション開発とリリースを行
いたい
一言で表すなら「変化」

14
DevOpsとは
DevOpsの目的
Dev
開発チームは新しいものをリリースしたい
新しい機能の追加や不具合改修を行い、迅
速なアプリケーション開発とリリースを行
いたい
一言で表すなら「変化」
Ops
運用チームはシステムを修正したくない
問題を起こさずシステムの安定稼働を行い
たい為、動いているシステムになるべく修
正を加えたくない
一言で表すなら「安定」

15
DevOpsとは
DevOpsの目的
Dev Ops
「変化」と「安定」という相反する要望を協調して実現しようと言うのが
DevOpsの目的であり狙い
「変化」「安定」
Ops
Dev
Plan
Code
Build
Test
Deploy
Operate
Monitor
Feed Back

16
DevOpsとは
DevOpsとは文化

17
CI / CD
DevOpsを実現させるために必要なCI / CD
CD
CI
Plan
Code
Build
Test
Release
Deploy
Operate
Measure

18
CI / CD
CIとは
「Continuous Integration」の略で継続的インテグレーションと呼ばれており、
アプリケーション開発において短期間で品質管理を行う手法のこと
テスト・ビルドといったアプリケーション開発のサイクルを頻繁に繰り返し実行
することで、問題の早期発見や開発効率の向上などが可能になる
Test Build Deploy
Clone
テスト環境
ステージング環境
本番環境

19
CI / CD
CDとは
「Continuous Delivery」の略で継続的デリバリーと呼ばれており、アプリケー
ションを実行環境に配備(デプロイ)して実際に動作する状態を作ること
各環境(テスト、本番等)に自動でデプロイが行える様になるので、頻繁にアプリ
ケーションをリリースできるようになる
Test Build Deploy
Clone
テスト環境
本番環境

20
CI / CD
CI / CD パイプラインとは
CI / CDを実践する為に必要な一連のステップを自動化したもの
CI / CD パイプラインを構築することでコードに変更があると、デプロイまでの
ステップが自動化される
部分的に導入することでも一定の効果がある
ただし、プロセス全体のリードタイムを短くするには各ステップだけでなく、ス
テップ間の処理も自動化する必要がある
Test Build Deploy
Clone
テスト環境
本番環境

21
CI / CD
CI/CDツール
参考：https://landscape.cncf.io/card-mode?category=continuous-integration-
delivery&grouping=category

22
GitOpsとは
GitOpsとは
Weaveworks社が2017年にBlogで発表したCDの手法
参考:https://www.weave.works/blog/gitops-operations-by-pull-request
[原文要約]
Gitを信頼出来る唯一の情報源として使用することで、バージョン管理・Peer Review・ロール
バック等をkubectl等のCLIを利用する事なくGitを介して行う
Trust Me!!

23
GitOpsとは
GitOpsとは
[少し噛み砕く]
インフラ(Kubernetes上のリソース)とアプリケーションの両方を含めたシステム全体をコード化
して、Gitで管理する
以下のサイクルでOpenShift / Kubernetes上のリソースを管理すること
- Gitへの変更をCommit
- Pull Requestを作成
- Pull Requestを承認
- 承認された変更を適用

24
GitOpsとは
Traditional CI / CD (CIOps)
Test Build Deploy
Clone
Kubernetes Cluster
Git
Push
(Source
)
Image Push
メリット
• シンプルでCIを契機にデプロイが行
われる
• 開発者にとってデプロイのタイミン
グが測りやすい
Git Push
(manifest)

25
GitOpsとは
Traditional CI / CD (CIOps)
Test Build Deploy
Clone
Kubernetes Cluster
Image Push
デメリット
• CIでインフラまで操作ができてしま
うのでセキュリティ的に問題がある
• Principle of Least Privilege(CIとCD
の分離)が遵守できない
Git Push
(manifest)
Git
Push
(Source
)

26
GitOpsとは
GitOpsツール - ArgoCD -
• CNCFのインキュベーションプロジェクト
• CRDとしてKubernetes上のリソースとして管理される
為、Kubernetesの一部のように利用可能
• リッチなGUIが提供されており、閲覧だけでなく、登
録/変更操作が可能
• Cluster内のリソースとGit Repoのマニフェストのdiff
を参照し同期する
• SSO統合が可能(OIDC、OAuth2、LDAP、GitHub、
GitLab等)

27
GitOpsとは
GitOpsツール - Flux -
• CNCFのインキュベーションプロジェクト
• シンプルで軽量(GUIすらない)
• Gitのhash値を参照し差分があれば同期する
• ユーザー管理機能はなくRBACで制御
• 後発製品だけあってデフォルトで通知等の便利なCRD
が予め用意されている

28
GitOpsとは
One Part Cloud Native CI / CD (GitOps)
Test Build
Clone
Kubernetes Cluster
Image Push
メリット
• CIとCDの責任分解ができる
開発者が実施したいCIの処理と運用
者が実施したいCDの処理がはっきり
と二分化されたフローに分けられる
Push
Git
Push
Watch
Deploy
Git Push
(manifest)
Git
Push
(Source
)

29
GitOpsとは
One Part Cloud Native CI / CD (GitOps)
Test Build
Clone
Kubernetes Cluster
Image Push
デメリット
• 開発者と運用者が明確に別れていな
い組織だと効果を実感しづらい
Push
Git
Push
Watch
Deploy
Git Push
(manifest)
Git
Push
(Source
)

30
GitOpsとは
Cloud Native CIツール - Tekton -
• CDFのインキュベーションプロジェクト
• Kubernetes Nativeのオープンソースフレームワーク
• Taskと呼ばれる一連のコマンド(テスト実行、イメージ
のビルド等)を定義する
• Pipelineと呼ばれるTaskの集合体で依存関係を定義し
パイプライン処理を実行する
• パイプライン処理は全てコンテナ上で稼働し、Tekton
自身もコンテナとして提供される

31
GitOpsとは
Cloud Native CI / CD (GitOps)
Test Build
Clone
Kubernetes Cluster
Image Push
メリット
• 全てのツールがKubernetes上のコン
テナとして起動
• CRで定義可能な為、CIとCDの定義
を GitOpsで管理可能
Push
Git
Push
Watch
Deploy
Git Push
(manifest)
Git
Push
(Source
)

32
GitOpsとは
まとめ
• DevOpsとは特定の定義のことではなく、Dev(開発)とOps(運
用)を統合する事を目的とした概念や文化である
• DevOpsを実現させる為にはCI / CDが必須である
• GitOpsを採用することによりDevOpsをさらに加速させる

33
3．Data OpsとML Ops （15 min ) 鵜飼裕紀

34
自己紹介
Name: 鵜飼裕紀
Role: Data Scientist
Joined: 2021年
Skills: Analytics, Sales-Engineering
大学院卒業後、日系ERPシステムベンダーにて会計システムの開発エンジニア、
外資系データアナリティクスベンダーでのデータ&AI利活用コンサルタントを経てIBMに入社。
前職では製造／電力／金融を担当し、データ整備から可視化・要因分析、AIモデル活用まで幅広く提案。
またシステム・サービス提案の上流から、契約後の実装や定着支援まで経験あり。

35
Agenda
1 データ利活用の足元課題
2 DataOps, MLOps
3 オペレーショナルエクセレンス
4 まとめ

36
データ利活用の足元課題
顕在化する課題と”見えない”課題
”見えない”課題
準備タスク
顕在化する課題
データ分析
業務実装
分析設計
データアクセス
（検索／取得）
予備分析
（あたりをつける）
予備分析の深堀
（要因分析／予測分析）
分析結果の
配信／自動更新
データ加工
サンプリング
予測処理を
システム化

37
データ利活用の足元課題
顕在化する課題と”見えない”課題
分析設計
データアクセス
（検索／取得）
予備分析
（あたりをつける）
予備分析の深堀
（要因分析／予測分析）
分析結果の
配信／自動更新
データ加工
サンプリング
予測処理を
システム化
DataOps MLOps
準備タスク
顕在化する課題
データ分析
業務実装
潜在する課題を先回りして対処

38
DataOps
DataOpsの目的
Data
データ分析者は自由にデータを使いたい
データ分析はトライ＆エラーの繰り返しで
あるため、様々な種類や粒度のデータを
柔軟に取得できることが必須
Ops
データ管理者はガバナンスを徹底したい
データの品質やセキュリティ担保の責任が
あるため、誰もが自由にデータにアクセス
できる状態は許容できない
管理者に求められるガバナンスを常に担保しつつ、分析者が必要なデータを必要なタイミングで
取得できるようになることでデータ利活用を促進するのがDataOpsの目的
組織の壁

39
DataOps
DataOpsに向けた取り組み
Data
データ分析者は自由にデータを使いたい
 データ分析上の要件精査と連携
 セルフサービス型ツールの検討
 データカタログの充足活動 etc...
Ops
データ管理者はガバナンスを徹底したい
 データ管理上の要件精査と連携
 分析者向けツールの検討や導入支援
 データマートや初期カタログ整備 etc...
相互理解
役割分担
双方のスキルアップとデータ利活用に係る業務の効率化を実現
（※データ準備やETLのツール導入だけでは限定的な解決課題にしかならない）

40
MLOps
MLOpsの目的
ML
Machine Learning
データ分析者
 モデルは1度作れば完了
 モデルを開発（再学習）しても
実装を待つ間に価値が薄まってしまう
 モデルの劣化を検知する仕組みがない
Ops
システム管理者
 モデルは1度実装すれば完了
 追加システムの導入や管理が発生するが
現行システムの保守運用だけでも業務の
負荷が高いため対応が難しい
共通の誤解
組織の壁
開発したモデルの実装と、実装後のモデルの監視／再学習／再実装までを、なるべく低負荷かつ
ガバナンスを担保して実現することでモデルの実運用を加速するのがMLOpsの目的

41
MLOps
MLOpsに向けた取り組み
ML
Machine Learning
データ分析者
 開発効率の向上
 モデルを迅速に実装
 精度検知と再学習
Ops
システム管理者
 ガバナンスの担保
 業務負荷の低減
 モデルのCI/CD
Ops
ML
モデル開発
EDA
データ準備
手動再学習
レビュー
実装
精度監視
自動再学習
適切なシステム化と運用設計により低負荷でのモデル開発と実業務での運用を実現

42
オペレーショナルエクセレンス
オペレーショナルエクセレンスの事例
Before Process After
“データ分析ツール”のみ導入
分析者
管理者
 「準備タスク」の課題が
新たに断片的に顕在化
 導入済ツールは機能不足
 分析者からの度重なる
システム設定の変更依頼
 新しいツールの検討依頼
分析者
管理者
 データ取得からモデル開発
までをセルフサービス化
 分析作業の工数を半減
 通知やアラートまでを含め
管理業務を半自動化
 分析関連の管理工数を削減
業務とツールの両方を見直し自走的なデータ活用サイクル
DataOps
MLOps
 業務目線の分析設計と要件精査
 将来の課題を想定し事前に対処
 CI/CD前提の分担と要件精査
 先行プロジェクトで仮説を検証

43
GitOpsとは
まとめ
 「データ利活用」には顕在化する課題と潜在的な課題がある
 これまでの「べからず事例」から抽出した学びを体系化したのが
DataOpsやMLOpsの考え方で、潜在的な課題への対応には必須
 ツールの闇雲な導入だけでは効果が薄く、DataOpsやMLOpsを参考に
分析者と管理者が業務設計の段階から協業的に検討することで、
（初めは遠回りに見えても）データ利活用のサイクルは加速できる

44
4．Design OpsとUX Ops （15 min ) ヒョンミン

45
自己紹介
Name: キムヒョンミン (Hyunmin Kim)
Role: Designer
Joined: 2021年
Skills: UX, Design Thinking, Facilitation
IBM Client Engineering Designer。HCD-Net 認定人間中心設計専門家。
多数の大手IT企業でLead UX Designer、Team Managerの経験を積む。
UXリサーチ、設計、戦略、UI制作、テスト、リリースまでプロジェクトを推進。
UX人材、メンバーの育成、チームビルディングなどのマネジメントを実施。
現在IBMで新規事業、事業展開などお客様とデザインシンキングを通じて共創しながら課題を見つけ、課題解決や新たな価値
を創出している。

46
4. Design Ops UX Ops Agenda
1 DesignOps
2 UX Ops
3 UX Opsの事例
4 まとめ

47
DesignOps
DesignOpsとは
デザインの価値や影響力を正しく伝えるためのメンバー、
プロセス、技術的な面の最適化を意味する

48
DesignOps
DesignOpsの目的
1. デザインアウトプットの品質改善
2. デザインプロセスの効率化
3. デザインチームの成⾧
4. デザインチームへポジティブな文化作り
5. デザイナー人材雇用の効率化

49
DesignOps
DesignOpsの事例
IBM Carbon Design System

50
UX Ops
UX Opsとは
組織やサービスにポジティブなエクスペリエンスを与える
ためにUXプロセス、思考、文化などを最適化すること
Process KA法 Service Blueprints

51
UX Ops
UX Opsの目的
1. 顧客とのアウトプットの品質改善
2. UXやデザインシンキングの効果的活用
3. デザインチームとメンバーの成⾧
4. UXを通じた多様な職種とのインタラクション（信頼、理解、共創）
5. 組織内へのポジティブな文化作り
6. 多様な経験のナレッジを共有

52
UX Ops
UX Opsで重要なこと
52
一方的な提案ではなく共創する

53
Design OpsとUX Ops
DesignOps
1. デザインアウトプットの品質改善
2. デザインプロセスの効率化
3. デザインチームの成⾧
4. デザインチームへポジティブな文化作り
5. デザイナー人材雇用の効率化
UX Ops
1. 顧客とのアウトプットの品質改善
2. UXやデザインシンキングの効果的活用
3. デザインチームとメンバーの成⾧
4. UXを通じた多様な職種とのインタラク
ション（信頼、理解、共創）
5. 組織内へのポジティブな文化伝播
6. 多様な経験のナレッジを共有
DesignOpsとUX Ops

55
UX Ops
UX Opsの事例
<IBM Client Engineering>
• IBM CE UX DAY!
(IBM Client Engineering UX DAY!)
• 電子書籍執筆
• IBM CE UX Designer’s Contents
• Project内UX共有会
など
<前職成果事例>
• UX ガイドライン
• UX Designer 社内教育プログラム
• UX メソッド教育
• プロジェクト内ワークショップ
• UX Designer キャリアプラン
• UX Designer 役割、仕事のプロセ
ス見直し、最適化

57
まとめ
UX Ops
1. UX OpsはDesignOps概念を応用/発展
2. 一方的な提案ではなく、共に共感・共創する
3. 企画は‘WHAT/HOW’ではなく、‘WHY’を先に考える
4. 現状と理想のギャップを把握し、実行案を考える
5. 想像だけではなく、実際形に落としてみるのが重要

59
ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報
提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むも
のでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗
示にかかわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害
が生じた場合も、IBMは責任を負わないものとします。本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかな
る保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したもので
もなく、またそのような結果を生むものでもありません。
本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示
するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっ
ていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講
演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示すること
を意図したものでも、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用し
た測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラ
ミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、
個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。
記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示された
ものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。
IBM、IBM ロゴ、ibm.com、IBM Client Engineering、Carbon Des は、世界の多くの国で登録されたInternational Business Machines Corporationの商標
です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、
www.ibm.com/legal/copytrade.shtmlをご覧ください。

Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」

Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」

Recommended

Recommended

More Related Content

Similar to Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」

Similar to Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」 (20)

More from Tsuyoshi Hirayama

More from Tsuyoshi Hirayama (20)

Cloud Festa 2022 Summer 「UX Ops(Design Ops)、Data Ops、ML Ops、DevOps、GitOpsで実現するオペレーショナルエクスペリエンスな世界」