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

Small_Start_Conscious_Development_Productivity_...

 Small_Start_Conscious_Development_Productivity_Improvement_Practices_at_freee

https://dev-productivity-con.findy-code.io/2024

6/29(土)16:50 ~ 17:30

ホール 5-B

freeeにおけるスモールスタートを意識した開発生産性向上の実践事例

freeeでは内製基盤で4keysを計測し可視化しています。技術選定や内製基盤の紹介をします。
また大規模な開発組織に対して、「継続して改善活動をするサイクル」を根付かせるために何をしてきたかを時系列に振り返りながら、スモールスタートを意識して取り組んだ実践事例を紹介します。

hikaru-miyazawa

June 28, 2024
Tweet

More Decks by hikaru-miyazawa

Other Decks in Technology

Transcript

  1. 2 2017 ~ 2021 株式会社Meily
 美容系SNSスタートアップの
 創業メンバー/1人SRE
 2022 ~ 2024

    フリー株式会社 
 SRE Platform Delivery team
 • Kubernetes
 • ArgoCD
 • GithubActions,SelfHostedRunner
 • 開発生産性の可視化、向上
 趣味
 • ポケモンカード
 • ポーカー
 miyahika(Hikaru Miyazawa)
 SRE Platform Delivery 
 プロフィール画像の
 トリミング方法
 X ID: miyahika214
 #開発生産性 con_findy_5B
 

  2. 7   電⼦稟議 経費精算 債権債務 管理 ⼈事労務 電⼦契約 固定資産 請求管理

    会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム
  3. 8 SRE チーム構成 
 
 Platform DBRE サービスの安定稼働をDBを始めとしたミドルウェアの使いこなしから⽀えるチーム 最近の担当テーマ: データストアミドルウェアの使いこなし‧標準化、運⽤⾃動化

    SRE 開発者の⽣産性向上を⽬的としたインフラのセルフサービス化を実現する仕組みの構築 インフラレイヤにおける先端技術の検証と導⼊のための抽象化 最近の担当テーマ: EKS Cluster 管理運⽤の効率化、Kubernetes API を中⼼としたミドルウェアの検証‧導⼊ Enabling Orchestration Solution サービスインフラ運⽤にフォーカスしたツールとセルフサービス機能を提供し開発者の⽣産性を向上 最近の担当テーマ: ⾃動化の推進、 セルフサービス化推進、構築⾃動化 Cloud Governance freee のクラウド活⽤に 秩序を導⼊ することで、健全かつ効率的な利⽤を促進 最近の担当テーマ: クラウドの管理⽅針策定並びに統制のための仕組みづくり Delivery デベロッパーの開発体験をインフラから改善していくチーム 最近の担当テーマ: EKS向けCI/CD基盤(Github SelfHosted Runner, ArgoCD)、評価環境基盤の設計開発、開発⽣産性向上 プロダクトチームに対して開発プロセスの改善、提案、プロダクトチームへの SRE プラクティスの導⼊ 最近の担当テーマ: プロセスの改善、提案、プロダクトチームへの SRE プラクティスの導⼊
  4. 10 SRE Platform Delivery Team の MVV
 
 Mission:
 エンジニアがマジ価値を届ける仕事に集中

    できるようにする
 開発者が機能を思いついてからユーザに届くまでを最短 にする
 Vision:
 最速でサービスをリリースできるCI/CDの標準を提供 する
 開発環境の立ち上げの際に誰も迷わない
 Value:
 開発者ファースト 
 freeeの未来のDXを発信し続ける
 開発者が安定して使える ものを提供する

  5. 11 SRE Platform Delivery Teamの業務領域 
 
 
 CI/CD 基盤


    Argo Family, Github Actions, Self-Hosted Runner, etc
 開発環境(EC2)
 開発生産性の計測・可視化・向上 
 SRE ミッション
 プロダクトと開発組織の成長、信頼性・安定稼働
 Delivery ミッション
 エンジニアが仕事に集中できるようにする、ユーザに届くまでを最短にする

  6. 12 01
 05
 06
 02
 07
 03
 04
 なぜケイパビリティの 改善をするのか

    
 
 [実践]
 内 製 統 合 デリバリー 基 盤 
 での計測・可視化 
 [実践]
 開発生産性アンケート 
 
 [実践]
 DORAフレームワークの 
 効果検証
 ケイパビリティの改善活動 
 [ 実 践 ]
 開発生産性 OKR作成 ガイドライン 
 まとめ
 
 
 今後の展望 
 
 
 本セッションのアジェンダ 

  7. 14 DORAとState of DevOps Report
 DORA (Google Cloud)
 • DevOps

    Research and Assessmentという組織の略称
 • DevOpsと組織のパフォーマンスについて9年間研究
 State of DevOps Report
 • 世界中の 36,000 を超える組織やチームからデータを収集
 • 高い成果を出している組織が、技術、プロセス、文化の改善を、
 どのように組み込んで成功を収めているかをまとめたレポート
 
 
 
 DORA 2023 年度版 State of DevOps Report :
 https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-d evops-report
 chapter1 なぜケイパビリティを改善するのか

  8. 15 Four Keys + SLI/SLO
 • 速度 ◦ 変更のリードタイム ◦

    デプロイ頻度 • 安定性 ◦ 変更時の障害率 ◦ 失敗したデプロイの復旧時間 • 信頼性 ◦ SLI/SLO DORA の調査で、組織のソフトウェアデリバリーのパフォーマンスから、 組織の全体的なパフォーマンス、チームのパフォーマンス、 従業員の健康状態を予測できることがわかっている。
 chapter1 なぜケイパビリティを改善するのか

  9. 16 ケイパビリティとは 
 
 組織の持つ能力や要素のこと。技術、プロセス、文化、3つのジャンルで27個ある。
 ケイパビリティを改善 していくことで
 組織的なパフォーマンス が向上する
 顧客やコミュニティに価値をもたらす、収益性が高まる、市場占有率


    チームのパフォーマンス が向上する
 チームが積極的にコラボレーションし、イノベーションを起こす
 従業員の健康状態 が改善する
 燃え尽き症候群(無気力、離職するリスク)を減らし、
 満足度 / 生産性を高める
 
 https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report
 chapter1 なぜケイパビリティを改善するのか

  10. 17 ケイパビリティ 一覧
 
 技術のケイパビリティ 
 • クラウド インフラストラクチャ
 •

    コードの保守性
 • 継続的デリバリー
 • 継続的インテグレーション
 • テストの自動化
 • データベースのチェンジマネジメント
 • デプロイの自動化
 • チームのツール選択をサポート
 • 疎結合アーキテクチャ
 • モニタリングとオブザーバビリティ
 • セキュリティのシフトレフト
 • テストデータ管理
 • トランクベース開発
 • バージョン管理
 プロセスのケイパビリティ 
 • お客様のフィードバック
 • システムモニタリングによって
 ビジネスの意思決定を促す
 • 障害の予兆通知
 • 変更承認の効率化
 • チームが実験をできるか
 • バリューストリームで作業の可視化
 • 視覚化の管理
 • 作業途中のタスクへの制限
 • 小さいバッチ単位の作業
 
 文化のケイパビリティ 
 • 創造的組織文化
 • 働きがい
 • 学習文化
 • 変革的リーダーシップ
 https://cloud.google.com/architecture/devops
 chapter1 なぜケイパビリティを改善するのか

  11. 18 なぜケイパビリティの改善をするのか 
 
 ケイパビリティの改善 
 ↓
 Four Keys
 •

    ソフトウェアデリバリーの 
 パフォーマンスが向上 
 ↓
 組織のパフォーマンス向上 
 • 収益性/顧客へ価値提供
 • チームのパフォーマンス
 • 従業員の満足度/生産性
 https://dora.dev/research/
 chapter1 なぜケイパビリティを改善するのか

  12. 19 SPACE フレームワーク 
 • Satisfaction and well-being(仕事、チーム、⽂化、ツールに満⾜しているか) ◦ 満⾜度、ツールの充⾜度、⾃チームを⼈に薦めるか

    • Performance(コードや成果物がどれだけのアウトカムを出したか) ◦ コード品質、顧客満⾜度、機能利⽤率、SLI/SLO、コスト削減 • Activity(タスク完了までの⾏動やアウトプットの数) ◦ ドキュメント、PR、commit、review、ストーリーポイント、障害対応数 ActivityはFour Keysを包含している(デプロイ頻度、変更障害率、復旧時間) • Communication and collaboration ◦ どうコミュニケーションを取り協⼒し合うか • Efficiency and flow (効率と集中、中断のない時間を作れているか) ◦ MTGの数と時間、レビューの時間、CI/CDなどのトイル、ベロシティ
 chapter1 なぜケイパビリティを改善するのか

  13. 20 Activityだけを評価していたら燃え尽きてしまう。。 
 
 
 • Activity(タスク完了までの⾏動やアウトプットの数) ◦ ドキュメント、PR、commit、review、ストーリーポイント、 デプロイ頻度、変更障害率、復旧時間、障害対応数

    どれか1つの指標だけを⾒たり評価するのはNG❌ 定量的な指標(A, P)と定性的な指標(S,C,E)をどちらも⾒ていくことが重要 →満⾜度、コミュニケーション、集中、ユーザーからのフィードバック など • 定量的な指標の計測可視化(freeeの内製デリバリー基盤による可視化) ◦ BigQueryにデータを貯めて、Grafanaで可視化 • 定性的な指標 ◦ 開発⽣産性アンケートを実施
 chapter1 なぜケイパビリティを改善するのか

  14. 21 時系列でなにを実践してきたか 
 
 • 開発生産性アンケート
 • DORAフレームワークの効果検証
 • スモールスタートのEnabling

    • トランクベース開発の導入 • ロールバックの推進
 • チームごとの分析
 • 開発生産性OKRガイドライン • 計測基盤構築 
 • 可視化
 2023 / 10
 2024 / 01
 2023 / 07
 2024 / 04

  15. 23 freeeの内製デプロイ統合基盤ができた背景 
 
 4年前に構築・運用を開始
 
 目的
 • QA /

    監査プロセス の担保 
 ◦ PR ごとの Staging 確認を必ず実施する仕組み
 ◦ 1日に2回デプロイしても、1デプロイに平均50PR 以上になる大きなプロダクトもある 
 • デプロイフローの標準化 
 ◦ 50以上のプロダクトがあるため、標準化する必要があった 
 • デプロイフローの自動化 
 
 
 chapter2 内製デプロイ統合基盤での計測、可視化

  16. 24 freeeのデプロイフロー (1/3)
 
 
 1. GitHub Actions から release

    tag を作成
 a. image の build & ECR Push
 b. k8s manifest 管理用レポジトリに、
 image tag 変更の PR を作成し slack で通知
 2. 自動生成された tag 変更の PR をmerge
 a. ArgoCD から staging 環境(EKS)へデプロイ
 chapter2 内製デプロイ統合基盤での計測、可視化

  17. 25 freeeのデプロイフロー (2/3)
 
 
 3. デプロイされたことを検知して 
 staging確認リストを作成 


    a. PR作成者は自分のPRに問題ないかを確認
 b. e2e test の実行
 c. QA プロセス
 d. デプロイ担当者は確認作業を待つ
 Staging確認の 進捗確認通知 Staging確認の 終了通知 chapter2 内製デプロイ統合基盤での計測、可視化

  18. 26 freeeのデプロイフロー (3/3)
 
 
 4. Production 環境のimage tag 変更PRを作成

    
 5. PR merge で ArgoCD から production 環境
 にデプロイされる 
 6. 監視通知が slack に届くので監視する 
 • デプロイ担当者が Error Rate などのメトリクスに
 問題ないことを確認してデプロイ終了
 chapter2 内製デプロイ統合基盤での計測、可視化

  19. 27 freeeの内製デプロイ統合基盤で計測・可視化 
 
 4年前に構築・運用を開始
 
 目的
 • QA /

    監査プロセスの担保 
 • デプロイフローの標準化
 • デプロイフローの自動化
 1年前から計測・可視化 
 • Four Keysの計測部分を開発実装 
 ◦ もともと内製基盤にデプロイの情報がたまっていた ため利用できると考えた
 ◦ Jiraで管理していた障害の情報をデプロイの情報と紐づける 
 ◦ 障害データ入力に GUIが活かせる 
 
 chapter2 内製デプロイ統合基盤での計測、可視化

  20. 29 変更失敗率 & 障害復旧時間 
 GUI から一覧で表示されている障害情報を入力
 • 障害検知時刻
 ◦

    自動入力
 • デプロイによる障害か? YES/NO
 ◦ デプロイを紐づけられる
 • デプロイで障害から復旧したか? YES/NO
 ◦ デプロイを紐づけられる
 ※ デプロイを紐付けると時刻が自動で入力される 
 chapter2 内製デプロイ統合基盤での計測、可視化

  21. 31 内製基盤で計測可視化するメリット・デメリット 
 
 メリット
 ◦ データの連携 や計測が自由にできる
 ▪ 復旧時間が正確に出せる


    • 障害発生時刻を正確にとれる 
 ◦ Jiraの障害データを連携
 • デプロイの完了時間を正確にとれる 
 ◦ ArgoCDでSyncし、Kubernetesのpodが入れ替わったタイミングのデータがとれるように設計
 ◦ その他、可視化したい内容に応じて、データの計測項目を柔軟に追加・変更 できる
 デメリット 
 ◦ 開発コスト がかかる
 ◦ 運用負荷が高い
 ▪ Platform Deliveryが専任チームで運用する必要がある
 ▪ freeeのプロダクトで使われている標準と構成や言語が違う 
 ▪ 運用、改善を回していかないと負債化してしまう
 chapter2 内製デプロイ統合基盤での計測、可視化

  22. 32 内製基盤か商用製品を利用するかの判断 
 
 DORAでは
 計測や可視化に時間と労力を割くのであれば、 
 簡単に導入できる商用製品を利用すべき とある
 


    freeeの場合は、もともとQA監査プロセスとデプロイフロー標準化の目的で内製基盤があり、
 計測可視化に必要なデータの連携部分を開発するだけでよかった ため、うまく内製化できた。
 
 組織の状況に合わせて、商用製品を利用するか計測部分を作り込むか検討して判断すべき。
 
 引用:
 改善を犠牲にして測定に重点を置く。
 チームがFourKeysについて収集する必要があるデータは、現在さまざまな場所で入手できます。ソフトウェア配信パフォーマンスに関する正確なデータを取 得するために複数のシステムとの統合を構築することは、初期投資に見合わない可能性があります。代わりに、会話をしたり、DORA Quick Checkを実行し たり、統合が事前に構築されたソースから入手可能な製品や商用製品を使用したりすることから始める方がよいでしょう。
 https://dora.dev/guides/dora-metrics-four-keys/
 chapter2 内製デプロイ統合基盤での計測、可視化

  23. 33 時系列でなにを実践してきたか 
 
 • 開発生産性アンケート 
 • DORAフレームワークの効果検証
 •

    スモールスタートのEnabling • トランクベース開発の導入 • ロールバックの推進
 • チームごとの分析
 • 開発生産性OKRガイドライン • 計測基盤構築
 • 可視化
 2023 / 10
 2024 / 01
 2023 / 07
 2024 / 04

  24. 35 なぜアンケートをとるのか 
 
 アンケートの目的 
 • SPACEの中でアンケートの定性的な回答からしか測れない ものがある
 •

    改善すべきケイパビリティ を特定するため
 • 改善活動の成果 を振り返るため
 ◦ 計測をしないと
 ▪ 勘をたよりに改善してしまう
 ▪ 実際に改善したかどうか確認されずに忘れさられる
 chapter3 開発生産性アンケート

  25. 36 アンケート作成時に意識したこと 
 • リッカート 尺度を採用
 ◦ 7段階で回答
 ▪ 1:まったくそうは思わない

    4: どちらともいえない 7: 非常にそう思う
 ▪ 中立な回答 があること
 ▪ 両極な回答だけでなく、程度まで測れる こと
 • Google フォーム で集計
 • スプレッドシート で可視化
 • 実施頻度が多いと調査疲れを起こしてしまう
 ◦ 振り返りのサイクルや現状把握したい頻度に合わせて設定する
 ◦ 1ヶ月に1回か3ヶ月に1回がDORAのオススメ
 ◦ freee では3ヶ月に1回
 ▪ 目標設定と振り返りを3ヶ月に1回のサイクルでするため
 ▪ 41個の設問があるため調査疲れを懸念
 chapter3 開発生産性アンケート

  26. 37 可視化するときに意識したこと 
 • 回答と可視化のシートを分ける
 ◦ 個人の回答が特定 されないよう配慮
 ◦ 四半期ごと推移をみれるように

    する
 ▪ 成果を振り返る ため
 • 振り返りやすくする
 ◦ チーム/設問をプルダウンで選択 
 chapter3 開発生産性アンケート

  27. 39 設問の一部を紹介 
 
 • SPACEのS 満足度
 ◦ 自分のチームを他の人に薦められるか 


    • SPACEのC コミュニケーション
 ◦ ドキュメントの質 
 ◦ 機能横断的なコラボレーションが推奨されているか 
 • SPACEのE 効率と集中
 ◦ MTGの量や質は適切か 
 ◦ フロー状態を作れているか 
 • ユーザーフォーカスの U
 ◦ ユーザーからのフィードバックを繰り返し反映しながら開発しているか 
 • freee独自の設問 F 
 ◦ LLMやGithub Copilotなどを業務で有効に活用できているか 
 
 chapter3 開発生産性アンケート

  28. 40 DORAメトリクスを可視化してみて 
 勘をたよりに改善する &やりやすい改善 から着手する ことを防ぐ
 マネージャーとチームが根拠と納得感をもって改善を実践 できる
 改善したあと成果が振り返れる

    
 
 開発チームが日頃から考えている改善アイデアは、
 実体験から考えているので正しい改善策であることが多い
 
 良い改善策は浮かんではいたが、優先度を上げ工数をとる判断ができず、
 実践されない状態は非常にもったいない
 chapter3 開発生産性アンケート

  29. 41 時系列でなにを実践してきたか 
 
 • 開発生産性アンケート
 • DORAフレームワークの効果検証 
 •

    スモールスタートの Enabling • トランクベース開発の導入 • ロールバックの推進
 • チームごとの分析
 • 開発生産性OKRガイドライン • 計測基盤構築
 • 可視化
 2023 / 10
 2024 / 01
 2023 / 07
 2024 / 04

  30. 44 失敗の原因まとめ 
 • 比較的freeeのなかでも大きなプロダクト でスタート
 • DORAフレームワーク の理解度低かった
 ◦

    ドキュメントが充実していなかった
 • 四半期の途中から提案 を始めたためチームの合意と工数を取れなかった 
 ◦ 改善施策の実行するリソース の半分以上がdeliveryチームになっていた
 ◦ コードの保守性のケイパビリティ改善では、deliveryチーム視点からどこが問題で保守性が
 悪くなっているか分からず具体的なアクションに落とし込めなかった 
 • 指標から取り組むべきケイパビリティを特定するのではなく、
 ヒアリングして出てきた課題を無理やりケイパビリティに結びつけて取り組んだ 
 chapter4 DORAフレームワークの効果検証

  31. 45 失敗を踏まえた DORAフレームワークの効果検証 
 • スモールスタートを意識 
 • 小規模なチーム でDORAのフレームワークの改善活動による成果がでるかを検証

    
 • アンケート によってデプロイ周りの満足度の数値が低いチームを選ぶ 
 • deliveryチームが具体的なアクションを決められるケイパビリティに取り組む 
 ◦ いずれプロダクトチームだけで取り組めるようにドキュメントや手順を整備
 • 指標で成果を振り返れる ようにする
 chapter4 DORAフレームワークの効果検証

  32. 46 チーム選定 
 
 アンケートによって選定 
 リリースフロー、 hotfix、ロールバック それぞれの満足度や安全度
 デプロイフローの改善にどれくらい興味があるか

    
 デプロイフローの改善に週どれくらい時間を割いても良いか 
 その他、CI/CD全般で感じている課題を自由記述
 
 課題感が深く、改善に関心が高い、時間が割けるチームを選定
 chapter4 DORAフレームワークの効果検証

  33. 47 時系列でなにを実践してきたか 
 
 • 開発生産性アンケート
 • DORAフレームワークの効果検証
 • スモールスタートのEnabling

    • トランクベース開発の導入 • ロールバックの推進 
 • チームごとの分析
 • 開発生産性OKRガイドライン • 計測基盤構築
 • 可視化
 2023 / 10
 2024 / 01
 2023 / 07
 2024 / 04

  34. 49 トランクベース開発の導入 
 
 トランクベース開発: ソフトウェア開発の⼀つのスタイル 開発者は⾃分の作業(PR)を⼩さなバッチに分割し、 少なくとも1回/1⽇はトランク(共有 branch)に merge

    する freee では短命の feature branch & PR を作成し main にmerge していく Github Actions で release tag を作成すると、デプロイが⾃動で実⾏される仕組み
 chapter4 DORAフレームワークの効果検証・トランクベース開発の導入

  35. 50 トランクベース開発のメリット・デメリット 
 
 トランクベース開発のメリット ⼩さなバッチ単位の作業のケイパビリティに効果がある ブランチの構成がシンプルで認知負荷が低い デプロイ‧hotfix対応の負荷軽減 GitHub Releaseからリリース毎に含まれているPRを参照しやすい

    トランクベース開発の注意点 main branch に⼊ったPRは 本番環境に⼊る前提で考える PRレビュー、CIで⾃動テストやセキュリティチェック 旧ブランチ戦略 Gitlab base
 chapter4 DORAフレームワークの効果検証・トランクベース開発の導入

  36. 51 トランクベース開発を導入後アンケート結果の推移 
 開発生産性アンケートの結果 (7段階)
 +1.0 デプロイフローの自動化、高速で快適だ
 +1.25 開発環境の満足度
 +1.25

    仕事の満足度
 トランクベース開発を導入した全チーム で
 デプロイフローの設問の回答がプラスの結果に!!!
 トランクベース開発導入後に実施した簡易アンケート (5段階で回答 )
 5.0 定時リリースフローは安全になった
 5.0 定時リリースフローは簡単になった・わかりやすくなった
 4.33 定時リリースフローは自動化された 
 4.83 hotfixは安全になった
 5.0  hotfixが簡単になった・わかりやすくなった
 4.83 hotfixの自動化が進んだ
 
 chapter4 DORAフレームワークの効果検証・トランクベース開発の導入

  37. 53 ロールバックの効率化・フロー整備 
 
 なぜやるのか 
 MTTR短縮とインシデント発生時の損失 を軽減
 改善活動の時間を確保 するため


    Well-being(幸福)のケイパビリティ の改善
 reworkの項目
 手戻りによるやり直し、セキュリティやインシデント対応 を減らす
 
 
 
 
 
 
 https://dora.dev/devops-capabilities/cultural/well-being/
 chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備

  38. 54 ロールバックを推進する意思決定に用いた数値 
 
 ロールバックの定義 
 デプロイ後にcontainer imageを前のバージョンに切り戻すこと
 ロールバック可能な障害の割合 37.9%


    デプロイ後すぐに不具合を検知できているか
 ロールバックできた障害の割合 18.2%
 ロールバックの判断ができているか
 MTTR
 ロールバックできた障害の平均復旧時間 15分
 ロールバックしなかった障害の平均復旧時間 1時間30分
 freeeのhotfixデプロイ
 hotfixPRをmerge
 image build & ECR Push
 staging環境にデプロイ、動作確認/テスト/QA
 production環境にデプロイ
 chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備

  39. 55 ロールバックを効率化するメリット 
 
 • 1障害辺り平均で 対応メンバー × 1時間15分の止血対応時間を削減 できる


    • 障害の影響事業所数を 80%減らす
 • 影響範囲の調査も短縮 
 • 重篤度が高い機能の障害だった場合、1000万〜1億円の損失を回避 できる可能性も
 
 インシデント対応 の時間が減る と、
 幸福度が上がり 、改善活動と価値を届ける仕事 に時間を使うことができる
 chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備

  40. 56 ロールバックの効率化とフロー整備 
 
 Rollback NG button
 ロールバックすべきでない PR があれば押す


    ロールバックの判断を高速化
 ロールバックによる二次被害防止
 互換性のあるリリース意識の向上 
 ドキュメント整備 
 ロールバック手順
 ロールバックチェック機能の紹介
 ロールバックを可能にするためのリリース作成ガイド
 chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備

  41. 57 ロールバックの推進によるアンケートの推移 
 
 • 5月にロールバック周りの整備
 • チーム規模 best4のプロダクト を確認


    • 3月実施アンケートと6月実施アンケートを比較
 • ロールバックのアンケートの結果が全てプラス 
 • Four Keys MTTRは大きな変化が見られなかった
 ◦ 施策実施から1ヶ月しか経っていないため障害数の サンプルが少ない
 ◦ 直近90日の中央値をとっている
 ◦ 安定性の指標(MTTRや変更障害率)は
 遅行指標のため3ヶ月や半年後に効果が現れる
 chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備

  42. 58 時系列でなにを実践してきたか 
 
 • 開発生産性アンケート
 • DORAフレームワークの効果検証
 • スモールスタートのEnabling

    • トランクベース開発の導入 • ロールバックの推進
 • チームごとの分析
 • 開発生産性 OKRガイドライン • 計測基盤構築
 • 可視化
 2023 / 10
 2024 / 01
 2023 / 07
 2024 / 04

  43. 60 開発生産性 OKRガイドライン 
 
 DORAフレームワークの効果検証の結果、
 有効な成果が出たので全社展開していきたい 
 
 ガイドラインの目的

    
 • 50以上あるプロダクト 
 ◦ 各チームで振り返りと目標設定のサイクルに取り入れるためにドキュメント化
 ◦ DORAフレームワークやメトリクスについて間違った利用をされるのを防ぐため
 
 
 chapter5 開発生産性OKRガイドライン

  44. 61 開発生産性 OKRガイドラインの概要 
 
 • DORAフレームワークについて 
 ◦ DORA/State

    of Devops Reportについて
 ◦ Four Keysについて
 ◦ SPACEフレームワークについて
 • DORAメトリクス の確認方法 /アンチパターン 
 • どのように目標設定と振り返りに組み込むか 
 • 各設問と指標に対応しているケイパビリティ、改善の具体例 
 chapter5 開発生産性OKRガイドライン

  45. 62 ガイドラインで特に伝えたいこと 
 • Four Keysやアンケート結果の数値で目標設定をしない 
 • DORAメトリクスを人事評価に利用しない 、改善に利用するためのもの


    • 1つだけのメトリクス を追わない
 • 継続的な取り組みが重要 
 
 Four Keysやアンケートの結果をもとに、
 改善するケイパビリティを決めるのはチーム であり
 ケイパビリティ改善自体を行うのもチーム である
 
 
 chapter5 開発生産性OKRガイドライン

  46. 64 まとめ
 
 • なぜケイパビリティを改善するのか 
 ◦ ケイパビリティ改善 →アンケート/Four Keysなどメトリクスに現れる→組織のパフォーマンス向上


    • 内製統合デリバリー基盤での計測・可視化 
 • 開発生産性アンケートの実施 
 ◦ 定性面の可視化、推移の可視化で振り返りに活かす、チーム単位の可視化で自分ごと化
 • スモールスタートで DORAフレームワーク効果検証 
 ◦ トランクベース開発 のケイパビリティの導入
 ◦ ロールバック の効率化・フロー整備
 • 開発生産性 OKRガイドライン 
 ◦ 正しい取り組み方を組織全体に広げるために

  47. 66 今後の展望 
 
 freeeではこれから1年のテーマの1つとして、
 開発生産性 2倍 を掲げている
 組織のパフォーマンスを上げ、成長を続けるためには何をすればいいのか
 組織全体に向けて、1つこの施策を進めればいい、この指標を追えばいい


    というような明確な答えがあるわけではない
 
 それぞれのチームで、開発者ひとりひとりがメトリクスを見て
 改善すべきケイパビリティを特定し
 継続的に改善を回し続けることが重要である

  48. 67 開発生産性における リーダーシップ の重要性
 トップダウンではなく、リーダーシップ を発揮する
 モチベーションが上がるような目標設定
 どんな改善を行うかはチームに任せる (トップダウンで改善内容を押し付けない)
 正しい取り組み方

    をチームに伝える
 PDCAサイクルをサポート
 通常業務で改善作業を圧迫しない 
 freeeでは
 各チームが品質改善に 10%の工数をとれるように調整 する
 各チームでENGとPdMが一緒に追う、共通の開発生産性の OKRを立てる
 引用:組織を変革する方法
 トップダウンで改善活動を実践した場合、最初の四半期に改善の取り組みが多くなり、
 次の四半期では取り組まれないというサイクルになってしまう
 そのサイクルを繰り返すなかで、疑念と無関心が組織に広がってしまう
 https://dora.dev/guides/devops-culture-transform/