DevOps accelerates Digital Transformation

DevOpsDays Tokyo2019で登壇させていただいた資料です。(一部抜粋
https://confengine.com/devopsdays-tokyo-2019/schedule

IDCの調査結果によると、2018年の国内企業におけるDevOps実践率は上昇し、2019年も引き続き多くの企業がDevOpsを実践すると予想されます。その一方で、実践の効果が出ている企業はまだ少なく、経済産業省が提唱する「2025年の崖」という既存システムの課題を数多く抱えながら、試行錯誤する企業も多くあります。

　デジタルトランスフォーメーションを推進する上では、アジャイルな開発体制、Kubernetesを活用したアプリケーション開発プロセス、クラウドネイティブな開発プラットフォームといった要素が欠かせません。しかし、Kubernetesを顧客に提案していく中で見えてきた課題は、そもそもチームの目標(Key Goal Indicator)が不明確といったものでした。

　本講演では、「2025年の崖」や「Accelerate: The Science Behind Devops」をベースとして、企業がどのようなプロセスでDevOpsを推進すべきかを紹介していきます。

Transcript

1. 組織でどのように を加速させるのか
3. とビジネス成果 年の崖が示す世界
4. あなたのビジネスに は必要なのか 本日お伝えしたいこと
5. とビジネス成果
6. 可能な限り費用対効果の高い方法で、顧客の期待 ビジネス要求 を満たすこと ビジネス成果とは 顧客 製品 サービス 生み出される 利益 企業 顧客価値 求められる品質 期待する速さ ビジネス価値 高い生産性 顧客は製品やサービスに価 値を定義している。 企業は生み出された利益 収益 コスト に価値を定 義している。 ビジネス要求 環境変化への迅速な対応 製品・サービス改善 柔軟に対応できる体制 費用対効果
7. の対応 デジタルトランスフォーメーションは技術 人 プロセスの変更によってビジネス成果を高める活動 とは ビジネス要求 環境変化への迅速な対応 期待する速さ 製品・サービス改革 柔軟に対応できる体制 企業が競合優位性を保つために、 より良いサービスやソフトウェアをユーザーに速く提供すること 求められる品質 人・組織 技術 プロセス つの要素を改革し、高い生産性 効率化を追求
8. は技術によって、人や企業文化、プロセスを効率化すること の考え方 プロセス <Reference> https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means- to-an-end-enabling-continuous-deliverydeployment/ の対応 新しい技術や既存のデータを活 用することによって、既存のプロセ スや組織のしがらみを開放する 技術やアーキテクチャの改善は、DX を達成するための手段に過ぎない。 最終的な目標は、技術の改善に よって、企業が既存のプロセスや組 織を改革し、より良いサービスやソ フトウェアをユーザーに速く提供す ること 人・組織 技術
9. の適正化 費用対効果の最大化 製品 サービスの品質 顧客価値と適切な品質 スピードのコス トが最小になる場所 顧客は一定の品質に達すると、会社がいくら 投資をしても、顧客の価値は上がらない。 また、それに対する投資も行えない。 顧客の適切な品質とスピードを定義
10. 技術によって、人や企業文化、プロセスを 費用対効果の最大化 製品 サービスの品質 文化やプロセスを効率化してコストを削減 人を投資して品質を守る時代は終焉 ライセンス費や運用費のコスト圧縮では限界 の対応 人・組織 技術 プロセス つの要素を改革し、高い生産性を追求
11. は、 にとらわれる話ではない ※補足 バイモーダルはリソース投資割合 利益はあくまで に対する成果であり、コストは利益を生むためのリソース 投資。 は「人」「プロセス」「技術」のリソース投資割合と捉えられる。 のリソース投資 迅速化 技術 人・組織 プロセス 運用 投資に対してビジネス貢献が可視化しやすいシステム のリソース投資 効率化 運用 人・組織 技術 プロセス 投資に対してビジネス貢献が可視化しにくいシステム システム変更を運用によっ て、安定性を確保する。 システム変更をシステム設 計によって、スピードを確保 する。
12. リソース効率とフロー効率の順番を検討する プロセスの効率化 <Reference> https://better-operations.com/2013/06/30/this-is-lean/ 現状の運用効率 リリースまでのリードタイムが長い 客の要求が満たせない状態 運用稼働率が低いチー ムはリリースまでのリードタ イムが短くなる 現状の運用状態を理解 プロセスを改善する コストを削減する 多くの企業は、人の稼働率の高さによってシステム運 用の最適化を行っていると思っているが、実際は管理 プロセスの遅さによってリードタイムが増えている。 まずはリソースの活用 人材やシステム を犠牲にして、 プロセスを効率化することで、顧客が求める品質や速 度を提供する。 ある程度の空きリソースが必要 プロセス改善によってできた人の稼働率を、有効的に 活用することでコストを削減する トイルの削減 リソースの有効活用
13. 「 年の崖」が示す課題
14. 『 レポート～ システム「 年の崖」の克服と の本格的な展開～』 【 年の崖】とは <Reference> https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf を実行する上での経営戦略における現状と課題 既存システムの現状と課題 ユーザ企業における経営層・各部門・人材等の課題 ユーザ企業とベンダー企業との関係 情報サービス産業の抱える課題 経済産業省が、日本企業のDXを実現していく上 での、ITシステムの現状課題を整理し、その対 応策の検討として取りまとめた報告書
15. ブラックボックス状態を解消し、既存システムを活用した本格的な の推進 【 の崖】 の本格的な展開を数値化 ラン・ザ・ビジネス：バリューアップ システム全体の整合性を確認 数ヶ月 ユーザー 情シス ベンダー 産業の年平均成長率 技術的負債を解消し、クラウドを活用 予算比率 リリース期間 人材分布 産業成長率 ラン・ザ・ビジネス：バリューアップ リリース作業にかかる時間 数日間 ユーザー 事業部門 ベンダー 産業の年平均成長率 年の現状 年の展望 既存システムのブラックボックス化を解消できない場合、技術的負債が増大し が実現できない。 マイクロサービス・テスト自動化の導入 事業のデジタル化を推進する人材育成 デジタルを活用した新規事業開拓 基幹系システム投資 ６割 既存 数ヶ月 既存市場 デジタル市場 人材の不足 万人に拡大 年の崖
16. 既存のシステムを見直していくことが不可欠 【 の崖】 既存システムの現状と課題 技術の老朽化 システムの肥大化 複雑化 既存システムの ブラックボックス化 既存システムの維持、保守 に資金や人材が割かれる 不十分なマネジメント 自社経営陣 の理解が得難い 既存システムのコスト削減 改善への投資不足 戦略的な 投資に資金・人材 を振り向けられていない 対策『既存システムの見直し』 既存システムを放置した場合、 技術的負債が増大する レガシーであることは自覚できない。 現状は問題なく稼働しているため、誰も困っていない。 システム全体を俯瞰できない。 事業部ごとの最適化を優先 多重下請け構造 人材に属していたノウハウの喪失。 スクラッチ開発の多用 【 年の崖】が示す 課題 現場リソースの課題 経営投資の課題 2025年の崖が示す 既存システムの課題
17. と の科学 から見る の対策 【 】 年の崖への対策 DXの必要性に対する認識は高まっているものの、ビジネスをどのように変革していくかの具体的な方 向性を模索している企業が多いのは、目標が不明確なため。 に対する ビジョンと戦略を明確化 を推進 戦略的な 投資に資金・人材 を振り向けられていない 「レガシーシステム」が の足かせとなっている 模索企業が 多い 【 年の崖】が示す課題 変革型リーダーシップ を持つ人が居ない 【 】から見る課題 対策 『デリバリパフォーマンスの見直し』 促進ガイドラインの策定 競争力の向上 企業業績の回復 対策 『既存システムの見直し』 現場リソースの課題 経営投資の課題 高いケイパビリティ 組織が持つ べき能力、機能 を持つこと
18. と の科学 テクノロジーの戦略的活用が組織変革を加速する 【 】 慣例上、学問の世界でしか用いられてこな かった厳格な研究方法を用い、結果を産業界 にも公表することで、ソフトウェアの開発とデリ バリの状況を改善すること と の科学 テクノロジーの戦略的活用が組織変革を加速する 作者 武舎広幸 武舎るみ 出版社 メーカー インプレス
19. システムがビジネスに対してバリューをもたらす指標 デリバリーパフォーマンスとは リードタイムの削減 実行ファイル作成中に対する フィードバックも、それを受けての 変更もすばやく判断できる。 また、不具合の修正や稼働停 止からの復旧も迅速かつ確実 になる。 変更失敗率の低減 サービス機能の障害、稼働停 止。変更に伴うロールバックや パッチが必要となった場合の発 生確率を減らす。 の短縮 複雑なシステムを急速に変化さ せるためには、失敗は不可欠な 事象。そのため、サービスをいか に迅速に復旧できるかが鍵とな る。 デプロイ頻度の短縮 デプロイメントフローにおける変 動の低減、フィードバックの高速 化、リスクと諸経費の低減、効 率、モチベーション、緊急性の 認識が共有できる。 平均修復時間 リードタイム 顧客のリクエストから、そのリクエストが 満たされるまでの時間 コードのコミットから本番稼働までの所要時間 デプロイ ソフトウェアのデプロイから本番稼働 サー ビス公開など まで 主要なサービスで予想外の稼働停止や サービスの機能障害などのインシデントが発生した場 合、どのくらいの時間がかかるか 変更失敗率 本番環境での稼働に失敗したケース の発生確率 スピーディな変化への対応 安定した品質の提供
20. ソフトウェアデリバリのパフォーマンス デプロイの頻度 週 回～月 回 週 回～月 回 日複数回 変更のリードタイム 週間～ ヶ月 週間～ ヶ月 時間未満 平均修復時間 日～ 週間 日未満 時間未満 変更失敗率 ～ ～ ～ 出典 パフォーマンスの改善と安定性と品質の向上との間に、トレード・オフの関係はない。 Low Performersとの差
22. ビジネスバリュー に対する システムが抑える指標 既存の「人・組織」「技術」「プロセス」への対応を、企業とともに検討 戦略 デプロイ頻度の短縮 MTTRの短縮 平均修復時間 変更失敗率の低減 リードタイムの削減 組織が で変革する要素 人 組織 技術 プロセス
23. デジタルトランスフォーメーションに向けた つの施策 ビジネスの変化に追従できる ビジネスプロセスを実現するた め、システムをプロセス・ルー ル・データに分離し、最適な アーキテクチャーを提案 ビジネスバリューチェーンと の関係性を明確に し、マイクロサービス化による 最適な 基盤への移行パ スを提案 アプリ開発と運用における課 題点を洗い出し、バリュースト リームマッピングにより改善点 を明確にしなら、お客様の組 織・プロセス・文化の改革の ロードマップを提案 アプリケーションのワークロード を最適な環境に自在に配置 でき、インフラコストの全体最 適化を実現するアーキテク チャーを提案 運用管理のプロセスにおける 課題点を洗い出し、組織全 体で最適な自動化の手段と 手法を提案
24. アジャイル インテグレーション アプリケーション モダナイゼーション オートメーション クラウドインフラ ② ① ③ 製品 トレーニング 導入支援 を推進する の確認 目標 を阻害する 課題整理・問題分析 取り組むべき 施策の検討・精査 デジタル変革を進める上での施策 や優先順位などを検討 それぞれの施策を進める上での課 題や進め方を検討 必要セッションのみ実施 による事前評価や 効果測定、スキル習得 に対する ビジョンと戦略を明確化 施策の実施前準備 目標値や評価項目の検討 本格展開に向けた 事前評価・スキル習得 展開計画 展開実施 日々の改善 次期施策の検討 施策の本格展開に向けた 計画と実施 サイクルでの改善 施策の本格展開 次期施策の検討
25. 小さなチーム 少数メンバー の中で、意識を合わせる バリューストリーム・マッピング リーンのコンセプトで、組織内で起こる情報や成果物の 流れを明らかにし、価値創造につなげること。 タイムライン分析 時間が費やされている箇所やボトルネックの箇所を発 見しようとする試み。 ムダ分析 組織が生み出すムダを徹底的に調べ上げて、それらを できる限り取り除くこと。 改善ポイント ムダ を発見し、共有すること
27. 目指すべき最終的な目標の具体的な値を共有しておく。 デリバリパフォーマンスに関する目標 【検討事項】 ・チームとして目指すべき目標を個人の経験値をもとに記載し、後ほどギャップを確認 ・他社との比較ではなく、あくまで自社のコアビジネスとしてどれくらいの目標を目指すのかを検討 ・最終目標であり、直近の目標ではない デプロイ頻度の目標 リードタイムの目標 MTTRの目標 変更失敗率の目標 2週間に1回 1日 24時間 1～10 %
28. の と の の差分を共有し、より効果の高いものを選択 目標 の認識合わせ デプロイ頻度 リードタイム MTTR 変更失敗率 3ヶ月に1回 3ヶ月 24時間未満 (*１時間以内) 0～5 % 2週間に1回 ～ 1日1回 1週間～半日 1～５分以内 1%以内 現状のデリバリパフォーマンス デリバリパフォーマンス目標 リードタイム 顧客のリクエストから、その リクエストが満たされるまで の時間 デプロイの頻度 ソフトウェアのデプロイから 本番稼働 サービス公開な ど までの頻度 改善効果の高い指標
29. 目標に向かうための現状の課題を共有する 各項目 課題以上 人 デリバリパフォーマンスに関する課題 【検討事項】 ・普段のデプロイメントプロセスの中で感じる課題 ・人や組織構造に関する課題 ・解決しづらい技術的なボトルネック デプロイ頻度の課題 リードタイムの課題 MTTRの課題 変更失敗率の課題 例 (１課題/１枚) ・パフォーマンステストやセ キュリティテストを属人的に 行っている 例 (１課題/１枚) ・デプロイメントプロセスの 承認項目が多すぎる 例 (１課題/１枚) ・運用ベンダ/Sierに対応し てもらうには、連絡フローに 従わなければいけない 例 (１課題/１枚) ・システムの現状を把握でき ていない状況であり、変更の 影響度が特定できていない
30. 目標に向かうための現状課題を一人ずつ共有 【共有】デリバリパフォーマンスに関する課題 【進め方】 ・同じ課題にカテゴライズされるものは、題名をつけて張り合わせていく ・人(組織) / プロセス / 技術の要因のどれかに課題を分類してみる (入らないものはみんなで議論) *本ワークショップでは、一旦「コスト(投資)」に対する課題などは分類しない ・お互いに気づいたことをその場で共有 デプロイ頻度の課題 リードタイムの課題 MTTRの課題 変更失敗率の課題 人(組織) による課題 プロセス による課題 技術 による課題 品質 に関わる課題 スピード に関わる課題 目標 AsIs / ToBe AsIs / ToBe AsIs / ToBe AsIs / ToBe
31. デリバリパフォーマンスにおける課題の優先順位を確認してみましょう 課題の優先順位付け 【進め方】 ・全員で行うか、(インフラ、アプリから)特定のメンバーを中心で行うかは、状況に応じて決定 1. KGIのAsIs/ToBeの差から「スピード」「品質」で効果のある方どちらかを特定する 2. 技術課題をグルーピングし、解決するソリューションを特定する 3. ソリューションによって解決される、人(組織)/プロセスの課題を関連付ける 4. 優先順位を特定(効果/影響度) 5. (*Option)具体的なツールとの関連付け 対応する の特定 ソリューショ ンの特定 ソリューショ ンと課題の 関連付け 優先順位の 特定
32. の の差から「スピード」「品質」で効果のある方どちらかを特定 本資料は「スピード」を重視したストーリーを例としています。 効果が見えやすい の特定 デプロイ頻度の課題 リードタイムの課題 MTTRの課題 変更失敗率の課題 目標 品質 に関わる課題 スピード に関わる課題 ３ヶ月 回 週間 回 週間 日 時間以内 時間 より効果的な解決策を深掘りする 副次的に課題が解決される可能性も高い
33. 技術課題をグルーピングし、解決するソリューションを特定する ソリューションの特定 デプロイ頻度の課題 リードタイムの課題 人(組織) による課題 プロセス による課題 技術 による課題 目標 AsIs / ToBe AsIs / ToBe インフラテストの自動化 デプロイ頻度もリードタイムの課題も「スピード」に 関わるので、ソリューションを考えるときは、一旦混 ぜて考える。 ただし、「品質」にあるものとは混ぜない。 アプリ環境構築の 化 レグレッションテストの 自動化 【進め方】 技術課題をグルーピングし、それらが解 決できるソリューションを検討 テーマ決め 具体的なツール選定ではない 一度「人」「プロセス」の課題を確認し、そ れらが、技術によって解決できるのかを確 認しておく の期待値に達するのかを確認して おく
34. ソリューションによって解決される、人 組織 プロセスの課題を特定する 技術課題の分類と関連付け 【進め方】 ソリューションによって解決する、人 組 織 プロセスの課題をグルーピング ソリューションとグルーピングした課題を 関連付けておく ソリューションが技術でない課題、課題 と関連しないソリューションは、再度考えて みる デプロイ頻度の課題 リードタイムの課題 人(組織) による課題 プロセス による課題 技術 による課題 目標 AsIs / ToBe AsIs / ToBe インフラテストの自動化 構築作業の 化 ソリューションが技術で はない課題 解決する課題 解決する課題 技術的に解決する方法がないのかを考えてみる ソリューションが出ていないだけかもしれない 対応しても、デリバリパフォーマンスに影響がない ソリューションなのか、解決すべき課題が足りてい ないのかを考えてみる 課題と関連しない ソリューション
35. ソリューションを実施する優先順位を特定 優先順位の特定 デプロイ頻度の課題 リードタイムの課題 人(組織) による課題 プロセス による課題 技術 による課題 目標 AsIs / ToBe AsIs / ToBe インフラテストの自動化 構築作業の 化 解決する課題 解決する課題 レグレッションテストの 自動化 解決する課題 【進め方】 各ソリューションを実行する前と後の 「リードタイム」を出す 効果の高いソリュー ションを特定 効果の高いソリューション、変更時の サービス影響度の低いソリューションから 優先順位を特定 サービス影響 低 日 分 サービス影響 低 週間 時間 サービス影響 低 日 時間 優先度1 優先度2 優先度3
36. デリバリパフォーマンスによる への道 現状のデリバリパフォーマンス デリバリパフォーマンス目標 ｔ 時間 達成度 ・サーバー仮想化 ・本番 開発間の環境差異をなくす ・シンプル構成、シンプル化、統一 ・アプリ設計の見直し 施策 解決策 対応課題 設定・環境の見直し デプロイプロセスの変更 物理的制約からの開放 手作業による属人的 作業からの開放 品質の課題見直し ・アプリのテスト自動化 ・デプロイ自動化 ・インフラのテスト自動化 ・インフラ構成のコード化
37. まとめ
38. まとめ 企業が競合優位性を保つために、 より良いサービスやソフトウェアをユーザーに速く提供すること 顧客の適切な品質とスピードを定義 文化やプロセスを効率化してコストを削減 ４つの の現状と目標を共有し、 を進める上での施策や、優先順 位を事前に作っておく やムダ分析を行うことで、普段のプロセスに潜む非効率的な運用や属人的な作業を洗い 出し、ソリューションやプロセス変更で変えていく
39. あなたのビジネスに は必要なのか 本日お伝えしたいこと あなたのビジネスに必要なものは何なのか