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

プロダクトの価値を最速で最大化し続けるために取り組んでいる、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/

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/