こんにちは！
ツクリンクでアソシエイトエンジニアリングマネージャーをしている八尾(@Tomoki____Y)です。
この記事は開発生産性 Advent Calendar 2024の18日の記事になります。
はじめに
この1年半、チームの開発生産性を高めるべく試行錯誤を重ねてきました。開発生産性の可視化には、DevOps Research and Assessment（DORA）が提唱している「Four Keys」を指標として採用し、その変化を追い続けることで、チームの現状把握と改善に活かしてきました。
本記事では、1年半にわたるFour Keys指標の推移や、行ってきた取り組み、そして今後注力したい方向性についてご紹介します。
現在のFourKeys指標の状況
以下は、1年半前と現在の「1ヶ月半の平均値」で集計したFour Keysメトリクスの変化です。
| 指標 | 1年半前 | 現在 |
|---|---|---|
| デプロイ頻度 | 0.3件/日 | 2.6件/日 |
| 変更のリードタイム | 118.8時間 | 21.6時間 |
| 変更障害率 | 0% | 0% |
| 平均修復時間 | 0時間 | 0時間 |
まず、デプロイ頻度は0.3件/日から2.6件/日へと大幅に向上し、変更のリードタイムは118.8時間から21.6時間へ大幅短縮できました。
変更障害率や平均修復時間は元々問題なかったこともあり、0%・0時間を維持しています。
定性的な面でも、「より開発に集中できる環境」や「安定した開発・デリバリー」が実現しつつあります。1年半前は常に何かに追われ、開発以外の業務やコンテキストスイッチが多発して、腰を据えてコードに向き合うことが難しい状況でした。しかし、現在では開発チームが一定のリズムでデプロイできるようになり、必要なタスクに集中して取り組めるようになっていると感じております。
弊社では、FindyTeam+の導入を行なっているので、そちらの1年半前と現在のキャプチャも下記に添付させていただきます。
1年半前の状態
現在
私自身1年半前の状態というのを見る事はほとんどないので、改めて見てみると改善されてるなと感じます。
ちょうど1年前に下記の記事で、弊社で取り組んで半年の時の記事がありますので良ければご覧ください。
効果的だった取り組み
1. Pull Request粒度の分割
以前は機能単位で1つのPull Request（PR）を作成していましたが、現在では「意図単位」で粒度を小さくするよう心がけています。
この変更によって、1PRあたりの変更行数が減少し、レビュアーの負担が軽減されました。結果的に、レビュー時間の短縮と品質向上を同時に実現しました。
品質向上においては、以下のSmartBear社による調査から「400行以上のコードをレビューすると、レビュー品質が低下する」結果があるようです。
Best Practices for Peer Code Review
また、短いPRであれば、レビュアーが「後でまとめてやろう」と先延ばしにする心理的障壁が下がり、結果的にリードタイム短縮にもつながりました。
2. チームとして目標数値を掲げる
数値改善そのものを目的化するのは避けたいものの、明確な目標値を定めることはチームが一丸となって改善に取り組む原動力となりました。
直近半年では、以下の数値を目標として掲げていました。
- デプロイ頻度: 2件/日
- 変更のリードタイム: 24時間以内
これらの目標があったことで、「どこまで改善すればよいのか」の指標が明確になり、改善活動が活発化しました。ただし、初期段階で「なぜこの目標なのか」を十分に議論・共有することで、目標数値が目的化しないよう注意を払っています。
3. ペアプロ・モブプロの導入
弊社では3人以上のチームで、1つのタスクに対して2人以上のレビューを必須とする体制を取っています。従来は各開発者が個別にタスクを進め、必要に応じてレビューを依頼するスタイルでしたが、これではフロー効率が低下してしまっていると考えておりました。
そこで、開発ラインを減らして1つのタスクに集中的に取り組むため、ペアプロ・モブプロを積極的に導入。
この結果、実装とレビューが同時進行で進むため、コンテキストスイッチが減少し、変更のリードタイム短縮につながっています。また、知識共有が自然発生しやすく、チーム内のスキル平準化にも貢献していくと考えております。
ペアプロ・モブプロの取り組みについては下記記事により詳細を書いておりますので、良ければご覧ください。
これからの取り組み
今後は以下の2点に注力していきたいと考えています。
-
実際にユーザーに届くまでのリードタイムの分析
現在はfeature toggleを活用することで、デプロイとリリースを切り分けています。そのため、今計測しているリードタイムはPR単位のものであり、ユーザーに機能が届くまでのリードタイムではありません。今後はユーザーに価値が届くまでのリードタイムを可視化することで、真に顧客価値を早く届けるための改善策を見出したいと考えています。 -
アウトカムや事業インパクトとの関連性の可視化
Four Keysの指標改善だけでなく、そこから得られるアウトカムや事業インパクトにも焦点を当てていきます。まずはビジネス上の重要な成果指標を定義し、それらとFour Keys指標の関連性を分析することで、開発施策が事業成果へどのような影響を及ぼしているかを明確にします。これにより、より事業価値に直結する改善へとステップアップできると考えています。
最後に
1年半の継続的な改善により、チームは着実に「安定的で生産性の高い状態」へ近づいています。今後は、ユーザーへの価値提供までの流れや事業インパクトとの関連性に目を向け、より高度な改善サイクルを回していきたいと思います。
改善活動は終わりなき旅ですが、一歩ずつでも前へ進め、ビジネスやユーザー価値に直結する組織づくりを目指していきます。
このような取り組みを積極的に行なっていただいているエンジニアの皆さんには感謝です！！
Discussion