高いレベルでQCDを達成できる組織に変化していくための開発生産性向上の取り組み

Transcript

1. 高いレベルで QCDを達成 できる組織に変化していく ための開発生産性向上の 取り組み 2024.09.11 #pharmax_tech_collabo
2. （C）PharmaX Inc. 2024 All Rights Reserve 2 自己紹介 古家大（ふるや まさる） PharmaXエンジニアリングマネージャー 趣味はJ1観戦で鹿島サポーター 妻はベトナム人で息子がトライリンガル
3. （C）PharmaX Inc. 2024 All Rights Reserve 3 取り組んだ時期とプロダクト状況 • 期間：2023年10月〜2024年8月 • YOJOは2019年6月にリリース。4年以上が経過
4. （C）PharmaX Inc. 2024 All Rights Reserve 4 • 継続顧客数は安定推移している状態で今後のグロースの策を検討 取り組んだ時期とプロダクト状況 • 新規事業も模索する中で既存プロダクトであるYOJOをどこまで開発するか 不確実性が高い状況
5. （C）PharmaX Inc. 2024 All Rights Reserve 5 プロダクトの方向性が不確実な中で開発主体でできる こと • 溜まった技術的負債を返済し、新規開発がしやすい状態にすること • 開発が扱えるデータで進捗を得てモーメンタムを生み出すこと • 高いQCDのレベルに自分たちで成長し、プロダクトを巻き込むこと
6. （C）PharmaX Inc. 2024 All Rights Reserve 6 プロダクトの方向性が不確実な中で開発主体でできる こと • 溜まった技術的負債を返済し、新規開発がしやすい状態にすること • 開発が扱えるデータで進捗を得てモーメンタムを生み出すこと • 高いQCDのレベルに自分たちで成長し、プロダクトを巻き込むこと 上記の目的のために開発生産性の向上に取り組むことを決定
7. （C）PharmaX Inc. 2024 All Rights Reserve 7 • 開発生産性について議論しすぎないこと • まず取れるデータから小さく始めること • スプリントレトロスペクティブで毎週数字の改善を追っていくこと 開発生産性向上を始める際に意識したこと
8. （C）PharmaX Inc. 2024 All Rights Reserve 8 • 複雑な話なので意義や指標の話をしすぎると無限に時間がかかる。結局 やってみないと有り難みはわからない • 開発生産性の3つのレベルの話をしてプロダクトの仮説検証を早く回すた めにはまずはデリバリーを改善しようという認識だけ合わせた • 改善しながら、常に次の方針をEMが考えてリード 開発生産性について議論しすぎないこと
9. （C）PharmaX Inc. 2024 All Rights Reserve 9 開発生産性について議論しすぎないこと 開発生産 性 レベル 開発チーム 仕事量の生産性 レベル1 プロダクト開発組織 期待付加価値 の生産 性 レベル2 事業部門全体 実現付加価値 の生産 性 レベル3 計測 指標例 • FourKeys (デプロイ頻度等) • PR数 • テストカバレッジ 開発チームとして 決まった時間で どの量の仕事ができたか？ プロダクト開発組織として 決まった時間で どのくらいの価値が期待され る仕事ができたか？ • リリースした施策のRICE スコア合計 • ベロシティ 事業部門全体として 決まった時間で どのくらいの価値が実現でき たか？ • NSM/KPI • 売上/利益 参考資料: 開発生産性について議論する前に知っておきたいこと : https://qiita.com/hirokidaichi/items/53f0865398829bdebef1
10. （C）PharmaX Inc. 2024 All Rights Reserve 10 • 指標について考えすぎると時間がかかるので、有名なFourKeysからまず 取得してみた • チームの規模的に変更失敗率と平均修復時間には課題を感じていなかっ たので、デリバリーに影響するデプロイ頻度とリードタイムの可視化を行う 手段を探した まず取れるデータから小さく始めること
11. （C）PharmaX Inc. 2024 All Rights Reserve 11 • はてなのテックブログを参考にGithub Action + BigQuery + Looker Studioでデプロイ頻度(d/d/d)・リードタイム・コミット量を可視化 まず取れるデータから小さく始めること 参考: Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう https://developer.hatenastaff.com/entry/2021/03/04/093000
12. （C）PharmaX Inc. 2024 All Rights Reserve 12 • 毎週それぞれのコミット量ランキングを出して1位を祝う スプリントレトロスペクティブで毎週数字の改善を追って いくこと • スプリントは2週間だったが数字を追うことが習慣化されるまでは変則的に レトロスペクティブは毎週実施 • リードタイムが長いのは何でだろう？どうしたら改善できるのか？という話 をEMと有志を中心に進行
13. 13 （C）PharmaX Inc. 2023 All Rights Reserve 開発生産性向上をさらに加速させていく中で 遭遇した課題と解決方法
14. （C）PharmaX Inc. 2024 All Rights Reserve 14 • developへの変更のリードタイムの場合、マージされるまでのどこがボトル ネックなのか？ • デプロイ頻度をどう改善していったらいいのかがわからない • データ品質が低く、保守にもエンジニア工数をとられてしまう • 取れるデータが少なく目的の1つだったチームのモーメンタム作りにはまだ 足りていない 課題1: BigQuery + Looker Studioでは改善したい時 にデータが足りない
15. （C）PharmaX Inc. 2024 All Rights Reserve 15 課題1: BigQuery + Looker Studioでは改善したい時 にデータが足りない 解決方法: Findy Team+を導入
16. （C）PharmaX Inc. 2024 All Rights Reserve 16 課題1: BigQuery + Looker Studioでは改善したい時 にデータが足りない Findy Team+の良いところ • CSが開発生産性について詳しく目標設定の相談ができる • 他社比較機能が嬉しい • レビュー分析・サイクルタイム分析でボトルネックの分析ができる
17. （C）PharmaX Inc. 2024 All Rights Reserve 17 課題1: BigQuery + Looker Studioでは改善したい時 にデータが足りない なぜFindy Team+にしたのか • Findy Awardの受賞というマイルストーンが置きやすかった • 採用広報という理由で稟議を通しやすかった • 他社比較機能があることで自分たちの立ち位置を把握しやすく 自己管理が促進される
18. （C）PharmaX Inc. 2024 All Rights Reserve 18 課題2: コードレビューが遅い • 当時のコードレビューの平均時間は20h以上
19. （C）PharmaX Inc. 2024 All Rights Reserve 19 課題2: コードレビューが遅い 解決方法①: • Findy Team+の他社の水準と比較し、チーム目標でリードタイム23h以内・ レビュー時間3h以内・平均PR行数500行以内を設定
20. （C）PharmaX Inc. 2024 All Rights Reserve 20 課題2: コードレビューが遅い 解決方法②: • コードレビューの目的/優先度を明文化
21. （C）PharmaX Inc. 2024 All Rights Reserve 21 課題2: コードレビューが遅い 解決方法③: • レビューのフロー・マージのルールも明確化
22. （C）PharmaX Inc. 2024 All Rights Reserve 22 課題3: アウトプットが少ない • 当時のPR数は1日1件/人に満たない程度
23. （C）PharmaX Inc. 2024 All Rights Reserve 23 課題3: アウトプットが少ない 解決方法①: • Findy Team+の他社の水準と比較し、 チーム目標で1日2件以上/人を設定。 • 1on1でFindy Team+のデータを元にアウトプットのサポート （一番多かったのは改善系のネタが自分で出せないこと）
24. （C）PharmaX Inc. 2024 All Rights Reserve 24 課題3: アウトプットが少ない 解決方法②: • ソフトウェアアーキテクチャ特性分析して技術課題を棚卸し （テスト容易性を上げるために皆でテストを書く方針に）
25. （C）PharmaX Inc. 2024 All Rights Reserve 25 課題4: テストコードがなく手動テストが大変。 大規模アップデートができない • フロントエンドはカバレッジ 0% • バックエンドもカバレッジは20%（コード行数6万行） • 大きめの機能リリース時は手動で受け入れテストを行わないと安心できな い状況
26. （C）PharmaX Inc. 2024 All Rights Reserve 26 解決方法①: • テストカバレッジをCIで可視化 • PR数と合わせてテストカバレッジを目標値に設定（80%以上） ◦ Logic・Repository層を中心に追加 ◦ 毎週2%のようなマイルストーンを置いて全員で書く 課題4: テストコードがなく手動テストが大変。 大規模アップデートができない
27. （C）PharmaX Inc. 2024 All Rights Reserve 27 解決方法②: • フロントエンドはNext.js13へのリアーキテクトPJを実施。既存仕様のリファク タリングと合わせてテストを追加 • プロダクトのロードマップにリファクタリングを入れてもらう 課題4: テストコードがなく手動テストが大変。 大規模アップデートができない
28. 28 （C）PharmaX Inc. 2023 All Rights Reserve 取り組んでみての成果
29. （C）PharmaX Inc. 2024 All Rights Reserve 29 当初の目的 • 溜まった技術的負債を返済し、新規開発がしやすい状態にすること • 開発が扱えるデータで進捗を得てモーメンタムを生み出すこと • 高いQCDのレベルに自分たちで成長し、プロダクトを巻き込むこと
30. （C）PharmaX Inc. 2024 All Rights Reserve 30 （成果: ◯）溜まった技術的負債を返済し、新規開発がしやす い状態にすること • テストカバレッジ ほぼ0%→80%以上（フロント・バックエンド両方） • Rubocopのlintエラーも対応完了 • 主なデッドコードは駆逐完了 • 膨張していたテーブルを半分に削減（280テーブル→140テーブル） • React18系/Next.js13系にアップデートし、リアーキテクチャ完了 • Ruby3系/Rails7系にアップグレード完了 • 過去の負債になっていたGraphQL層を削除完了 • 他の技術課題についてもバックログリファインメントで全体を棚卸し可視化でき ている状態
31. （C）PharmaX Inc. 2024 All Rights Reserve 31 （成果: ◯）開発が扱えるデータで進捗を得てモーメンタムを 生み出すこと • リードタイム1/10改善の成果で社内表彰
32. （C）PharmaX Inc. 2024 All Rights Reserve 32 （成果: ◯）開発が扱えるデータで進捗を得てモーメンタムを 生み出すこと • Findyさんにも事例紹介でインタビュー依頼を受けた
33. （C）PharmaX Inc. 2024 All Rights Reserve 33 （成果: ◯）開発が扱えるデータで進捗を得てモーメンタムを 生み出すこと • 開発生産性スコア 49→63に上昇（Findy Award入賞ギリギリライン...!）
34. （C）PharmaX Inc. 2024 All Rights Reserve 34 （成果: ◯）開発が扱えるデータで進捗を得てモーメンタムを 生み出すこと • PR数 1人1件/日 → 1人3件/日（3倍に向上）
35. （C）PharmaX Inc. 2024 All Rights Reserve 35 （成果: ◯）開発が扱えるデータで進捗を得てモーメンタムを 生み出すこと • 改善してきた指標はチームのSPACEサーベイでも高評価
36. （C）PharmaX Inc. 2024 All Rights Reserve 36 （成果: △） 高いQCDのレベルに自分たちで成長し、プロダク トを巻き込むこと • レベル1の仕事量の生産性ではQCDは自己管理できるようになってきた • Delivery ◦ デリバリー頻度（d/d/d）: 0.2以上 ◦ 変更のリードタイム: 20-30h ▪ レビュー速度: 1-2h以内 ◦ PR数: 2-3件/日・テストカバレッジ: 80%以上 • Quality ◦ 障害発生率5%以下 • Cost ◦ インフラ費用の把握
37. （C）PharmaX Inc. 2024 All Rights Reserve 37 （成果: △） 高いQCDのレベルに自分たちで成長し、プロダク トを巻き込むこと 開発生産 性 レベル 開発チーム 仕事量の生産性 レベル1 プロダクト開発組織 期待付加価値 の生産 性 レベル2 事業部門全体 実現付加価値 の生産 性 レベル3 計測 指標例 • FourKeys (デプロイ頻度等) • PR数 • テストカバレッジ 開発チームとして 決まった時間で どの量の仕事ができたか？ プロダクト開発組織として 決まった時間で どのくらいの価値が期待され る仕事ができたか？ • リリースした施策のRICE スコア合計 • ベロシティ 事業部門全体として 決まった時間で どのくらいの価値が実現でき たか？ • NSM/KPI • 売上/利益 参考資料: 開発生産性について議論する前に知っておきたいこと : https://qiita.com/hirokidaichi/items/53f0865398829bdebef1 次はココ
38. （C）PharmaX Inc. 2024 All Rights Reserve 38 （成果: △） 高いQCDのレベルに自分たちで成長し、プロダク トを巻き込むこと プロダクト開発組織のミッションは 期待付加価値を最大化し NSM/KPIにインパクトを与える こと 期待付加価値の質 期待付加価値の量 質と量はトレードオフではない。両方を高めて総量を最大化 ×
39. （C）PharmaX Inc. 2024 All Rights Reserve 39 （成果: △） 高いQCDのレベルに自分たちで成長し、プロダク トを巻き込むこと PdM力（質） 期待付加価値の実現検証 &アッ プデート回数（量） × エンジニアリング力（質） 期待付加価値のある機能の リリース数（量） × 期待付加価値の質 （ディスカバリー） 期待付加価値の量 （デリバリー） × PdM力とエンジニアリング力のさらなる底上げが必要
40. （C）PharmaX Inc. 2024 All Rights Reserve 40 （成果: △） 高いQCDのレベルに自分たちで成長し、プロダク トを巻き込むこと • コストを見つつ、期待付加価値の最大化にコミットしていく • Delivery ◦ 期待付加価値のある機能リリース数 ◦ 期待付加価値の平均工数 ◦ ベロシティ • Quality ◦ リリース済RICEスコア合計 • Cost ◦ チーム人月コスト
41. （C）PharmaX Inc. 2024 All Rights Reserve 41 今回の取り組みの学び • いきなり工数・ベロシティという話をしたくなりがちだが、そこを高めることに近 道はない。学習・プロセスの磨き込みに覚悟をもって向き合っていく先にある （採用ですぐ上がるのは仕事量の生産性だけ） • 実行を進めながら、必要な分の方向性だけ言語化するバランス感が大事 • デリバリー以外にディスカバリーの質・スピードを上げていくこともやっていくと 取れる選択肢の幅は広がる （開発せずにイシューの質を上げられるとデリバリーの価値も上がる）
42. （C）PharmaX Inc. 2024 All Rights Reserve 42 ご清聴ありがとうございました エンジニア募集中！ https://herp.careers/v1/yojo