Practices_for_improving_freee_development_productivity

20240531 freee技術の日 DAY1
ASOBIBA Stage 18:10~18:30
freeeの開発生産性向上の取り組み_宮澤輝
登壇資料

Transcript

1. freeeの開発⽣産性向上の ために実践してきたこと ~ State of DevOps Report ~ 宮澤 輝 / miyahika 2024年5⽉31⽇
2. 2 宮澤 輝 / miyahika
 freeeに2022年1月入社。
 freeeの開発者の体験が向上する取り組みを 行ってきました。
 好きなtopic:
 Kubernetes/ArgoCD/ARC/Four Keys
 趣味：ポケカ、カラオケ、ポーカー
 SRE / Platform Delivery
3. 　 本日のアジェンダ 01
 05
 06
 02
 07
 03
 04
 Platform Delivery
 チーム紹介
 開発生産性向上の取り組みをは じめたきっかけ
 State of DevOps Report
 とは
 なぜケイパビリティの
 改善に取り組むのか
 開発生産性向上
 実践してきたこと
 トランクベース 開 発
 のケイパビリティ
 まとめ

4. 　 SRE Platform Delivery チーム の紹介
5. 　 SRE Platform Delivery チーム • 主な業務領域 ◦ CI/CDパイプライン ◦ 開発環境の改善 ◦ 開発⽣産性の計測と可視化 • 他社ではいわゆるDevOpsチームが担当することが多い領域です。 • チームの技術スタック ◦ Kubernetes, ArgoCD, GitHub Actions, Terraform, CircleCI, Datadog
6. 　 開発⽣産性向上をはじめたきっかけ • チームでやっているCI/CD改善の成果を視える化したい...！ • 2023年4⽉ CloudNativeDays Tokyo ◦ Four Keys‧ケイパビリティについてチームメンバーが登壇 • 2022と2023のState of DevOps Report ＆ Assessment • LeanとDevOpsの科学 書籍 2017出版 • 他社事例をインプット/イベント登壇や発表資料集め
7. 　 State of DevOps Reportとは
8. 　 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
9. 　 レポートで⾔われている成功や成果とは？ • 組織的なパフォーマンス ◦ 顧客やコミュニティに価値をもたらす • チームのパフォーマンス ◦ チームのイノベーションとコラボレーションを⽀援する • 従業員の健康 ◦ 燃え尽き症候群を減らし、満⾜度 / ⽣産性を⾼める https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report

10. 　 Four Keys + SLI/SLO • 速度 ◦ 変更のリードタイム ◦ デプロイ頻度 • 安定性 ◦ 変更時の障害率 ◦ 失敗したデプロイの復旧時間 • 信頼性 ◦ SLI/SLO DORA の調査で、組織のソフトウェアデリバリーのパフォーマンスから、 組織の全体的なパフォーマンス、チームのパフォーマンス、 従業員の健康状態を予測できることがわかっている。
11. 　 Four Keys + SLI/SLO • ⾼いパフォーマンスに分類されたチームは、速度も安定性も⾼い • 低いパフォーマンスに分類されたチームは、速度も安定性も低い →速度と安定性はトレードオフではなく両⽴できる！ 信頼性（SLI/SLO）の取り組みは組織のパフォーマンスを向上させる SREのプラクティスを実践するチームでは、⽣産性と働きがいが⾼く、 燃え尽き症候群になる可能性も下がることが分かった。
12. 　 DORAメトリクスは組織が⾼いパフォーマンスであることを保証できる？ • Eliteカテゴリに分類された企業 ◦ DORAメトリクスを活⽤してサービスを継続的に改善していて、 競合他社に⽐べて急速に成⻑している。 • どこをどのように改善すべきかを正確に特定するのに役⽴つ • 推移を⾒ていくと、チームの成⻑やどの領域がよりよくなったかがわかる。 • ⼀⽅で批判的な意⾒もある ◦ 批判的な意⾒の中には、間違った使い⽅や部分的な使い⽅をしている場合 が多い • アンチパターンとして ◦ 数字を取り巻く状況ではなく、数字⾃体を⾒てしまう
13. 　 SPACE フレームワーク • Satisfaction and well being(仕事、チーム、⽂化、ツールに満⾜して いるか) ◦ 満⾜度、ツールの充⾜度、⾃チームを⼈に薦めるか • Performance(コードや成果物がどれだけのアウトカムを出したか) ◦ コード品質、顧客満⾜度、機能利⽤率、SLI/SLO、コスト削減 • Activity(タスク完了までの⾏動やアウトプットの数) ◦ ドキュメント、PR、commit、review、ストーリーポイント、 デプロイ頻度、変更障害率、復旧時間、障害対応数 • Communication and collaboration ◦ どうコミュニケーションを取り協⼒し合うか • Efficiency and flow (効率と集中、中断のない時間を作れているか) ◦ MTGの数と時間、レビューの時間、CI/CDなどのトイル、ベロシティ
14. 　 Activityだけを評価していたら燃え尽きてしまう。。 • Activity(タスク完了までの⾏動やアウトプットの数) ◦ ドキュメント、PR、commit、review、ストーリーポイント、 デプロイ頻度、変更障害率、復旧時間、障害対応数 • どれか1つの指標だけを⾒たり、評価するのはアンチパターン • 定量的な指標(A, P)と定性的な指標(S,C,E)を両⽅⾒ていくことが重要 • 定量的な指標の計測可視化 ◦ BigQuery×Grafana • 定性的な指標 ◦ 開発⽣産性アンケートを実施
15. 　 Grafana Four Keysダッシュボード
16. 　 開発⽣産性アンケート(質問の例を抜粋) 7段階で回答してもらい、チームごとに分析する • 私は自分の仕事にオーナーシップを感じている • freeeの開発環境に満足している • 友人にfreeeに入って開発することを勧めたい • 重要な情報がドキュメントにまとまっている • コードレビューの質や指摘方法は健全だ • Meetingの量は適切だ • フロー(集中)状態を作れている • 自分のチームには学習しやすい環境がある
17. 　 なぜケイパビリティを改善するのか
18. 　 ケイパビリティとは • 組織の持つ能⼒や要素のこと。 ◦ 3つのジャンルで27個ある • 技術に関するケイパビリティ • プロセスに関するケイパビリティ • ⽂化に関するケイパビリティ https://cloud.google.com/architecture/devops?hl=ja
19. 　 ケイパビリティの例 • 技術に関するケイパビリティ
 ◦ コードの保守性
 ◦ テストの自動化
 ◦ トランクベース開発
 • プロセスに関するケイパビリティ
 ◦ ユーザーからのフィードバック
 ◦ 小さいバッチ単位の作業
 • 文化に関するケイパビリティ
 ◦ 創造的な組織文化
 ◦ 仕事の満足度 https://cloud.google.com/architecture/devops?hl=ja
20. 　 なぜケイパビリティを改善するのか • アンケート+計測‧可視化の結果を、 どのケイパビリティを改善するかを特定するために役⽴てる。 • 改善を進めて、よくなった部分が結果として指標に現れる。 数値にとらわれて、数字⾃体をハックするのではなく 組織にとって重要な能⼒や要素を、継続的に改善することが本質 https://cloud.google.com/architecture/devops?hl=ja
21. 　 開発⽣産性向上のために実践してきたこと
22. 　 開発⽣産性向上のために実践してきたこと • 定量指標の計測‧可視化 • 開発⽣産性アンケートの実施 • トランクベース開発のケイパビリティの推進 • 開発チームへのEnabling
23. 　 開発⽣産性向上のために実践してきたこと • 定量指標の計測‧可視化 • 開発⽣産性アンケートの実施 • トランクベース開発のケイパビリティの推進 • 開発チームへのEnabling
24. 　 トランクベース開発のケイパビリティ 最初は普段CI/CD改善をしている Deliveryが得意なケイパビリティを選定 ブランチ戦略を Gitlab-flowからGithub flowに変更 • 複雑で分かりづらいブランチ戦略 • stepの多いデプロイフロー • 緊急を要するhotfix修正作業時に stagingブランチでコンフリクトが が発⽣することも https://docs.gitlab.co.jp/ee/topics/gitlab_flow.html
25. 　 トランクベース開発のケイパビリティ ブランチ戦略をGitlab-flowからGithub flowに！ • Github flow ◦ デフォルトブランチ main branch ◦ 短命なfeature branchを切ってmainブランチに変更を⼊れる ◦ release tagを打つことをトリガーに⾃動リリースする
26. 　 トランクベース開発のケイパビリティ • トランクベース開発のメリット ◦ GitHub Releaseからリリース毎に含まれているPRを参照しやすい ◦ ブランチの構成がシンプルで認知負荷が低い ◦ デプロイのステップが減りデプロイが⾼速化 ◦ 安全かつ容易なhotfix ▪ stagingなどの⻑寿命ブランチではなく、特定タグに対して cherry-pickする形式であるため、間違えたcommitをcherry-pick してもやり直せる
27. 　 トランクベース開発のケイパビリティ デプロイフローの⾃動化×標準化を進めた • 標準化/横展開の意識 • 1つの共有リポジトリでデプロイ⽤のGithubActionsWorkflowを管理 • それぞれプロダクトのリポジトリから呼び出して利⽤する 1. Workflowを実⾏するとmain branchでrelease tagが切られる 2. tagをトリガーに⾃動でstaging環境へのデプロイが実施される 3. staging環境での確認 4. productionデプロイのWorkflowを実⾏
28. 　 トランクベース開発のケイパビリティ 複数のプロダクトに導⼊し、アンケートを実施 認知負荷の⾼いブランチ戦略とデプロイフローがなくなり、 開発者の満⾜度が向上しました！ 5.0 定時リリースフローは安全になった 5.0 定時リリースフローは簡単になった‧わかりやすくなった 4.33 定時リリースフローは⾃動化された  4.83 hotfixは安全になった 5.0 hotfixが簡単になった‧わかりやすくなった 4.83 hotfixの⾃動化が進んだ
29. 　 開発⽣産性向上のために実践してきたこと • 定量指標の計測‧可視化 • 開発⽣産性アンケートの実施 • トランクベース開発のケイパビリティの推進 • 開発チームへのEnabling
30. 　 開発チームへのEnabling • いきなり組織全体に適⽤するのではなくスモールスタートを意識 • 開発チームと⼀緒にボトムアップで改善していく • アンケートを実施して開発チームの選定 ◦ デプロイ改善、CI/CD改善にどのくらい興味や課題感があるか ◦ どれくらいリソースを割けるか • 開発チームにどう意識付けをしたか ◦ 認識合わせした上で、必要に応じてコミュニケーションを取る ◦ 最初から指標から課題を⾒つけ、改善するサイクルを作るのは 難しいのでこちらで⽤意したケイパビリティを⼀緒に改善する
31. 　 まとめ
32. 　 まとめ • DORAメトリクスとState of DevOps Reportについて • Four Keys , SLI/SLO, SPACE フレームワークについて • ケイパビリティについて ◦ 指標やアンケートの結果から、改善すべきケイパビリティを特定する ◦ 継続して改善をし、指標やアンケートの結果から 成⻑したところや良くなった部分を確認する。 • トランクベース開発のケイパビリティの実践例 • 開発チームへのEnabling
33. 　 今後の展望 • 6⽉頭に開発⽣産性のアンケートを実施 • アンケート結果とFourKeysの指標から、 チームが四半期で取り組む課題を⾒つけるためのガイドラインを作成 • 四半期が終わりに取り組みの成果を定点観測 →次の四半期につなげるサイクルを作る。 • Deliveryとして進める改善 ◦ 引き続きCI/CD周りの改善 ◦ ロールバック可能な環境を整備して、障害復旧時間の短縮
34. 　 最後に きっかけは⾃チームの成果の可視化でしたが • 組織の⽂化を変えていく • 改善サイクルを作る • 組織全体のパフォーマンスを最⼤化する 思いがけず組織を巻き込む⼤きな挑戦になりました！ このフレームワークを通じて、freeeの⽣産性あげ、 freeeが成⻑し続けられる⼿助けができたらと思っています！
35. 　 ご清聴ありがとうございました！