freeeの開発⽣産性向上の ために実践してきたこと ~ State of DevOps Report ~ 宮澤 輝 / miyahika 2024年5⽉31⽇

2 宮澤 輝 / miyahika
 freeeに2022年1月入社。
 freeeの開発者の体験が向上する取り組みを 行ってきました。
 好きなtopic:
 Kubernetes/ArgoCD/ARC/Four Keys
 趣味：ポケカ、カラオケ、ポーカー
 SRE / Platform Delivery

　 本日のアジェンダ 01
 05
 06
 02
 07
 03
 04
 Platform Delivery
 チーム紹介
 開発生産性向上の取り組みをは じめたきっかけ
 State of DevOps Report
 とは
 なぜケイパビリティの
 改善に取り組むのか
 開発生産性向上
 実践してきたこと
 トランクベース 開 発
 のケイパビリティ
 まとめ


　 SRE Platform Delivery チーム の紹介

　 SRE Platform Delivery チーム ● 主な業務領域 ○ CI/CDパイプライン ○ 開発環境の改善 ○ 開発⽣産性の計測と可視化 ● 他社ではいわゆるDevOpsチームが担当することが多い領域です。 ● チームの技術スタック ○ Kubernetes, ArgoCD, GitHub Actions, Terraform, CircleCI, Datadog

　 開発⽣産性向上をはじめたきっかけ ● チームでやっているCI/CD改善の成果を視える化したい...！ ● 2023年4⽉ CloudNativeDays Tokyo ○ Four Keys‧ケイパビリティについてチームメンバーが登壇 ● 2022と2023のState of DevOps Report ＆ Assessment ● LeanとDevOpsの科学 書籍 2017出版 ● 他社事例をインプット/イベント登壇や発表資料集め

　 State of DevOps Reportとは

　 DORA / State of DevOps Report とは？ DORA＝DevOps Research and Assessmentの略 DevOpsと組織のパフォーマンスについて9年間研究している 世界中の 36,000 を超える組織やチームからデータを集め、 ⾼い成果を出している組織が、技術、プロセス、⽂化の改善を どのように組み込んで成功を収めているかをまとめたレポート DORA 2023 度版 State of DevOps Reportより⼀部引⽤： https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report

　 レポートで⾔われている成功や成果とは？ ● 組織的なパフォーマンス ○ 顧客やコミュニティに価値をもたらす ● チームのパフォーマンス ○ チームのイノベーションとコラボレーションを⽀援する ● 従業員の健康 ○ 燃え尽き症候群を減らし、満⾜度 / ⽣産性を⾼める https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report


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

　 Four Keys + SLI/SLO ● ⾼いパフォーマンスに分類されたチームは、速度も安定性も⾼い ● 低いパフォーマンスに分類されたチームは、速度も安定性も低い →速度と安定性はトレードオフではなく両⽴できる！ 信頼性（SLI/SLO）の取り組みは組織のパフォーマンスを向上させる SREのプラクティスを実践するチームでは、⽣産性と働きがいが⾼く、 燃え尽き症候群になる可能性も下がることが分かった。

　 DORAメトリクスは組織が⾼いパフォーマンスであることを保証できる？ ● Eliteカテゴリに分類された企業 ○ DORAメトリクスを活⽤してサービスを継続的に改善していて、 競合他社に⽐べて急速に成⻑している。 ● どこをどのように改善すべきかを正確に特定するのに役⽴つ ● 推移を⾒ていくと、チームの成⻑やどの領域がよりよくなったかがわかる。 ● ⼀⽅で批判的な意⾒もある ○ 批判的な意⾒の中には、間違った使い⽅や部分的な使い⽅をしている場合 が多い ● アンチパターンとして ○ 数字を取り巻く状況ではなく、数字⾃体を⾒てしまう

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

　 Activityだけを評価していたら燃え尽きてしまう。。 ● Activity(タスク完了までの⾏動やアウトプットの数) ○ ドキュメント、PR、commit、review、ストーリーポイント、 デプロイ頻度、変更障害率、復旧時間、障害対応数 ● どれか1つの指標だけを⾒たり、評価するのはアンチパターン ● 定量的な指標(A, P)と定性的な指標(S,C,E)を両⽅⾒ていくことが重要 ● 定量的な指標の計測可視化 ○ BigQuery×Grafana ● 定性的な指標 ○ 開発⽣産性アンケートを実施

　 Grafana Four Keysダッシュボード

　 開発⽣産性アンケート(質問の例を抜粋) 7段階で回答してもらい、チームごとに分析する ● 私は自分の仕事にオーナーシップを感じている ● freeeの開発環境に満足している ● 友人にfreeeに入って開発することを勧めたい ● 重要な情報がドキュメントにまとまっている ● コードレビューの質や指摘方法は健全だ ● Meetingの量は適切だ ● フロー(集中)状態を作れている ● 自分のチームには学習しやすい環境がある

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

　 ケイパビリティとは ● 組織の持つ能⼒や要素のこと。 ○ 3つのジャンルで27個ある ● 技術に関するケイパビリティ ● プロセスに関するケイパビリティ ● ⽂化に関するケイパビリティ https://cloud.google.com/architecture/devops?hl=ja

　 ケイパビリティの例 ● 技術に関するケイパビリティ
 ○ コードの保守性
 ○ テストの自動化
 ○ トランクベース開発
 ● プロセスに関するケイパビリティ
 ○ ユーザーからのフィードバック
 ○ 小さいバッチ単位の作業
 ● 文化に関するケイパビリティ
 ○ 創造的な組織文化
 ○ 仕事の満足度 https://cloud.google.com/architecture/devops?hl=ja

　 なぜケイパビリティを改善するのか ● アンケート+計測‧可視化の結果を、 どのケイパビリティを改善するかを特定するために役⽴てる。 ● 改善を進めて、よくなった部分が結果として指標に現れる。 数値にとらわれて、数字⾃体をハックするのではなく 組織にとって重要な能⼒や要素を、継続的に改善することが本質 https://cloud.google.com/architecture/devops?hl=ja

　 開発⽣産性向上のために実践してきたこと

　 開発⽣産性向上のために実践してきたこと ● 定量指標の計測‧可視化 ● 開発⽣産性アンケートの実施 ● トランクベース開発のケイパビリティの推進 ● 開発チームへのEnabling

　 開発⽣産性向上のために実践してきたこと ● 定量指標の計測‧可視化 ● 開発⽣産性アンケートの実施 ● トランクベース開発のケイパビリティの推進 ● 開発チームへのEnabling

　 トランクベース開発のケイパビリティ 最初は普段CI/CD改善をしている Deliveryが得意なケイパビリティを選定 ブランチ戦略を Gitlab-flowからGithub flowに変更 ● 複雑で分かりづらいブランチ戦略 ● stepの多いデプロイフロー ● 緊急を要するhotfix修正作業時に stagingブランチでコンフリクトが が発⽣することも https://docs.gitlab.co.jp/ee/topics/gitlab_flow.html

　 トランクベース開発のケイパビリティ ブランチ戦略をGitlab-flowからGithub flowに！ ● Github flow ○ デフォルトブランチ main branch ○ 短命なfeature branchを切ってmainブランチに変更を⼊れる ○ release tagを打つことをトリガーに⾃動リリースする

　 トランクベース開発のケイパビリティ ● トランクベース開発のメリット ○ GitHub Releaseからリリース毎に含まれているPRを参照しやすい ○ ブランチの構成がシンプルで認知負荷が低い ○ デプロイのステップが減りデプロイが⾼速化 ○ 安全かつ容易なhotfix ■ stagingなどの⻑寿命ブランチではなく、特定タグに対して cherry-pickする形式であるため、間違えたcommitをcherry-pick してもやり直せる

　 トランクベース開発のケイパビリティ デプロイフローの⾃動化×標準化を進めた ● 標準化/横展開の意識 ● 1つの共有リポジトリでデプロイ⽤のGithubActionsWorkflowを管理 ● それぞれプロダクトのリポジトリから呼び出して利⽤する 1. Workflowを実⾏するとmain branchでrelease tagが切られる 2. tagをトリガーに⾃動でstaging環境へのデプロイが実施される 3. staging環境での確認 4. productionデプロイのWorkflowを実⾏

　 トランクベース開発のケイパビリティ 複数のプロダクトに導⼊し、アンケートを実施 認知負荷の⾼いブランチ戦略とデプロイフローがなくなり、 開発者の満⾜度が向上しました！ 5.0 定時リリースフローは安全になった 5.0 定時リリースフローは簡単になった‧わかりやすくなった 4.33 定時リリースフローは⾃動化された  4.83 hotfixは安全になった 5.0 hotfixが簡単になった‧わかりやすくなった 4.83 hotfixの⾃動化が進んだ

　 開発⽣産性向上のために実践してきたこと ● 定量指標の計測‧可視化 ● 開発⽣産性アンケートの実施 ● トランクベース開発のケイパビリティの推進 ● 開発チームへのEnabling

　 開発チームへのEnabling ● いきなり組織全体に適⽤するのではなくスモールスタートを意識 ● 開発チームと⼀緒にボトムアップで改善していく ● アンケートを実施して開発チームの選定 ○ デプロイ改善、CI/CD改善にどのくらい興味や課題感があるか ○ どれくらいリソースを割けるか ● 開発チームにどう意識付けをしたか ○ 認識合わせした上で、必要に応じてコミュニケーションを取る ○ 最初から指標から課題を⾒つけ、改善するサイクルを作るのは 難しいのでこちらで⽤意したケイパビリティを⼀緒に改善する

　 まとめ

　 まとめ ● DORAメトリクスとState of DevOps Reportについて ● Four Keys , SLI/SLO, SPACE フレームワークについて ● ケイパビリティについて ○ 指標やアンケートの結果から、改善すべきケイパビリティを特定する ○ 継続して改善をし、指標やアンケートの結果から 成⻑したところや良くなった部分を確認する。 ● トランクベース開発のケイパビリティの実践例 ● 開発チームへのEnabling

　 今後の展望 ● 6⽉頭に開発⽣産性のアンケートを実施 ● アンケート結果とFourKeysの指標から、 チームが四半期で取り組む課題を⾒つけるためのガイドラインを作成 ● 四半期が終わりに取り組みの成果を定点観測 →次の四半期につなげるサイクルを作る。 ● Deliveryとして進める改善 ○ 引き続きCI/CD周りの改善 ○ ロールバック可能な環境を整備して、障害復旧時間の短縮

　 最後に きっかけは⾃チームの成果の可視化でしたが ● 組織の⽂化を変えていく ● 改善サイクルを作る ● 組織全体のパフォーマンスを最⼤化する 思いがけず組織を巻き込む⼤きな挑戦になりました！ このフレームワークを通じて、freeeの⽣産性あげ、 freeeが成⻑し続けられる⼿助けができたらと思っています！

　 ご清聴ありがとうございました！

No content