Small_Start_Conscious_Development_Productivity_Improvement_Practices_at_freee

by hikaru-miyazawa

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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_ﬁndy_5B   

Slide 3

Slide 3 text

　 freeeの事業内容   SREチーム  Platform Deliveryの紹介 

Slide 4

Slide 4 text

4 　ミッション‧ビジョン‧バリュー Mission Vision Value

Slide 5

Slide 5 text

5 　 freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームを開発‧提供し、だれもが⾃由に⾃然体で経営できる環境をつくっていきます。起業やビジネスを育てていくことを、もっと魅⼒的で気軽な⾏為に。個⼈事業や中⼩企業などのスモールビジネスに携わるすべての⼈が、じぶんらしく⾃信をもって経営できるように。⼤胆にスピード感をもってアイデアを具現化できるスモールビジネスは、今までにない多様な価値観や⽣き⽅、新しいイノベーションを⽣み出す起爆剤だと私たちは考えています。スモールビジネスが⼤企業を刺激し、社会をさらにオモシロク、世の中全体をより良くする流れを後押ししていきます。 Mission スモールビジネスを、世界の主役に。

Slide 6

Slide 6 text

　 6 だれもが⾃由に経営できる統合型経営プラットフォーム。だれもが⾃由に⾃然体で経営できる環境をつくるために、「統合型経営プラットフォーム」を開発‧提供します。バックオフィス業務を統合することで、⾃動化と業務全体の効率化。さらに経営全体を可視化することで、これまでにないスマートかつ最適なアクションまで実⾏できるプラットフォームへと進化させていきます。また外部サービスとも連携したオープンプラットフォームとして、多様なビジネスニーズに対応。ユーザーネットワークの中における相互取引の活性化も強化していきます。プラットフォームの提供のみならず、スモールビジネスに携わる⼈の環境そのものをより良くしていく取り組みを⾏うことで、世の中の変化を促します。 Vision

Slide 7

Slide 7 text

7 　電⼦稟議経費精算債権債務管理⼈事労務電⼦契約固定資産請求管理会計⼯数管理販売管理会計‧⼈事労務‧販売管理を核とした統合型経営プラットフォーム

Slide 8

Slide 8 text

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 プラクティスの導⼊

Slide 9

Slide 9 text

9 freee SREのミッション         社会基盤として重要性を増すfreeeの全サービスの  信頼性・安定稼働を実現する  高い開発者体験を実現する基盤を開発運用し  プロダクトと開発組織の成長を支える 

Slide 10

Slide 10 text

10 SRE Platform Delivery Team の MVV    Mission:  エンジニアがマジ価値を届ける仕事に集中できるようにする  開発者が機能を思いついてからユーザに届くまでを最短にする  Vision:  最速でサービスをリリースできるCI/CDの標準を提供する  開発環境の立ち上げの際に誰も迷わない  Value:  開発者ファースト   freeeの未来のDXを発信し続ける  開発者が安定して使えるものを提供する 

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

　なぜケイパビリティの   改善をするのか  

Slide 14

Slide 14 text

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 なぜケイパビリティを改善するのか 

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

16 ケイパビリティとは     組織の持つ能力や要素のこと。技術、プロセス、文化、3つのジャンルで27個ある。  ケイパビリティを改善していくことで  組織的なパフォーマンスが向上する  顧客やコミュニティに価値をもたらす、収益性が高まる、市場占有率  チームのパフォーマンスが向上する  チームが積極的にコラボレーションし、イノベーションを起こす  従業員の健康状態が改善する  燃え尽き症候群（無気力、離職するリスク）を減らし、  満足度 / 生産性を高める    https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report  chapter1 なぜケイパビリティを改善するのか 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

19 SPACE フレームワーク   ● Satisfaction and well-being(仕事、チーム、⽂化、ツールに満⾜しているか) ○ 満⾜度、ツールの充⾜度、⾃チームを⼈に薦めるか ● Performance(コードや成果物がどれだけのアウトカムを出したか) ○ コード品質、顧客満⾜度、機能利⽤率、SLI/SLO、コスト削減 ● Activity(タスク完了までの⾏動やアウトプットの数) ○ ドキュメント、PR、commit、review、ストーリーポイント、障害対応数 ActivityはFour Keysを包含している（デプロイ頻度、変更障害率、復旧時間） ● Communication and collaboration ○ どうコミュニケーションを取り協⼒し合うか ● Eﬃciency and ﬂow (効率と集中、中断のない時間を作れているか) ○ MTGの数と時間、レビューの時間、CI/CDなどのトイル、ベロシティ  chapter1 なぜケイパビリティを改善するのか 

Slide 20

Slide 20 text

20 Activityだけを評価していたら燃え尽きてしまう。。       ● Activity(タスク完了までの⾏動やアウトプットの数) ○ ドキュメント、PR、commit、review、ストーリーポイント、デプロイ頻度、変更障害率、復旧時間、障害対応数どれか1つの指標だけを⾒たり評価するのはNG❌ 定量的な指標(A, P)と定性的な指標(S,C,E)をどちらも⾒ていくことが重要 →満⾜度、コミュニケーション、集中、ユーザーからのフィードバックなど ● 定量的な指標の計測可視化（freeeの内製デリバリー基盤による可視化） ○ BigQueryにデータを貯めて、Grafanaで可視化 ● 定性的な指標 ○ 開発⽣産性アンケートを実施  chapter1 なぜケイパビリティを改善するのか 

Slide 21

Slide 21 text

21 時系列でなにを実践してきたか     ● 開発生産性アンケート  ● DORAフレームワークの効果検証  ● スモールスタートのEnabling ● トランクベース開発の導入 ● ロールバックの推進  ● チームごとの分析  ● 開発生産性OKRガイドライン ● 計測基盤構築   ● 可視化  2023 / 10  2024 / 01  2023 / 07  2024 / 04 

Slide 22

Slide 22 text

　内製デプロイ統合基盤での   計測、可視化  

Slide 23

Slide 23 text

23 freeeの内製デプロイ統合基盤ができた背景     4年前に構築・運用を開始    目的  ● QA / 監査プロセスの担保   ○ PR ごとの Staging 確認を必ず実施する仕組み  ○ 1日に2回デプロイしても、1デプロイに平均50PR 以上になる大きなプロダクトもある   ● デプロイフローの標準化   ○ 50以上のプロダクトがあるため、標準化する必要があった   ● デプロイフローの自動化       chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 24

Slide 24 text

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 内製デプロイ統合基盤での計測、可視化 

Slide 25

Slide 25 text

25 freeeのデプロイフロー (2/3)      3. デプロイされたことを検知して   staging確認リストを作成   a. PR作成者は自分のPRに問題ないかを確認  b. e2e test の実行  c. QA プロセス  d. デプロイ担当者は確認作業を待つ  Staging確認の進捗確認通知 Staging確認の終了通知 chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 26

Slide 26 text

26 freeeのデプロイフロー (3/3)      4. Production 環境のimage tag 変更PRを作成   5. PR merge で ArgoCD から production 環境  にデプロイされる   6. 監視通知が slack に届くので監視する   ● デプロイ担当者が Error Rate などのメトリクスに  問題ないことを確認してデプロイ終了  chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

28 Jiraとの障害データの連携   Jiraで管理されている障害情報を webhook で受け取り、統合デリバリー基盤の GUI に⼀覧で表⽰される仕組み  chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 29

Slide 29 text

29 変更失敗率 & 障害復旧時間   GUI から一覧で表示されている障害情報を入力  ● 障害検知時刻  ○ 自動入力  ● デプロイによる障害か？ YES/NO  ○ デプロイを紐づけられる  ● デプロイで障害から復旧したか？ YES/NO  ○ デプロイを紐づけられる  ※ デプロイを紐付けると時刻が自動で入力される   chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 30

Slide 30 text

30 Four Keys ダッシュボードの図   引用URL  chapter2 内製デプロイ統合基盤での計測、可視化 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 時系列でなにを実践してきたか     ● 開発生産性アンケート   ● DORAフレームワークの効果検証  ● スモールスタートのEnabling ● トランクベース開発の導入 ● ロールバックの推進  ● チームごとの分析  ● 開発生産性OKRガイドライン ● 計測基盤構築  ● 可視化  2023 / 10  2024 / 01  2023 / 07  2024 / 04 

Slide 34

Slide 34 text

　開発生産性アンケート  

Slide 35

Slide 35 text

35 なぜアンケートをとるのか     アンケートの目的   ● SPACEの中でアンケートの定性的な回答からしか測れないものがある  ● 改善すべきケイパビリティを特定するため  ● 改善活動の成果を振り返るため  ○ 計測をしないと  ■ 勘をたよりに改善してしまう  ■ 実際に改善したかどうか確認されずに忘れさられる  chapter3 開発生産性アンケート 

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

37 可視化するときに意識したこと   ● 回答と可視化のシートを分ける  ○ 個人の回答が特定されないよう配慮  ○ 四半期ごと推移をみれるようにする  ■ 成果を振り返るため  ● 振り返りやすくする  ○ チーム/設問をプルダウンで選択   chapter3 開発生産性アンケート 

Slide 38

Slide 38 text

38 可視化するときに意識したこと   ● 小規模なチーム(5〜9人単位)ごとに確認できるようにする  ○ メンバーひとりひとりに自分ごととして取り組んでもらうため             低い順に並び替え課題を特定しやすくする  chapter3 開発生産性アンケート 

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40 DORAメトリクスを可視化してみて   勘をたよりに改善する &やりやすい改善から着手することを防ぐ  マネージャーとチームが根拠と納得感をもって改善を実践できる  改善したあと成果が振り返れる     開発チームが日頃から考えている改善アイデアは、  実体験から考えているので正しい改善策であることが多い    良い改善策は浮かんではいたが、優先度を上げ工数をとる判断ができず、  実践されない状態は非常にもったいない  chapter3 開発生産性アンケート 

Slide 41

Slide 41 text

41 時系列でなにを実践してきたか     ● 開発生産性アンケート  ● DORAフレームワークの効果検証   ● スモールスタートの Enabling ● トランクベース開発の導入 ● ロールバックの推進  ● チームごとの分析  ● 開発生産性OKRガイドライン ● 計測基盤構築  ● 可視化  2023 / 10  2024 / 01  2023 / 07  2024 / 04 

Slide 42

Slide 42 text

　 DORAフレームワークの効果検証   スモールスタートの Enabling   

Slide 43

Slide 43 text

43 最初はフレームワークを浸透させることが出来なかった  

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

45 失敗を踏まえた DORAフレームワークの効果検証   ● スモールスタートを意識   ● 小規模なチームでDORAのフレームワークの改善活動による成果がでるかを検証   ● アンケートによってデプロイ周りの満足度の数値が低いチームを選ぶ   ● deliveryチームが具体的なアクションを決められるケイパビリティに取り組む   ○ いずれプロダクトチームだけで取り組めるようにドキュメントや手順を整備  ● 指標で成果を振り返れるようにする  chapter4 DORAフレームワークの効果検証 

Slide 46

Slide 46 text

46 チーム選定     アンケートによって選定   リリースフロー、 hotﬁx、ロールバックそれぞれの満足度や安全度  デプロイフローの改善にどれくらい興味があるか   デプロイフローの改善に週どれくらい時間を割いても良いか   その他、CI/CD全般で感じている課題を自由記述    課題感が深く、改善に関心が高い、時間が割けるチームを選定  chapter4 DORAフレームワークの効果検証 

Slide 47

Slide 47 text

47 時系列でなにを実践してきたか     ● 開発生産性アンケート  ● DORAフレームワークの効果検証  ● スモールスタートのEnabling ● トランクベース開発の導入 ● ロールバックの推進   ● チームごとの分析  ● 開発生産性OKRガイドライン ● 計測基盤構築  ● 可視化  2023 / 10  2024 / 01  2023 / 07  2024 / 04 

Slide 48

Slide 48 text

　ケイパビリティの改善活動   トランクベース開発の導入  

Slide 49

Slide 49 text

49 トランクベース開発の導入     トランクベース開発: ソフトウェア開発の⼀つのスタイル開発者は⾃分の作業(PR)を⼩さなバッチに分割し、少なくとも1回/1⽇はトランク(共有 branch)に merge する freee では短命の feature branch & PR を作成し main にmerge していく Github Actions で release tag を作成すると、デプロイが⾃動で実⾏される仕組み  chapter4 DORAフレームワークの効果検証・トランクベース開発の導入 

Slide 50

Slide 50 text

50 トランクベース開発のメリット・デメリット     トランクベース開発のメリット⼩さなバッチ単位の作業のケイパビリティに効果があるブランチの構成がシンプルで認知負荷が低いデプロイ‧hotﬁx対応の負荷軽減 GitHub Releaseからリリース毎に含まれているPRを参照しやすいトランクベース開発の注意点 main branch に⼊ったPRは本番環境に⼊る前提で考える PRレビュー、CIで⾃動テストやセキュリティチェック旧ブランチ戦略 Gitlab base  chapter4 DORAフレームワークの効果検証・トランクベース開発の導入 

Slide 51

Slide 51 text

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フレームワークの効果検証・トランクベース開発の導入 

Slide 52

Slide 52 text

　ケイパビリティの改善活動   ロールバックの推進  

Slide 53

Slide 53 text

53 ロールバックの効率化・フロー整備     なぜやるのか   MTTR短縮とインシデント発生時の損失を軽減  改善活動の時間を確保するため  Well-being(幸福)のケイパビリティの改善  reworkの項目  手戻りによるやり直し、セキュリティやインシデント対応を減らす              https://dora.dev/devops-capabilities/cultural/well-being/  chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備 

Slide 54

Slide 54 text

54 ロールバックを推進する意思決定に用いた数値     ロールバックの定義   デプロイ後にcontainer imageを前のバージョンに切り戻すこと  ロールバック可能な障害の割合 37.9%  デプロイ後すぐに不具合を検知できているか  ロールバックできた障害の割合 18.2%  ロールバックの判断ができているか  MTTR  ロールバックできた障害の平均復旧時間 15分  ロールバックしなかった障害の平均復旧時間 1時間30分  freeeのhotﬁxデプロイ  hotﬁxPRをmerge  image build & ECR Push  staging環境にデプロイ、動作確認/テスト/QA  production環境にデプロイ  chapter4 DORAフレームワークの効果検証・ロールバックの効率化・フロー整備 

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

58 時系列でなにを実践してきたか     ● 開発生産性アンケート  ● DORAフレームワークの効果検証  ● スモールスタートのEnabling ● トランクベース開発の導入 ● ロールバックの推進  ● チームごとの分析  ● 開発生産性 OKRガイドライン ● 計測基盤構築  ● 可視化  2023 / 10  2024 / 01  2023 / 07  2024 / 04 

Slide 59

Slide 59 text

　開発生産性 OKRガイドライン  

Slide 60

Slide 60 text

60 開発生産性 OKRガイドライン     DORAフレームワークの効果検証の結果、  有効な成果が出たので全社展開していきたい     ガイドラインの目的   ● 50以上あるプロダクト   ○ 各チームで振り返りと目標設定のサイクルに取り入れるためにドキュメント化  ○ DORAフレームワークやメトリクスについて間違った利用をされるのを防ぐため      chapter5 開発生産性OKRガイドライン 

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

62 ガイドラインで特に伝えたいこと   ● Four Keysやアンケート結果の数値で目標設定をしない   ● DORAメトリクスを人事評価に利用しない、改善に利用するためのもの  ● 1つだけのメトリクスを追わない  ● 継続的な取り組みが重要     Four Keysやアンケートの結果をもとに、  改善するケイパビリティを決めるのはチームであり  ケイパビリティ改善自体を行うのもチームである      chapter5 開発生産性OKRガイドライン 

Slide 63

Slide 63 text

　まとめ 

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

　今後の展望  

Slide 66

Slide 66 text

66 今後の展望     freeeではこれから1年のテーマの1つとして、  開発生産性 2倍を掲げている  組織のパフォーマンスを上げ、成長を続けるためには何をすればいいのか  組織全体に向けて、1つこの施策を進めればいい、この指標を追えばいい  というような明確な答えがあるわけではない    それぞれのチームで、開発者ひとりひとりがメトリクスを見て  改善すべきケイパビリティを特定し  継続的に改善を回し続けることが重要である 

Slide 67

Slide 67 text

67 開発生産性におけるリーダーシップの重要性  トップダウンではなく、リーダーシップを発揮する  モチベーションが上がるような目標設定  どんな改善を行うかはチームに任せる (トップダウンで改善内容を押し付けない)  正しい取り組み方をチームに伝える  PDCAサイクルをサポート  通常業務で改善作業を圧迫しない   freeeでは  各チームが品質改善に 10％の工数をとれるように調整する  各チームでENGとPdMが一緒に追う、共通の開発生産性の OKRを立てる  引用：組織を変革する方法  トップダウンで改善活動を実践した場合、最初の四半期に改善の取り組みが多くなり、  次の四半期では取り組まれないというサイクルになってしまう  そのサイクルを繰り返すなかで、疑念と無関心が組織に広がってしまう  https://dora.dev/guides/devops-culture-transform/ 

Slide 68

Slide 68 text

68 開発生産性について語りましょう！   freeeのブース・懇親会でお話聞かせてください！    X ID: miyahika214  資料アップロードしています！  #開発生産性con_ﬁndy_5B  感想ポストお待ちしています！   

Slide 69

Slide 69 text

スモールビジネスを、世界の主役に。  