可視化からはじめる 開発生産性向上への道のり Qiita Conference 2023 Autumn 2023/10/25

自己紹介
 2
 【略歴】 新卒でSIerとして就職 その後、Web系企業やスタートアップを経て2022年5月に ファインディに参画 ファインディではFindy Team+を開発しつつ、EMとして 開発チームのマネジメントを担当 浜田 直人 (ham) ファインディ株式会社 @hamchance0215

Findy Team+(チームプラス)とは？
 3
 開発生産性の可視化、開発プロセスの伸びしろの発見、継続的な改善をサポート 生産性可視化 生産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化・最適化) 文化づくり・自己組織化 (メンバーの自発的な改善促進、改善を称賛する文化作り) 継続的な生産性向上サイクル データ 連携 Biz Engineer Engineer 開発組織ブランディング (エンジニアは、開発生産性が高い組織で働きたい) Recruit

No content

Qiita いつも使ってます！！
 5


6


目次
 a g e n d a 7
 1. 開発生産性を測る指標 2. Findyが開発生産性を向上させるために重視する指標

開発生産性を測る指標 8


Q 「開発生産性」を測る指標 何が思い浮かびますか？ 9


10
 コードの行数に よる生産性管 理
 目標
 1日500行！
 隣のチームは
 1日800行
 隣のチームと 同じくらいコー ド書けない の？
 本質的ではない 対策でコード量 をかさ増し
 労働時間で
 生産性をカバー


11
 コードの行数に よる生産性管 理
 目標
 1日500行！
 隣のチームは
 1日800行
 隣のチームと 同じくらいコー ド書けない の？
 本質的ではない 対策でコード量 をかさ増し
 労働時間で
 生産性をカバー
 ・開発生産性はコード量では測れない！
 　・同じ1行でも内容によって重みが全然違う
 ・コード量で考えると、本質的な改善ができない
 　・時間でカバー
 　・同じ意味だがコード行数が増える書き方をする
 　　・三項演算子禁止など
 
 ⇨ 生産性を測る指標が間違っている！


開発生産性を測る指標
 12
 ・開発生産性が高い企業のデータを集め分析
 ・これらの開発チームの特徴を定量的に表したもの
 　・Four Keys
 
 ⇨ 開発生産性に相関がある指標
 
 ・開発生産性が高い企業は従業員満足度も高い
 
 ⇨ ボトムアップで改善を進める動機に！！


Findyが開発生産性を向上させるために 重視する指標 13


● Four Keys ● プルリクエストの作成数とマージまでの時間 Findyが開発生産性を向上させるために重視する指標
 14


● Four Keys(2023 State of DevOps Report) https://cloud.google.com/devops/state-of-devops?hl=en 指標(1) Four Keys
 15


● なぜFour Keys？ ○ チームのデリバリーパフォーマンスを可視化したもの ○ 品質を維持し、顧客へ迅速に価値を届けられていることを定量的に確認できる ○ DevOpsのプラクティスを適切に取り入れることで数値が良くなるので、取り組み の良し悪しが定量的に確認できる 指標(1) Four Keys
 16


● 顧客への価値提供が速い ○ Findyの場合、平均でコミットが20時間以内に本番環境に反映 ○ 小さな変更をすぐに本番に反映させることができる Four Keysの数値が良いと...
 17


● 障害が発生しづらく、発生してもすぐに解決できる ○ 1回のパッチサイズが小さいため変更を起因とした障害が発生しづらい ○ 障害が発生してから対応完了までの時間も速い ○ 変更に対する心理的安全性が高まり、価値提供を高める挑戦がしやすい ○ 変更障害率はエリートでも5% ■ 一定数の障害が起きることは問題ではない ■ いかに速く検知して復旧させるか(平均修復時間)が重要 Four Keysの数値が良いと...
 18


● 障害が発生しづらく、発生してもすぐに解決できる ○ 1回のパッチサイズが小さいため変更を起因とした障害が発生しづらい ○ 障害が発生してから対応完了までの時間も速い ■ Findyの場合、対応完了まで平均1.2時間 ○ 変更に対する心理的安全性が高まり、価値提供を高める挑戦がしやすい ○ 変更障害率はエリートでも5% ■ 一定数の障害が起きることは問題ではない ■ いかに速く検知して復旧させるか(平均修復時間)が重要 Four Keysの数値が良いと...
 19
 プロダクトの性質によるが、デプロイは絶対に失敗できないものと考 えると、デプロイに対するハードルが上がり身動きが取りづらくなりま す。
 
 スピードと品質のバランスを取ることでデプロイをカジュアルにしてい くことが大事です！


指標(2) プルリクエストの作成数とマージまでの時間 
 ● なぜ？ ○ Four Keysだけでは不十分 ■ チームのパフォーマンスを測るのには適しているが、個人のパフォーマ ンスは見えづらい ■ 結果指標なので改善の結果が反映されるまでタイムラグがある ○ チームだけではなく個人のアウトプット量とスピードがわかる ○ 改善結果がすぐに反映される ○ パフォーマンスが高いエンジニアのマネがしやすい ■ ロールモデルの方をベンチマークして目標にできる ○ Four Keysのデプロイ頻度やリードタイムの向上につながる 20


プルリクエストの粒度が小さくマージまでの時間が速いと...
 ● 開発がサクサク進む ○ Findyでは、1人あたり1日3プルリクエスト作って、ほぼその日中にマージされる ○ 本番で使われなくても既存に影響がなければガンガン mainブランチへマージ ● レビュー時間が短く、手戻りが少ない ○ Findyでは、プルリクエストあたりの平均行数は 200行前後 ○ レビュアーの負荷も軽減。素早くレビューできる ■ レビュー依頼からレビュー完了まで平均 3時間以内 ○ 細かくレビューするので手戻りが少ない ● コンフリクトがほぼ起きない ○ Findyでは、平均10時間以内にマージされる ○ コンフリクトの解消からの解放！ 21


プルリクエストの粒度が小さくマージまでの時間が速いと...
 ● 開発がサクサク進む ○ Findyでは、1人あたり1日3プルリクエスト作って、ほぼその日中にマージされる ○ 本番で使われなくても既存に影響がなければガンガン mainブランチへマージ ● レビュー時間が短く、手戻りが少ない ○ Findyでは、プルリクエストあたりの平均行数は 200行前後 ○ レビュアーの負荷も軽減。素早くレビューできる ■ レビュー依頼からレビュー完了まで平均 3時間以内 ○ 細かくレビューするので手戻りが少ない ● コンフリクトがほぼ起きない ○ Findyでは、平均10時間以内にマージされる ○ コンフリクトの解消からの解放！ 22
 プルリクエストの粒度が小さく
 マージまでの時間が速い開発はかなり快適です！
 
 半信半疑の方もだまされたと思って
 ぜひ一度お試しください〜！！


23
 続いて... Findyの開発生産性向上への取り組み ~Findyフロントエンドの場合~