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

エンジニアの成長機会はリリースサイクルの計測にあった

44e224d065ca58a456e14c4bc04a1a81?s=47 Kazuaki Shibuya
June 21, 2022
1.9k

 エンジニアの成長機会はリリースサイクルの計測にあった

プロダクトの価値を最速で最大化し続けるために取り組んでいる、SaaSスタートアップのモニタリングLT
https://dinii.connpass.com/event/247726/
で発表させていただいた内容です。

当日のYouTube Liveはこちらです。
https://www.youtube.com/watch?v=G7bCG4y5Udg&t=3932s

---
Tebiki株式会社
https://tebiki.co.jp/
Tech Blog
https://techblog.tebiki.co.jp/

44e224d065ca58a456e14c4bc04a1a81?s=128

Kazuaki Shibuya

June 21, 2022
Tweet

Transcript

  1. エンジニアの成長機会は リリースサイクルの計測にあった Kazuaki Shibuya Tebiki, Inc. 2022/06/21

  2. 自己紹介 渋谷 和暁 2018.3 ~ Tebiki株式会社 CTO & Co-Founder 現在は「tebiki」開発チームの

    DevOps を計測し、 組織設計に反映させる活動に注力しています BtoB のプロダクトづくりにおけるドメインエキスパートの重要性とは https://techblog.tebiki.co.jp/domain-expert-a27d17292a5f
  3. 今日のお話 • 今回はどちらかというとマネジメントレイヤーの方向けです。 • Four Keys についてはほぼ触れません。 • 組織のモニタリングがチームメンバーの成長に結びついた、そんな話です。

  4. エンジニアの開発速度を 上げたいなぁ💭

  5. 開発速度、早いのか遅いのか問題 • 起業したときと比べて、なんとなく遅くなった気がする  ◯ アプリケーションの仕様が複雑になった?  ◯ 求められる品質が上がった?  ◯ メンバーの増加に伴いコミュニケーションコストが増えた? ↓

    遅くなった気がするのは単なる感覚で、むしろ早くなってる説すらある そもそも「開発速度」ってコーディングの速度?リリースの速度?定義は?
  6. 「推測するな、計測せよ」

  7. 何を?

  8. LeanとDevOpsの科学 • 超有名な本 • 品質に対する継続デリバリの効果に   ついて書いているやつ • 求めていたのはこれじゃんね

  9. さっそくリリースサイクルを 測ってみることにした

  10. LinearBの導入 • LinearB というサービスがある • GitHub と連携するだけで、その週の「サイクルタイム」が計測できる  ◯ サイクルタイム=コーディングの時間 /

    レビューが開始されるまでの時間 /            レビュー対応の時間 / デプロイの時間、の合計時間  ◯ Four Keys のうちの「変更リードタイム」をさらに超えた?指標らしい • 8人まで無料
  11. 2021年11月時点のサイクルタイム  基本的にはこのサイクルタイムのみ注目すればよいので、導入自体はとてもかんたん  (画像が残ってなかったが)7日とか掛かってた週もあった…

  12. その結果、早い週と遅い週が あることが分かった

  13. 遅い週の特徴 • 設計やレビューでの手戻りが多い • 少しの仕様変更なのに変更箇所が多い • レビューで同じような議論になる • レビューに時間がかかる

  14. ケイパビリティに問題があるから遅い

  15. ケイパビリティ is 何 • ケイパビリティとは、ソフトウェア デリバリーと組織のパフォーマンスを改善   するための組織が持つべき能力のこと  ◯ DevOps本では24個だったが、今は27個

    • Four Keys はパフォーマンスを測るための指標  ◯ このパフォーマンスを改善するための要素がケイパビリティという関係性
  16. https://cloud.google.com/architecture/devops/capabilities?hl=ja Googleが定義する27のケイパビリティ

  17. 遅い週の特徴をケイパビリティに分類 • 設計やレビューでの手戻りが多い   → 変更承認の効率化 • 少しの仕様変更なのに変更箇所が多い   →

    アーキテクチャ 学習文化 • レビューで同じような議論になる   → ビジュアル管理機能 • レビューに時間がかかる   → トランクベース開発 小さいバッチ単位の作業
  18. つまりこのケイパビリティに問題あり

  19. このケイパビリティの問題を 解決すればよさそう

  20. トランクベース開発/小さいバッチ単位の作業 リリースしたい機能がでかいので、Pull Request もでかい Pull Request が大きいせいで、レビューにも時間がかかっていた ↓ Feature Toggles

    を利用しながら機能を垂直的に作ることで小さくリリースしつ つ、main マージでガンガンリリースする GitOps のデプロイ環境を整備
  21. 変更承認の効率化 Pull Request が出来上がってさあこれからレビューをするぞという段になって 設計の考慮漏れが発覚したりして、そうすると何もかもやり直しに… ↓ Design Docs を書いて、それをコーディング前にモブで必ずチェックしたり、 ペアプロで方向性を合致させることで、レビューより前に承認を獲得

  22. ビジュアル管理機能 前にも同じ議論なかったっけ?みたいな議論がレビューでよく発生していた ↓ rubocop のルールをより合理的なものに変更しつつ強化、さらに reviewdog と 組み合わせて自動化することで議論そのものを排除 ナレッジは GitHub

    Discussions で気軽に共有
  23. アーキテクチャ/学習文化 偽の DRY で書かれているコードや拡張性の低いコードが散見されていた (私が犯人です、すみません…) ↓ SOLID 原則に基づいて機能を疎に作る意識を、ペアプロや Clean Architecture

    本の輪読会で醸成
  24. こうしてケイパビリティの改善に メンバーそれぞれが取り組んだ結果…

  25.  だいたい6ヶ月後には Four Keys でいうところのエリートに  リリースが小さくなって短くなったからではなく、開発チームのアウトカムも上がった 2022年5月時点のサイクルタイム

  26. リリースサイクルを計測することで ケイパビリティの問題が分かり、

  27. ケイパビリティの改善に取り組むことで メンバーも成長できた

  28. まとめ • チームで何の数字を良くするか、の計測可能な指標を持つことが一番重要 • 目指すべき指標をメンバーに与えて試行錯誤をしてもらう • ケイパビリティの問題解決は成長のトリガーになる • 組織としては QA・テストをもっと整備して、ガンガンリリースし改善を回し

      ていく体制にしていきたい
  29. We are hiring! オールポジションで絶賛採用中です! 「Tebiki 採用」でご検索ください🙌

  30. 〒160-0023 東京都新宿区西新宿3-2-4 JRE西新宿テラス6F https://tebiki.co.jp/