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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介渋谷和暁 2018.3 ～ Tebiki株式会社 CTO & Co-Founder 現在は「tebiki」開発チームの DevOps を計測し、組織設計に反映させる活動に注力しています BtoB のプロダクトづくりにおけるドメインエキスパートの重要性とは https://techblog.tebiki.co.jp/domain-expert-a27d17292a5f

Slide 3

Slide 3 text

今日のお話 ● 今回はどちらかというとマネジメントレイヤーの方向けです。 ● Four Keys についてはほぼ触れません。 ● 組織のモニタリングがチームメンバーの成長に結びついた、そんな話です。

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

開発速度、早いのか遅いのか問題 ● 起業したときと比べて、なんとなく遅くなった気がする　◯ アプリケーションの仕様が複雑になった？　◯ 求められる品質が上がった？　◯ メンバーの増加に伴いコミュニケーションコストが増えた？ ↓ 遅くなった気がするのは単なる感覚で、むしろ早くなってる説すらあるそもそも「開発速度」ってコーディングの速度？リリースの速度？定義は？

Slide 6

Slide 6 text

「推測するな、計測せよ」

Slide 7

Slide 7 text

何を？

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

LinearBの導入 ● LinearB というサービスがある ● GitHub と連携するだけで、その週の「サイクルタイム」が計測できる　◯ サイクルタイム＝コーディングの時間 / レビューが開始されるまでの時間 / 　　　　　　　　　　レビュー対応の時間 / デプロイの時間、の合計時間　◯ Four Keys のうちの「変更リードタイム」をさらに超えた?指標らしい ● 8人まで無料

Slide 11

Slide 11 text

2021年11月時点のサイクルタイム　基本的にはこのサイクルタイムのみ注目すればよいので、導入自体はとてもかんたん　（画像が残ってなかったが）7日とか掛かってた週もあった…

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

ケイパビリティ is 何 ● ケイパビリティとは、ソフトウェアデリバリーと組織のパフォーマンスを改善　するための組織が持つべき能力のこと　◯ DevOps本では24個だったが、今は27個 ● Four Keys はパフォーマンスを測るための指標　◯ このパフォーマンスを改善するための要素がケイパビリティという関係性

Slide 16

Slide 16 text

https://cloud.google.com/architecture/devops/capabilities?hl=ja Googleが定義する27のケイパビリティ

Slide 17

Slide 17 text

遅い週の特徴をケイパビリティに分類 ● 設計やレビューでの手戻りが多い　 → 変更承認の効率化 ● 少しの仕様変更なのに変更箇所が多い　 → アーキテクチャ学習文化 ● レビューで同じような議論になる　 → ビジュアル管理機能 ● レビューに時間がかかる　 → トランクベース開発小さいバッチ単位の作業

Slide 18

Slide 18 text

つまりこのケイパビリティに問題あり

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

トランクベース開発/小さいバッチ単位の作業リリースしたい機能がでかいので、Pull Request もでかい Pull Request が大きいせいで、レビューにも時間がかかっていた ↓ Feature Toggles を利用しながら機能を垂直的に作ることで小さくリリースしつつ、main マージでガンガンリリースする GitOps のデプロイ環境を整備

Slide 21

Slide 21 text

変更承認の効率化 Pull Request が出来上がってさあこれからレビューをするぞという段になって設計の考慮漏れが発覚したりして、そうすると何もかもやり直しに… ↓ Design Docs を書いて、それをコーディング前にモブで必ずチェックしたり、ペアプロで方向性を合致させることで、レビューより前に承認を獲得

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

アーキテクチャ/学習文化偽の DRY で書かれているコードや拡張性の低いコードが散見されていた（私が犯人です、すみません…） ↓ SOLID 原則に基づいて機能を疎に作る意識を、ペアプロや Clean Architecture 本の輪読会で醸成

Slide 24

Slide 24 text

こうしてケイパビリティの改善にメンバーそれぞれが取り組んだ結果…

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

We are hiring! オールポジションで絶賛採用中です！「Tebiki 採用」でご検索ください🙌

Slide 30

Slide 30 text

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