Small_Start_Conscious_Development_Productivity_Improvement_Practices_at_freee

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

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   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　開発生産性アンケート  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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フレームワークの効果検証・ロールバックの効率化・フロー整備 

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

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

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

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

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

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

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

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

　まとめ 

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

　今後の展望  

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

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

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

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

Small_Start_Conscious_Development_Productivity_...

Small_Start_Conscious_Development_Productivity_Improvement_Practices_at_freee

More Decks by hikaru-miyazawa

Other Decks in Technology

Featured

Transcript