開発生産性 Advent Calendar 2022 16日目の記事です。
はじめに
ペイトナー株式会社の脇田（@shimpeee_）です！『ペイトナー ファクタリング』開発チームでエンジニアリングマネージャー兼スクラムマスターとして、開発生産性と日々向き合っています。
「コード品質？レビュー効率？いや、PR数だ！！！」これは、他の誰でもなく、半年前の自分に声を大にして伝えたい叫びです。
「PR作成数をKPIにすると良い」とは知っていましたが、実は勘違いしていました。
コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。
PR数を増やそうとする（つまり、 PRサイズを小さくする）ことで、レビュー効率が改善され、コード品質も高まっていくのです。
本記事は「PRサイズが大きいことが、生産性を落としている全ての元凶だったのか・・・！」と気づくまでの物語となっております。
僕は半年という長い期間を経てこの事実に気づくことができましたが、同じだけの時間を無駄にする人が少しでも減るようにという想いで書きました。
入社当時の状況
入社して開発チームに入ってすぐ肌で感じたのは、「コードレビューが明らかにボトルネックになっている」ことでした。Findy Team+を導入し生産性可視化を行なっていますが、レビューボトルネック問題は、変更リードタイムの長さにも表れていました。
現状把握
レビューがボトルネックになっていることはわかりました。その原因を深掘りしました。
その結果、一次レビュー後、実質チームのテックリードでもあるCTOによる最終コードレビューでの手戻りが多いことがわかりました。
どんな理由で手戻りが発生しているのか
直近数十件分のPRに目を通し、手戻りの理由を分類すると大きく①コード品質に関するもの ②仕様に関するもの の2つに分けられました。
そして、チケット作成〜リリースまでの開発全工程のフェーズごとに要素分解し、レビューのボトルネックになっているコード品質向上・仕様の認識齟齬や考慮不足に効きそうな部分を探しました。
↑実際に分解で使ったロジックツリー
やったこと
停滞タスクの解消
まず、レビュー工程で止まっているタスクが数十件になっていたので、それを全て消化しようと決めました。
停滞しているところにどんどんレビュー待ちのタスクが追加され、リードタイムが伸び、レビューで指摘事項があって修正しようと思ったら時間が経ちすぎて思い出すのに時間がかかり、さらにリードタイムが伸びて停滞し、、、という悪循環を断ち切りたかったためです。
結局、最終的にほぼ全てが消化されるまでに2〜3ヶ月かかりました。それだけ溜まっていたということですね。
コード品質・レビュー効率向上施策
停滞タスクの解消をしたとしても、その後同じやり方をすればあっという間に元の状態に戻ってしまいます。
停滞タスク解消期間に、コード品質・レビュー効率向上の施策として
- ペアプロ・ペアレビューの導入
- 技術書輪読会の開始
- 設計レビュー導入
- スクラムの導入
- レビュワー増員
- レビューフロー改善
など、他にも細かいことを挙げればキリがないほどたくさんの取り組みを行ないました。
結果
「1人あたりPR作成数」と、「変更リードタイム」を評価指標として、半年間の結果は以下のようになりました。
- 一人あたりPR作成数
- 新規タスクストップ期間を経て、やや上昇傾向
- 変更リードタイム
- 短期ではバラツキが非常に大きく、長期スパンでは改善も悪化もしていない
一人あたりPR作成数、上がってはいるけど・・・
一人あたりPR作成数はたしかに上昇傾向にありました。しかし、その要因を分析してみると、気になる点が。。。
Four Keysの一つ、「変更障害率」が大きく悪化していました。直近の大きなリリースで仕様不備が見つかり、何度かリバートしたことが直接の要因です。
その切り戻しのためリバートPRが多く作られた結果、一人あたりPR数が増加していました。つまり、純粋な価値提供をしているPR作成数は伸びていませんでした。。
結果まとめ
まとめると、「1人あたりPR作成数」「変更リードタイム」ともに改善されなかった、という結果でした。
多くの施策を推進してきた立場としては、正直かなりショッキングな事実です。。
意外な結果だった？
開発者体験、上がってますけど？
この事実をメンバーに話すと、意外だという反応をされました。肌感覚として、開発者体験は上がっているとのことでした。
開発者体験上がっていると感じる部分を具体的に聞いてみると、以下が出てきました。
- レビューフローの改善により、レビューのレスポンスが早くなっている
- タスクを適切な粒度で分割することにより、進捗が見えやすくなったり、優先度を付けやすくなった
- スクラムの枠組みの中で振り返りを開始して、1週間単位で改善のサイクルが回るようになり、日々感じる負がすぐに解消されるようになった
- スクラムにおいて「スプリントゴール」を定めるようになり、同じ方向を向いて開発を進められるようになった
- ...
僕自身もスクラムマスターとしてチームに入っているので、肌感としては合っています。
しかし、主要指標には改善が見られませんでした。特に上の二つ、「レビューのレスポンスが早くなっている」「適切にタスク分割できている」は、「1人あたりPR作成数」「変更リードタイム」にもダイレクトに効いても良さそうなはずです。
ちゃんと理由があった
次の打ち手を考えるべく、現状の課題を深掘りします。 各種指標を見ていると、「1PRあたりの変更行数」が半年前と変わっていないことが分かりました。
仮説として考えたのは、「適切なタスク分割ができたチケットはリードタイム短くリリースまで持っていけるが、タスクが大きいまま進めてしまったものがチーム全体の生産性を下げている」です。
実際メンバーにヒヤリングしてみると、「小さいPRが増えてレビューもやりやすくなったが、たまにでかいPRがあってしんどい」という声がありました。
これも実感と合っていて、1000行を超えるようなPRも散見されます。しかし、これらの大半はスクラム導入以前に着手したチケットであり、スクラムのリファインメント内でのチケット分割議論を経由していないものでした。
つまり、スクラム開始以降に着手したチケットは正しく分割され、小さい単位のPRで開発できている、ということになります。これは、間違いなく改善が進んでいるといえます。
このことから、「PRサイズ」こそがリードタイムや開発者体験を決める決定的な因子であると特定しました。
これからやること
何をやる？
スクラム開始以降は適切にタスク分割でき、PRサイズを小さくできていることが分かりました。しかし、実際にデータを見ると、1PRあたりの変更行数は200行くらいあります。
他社の取り組みを見ていると、「1PRの変更行数は100行以下」を目安とする会社が多いようです。さらなる生産性改善のため、まずはこの水準を目指したいと思います！！！
どうやってやる？
チケット分割においてかなり手応えは感じているものの、現状のやり方ではある程度限界も見えているので、他の打ち手も検討しています。
具体的な方法の一つとしては、「フィーチャーフラグを使ったトランクベース開発」に挑戦したいと思っています！
現在、FindyTeam+の運用サポートのため月一ペースでFindyさんとMTGの場を設けていただいています。
そこで聞いたFindyさんの開発手法が「機能として不完全な状態でもガンガンmainにマージして本番にデプロイする」というものでした（Findyさんはトランクベース開発という言葉を使っていたか定かではありませんが、恐らく同義だと解釈しています）。
そして、既存のUXに影響を与える部分はフィーチャーフラグを使って隠していきます。
この開発手法が実現できれば、間違いなくPRサイズを小さくすることができ、PR作成数は増え、リードタイムも短くなっていくでしょう。
ただ、「不完全なコードを本番にマージする」というチームとして経験のない新たな試みです。 リスクを適切にコントロールしながら進めるため、現在は他社事例等参考に運用方法を整備中です。
この開発手法を取る上での難しさとして、「未完成のコードをマージしていくという文化作りが大切」とFindyさんも仰っていました。 エンジニアだけでなく、PMサイドも含めて合意形成必要なところなので、ステークホルダー巻き込みながら推進していきたいと思います。
まとめ
半年間の取り組みは、チーム全体の結果として主要指標に跳ね返ってはきませんでしたが、やったことは確実に効果が出ていることも確認できました！チームとしてのモメンタムを感じます！
効果の出た取り組みは継続しつつ、新たな取り組みも実施することで、さらに生産性高く開発者体験のよいチームを目指してがんばっていきます！！！
余談
本記事では、半年間の試行錯誤の結果を共有しました。このような継続的な改善活動の結果、直近1年ほどの取り組みが評価され「Findy Team+ Award2022」に選出いただきました 🎉
今後も、引き続き生産性の高い開発組織を目指して全社で取り組んでいきます！！！
【ご報告】ペイトナーが「Findy Team+ Award 2022」に選出されました。過去半年間で生産性指標が大きく向上した企業が対象となる「グロース部門」で受賞しました。
— 阪井 優 / 請求書振込サービスなら「ペイトナー」 (@redxyz_) 2022年10月25日
＜受賞企業＞
・株式会社PR TIMES
・ペイトナー株式会社
・株式会社星野リゾート
・株式会社マネーフォワード
・株式会社ワンキャリア pic.twitter.com/5RFc9L3M9z
終わりに
最後まで読んでいただきありがとうございました！！！
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください！！
現在ペイトナーでは、以下ポジション積極採用中です！！！
- VPoE
- リードエンジニア
