8ヶ月で リリース速度が約2倍、プルリクエスト件数122%向上した話
皆さんは、開発組織のふりかえりで何を・どのように実施されていますか？各チームごとの開発の振り返りと、施策を実施した結果、改善した話をご紹介します。
AD
誰向けの記事か
- 開発生産性を上げるためにどうしたらいいのかわからない
- Four Keysで開発生産性をモニタリングしていきたい
- Four Keysで計測後どうしたらいいのかわからない
- リリース量を増やす方法がわからない
お伝えしたいこと
- overflowは自社でドッグフーディングしながら開発、改善した内容を共有します
- 定量データとして Four Keysからサイクルタイムへ掘り下げてみることで、開発チーム・個人の課題と施策の解像度が上がること
- 開発生産性の数値は結果であり、プロセスをまず課題発見と改善することが大事であること
- コミュニケーションを見ずに、開発生産性を上げ続けることは難しいこと
Four Keysとサイクルタイムの運用結果
- 期間：2022年10月-2023年6月
- 結果：
- 1プルリクエストリリースまでの速度（約2倍早く ）＋ プルリクエスト件数（122%向上）
- Four Keysはデプロイ頻度が3→3.86、変更のリードタイムは160h→83hで
- 人数：エンジニア3名増加し、エンジニアは14名。PM2名、デザイナー3名
開発生産性の可視化と、自律駆動的なチームを作るための実行
以下は、施策の主要点です。細かくは次のセクションからご紹介します。
- Four Keys でデプロイ頻度や変更のリードタイムを確認する
- サイクルタイム分析機能でチーム・個人で開発状況を確認する
- KPT（Keep（キープ）、Problem（プロブレム）、Try（トライ））で、できてること・課題・やることを整理し、定期的に確認する
- エンジニア、PM、デザイナー間のコミュニケーション分析による個々人の負荷と進行を深掘り
この3点を愚直にやり続け「小さく、早くデリバリー」し、お客様に価値を届けるための安定したプロダクト開発組織が形成されつつあります。
弊社は開発チームが3チームあり、Enabling・Platform Teamなどはない状況です。
各チームの各メンバーが自ら考え、改善することが求められ、個人やチームの自律駆動性を高める振り返りをトライしています。自分達で思考・状況判断し、行動を変化させ続けることができるチームは強いからです。
ここからはやったことの具体的な内容になります。
1.生産性改善の具体的なステップ: Four Keysとサイクルタイム分析の活用法
Four Keysについては以下のリンクを参照してください。
掘り下げる流れは以下の流れです。
1 デプロイ頻度、変更のリードタイム
- Four Keysで計測できる2指標は、あくまで全体把握のためのマクロ数値
- Four Keysの数値を上げるならチーム・個人ごとの深掘りが必須となる
- Four Keysメトリクスだけでしか可視化できない場合は、施策立案・具体化が難しい。
- なんとなくで施策立案し、手を打ち、成果につながらないと数値を見るだけ疲れてしまう。
2 サイクルタイム分析
- チーム・個人でプルリクエスト単位での傾向を把握する
- なぜ発生しているのか、どう改善できるのかをKPTやスプリント定例などで議論する
- 開発タスクが大きすぎる、ビックバンリリースを起こしている、レビューの時間が長くなっている
- なぜ発生しているのか、どう改善できるのかをKPTやスプリント定例などで議論する
- 個人単位での全体、プルリクエスト単位での傾向を把握する
- なぜ発生しているのか、どう改善できるのかをヒアリングし施策に落とす
- 場合によってはValue目標などに追加し、個人で追いかけやすくする
2 定量データを基に、KPTの質を上げる
チーム、個人共に振り返りの質がそれぞれの成長を促進させると考えています。振り返りの質が低いと個々人の成長→チームの成長に繋がりづらくなるからです。
弊社での振り返りの方法をご紹介します。
-
弊社では開発の各チームごとで月次のふりかえりを実施
-
振り返りのフォーマット
- 事業状況・MBO（目標、実績、達成率）
- POが事業KPI、プロダクトKPIの進捗・イシュー共有
- プロダクトロードマップの進捗状況
- POがプロダクト開発の進捗と、それに対してのギャップ、今後について共有
- KPT
- 開発チーム＋セールス・CSがそれぞれの視点でKPT
- Offers MGR を使って、Four Keys・サイクルタイムでの定量データでの振り返り
- テックリードが定量データをもとに振り返り、意識すること、ネクストアクションなどを共有
- 事業状況・MBO（目標、実績、達成率）
notionテンプレートで公開しています、必要であればご利用ください。
ご利用いただく際に、この記事のリンクを貼っていただけるとありがたいです。
3.エンジニア、PM、デザイナーでのコミュニケーション分析による個々人の負荷と進行を深掘り
コミュニケーション分析による、深掘りの流れは以下です。
- メンション、被メンション数値でコミュニケーションによる全体の負荷を把握
- コミュニケーションパスで、常に同じ人が上位に含まれていないか確認する
- 仮にチームの1人が全員とのコミュニケーションパスが上位である場合、その人が異動・退職・チーム移動でいなくなる・休むなどがあると生産性が下がってしまう
- 結果、継続的に高い生産性を維持するチームではなくなってしまう
コミュニケーションが極端に低い人は、誰かからの業務やタスクの振られ待ちのスタンスで仕事をしているか、ホウレンソウが弱いタイプであることが多く、勝手に仕事を進めてしまいずれが発生させたり、生産性が低くなりがちです。
コミュニケーション分析による生産性・チームへの影響の詳細に関しては以下の記事を参考に。
チーム構成とデプロイ頻度の傾向と弊社の今後
傾向
前提、基本的にはフィーチャーチームに所属するエンジニアのレベルによります。
- エンジニア2-3名のチーム：デプロイ頻度は1.5-2のレンジ
- エンジニア 4-5名のチーム：デプロイ頻度は2-4のレンジ
Offers MGR利用企業の傾向は、エンジニア2.3名のチームで構成されることが多く、デプロイ頻度は0.5-4の間となっています。（中には6以上などのチームもあります）
チーム分割のタイミング
1チームにエンジニアが5-10人いてもコミュニケーションパスが増えて業務の連絡や連携が遅くなるのと、個人の自主性が失われるので、1チームエンジニアが2-3名で区切られることが多いです。組織・プロダクトのフェーズによっても様々なので、参考まで。
チームとしての今後
各チームごとの自律駆動性を高める動きの継続
- Four Keys、サイクルタイム、コミュニケーションのデータを可視化し、KPTでエンジニア・デザイナー・PMなど参加者の中での振り返りの質を高め、個々人の成長を促進
小さく作って、価値検証して伸ばしていく意識がデプロイ頻度を向上させる
- とはいえ、新規機能開発でのMVPは要望を満たしているのか顧客提供価値と速度のバランスが大事
- デプロイ頻度・変更のリードタイムだけを評価基準に置かない
ディスカバリーの強化のためのプロダクトマネジメントフローの型化
- 弊社は企業様向けのサービスが含まれるため、セールス・マーケティング・カスタマーサクセスから課題を吸い上げている
- SlackでNotion DBに簡単に意見を吸い上げる仕組みがある
- DBでICEスコア設定、それ以外に価値を最大化するためのトップダウンな機能を混ぜたバックログ
- 優先順位をつけてチケット化、開発進捗を全社に共有し、各々の行動を改善してもらえるように再度強化する
Offers MGRの今後
Offers MGR チームは 月次70-80の大小の新規・機能改善しています。引き続き、エンジニア以外も含むプロダクト開発組織全体のスループットの最大化に向けて機能開発を進めていきます。
弊社チームの進捗をまた共有します、参考になれば幸いです。
🤞告知コーナー
副業・転職なら
開発者、マネージャー向けのイベントを定期的に開催しています。ぜひ、グループへの登録をお願いします。
カミナシのCTO Tori氏、日本のテスト駆動開発の第一人者のt_wada氏の対談！
DMM アーキテクトpospome氏、カウシェ アーキテクト伊藤氏に聞く
Discussion