Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜

kamo shinichiro
April 21, 2022
14k

ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜

kamo shinichiro

April 21, 2022
Tweet

Transcript

  1. l 自己紹介 l Visionalグループ紹介 l ビズリーチで始まった"SPI"活 動とは何か? l ファクトから始めるために何を しているか

    l 計測までの道のり l 計測 - four keys l 計測 – ケイパビリティ l 計測結果をどう活かしているか l 活動を振り返って l 今後の展望 2 アジェンダ
  2. ▪ 【出身】 名古屋:東京在住10年 ▪ 【所属】 プロダクト品質管理部 SPIグループ ▪ 【専門領域】 アジャイル、ソフトウェアプロセス改善

    ▪ 【略歴】 Slerにて複数の開発PJを経験後、スクラムマスターとして活動 ビズリーチには2020年1月入社。 ▪ 【取得資格】 Certified ScrumMaster® Certified Scrum Product Owner® ▪ 【Strength Finder】 ポジティブ、社交性、コミュニケーション、最上志向、アレンジ ▪ 【好きなもの】 ボドゲ(バトルライン、ドミニオン)、漫画(ヒロアカ、ブルー ピリオド、暗殺教室、HUNTER×HUNTER、ハガレン、その他無 数) 賀茂 慎一郎 4
  3. ▪ 所属:プロダクト組織開発本部 プロダクト品質管理部 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 内藤 靖子
  4. ▪ 所属:プロダクト組織開発本部 プロダクト品質管理部 部長 ▪ ソフトウェアエンジニア31年目 ▪ 専門領域1:アジャイルコーチ、ソフトウェアプロセス改善コーチ ▪ 専門領域2:エンジニアリング組織のリファクタリング

    ▪ 【略歴】倒産1回・フリーランス1回・転職7回 組込みエンジニアとして交換器やルーターなどの通信インフラソ フトウェア開発、コンシューマー向けデジタルカメラ・カムコー ダー開発のプロジェクトリーダーを経て、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
  5. 2009年4月 創業 (資本準備金含む) ※2021年5月18日時点 164億円 資本金 (2021年7月末日時点) ※臨時従業員(契約社員、パート タイマー、アルバイト)を含む 1,469名

    従業員数 東京・大阪・名古屋・福岡 静岡・広島 拠点 ) (株式会社ビズリーチ創業) 2020年2月 設立 (ビジョナル株式会社設立) グループ概要 8
  6. 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% 成長
  7. 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
  8. ソフトウェアプロセス改善(SPI)とは何か? アセスメント 能力判定 改善戦略 ソフトウェア プロセス (ソフトウェアプロセス)は (アセスメント)によって 判断される (アセスメント)は

    (能力判定)へつながる (能力判定)は(改善戦略)の 基盤となる (アセスメント)は (改善戦略)へつながる (能力判定)は(ソフトウェアプロセス)の ➢ 能力,強み,弱みを識別する ➢ 成熟度を明らかにする (改善戦略)は(ソフトウェアプロセス)の ➢ 変更を明らかにする ➢ 改善アプローチを 提案する 実践ソフトウェアエンジニアリング[第9版] Roger S Pressman・Bruce R.Maxim著 より引用 17
  9. ソフトウェアプロセス改善(SPI)とは何か? 材料 × 料理法 × 味付け = おいしい料理 Scrum ウォーターフォール

    アジャイル風の何か リモートワーク Java Python iPhone Mac Angular AWS JIRA Git Hub 信頼性 マーケット 利用時の品質 セキュリティ 保守性 性能効率性 プロダクト …… …… …… 18
  10. ソフトウェアプロセス改善活動(SPI活動)とは? 20 ソフトウェア開発は料理に似ている 料理 ソフトウェア開発 料理研究家 プロセス改善コーチ アジャイルコーチ 研究・鍛錬 研究・鍛錬

    似ている 実践・伝達 SPI活動 日本の食卓を変える 日本人のくらしを変える アウトカムを加速する エンジニアの仕事を楽しくする
  11. Andrew Z. Colvin, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons

    https://commons.wikimedia.org/wiki/File:Earth%27s_Location_in_the_Universe_SMALLER_(JPEG).jpg ところで、ものごとを俯瞰して見れてますか? 21
  12. エターナルズ? 開発者 スクラムマスター プロダクトオーナー スクラムチーム セールス マネジャー サポート デザイン メンテナンスで

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

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

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

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

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

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

    メンテナンスで すぐ停止するよね 品質が悪いなー サービスよく 落ちてない? 製品の進化が遅いねぇ 処理が重いね 設 計 デプロイ 対策案を 作る 対策案を 動かす 32
  19. Opinion vs Fact(意見か事実か) * https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem(問題) Solution(解決策) Fact(事実) Opinion(意見)

    メンテナンスで すぐ停止するよね 品質が悪いなー サービスよく 落ちてない? 製品の進化が遅いねぇ 処理が重いね 設 計 デプロイ 対策案を 作る 対策案を 動かす 計 測 結果を 検証する 33
  20. Opinion vs Fact(意見か事実か) * https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem(問題) Solution(解決策) Fact(事実) Opinion(意見)

    メンテナンスで すぐ停止するよね 品質が悪いなー サービスよく 落ちてない? 製品の進化が遅いねぇ 処理が重いね 設 計 デプロイ 対策案を 作る 対策案を 動かす 計 測 結果を 検証する 事 実 ! 34
  21. Opinion vs Fact(意見か事実か) * https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem(問題) Solution(解決策) Fact(事実) Opinion(意見)

    メンテナンスで すぐ停止するよね 品質が悪いなー サービスよく 落ちてない? 製品の進化が遅いねぇ 処理が重いね 設 計 デプロイ 対策案を 作る 対策案を 動かす 計 測 結果を 検証する 36
  22. Opinion vs Fact(意見か事実か) * https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」より引用 Problem(問題) Solution(解決策) Fact(事実) Opinion(意見)

    メンテナンスで すぐ停止するよね 品質が悪いなー サービスよく 落ちてない? 製品の進化が遅いねぇ 処理が重いね 設 計 デプロイ 対策案を 作る 対策案を 動かす 計 測 結果を 検証する 仮説 対策案を 考える 37
  23. 39 「LeanとDevOpsの科学」の著者の1人 Gene Kimさんが、DevOpsDays 2019 のキーノートセッション でDevOpsをシンプルに定義するならば以下であると仰っていました。 そうだ、計測しよう! “Better, Faster,

    Saler, Happier” 「より良く、速く、安全に、もっとハッピーに」 LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加する Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (著), 武舎るみ (著)
  24. l DORA社(現Google)が直近6年間の研究から導いた開発チームのパフォーマンス指標=Four Keys l アジャイルでもウォーターフォールでも計測可能 デリバリーパフォーマンスの指標 リードタイム コードがコミットされて から本番環境で正常に実 行されるまでの時間

    デプロイ頻度 コードを本番環境にデプ ロイまたはエンドユーザ ーにリリースした頻度 平均修復時間 (MTTR) サービスインシデント または不具合が発生した ときにサービスの復元に どれくらいの 時間がかかるか 変更失敗率 本番環境に変更を加えた、 またはユーザーへのリリ ースを実施した結果サー ビスが低下し、 その後修正を行う必要が 生じた割合 44
  25. デリバリーパフォーマンスの指標 エリート ハイ ミディアム ロー 変更リードタイム 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
  26. エリートとローの差は年々開いている デリバリーパフォーマンスの指標 エリート エリートとローの差 ロー 変更リードタイム 1時間未満 6570倍 6ヶ月以上 デプロイ頻度

    オンデマンド (1日複数回) 973倍 半年以上 平均修復時間(MTTR) 1時間未満 6570倍 6ヶ月以上 変更失敗率 0-15% 3倍 16-30% state of devops 2021を参考に作成 46
  27. l four keysは互いに独立した指標ではなく、デリバリにおける質とスピードをいかに高いレベルで実 施できているかを測る指標である 質とスピードの両立 質 スピード 変更リードタイム デプロイ頻度 平均修復時間

    変更失敗率 リードタイムが短くなると 学習スピードが増し、 品質が向上する 品質が向上すると リードタイムは短くなり、 頻繁なデプロイが容易になる 47
  28. l 定められた成熟度レベルではなく、組織が保有するケイパビリティ(能力)に着目 l 「LeanとDevOpsの科学」ではfour keysの改善に効果が高いとされる24のケイパビリティが 紹介されている 成熟度ではなく、ケイパビリティ 一定の成熟状態の「到達」に焦点 同じレベルのチームには 似たツールやプラクティスを推奨

    計測内容と成果への紐付けが曖昧 (計測は比較的容易) 到達ポイントが静的 終わりのない継続的改善 組織の目標に応じた ケイパビリティに焦点を当てる 結果をベースに特定のケイパビリティが 結果にどう有用なのか重視する 変化に合わせた(動的な)改善が可能 成熟度モデルの特徴 ケイパビリティモデルの特徴 48
  29. ケイパビリティは定期的にアップデートされている 技術 プロセス 測定 組織文化 バージョン管理 チームのツール選択の サポート チームのテスト システムをモニタリングしてビ

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

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

    keysとケイパビリティ調査結果を踏まえ、改善施策を定める 6. 改善施策を実行する 大まかな流れ ここを説明 52
  32. 計測仕様の一例 four keys 定義 計測仕様 リードタイム コードがコミットされてから本番環 境で正常に実行されるまでの時間 初回コミットからメインブランチへの マージ日時

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

  34. 89 l 可視化することで同じものをみて、建設的に 話し合うことができる l 実際にでてきた意見 l 「次はプルリク単位のリードタイムでは なく、PBI単位のリードタイムがみたい」 l

    「障害のより詳細な情報がみたい (とりたい)」 l ファクトを元に話し合い、カイゼンする文化の 第一歩になった 視えるからこそ意見が生まれる
  35. 101