開発生産性に取り組んできた2年間を振り返る

この記事は [セゾンテクノロジー Advent Calendar 2024](https://qiita.com/advent-calendar/2024/saison-tech) 20日目の記事です。


開発生産性に取り組んでちょうど2年が経つので、これまでの取り組みとそこから得た知見や学びを振り返ります。

## 当初のモチベーション
「イケてる開発組織でありたい」というのが漠然としたモチベーションでした。
何をもって「イケてる開発組織」とするのかというと、以下の状態をイメージしていました。
- 組織やチームのパフォーマンスが客観的に見て優れている
- 組織やチームが多角的な視点で健全性が保たれている

## 試行錯誤
上記のような状態をどのように計測、評価すればよいか試行錯誤していたのが、ちょうど2年前くらいです。
ベロシティや工数、稼働率の相関をみて分析したりと、試行錯誤していましたが「客観的」という指標にはなりません。他社事例や文献を読み漁っていてたどり着いたのが、FourKeys という指標でした。

## FourKeys
DevOps Research and Assessment（DORA）チームが提唱したソフトウェアデリバリーにおけるパフォーマンスを計測するためのフレームワークです。「LeanとDevOpsの科学」でも言及されている指標で、「デリバリースピード」と「安定性 (品質)」の2軸からデリバリーパフォーマンスを評価できる DevOps 指標です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286805/ad3b6274-faff-308d-4d17-7be4bb066484.png)

## 可視化
指標が定まったところで、これらの指標をどのようなデータから可視化していくかという次の壁にぶち当たります。
バックログ管理を JIRA で行っていたので、JIRA のステータス遷移の時間から「Change lead time」がとれないかとか、「Deployment frequency」はそのままリリース頻度とし、CI のエラー率から「Change fail percentage」をとる、「Failed deployment recovery time」は CI で発生したエラーの復旧までにかかる時間で計測する、などと定義して可視化しようとしていました。
ですが、JIRA のステータス遷移はマニュアル操作になっていたため、ステータスを変え忘れたりなど正確な計測が難しく、また CI のエラー率や復旧時間はデリバリーパフォーマンスとして適切な計測対象なのかと悶々としていました。

## Findy Team+
そんな中 Findy Team+ というサービスに出会います。
Github や JIRA のデータを連携し、FourKeys メトリクスの可視化をしてくれます。
それだけではなく、Github や JIRA でのアクティビティをもとにチーム全体やメンバー単位でのコンディション分析も可能です。
最近では、ふりかえりやチームサーベイを支援する機能もリリースされ、パフォーマンスだけでなく健全性の可視化や分析もできるようになりました。

https://findy-team.io/

## 具体的になにをしたか
まずは、Findy Team+ の導入により、可視化された自分たちのパフォーマンスを分析します。
最初に可視化された状態は Performance level「Medium」という結果でした。
ソフトウェアデリバリーにおけるパフォーマンスに影響するケイパビリティはこれだけあります。
それぞれのケイパビリティにおけるプラクティスは公開されているので、アセスメント形式にしボトルネックを突き止めていきました。
少しずつ改善していき、週次で Findy Team+ の測定結果を分析、ふりかえり、改善するというサイクルを回して行きました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286805/2b41207b-4cc5-c28d-ab77-1fa6b5c39ddb.png)

また、パフォーマンス向上の土台にはメンバー間の信頼関係やマインドセット・文化の醸成が不可欠だと思います。
相互理解を深め価値観、期待をしり信頼関係を気づくためにドラッカー風エクササイズを実施したり、デリゲーションポーカーを実施したり、マインドセット・チーム文化の醸成として行動指針やチームとして大切にしたい価値観を定義したりと、改めてチームビルディングをし直しました。
DX Criteria というガイドラインを活用してチームの改善点を見つける方法も効果的でした。

## どうなった?
もともとスキルやナレッジが属人化していたり、特定のメンバーに負荷が偏っていたりという状況だったりと、ボトルネックが至る所にある状態でしたが、現在ではメンバー一人ひとりが主体的にチーム改善の意識を持てるようになり自走できる状態です。

Performance level「Medium」だった状態が「Elite」まで改善し、2年連続で Award 表彰していただきました。

https://award.findy-team.io/2023/

https://award.findy-team.io/2024/

## これから
SPACEフレームワークという、デリバリーパフォーマンス以外にも多角的に開発生産性を捉える指標を導入しています。ひとつの指標に着目してしまうと、どうしても数値データに意識が向いてしまいグッドハートの法則であるように本来の目的を見失ってしまいます。SPACEではそういった課題に対処するためバランスよく指標を選定することを提唱されており、当初のモチベーションに掲げていた多角的な視点から健全性を評価できそうというのが導入の狙いです。

https://queue.acm.org/detail.cfm?id=3454124

現在はこれまでの取り組みを踏まえて、他のプロダクトチームへの展開を進めています。


## まとめ
#### まずは文化、マインドセットの醸成から
なにを始めるにしても言えることですが、取り組みの質を改善し向上させていくための文化やマインドセットは重要です。そのために必要なコミュニケーションやチームビルディングは手を抜かずに実施しましょう。

#### 方法論が先行しないようにする
開発生産性を可視化・向上させていくのは、あくまでその先にある目的のための手段の一つにすぎません。
目的やどんな状態を目指すのかをチームで話し合いましょう。

#### 継続は大変
試行錯誤しながらの継続は大変です。チームへの導入の際は否定意見も当然あります。
継続していくため、チーム内に賛同者 (仲間) を作りましょう。
二人目に踊ってくれる人がいるのと、いないのとでは導入と継続のハードルが全然違います。

#### 簡単に横展開できない
チームが違えば成熟度も違うし感じている課題感や取り組みに対するモチベーションの根源も違いますし、
重要視する指標も異なります。各チーム内に推進者を立て、その人を中心に取り組みを推進してもらい一緒に伴走しましょう。


## 参考文献

https://dora.dev/
https://dora.dev/research/?view=detail