Four Keys 他社事例 01
Categories:
エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～を読んで、自分の言葉に直しました。
背景
開発生産性導入の経緯として、経営層の目線として、組織の急成長に伴い組織の生産性を可視化する必要があった。
Four Keysを導入に伴い、それぞれのチームにおいて、以下の二つのアクションを実施した。
- Pull Request作成数を「リードタイム改善」の指標として設定(ジュニアエンジニアが多いチーム)
- リファインメントとレトロスペクティブの再設計(スクラムを導入しているチーム)
Pull Request作成数を「リードタイム改善」の指標として設定
チームメンバーとテックリードの間でPull Request作成数に差があったことがあり、目標として設定した。
課題
- Pull Requestの作成を増やすためには、単位を小さくする必要がある
- そのためには、タスクの粒度を小さくする必要があり、仕様の深い理解が必要
取り組み
- 1on1において、個人における生産性のふりかえりを行う
- レトロスペクティブにおいて、チームの開発生産性の確認をする
成果
- Pull Requestが三ヶ月で二倍に増加し、一つ一つのPull Requestの負荷が下がりデプロイ頻度が上がった。
- 見積りの精度が上がったことでスケジュールの後ろ倒しが少なくなり、心理的安全性の改善にもつながった。
リファインメントとレトロスペクティブの再設計
「フロントエンド」や「ドメイン知識」の知識が属人化しており、稼働できないメンバーがいる時に開発が完全に止まってしまう課題があった。
リファインメントの見直し
全員が実装イメージをはっきり持てるようにするために、全てのチケットが無くなるまで、1h/一回のmtgを行った。
- 社員、業務内容を問わず、参加できるメンバーは全員が参加
- 全員がストーリーポイントの実装イメージをはっきり盛れるまで議論し、詳細化する
- ストーリーポイント付けの根拠をエンジニア全員が発表し、認識のずれを矯正
プランニングの見直し
二つの方針に従って、プランニングの進め方を整備した。
- チケットを見るだけでメンバー誰もが、「作業内容の共通イメージ」を持てるようにする
- チケットを見るだけでメンバー誰もが、「なぜその作業を行うかの共通認識」を持てるようにする
具体的には、
- ストーリーチケットの作業内容を深掘りし(プランニングに参加していないメンバーでも同等の認識を得られる程度)、具体的な作業内容を細かく書く
- 記載した具体的な作業内容を元に、全員の合意をもとサブチケットをきる
成果として、
- 手が空いているメンバーはどのサブチケットも引き受けられるようになった。
- メンバーの負荷軽減につながり、知識量や技術力不足により進められなかったメンバーの開発生産性向上に繋がった。
レトロスペクティブの見直し
KPTやフリーテーマを行っていたが、開発生産性の指標に焦点を当てたふりかえりへと設計し直した。
話し合うことは、
- 1日あたりのPull Request作成数の変化をスプリント間で比較すること
- スプリント内でマージまでに時間のかかったPull Requestの理由を深掘りすること
Pull Requestの目標やルール設計
一日当たりのPull Request作成数と、Pull Requestの変更行数などを具体的なルールとして設定した
一日一人当たり二つ以上のPull Requestを作成する
- 具体的にどの程度のPull Request作成数があると、開発生産性が高いのか明確にするため。
1Pull Requestあたりの変更行数は100行以内
- Pull Requestの分割の粒度について、思統一が当初から難しかく、実験的に設定したが実際に導入してみるとうまくいった。