Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Practices_for_improving_freee_development_produ...

 Practices_for_improving_freee_development_productivity

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

hikaru-miyazawa

June 04, 2024
Tweet

More Decks by hikaru-miyazawa

Other Decks in Technology

Transcript

  1.   本日のアジェンダ 01
 05
 06
 02
 07
 03
 04
 Platform

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

  2.   SRE Platform Delivery チーム • 主な業務領域 ◦ CI/CDパイプライン ◦

    開発環境の改善 ◦ 開発⽣産性の計測と可視化 • 他社ではいわゆるDevOpsチームが担当することが多い領域です。 • チームの技術スタック ◦ Kubernetes, ArgoCD, GitHub Actions, Terraform, CircleCI, Datadog
  3.   開発⽣産性向上をはじめたきっかけ • チームでやっているCI/CD改善の成果を視える化したい...! • 2023年4⽉ CloudNativeDays Tokyo ◦ Four

    Keys‧ケイパビリティについてチームメンバーが登壇 • 2022と2023のState of DevOps Report & Assessment • LeanとDevOpsの科学 書籍 2017出版 • 他社事例をインプット/イベント登壇や発表資料集め
  4.   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
  5.   レポートで⾔われている成功や成果とは? • 組織的なパフォーマンス ◦ 顧客やコミュニティに価値をもたらす • チームのパフォーマンス ◦ チームのイノベーションとコラボレーションを⽀援する

    • 従業員の健康 ◦ 燃え尽き症候群を減らし、満⾜度 / ⽣産性を⾼める https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report

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

    デプロイ頻度 • 安定性 ◦ 変更時の障害率 ◦ 失敗したデプロイの復旧時間 • 信頼性 ◦ SLI/SLO DORA の調査で、組織のソフトウェアデリバリーのパフォーマンスから、 組織の全体的なパフォーマンス、チームのパフォーマンス、 従業員の健康状態を予測できることがわかっている。
  7.   Four Keys + SLI/SLO • ⾼いパフォーマンスに分類されたチームは、速度も安定性も⾼い • 低いパフォーマンスに分類されたチームは、速度も安定性も低い →速度と安定性はトレードオフではなく両⽴できる!

    信頼性(SLI/SLO)の取り組みは組織のパフォーマンスを向上させる SREのプラクティスを実践するチームでは、⽣産性と働きがいが⾼く、 燃え尽き症候群になる可能性も下がることが分かった。
  8.   DORAメトリクスは組織が⾼いパフォーマンスであることを保証できる? • Eliteカテゴリに分類された企業 ◦ DORAメトリクスを活⽤してサービスを継続的に改善していて、 競合他社に⽐べて急速に成⻑している。 • どこをどのように改善すべきかを正確に特定するのに役⽴つ •

    推移を⾒ていくと、チームの成⻑やどの領域がよりよくなったかがわかる。 • ⼀⽅で批判的な意⾒もある ◦ 批判的な意⾒の中には、間違った使い⽅や部分的な使い⽅をしている場合 が多い • アンチパターンとして ◦ 数字を取り巻く状況ではなく、数字⾃体を⾒てしまう
  9.   SPACE フレームワーク • Satisfaction and well being(仕事、チーム、⽂化、ツールに満⾜して いるか) ◦

    満⾜度、ツールの充⾜度、⾃チームを⼈に薦めるか • Performance(コードや成果物がどれだけのアウトカムを出したか) ◦ コード品質、顧客満⾜度、機能利⽤率、SLI/SLO、コスト削減 • Activity(タスク完了までの⾏動やアウトプットの数) ◦ ドキュメント、PR、commit、review、ストーリーポイント、 デプロイ頻度、変更障害率、復旧時間、障害対応数 • Communication and collaboration ◦ どうコミュニケーションを取り協⼒し合うか • Efficiency and flow (効率と集中、中断のない時間を作れているか) ◦ MTGの数と時間、レビューの時間、CI/CDなどのトイル、ベロシティ
  10.   開発⽣産性アンケート(質問の例を抜粋) 7段階で回答してもらい、チームごとに分析する • 私は自分の仕事にオーナーシップを感じている • freeeの開発環境に満足している • 友人にfreeeに入って開発することを勧めたい •

    重要な情報がドキュメントにまとまっている • コードレビューの質や指摘方法は健全だ • Meetingの量は適切だ • フロー(集中)状態を作れている • 自分のチームには学習しやすい環境がある
  11.   ケイパビリティの例 • 技術に関するケイパビリティ
 ◦ コードの保守性
 ◦ テストの自動化
 ◦ トランクベース開発


    • プロセスに関するケイパビリティ
 ◦ ユーザーからのフィードバック
 ◦ 小さいバッチ単位の作業
 • 文化に関するケイパビリティ
 ◦ 創造的な組織文化
 ◦ 仕事の満足度 https://cloud.google.com/architecture/devops?hl=ja
  12.   トランクベース開発のケイパビリティ 最初は普段CI/CD改善をしている Deliveryが得意なケイパビリティを選定 ブランチ戦略を Gitlab-flowからGithub flowに変更 • 複雑で分かりづらいブランチ戦略 •

    stepの多いデプロイフロー • 緊急を要するhotfix修正作業時に stagingブランチでコンフリクトが が発⽣することも https://docs.gitlab.co.jp/ee/topics/gitlab_flow.html
  13.   トランクベース開発のケイパビリティ ブランチ戦略をGitlab-flowからGithub flowに! • Github flow ◦ デフォルトブランチ main

    branch ◦ 短命なfeature branchを切ってmainブランチに変更を⼊れる ◦ release tagを打つことをトリガーに⾃動リリースする
  14.   トランクベース開発のケイパビリティ • トランクベース開発のメリット ◦ GitHub Releaseからリリース毎に含まれているPRを参照しやすい ◦ ブランチの構成がシンプルで認知負荷が低い ◦

    デプロイのステップが減りデプロイが⾼速化 ◦ 安全かつ容易なhotfix ▪ stagingなどの⻑寿命ブランチではなく、特定タグに対して cherry-pickする形式であるため、間違えたcommitをcherry-pick してもやり直せる
  15.   トランクベース開発のケイパビリティ デプロイフローの⾃動化×標準化を進めた • 標準化/横展開の意識 • 1つの共有リポジトリでデプロイ⽤のGithubActionsWorkflowを管理 • それぞれプロダクトのリポジトリから呼び出して利⽤する 1.

    Workflowを実⾏するとmain branchでrelease tagが切られる 2. tagをトリガーに⾃動でstaging環境へのデプロイが実施される 3. staging環境での確認 4. productionデプロイのWorkflowを実⾏
  16.   開発チームへのEnabling • いきなり組織全体に適⽤するのではなくスモールスタートを意識 • 開発チームと⼀緒にボトムアップで改善していく • アンケートを実施して開発チームの選定 ◦ デプロイ改善、CI/CD改善にどのくらい興味や課題感があるか

    ◦ どれくらいリソースを割けるか • 開発チームにどう意識付けをしたか ◦ 認識合わせした上で、必要に応じてコミュニケーションを取る ◦ 最初から指標から課題を⾒つけ、改善するサイクルを作るのは 難しいのでこちらで⽤意したケイパビリティを⼀緒に改善する
  17.   まとめ • DORAメトリクスとState of DevOps Reportについて • Four Keys

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