DevOpsDays Tokyo2022 ファクトから始める改善アプローチ〜「LeanとDevOpsの科学」を実践して〜 #DevOpsDaysTokyo #DevOps #4keys #cloud #cicd #Accelerate #LeanとDevOpsの科学

by Hiroyuki TAKAHASHI

Slide 1

Slide 1 text

ファクトから始める改善アプローチ〜「LeanとDevOpsの科学」を実践して〜 2022年4月21日(木) DevOpsDaysTokyo2022 Day1 株式会社ビズリーチ（Visionalグループ）賀茂慎一郎高橋裕之内藤靖子

Slide 2

Slide 2 text

l 自己紹介 l Visionalグループ紹介 l ビズリーチで始まった"SPI"活動とは何か？ l ファクトから始めるために何をしているか l 計測までの道のり l 計測 - four keys l 計測 – ケイパビリティ l 計測結果をどう活かしているか l 活動を振り返って l 今後の展望 2 アジェンダ

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

■ 【出身】名古屋：東京在住10年 ■ 【所属】プロダクト品質管理部 SPIグループ ■ 【専門領域】アジャイル、ソフトウェアプロセス改善 ■ 【略歴】 Slerにて複数の開発PJを経験後、スクラムマスターとして活動ビズリーチには2020年1月入社。 ■ 【取得資格】 Certified ScrumMaster® Certified Scrum Product Owner® ■ 【Strength Finder】ポジティブ、社交性、コミュニケーション、最上志向、アレンジ ■ 【好きなもの】ボドゲ（バトルライン、ドミニオン）、漫画（ヒロアカ、ブルーピリオド、暗殺教室、HUNTER×HUNTER、ハガレン、その他無数）賀茂慎一郎 4

Slide 5

Slide 5 text

■ 所属：プロダクト組織開発本部プロダクト品質管理部 SPIグループマネジャー ■ ソフトウェアエンジニア22年目 ■ 組込みエンジニアとしてプリンタドライバ開発、コンシューマー向けデジタルカメラ・カムコーダー開発を経て、SEPG、PMO に従事 ■ ビズリーチには2021年8月に入社 ■ お仕事：ソフトウェアプロセス改善/アジャイルコーチ/プロダクトマネジメント/プロジェクトマネジメント/チームビルディング/ ■ 好き：コストコ/ディズニーリゾート/ネコ/ファスティング ■ 苦手：ナッツ類/キャンプ/睡眠不足/運動 ■ StrengthFineder：協調性/回復志向/アレンジ/公平性（人間関係構築力と実行力が強み） ■ Certified ScrumMaster® Advanced Certified ScrumMaster® Certified Scrum Product Owner® Certified Agile Leadership I 高橋裕之（たかぼー） hiroyukitakah taka_bow @Taka_bow 5 内藤靖子

Slide 6

Slide 6 text

■ 所属：プロダクト組織開発本部プロダクト品質管理部部長 ■ ソフトウェアエンジニア31年目 ■ 専門領域1：アジャイルコーチ、ソフトウェアプロセス改善コーチ ■ 専門領域2：エンジニアリング組織のリファクタリング ■ 【略歴】倒産１回・フリーランス１回・転職７回組込みエンジニアとして交換器やルーターなどの通信インフラソフトウェア開発、コンシューマー向けデジタルカメラ・カムコーダー開発のプロジェクトリーダーを経て、SEPG、PMO、QA などのマネジメントに従事。ビズリーチには2021年7月入社。 ■ Certified ScrumMaster® Advanced Certified ScrumMaster® Certified Scrum Product Owner® Certified Scrum Professional® - ScrumMaster Certified Scrum Professional® - Product Owner Certified Agile Leadership I ■ 好きな言葉：「そなえよつねに」(Be Prepared) ■ 好きな小説：十二国記シリーズ (小野不由美) 高橋裕之（たかぼー） hiroyukitakah taka_bow @Taka_bow 6

Slide 7

Slide 7 text

Visionalグループ紹介

Slide 8

Slide 8 text

2009年4月創業（資本準備金含む） ※2021年5月18日時点 164億円資本金（2021年7月末日時点） ※臨時従業員（契約社員、パートタイマー、アルバイト）を含む 1,469名従業員数東京・大阪・名古屋・福岡静岡・広島拠点）（株式会社ビズリーチ創業） 2020年2月設立（ビジョナル株式会社設立）グループ概要 8

Slide 9

Slide 9 text

グループミッション 9

Slide 10

Slide 10 text

目指す姿産業のデジタルトランスフォーメーション（DX）を推進する事業を展開し、ビジネスの生産性向上を支えていきます。 10

Slide 11

Slide 11 text

11 会社の成長売上高推移サービス数推移 ೥ؒͰ ਓҎ্ͷ૊৫ʹ੒௕ͨ͠ݱࡏ΋ɺച্ߴɺαʔϏε਺ڞʹ૿͑ଓ͚͍ͯ·͢ɻ 約 100億 2017年 ※2016年8月〜2017年7月約 287億 10以上 1 ※2020年8月〜2021年7月 2009 2013 2015 2017 2011 2021 1,469名従業員数 2021年 2021年 2009年 2019 雇用形態：正社員、契約社員、アルバイト・パート、派遣社員、出向受入 ※当社グループから当社グループ外への出向者を除き、当社グループ外から当社グループへの出向者を含む 5年間 287％成長

Slide 12

Slide 12 text

Visional グループサービスの歴史 12

Slide 13

Slide 13 text

グループ運営サービス 13

Slide 14

Slide 14 text

ビズリーチで始まった"SPI"活動とは何か？

Slide 15

Slide 15 text

l SPI：Software Process Improvement l 「継続的に」ソフトウェアプロセスを改善する活動、ならびに支援チームを指す l もともとはCMM/CMMI、SPICE、TickIT Plusといったフレームワークを組織にインストール実戦部隊。昔はSEPGと呼ばれていた。 l 2000年8月に「日本SPIコンソーシアム(JASPIC)」という研究・普及団体が作られ、今も活動している。 l 近年、アジャイルな開発において、本当にプロセス効率が高く顧客のアウトカムを達成しているのか？を証明するためにSPI活動が益々重要になっている。ソフトウェアプロセス改善(SPI)とは何か？ ※日本SPIコンソーシアム(JASPIC)：http://www.jaspic.org/ 15

Slide 16

Slide 16 text

1. 優れたソフトウェアプロセスの要素が、優れたやり方で定義できること 2. ソフトウェア開発への既存の組織的アプローチが、これらの要素と照らし合わせて診断できること 3. 改善のための有意な戦略を定義できることソフトウェアプロセス改善(SPI)とは何か？実践ソフトウェアエンジニアリング[第9版] Roger S Pressman・Bruce R.Maxim著より引用 16

Slide 17

Slide 17 text

ソフトウェアプロセス改善(SPI)とは何か？アセスメント能力判定改善戦略ソフトウェアプロセス (ソフトウェアプロセス)は (アセスメント)によって判断される (アセスメント)は (能力判定)へつながる (能力判定)は(改善戦略)の基盤となる (アセスメント)は (改善戦略)へつながる (能力判定)は(ソフトウェアプロセス)の ➢ 能力,強み,弱みを識別する ➢ 成熟度を明らかにする (改善戦略)は(ソフトウェアプロセス)の ➢ 変更を明らかにする ➢ 改善アプローチを提案する実践ソフトウェアエンジニアリング[第9版] Roger S Pressman・Bruce R.Maxim著より引用 17

Slide 18

Slide 18 text

ソフトウェアプロセス改善(SPI)とは何か？材料 × 料理法 × 味付け＝おいしい料理 Scrum ウォーターフォールアジャイル風の何かリモートワーク Java Python iPhone Mac Angular AWS JIRA GitHub 信頼性マーケット利用時の品質セキュリティ保守性性能効率性プロダクト …… …… …… 18

Slide 19

Slide 19 text

つまり要約するとソフトウェアプロセス改善(SPI)とは何か？ソフトウェア界のお料理研究家である 19

Slide 20

Slide 20 text

ソフトウェアプロセス改善活動(SPI活動)とは？ 20 ソフトウェア開発は料理に似ている料理ソフトウェア開発料理研究家プロセス改善コーチアジャイルコーチ研究・鍛錬研究・鍛錬似ている実践・伝達 SPI活動日本の食卓を変える日本人のくらしを変えるアウトカムを加速するエンジニアの仕事を楽しくする

Slide 21

Slide 21 text

Andrew Z. Colvin, CC BY-SA 3.0 , via Wikimedia Commons https://commons.wikimedia.org/wiki/File:Earth%27s_Location_in_the_Universe_SMALLER_(JPEG).jpg ところで、ものごとを俯瞰して見れてますか？ 21

Slide 22

Slide 22 text

デベロッパー星開発者開発たのしー 22

Slide 23

Slide 23 text

デベロッパー星＜スクラム系開発者スクラムマスタープロダクトオーナースクラムチームイケてるチームだぜ！ 23

Slide 24

Slide 24 text

デベロッパー領＜スクラム系＜事業会社銀河開発者スクラムマスタープロダクトオーナースクラムチームセールスマネジャーサポートデザインお客様の期待に答えます！ 24

Slide 25

Slide 25 text

エターナルズ？開発者スクラムマスタープロダクトオーナースクラムチームセールスマネジャーサポートデザイン 25

Slide 26

Slide 26 text

エターナルズ？開発者スクラムマスタープロダクトオーナースクラムチームセールスマネジャーサポートデザインメンテナンスですぐ停止するよね品質が悪いなーサービスよく落ちてない？製品の進化が遅いねぇ処理が重いね 26

Slide 27

Slide 27 text

Opinion vs Fact（意見か事実か）＊ https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem（問題） Solution（解決策） Fact（事実） Opinion（意見）メンテナンスですぐ停止するよね品質が悪いなーサービスよく落ちてない？製品の進化が遅いねぇ処理が重いね事実か？ 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

そうだ、計測しよう！ 35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

仮説 Opinion vs Fact（意見か事実か）＊ https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem（問題） Solution（解決策） Fact（事実） Opinion（意見）計測設計デプロイ ② ③ ④ ① 38

Slide 39

Slide 39 text

39 「LeanとDevOpsの科学」の著者の1人 Gene Kimさんが、DevOpsDays 2019 のキーノートセッションでDevOpsをシンプルに定義するならば以下であると仰っていました。そうだ、計測しよう！ “Better, Faster, Safer, Happier” 「より良く、速く、安全に、もっとハッピーに」 LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加する Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (著), 武舎るみ (著)

Slide 40

Slide 40 text

「書いたコードの量」「ベロシティ(速度)」「リソース効率(利用率)」 40 そうだ、計測しよう！ LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加する Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (著), 武舎るみ (著) 生産量(Output)ではなく成果(Outcome)に焦点を当てる

Slide 41

Slide 41 text

ファクトから始めるために何をしているか

Slide 42

Slide 42 text

「LeanとDevOpsの科学」とは l 原書は「ACCELERATE」、日本語版は2018年に出版。 l 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果をまとめている。 https://book.impress.co.jp/books/1118101029 https://www.oreilly.com/library/view/accelerate/9781457191435/ 42

Slide 43

Slide 43 text

l 2018年よりGoogle Cloudと共同で実施しており、毎年調査レポート（State of DevOps）を公表している調査結果は毎年公開されている https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report 43

Slide 44

Slide 44 text

l DORA社(現Google)が直近6年間の研究から導いた開発チームのパフォーマンス指標＝Four Keys l アジャイルでもウォーターフォールでも計測可能デリバリーパフォーマンスの指標リードタイムコードがコミットされてから本番環境で正常に実行されるまでの時間デプロイ頻度コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度平均修復時間 (MTTR) サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか変更失敗率本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合 44

Slide 45

Slide 45 text

デリバリーパフォーマンスの指標エリートハイミディアムロー変更リードタイム 1時間未満 1日〜1週間 1ヶ月から6ヶ月 6ヶ月以上デプロイ頻度オンデマンド（1日複数回） 1週間から1ヶ月 1ヶ月から半年半年以上平均修復時間(MTTR) 1時間未満 1日未満 1日〜1週間 6ヶ月以上変更失敗率 0-15% 16-30% 16-30% 16-30% state of devops 2021を参考に作成 45

Slide 46

Slide 46 text

エリートとローの差は年々開いているデリバリーパフォーマンスの指標エリートエリートとローの差ロー変更リードタイム 1時間未満 6570倍 6ヶ月以上デプロイ頻度オンデマンド（1日複数回） 973倍半年以上平均修復時間(MTTR) 1時間未満 6570倍 6ヶ月以上変更失敗率 0-15% 3倍 16-30% state of devops 2021を参考に作成 46

Slide 47

Slide 47 text

l four keysは互いに独立した指標ではなく、デリバリにおける質とスピードをいかに高いレベルで実施できているかを測る指標である質とスピードの両立質スピード変更リードタイムデプロイ頻度平均修復時間変更失敗率リードタイムが短くなると学習スピードが増し、品質が向上する品質が向上するとリードタイムは短くなり、頻繁なデプロイが容易になる 47

Slide 48

Slide 48 text

l 定められた成熟度レベルではなく、組織が保有するケイパビリティ（能力）に着目 l 「LeanとDevOpsの科学」ではfour keysの改善に効果が高いとされる24のケイパビリティが紹介されている成熟度ではなく、ケイパビリティ一定の成熟状態の「到達」に焦点同じレベルのチームには似たツールやプラクティスを推奨計測内容と成果への紐付けが曖昧（計測は比較的容易）到達ポイントが静的終わりのない継続的改善組織の目標に応じたケイパビリティに焦点を当てる結果をベースに特定のケイパビリティが結果にどう有用なのか重視する変化に合わせた（動的な）改善が可能成熟度モデルの特徴ケイパビリティモデルの特徴 48

Slide 49

Slide 49 text

ケイパビリティは定期的にアップデートされている技術プロセス測定組織文化バージョン管理チームのツール選択のサポートチームのテストシステムをモニタリングしてビジネス上の意思決定に役立てる仕事の満足度トランクベース開発テストデータ管理変更承認の効率化障害の予兆通知 Westrumの組織類型継続的インテグレーションセキュリティのシフトレフトお客様のフィードバック仕掛かり制限学習文化デプロイの自動化データベースのチェンジマネジメントバリューストリームでの作業の可視性ビジュアル管理変革型リーダーシップ継続的なテストクラウドインフラストラクチャ小さいバッチ単位の作業モニタリングとオブザービリティ継続的デリバリーコードの保守性アーキテクチャ現在27のケイパビリティが公開されている https://cloud.google.com/architecture/devops/capabilities?hl=ja 49

Slide 50

Slide 50 text

計測までの道のり

Slide 51

Slide 51 text

1. 計測仕様を決める 2. 計測データを収集する 3. 計測結果を可視化する 4. プロダクト開発チームのケイパビリティ調査を実施する 5. four keysとケイパビリティ調査結果を踏まえ、改善施策を定める 6. 改善施策を実行する大まかな流れ 51

Slide 52

Slide 52 text

1. 計測仕様を決める 2. 計測データを収集する 3. 計測結果を可視化する 4. プロダクト開発チームのケイパビリティ調査を実施する 5. four keysとケイパビリティ調査結果を踏まえ、改善施策を定める 6. 改善施策を実行する大まかな流れここを説明 52

Slide 53

Slide 53 text

計測 - four keys

Slide 54

Slide 54 text

Kick Off ü 計測は社内全プロダクトへの展開を予定している ü プロダクトチーム向けの説明会を実施し、キックオフ！ • エンジニアにとって身近で関心のあるメトリクスだったのか、スムーズにスタートしたそうだ！計測しよう 54

Slide 55

Slide 55 text

開発チームとSPIで協力して進める ü 開発チームはプロダクトのデリバリープロセスを踏まえ、計測方法、収集するデータを検討する ü SPIは開発チームと話し合って決めたことを他プロダクトに展開し、プロダクト毎に解釈が異ならないようにする計測仕様を決める 55

Slide 56

Slide 56 text

計測仕様の一例 four keys 定義計測仕様リードタイムコードがコミットされてから本番環境で正常に実行されるまでの時間初回コミットからメインブランチへのマージ日時デプロイ頻度コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度一定期間にメインブランチへマージした回数平均修復時間（MTTR）サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか障害検知から解消までの時間変更失敗率本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合障害件数 / メインブランチへのマージ件数データ収集に手間がかかる場合もあるので、なるべく軽くスタートして、必要であれば改善をする方針とした 56

Slide 57

Slide 57 text

相談例（1） Feature Flagは計測対象とする？エンジニア SPI 計測対象にしましょう。ビジネス戦略としてお客様に提供していないだけで、提供可能にはなっているので。 57

Slide 58

Slide 58 text

相談例（2）リリースして1年後に発生した不具合は変更失敗率してカウントする？エンジニア SPI カウントしないことにしましょう！追加した機能や変更によってリリースに失敗したケースをしりたい。こういう潜在バグは違うメトリクスでとれるようにしましょう。 58

Slide 59

Slide 59 text

相談例（3） 1プロダクトを複数チームで開発しているけど、 four keysはチーム毎にとる？エンジニア SPI まずはプロダクト単位で計測しましょう。プロダクト毎の状態を把握したあと、チームごとでみれるようにチームの情報は収集するデータにいれておきましょう。 59

Slide 60

Slide 60 text

相談例（4）市場不具合の一部は収集できないかもしれないわよ？エンジニア SPI まずはできる範囲で計測開始して、制限事項を明確にしましょう。収集方法や管理の改善は可視化・分析後に再度相談しましょう。 60

Slide 61

Slide 61 text

l まずは2021年1月~のデータはスプレッドシートに収集した l 普段管理しているツールやドキュメントからデータを収集できたため、容易に過去分を収集できた計測データを収集する 61

Slide 62

Slide 62 text

l 収集したデータをGoogleデータポータルで可視化する（※図はぼかしてます）計測結果を可視化するプロダクトA プロダクトB 62

Slide 63

Slide 63 text

l これまで計測した2プロダクトは、半分は手動で収集しスプレッドシートに展開している l 現在、月次でデータを更新している。毎月30分未満だが、面倒になってくる苦労ポイント①：更新に手間がかかるリードタイムデプロイ頻度平均修復時間（MTTR）変更失敗率 GitHubから自動収集 GitHubから自動収集市場不具合情報から手動収集市場不具合情報から手動収集 63

Slide 64

Slide 64 text

l 可視化したからこそ意見や要望が出てくる l 「月次の他にクォーターごとに見たい」 l 「ぱっとみて、Elite/High/Medium/Lowのどこにいるかわかるといいな」 l 要望を受けて更新しているが、無料ツールの限界を感じている苦労ポイント②：見たいように見せられないジレンマ 64

Slide 65

Slide 65 text

計測 - ケイパビリティ

Slide 66

Slide 66 text

l ケイパビリティを計測する上で「何を持ってそのケイパビリティが備わっているか」の定義が必要 l ケイパビリティ毎に満たすために必要な観点を作成 l 観点についてはGoogle cloudが公開しているケイパビリティに関する説明を参考に作成ケイパビリティ毎の観点を定める https://cloud.google.com/architecture/devops/devops-tech-test-automation?hl=ja 66

Slide 67

Slide 67 text

l 実際にプロダクトに携わっているメンバーに回答を依頼 l 保有しているor保有してないの二者択一ではなく、どの程度満たしているのか度合いを調査 l 「一部同意できる」については詳細を残すことで現状を正しく可視化するどの程度ケイパビリティを保有しているのか調査 67

Slide 68

Slide 68 text

作成した観点表 68

Slide 69

Slide 69 text

Slide 70

Slide 70 text

● 組織文化（4ケイパビリティ）を除く23ケイパビリティを調査実際の回答結果 70

Slide 71

Slide 71 text

工夫ポイント①：ビズリーチの状況を踏まえて観点を作成 l ケイパビリティの中にはGoogle Cloudの公開文書だけでは調査不足に陥る可能性があった l ケイパビリティが何を目指し、なぜfour keysを高めるのに有効なのか、有効な要素・プラクティスは何かを丁寧に読み解いた https://cloud.google.com/architecture/devops/devops-tech-test-automation?hl=ja 71

Slide 72

Slide 72 text

工夫ポイント①：ビズリーチの状況を踏まえて観点を作成 Googleはユニット・結合を100%自動化している前提のように見える。現状組織によって自動化の度合いが異なるから、その点を計測した方がいいのでは？エンジニア SPI たしカニ！ 72

Slide 73

Slide 73 text

l 2021年度のstate of devopsにドキュメントに関する言及がされており、現状のビズリーチの開発組織におけるドキュメントの必要性を含めケイパビリティとして採用 l 観点についてはstate of devopsに記載されている内容をベースに作成工夫ポイント②：新たなケイパビリティの追加 https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report 73

Slide 74

Slide 74 text

l 直訳なものもあり、内容を理解するのに時間を要した l 例えば「継続的テスト」では承認テストという単語が何度も登場するが、どのテストを指しているのか当初わからなかった。原文を見返したり、社内の有識者と意見交換するなどした。苦労ポイント①：内容の咀嚼が重い。。 https://cloud.google.com/architecture/devops/devops-tech-test-automation?hl=ja 承認テストとは、、？ 74

Slide 75

Slide 75 text

l 当初観点表の回答は1.5h程度の想定をしていた l 実際に回答者に確認したら5時間以上かかっていることが判明苦労ポイント②：回答者の負担が大きい回答に5時間くらいかかりましたね…… エンジニア SPI ファッ！！！！ 75

Slide 76

Slide 76 text

l 回答している場に同席し観察していると、どこで時間がかかっているか見えてくる l 明らかにわからない場合は質問するが、そうでない場合は自分で悩んでしまい時間がかかっていることが判明（１つ１つは重くないため本人も自覚がない）苦労ポイント③：回答に時間を要するこれってどういう意味だろ。。エンジニア SPI 悩んでいそう… 聞いてくれればいいのに！ 76

Slide 77

Slide 77 text

計測結果をどう活かしているか

Slide 78

Slide 78 text

l ケイパビリティ強化やプロセス改善進めると、質・スピードが向上し、four keyも向上するはず l 継続的にfour keysを計測することで施策の効果をみえるようにする改善効果を定量的に把握する 78

Slide 79

Slide 79 text

l 「THE DevOps HANDBOOK」の3つの道を参考にケイパビリティ毎の関連をマッピングし整理ケイパビリティの活かし方① 79

Slide 80

Slide 80 text

l THE DevOps HANDBOOKの3つの道を参考にケイパビリティ毎の関連をマッピングし整理ケイパビリティの活かし方① 調査結果を元に特に不足しているケイパビリティに 👀をつけ、どこから改善していくか認識を合わす 👀 👀 👀 👀 80

Slide 81

Slide 81 text

l ケイパビリティを調査したところ、どの項目も獲得できていないケイパビリティがあり、どこから手をつければいいのか一目でわからなかった.. ケイパビリティの活かし方② 84

Slide 82

Slide 82 text

“DevOpsへの変革の候補となるアプリケーション、サービスを選択したら、顧客に対して価値を生み出すために協力しなければならないバリューストリームの中の全てのメンバーを明らかにする必要がある。（中略）バリューストリームのメンバーが明らかになったら、次は仕事がどのように進められるかを具体的に理解することだ。” ヒントは先人の英知の中に https://www.nikkeibp.co.jp/atclpubmkt/book/17/P85480/ The DevOps HANDBOOK 理論・実践・原則の全てジーン・キム、ジェズ・ハンブル、パトリック・ドボア、ジョンウィリス榊原彰監修長尾高弘日経BP社 P105 85

Slide 83

Slide 83 text

l ケイパビリティの１つである「バリューストリームでの作業の可視化」に着目 l バリューストリームマップを作成し、洗い出した課題とケイパビリティを紐づけながら改善の方向性を探っていくバリューストリームマップの作成 86

Slide 84

Slide 84 text

活動を振り返って

Slide 85

Slide 85 text

3つの学び視えるからこそ意見が生まれる指標はあくまで指標改善の一歩目はユーザーを観る 88

Slide 86

Slide 86 text

89 l 可視化することで同じものをみて、建設的に話し合うことができる l 実際にでてきた意見 l 「次はプルリク単位のリードタイムではなく、PBI単位のリードタイムがみたい」 l 「障害のより詳細な情報がみたい（とりたい）」 l ファクトを元に話し合い、カイゼンする文化の第一歩になった視えるからこそ意見が生まれる

Slide 87

Slide 87 text

l ある組織の改善提案で、調査結果だけ見て改善提案を出したところ担当者が渋い表情に…… 指標はあくまで指標まずは最も数値が悪いリードタイムの改善を進めるのがいいと思っていますがいかがでしょう？ SPI エンジニア今の数値で戦略上問題ないと思っているのだけど…… 90

Slide 88

Slide 88 text

l four keysやケイパビリティは現状把握の1つの側面にすぎない l 組織の成長戦略と調査結果から見えることを紐付けることが重要指標はあくまで指標 SPI 無意識にfour keysを高める方に意識が向きすぎていた！組織の困りごとがどう解消されるか考えないと …… 91

Slide 89

Slide 89 text

l 実際にプロダクトを使っている様子をみることでユーザーが何に困っているのか、どう使っているのか理解を深めることができた改善の一歩目はユーザーを観る 92

Slide 90

Slide 90 text

l プロダクト開発も同様に、ユーザーが利用している様子を観に行くことで新しい発見がある l 現場（ユーザーがプロダクトに触れる場）にこそ改善のヒントが眠っている！！「ファクトから始める」とは 93

Slide 91

Slide 91 text

今後の展望

Slide 92

Slide 92 text

今後の展望 96 計測負担の軽減信頼性の計測イケてる可視化組織文化のケイパビリティ計測

Slide 93

Slide 93 text

l Dadadogのオプション拡充等を行い、なるべく自動化したい計測負担の軽減 97 https://docs.datadoghq.com/ja/monitors/incident_management/

Slide 94

Slide 94 text

l State of DevOps2021では5番目の指標として信頼性を挙げている l 既にSLOなどはプロダクト毎に定義しているが、State of DevOps2021を元にさらにできることがないかSRE と協力して実施していく信頼性の計測 https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report 98

Slide 95

Slide 95 text

l 現在はケイパビリティがどの程度獲得できているかわかる状態にはなっている l 今後は、どのケイパビリティの改善が最もインパクトが大きいかを可視化していきたいイケてる可視化（ケイパビリティ） https://speakerdeck.com/ttorii0609/acceleratefan-yi-ben-falsekimo?slide=4 99

Slide 96

Slide 96 text

l 現状は組織文化に対する詳細な調査は実施できていない l 今後HRMOSの組織診断サーベイを活用して、組織文化項目の調査を実施予定サーベイを活用した組織文化項目の調査 https://hrmos.co/landing/core/01_survey_nor.html 100

Slide 97

Slide 97 text

101