はじめに
こんにちは。会員基盤ブロックの小原田です。弊社では、ZOZOTOWNという大規模なモノリシックシステムをマイクロサービスへリプレイスする取り組みを進めています。私が所属する会員基盤ブロックでは、ZOZOTOWNの会員情報を扱うマイクロサービスの開発と運用を担当しています。
会員基盤ブロックでは、開発生産性の向上を目指し、約半年間にわたり様々な取り組みを行ってきました。本記事では、会員基盤ブロックが開発生産性の向上のために実施してきた施策と、その成果について紹介します。
目次
- はじめに
- 目次
- 開発生産性の向上に関する取り組みの背景
- Findy Team+を用いた調査
- サイクルタイム短縮の取り組み
- ブレスト会の実施
- 品質向上についての取り組み
- 半年間の取り組みの結果
- 取り組みに関するメンバーからのフィードバック
- まとめ
開発生産性の向上に関する取り組みの背景
弊社では、全社的に開発生産性の向上に注力しており、各部署やチームでさまざまな取り組みを進めています。その中でも、私たちの部署は「品質を維持しながら効率を高める」ことを目標に掲げ、各チームに対して開発生産性の可視化とそのサポートツールであるFindy Team+の導入を推進しました。各チームは、Findy Team+が提供する指標をもとに、開発生産性の向上に取り組んでいます。
こうした背景を受けて、会員基盤ブロックでも開発生産性の向上に向けた取り組みを進めることになりました。私たちはFindy Team+の指標や機能を用いて開発生産性の課題を調査するところから始めました。
Findy Team+を用いた調査
会員基盤ブロックでは、チーム状況を正しく把握することを目的とした「ふりかえり会」を週に一度実施しました。このふりかえり会では主に以下のようなFindy Team+が提供する指標を用いて、これまでのチームの動き方がどのような状態であったかを確認していました。
- DevOps分析
- チームサマリ
- サイクルタイム分析
- レビュー分析
会員基盤ブロックが抱える開発生産性の課題
毎週のふりかえり会を通してわかったことは、会員基盤ブロックでは主にPRのレビュープロセスに課題が存在することでした。以下の図は、Findy Team+の「サイクルタイム分析」を用いて可視化した、2024年3月の会員基盤ブロックのサイクルタイムです。
ここでのサイクルタイムとは、ある機能の実装（コミット）を開始してから、PRを作成し、それがマージされるまでにかかる時間を指します。Findy Team+のサイクルタイム分析では、サイクルタイムの平均時間の他に以下の4つの項目を確認できます。
- コミットが開始されてからPRがオープンされるまでの平均時間
- PRがオープンされてから初めてレビューされるまでの平均時間
- PRのレビューが開始されてから初めてアプルーブされるまでの平均時間
- PRがアプルーブされてからマージされるまでの平均時間
会員基盤ブロックでは、サイクルタイムの平均値が212時間と、かなりの時間を要していました。特に、PRがレビューされてからアプルーブされるまでの平均時間は108時間であり、サイクルタイムの大半を占めています。
レビューからアプルーブされるまでの時間が長くなる要因としては様々なものが考えられますが、代表的なものとしてPRの規模が挙げられます。PRの規模が大きいと、PRの確認に時間がかかり結果としてサイクルタイムが伸びます。実際、会員基盤ブロックでもこの傾向がみられました。次の図は2023年12月の変更行数の平均とレビューからアプルーブまでの時間のグラフです。棒グラフが変更行数の平均を表し、赤色の折れ線グラフがレビューからアプルーブまでの平均時間を表します。変更行数が多くなるにつれてレビューからアプルーブまでの時間が伸びていることが分かります。
また、図1や図2をみるとオープンからレビューまでの時間は短いことがわかります。しかし、会員基盤ブロックでは一部のPRのレビューが後回しにされ、長時間レビューされないといった問題も見られました。次の図は2024年3月における、PRがオープンされてからレビューされるまでの時間をヒストグラムで表したものです。横軸はオープンされてからレビューされるまでの時間、縦軸はPRの数を表します。図から分かるように、100時間以上レビューされていないPRが存在します。このような場合、レビューよりも自分の作業を優先することや優先度の低いPRは後回しにし続けるといったレビュー意識に関する問題があると考えられます。
サイクルタイム短縮の取り組み
上記のような課題を解決するために、Findy Team+の「KPTふりかえり」を用いることにしました。以下の図はKPTふりかえりの様子です。私たちはFindy Team+の指標や分析から、それぞれ良かった点や改善したい点などを挙げ、今後行うべき取り組みをチームで出し合いました。
このKPTふりかえりを通して実際に行なってきた取り組みのうち、効果的であった取り組みをいくつか紹介します。
PRの変更行数を100行以下にする
会員基盤ブロックではPRの粒度が大きくなると、レビューからアプルーブまでの平均時間が長くなる傾向にありました。そこでPRのレビューを効率的に行うために、PRの粒度を小さくする取り組みを実施しました。実のところ会員基盤ブロックでも以前からこの取り組みはされており、実際「変更ファイル数が5〜8を超える場合はPRを分けることを検討する」というルールが存在していました。今回、新たに「ファイル数」ではなく「変更行数」に着目し、1PRあたりの変更行数を100行以内に抑えることを目標に設定しました。
図2を見ると取り組み前の変更行数の平均は300行を超えているため、1PRあたり100行という目標は厳しいものと考えられます。実際、会員基盤ブロックではこの目標を完全に達成できていません。しかし、各メンバーはできる限り100行程度の変更行数でPRを出すよう努力しています。例えば、リポジトリを作成する際には、最初にインタフェースのみ定義したPRを作成するなど、スコープを狭める工夫をしています。
この取り組みの結果、以前よりもサイクルタイムが改善しました。取り組み前後に実装したAPIの中から、機能的に類似した4つのAPIを取り出し、サイクルタイムを比較した図を次に示します。棒グラフの各要素はPRごとのサイクルタイムを示しており、その合計、つまり棒グラフ全体が1つのAPIを実装するのにかかったサイクルタイムを表しています。変更行数を抑える取り組みの結果、API実装にかかる合計のサイクルタイムが減少していることが読み取れます。
レビューを優先する仕組みの整備
レビューを優先させるために、チーム全員で積極的にPRを確認する機会を設けました。会員基盤ブロックでは、毎朝、各自のタスクを確認する「朝会」を行っていますが、この朝会で、現在出ているPRやレビューコメントの確認も行うようにしました。さらに、アプルーブされていないPRがある場合には、毎朝Slackで通知される仕組みも整備しました。これらの施策により、PRが長期間レビューされない状況を改善できました。
次の図はこの取り組みを開始した後の2024年6月における、PRがオープンされてからレビューされるまでの時間をヒストグラムで表したものです。図3ではレビューされるまでに100時間を超えるようなPRがありましたが、取り組みを開始してからは最大でも25時間未満でレビューを開始できました。
ブレスト会の実施
会員基盤ブロックではKPTふりかえりを通じてさまざまな取り組みを行ってきましたが、「レビューからアプルーブまでの平均時間」の改善が頭打ちしていました。次の図は2024年5月のサイクルタイム分析です。レビューからアプルーブまでの時間が42.3時間になっており、図1の場合の108.4時間と比べて大きく改善しています。Findy Team+のサイクルタイム分析にはそれぞれの項目に評価が設けられており、上から「Elite」「High」「Medium」「Low」と設定されています。図7のレビューからアプルーブまでの時間の評価をみると、最低評価のLowとなっており、まだ十分に改善できていない状態でした。
そこで、レビューからアプルーブまでの時間が長くなっている原因を特定するために、チームメンバーとブレスト会を実施しました。ブレスト会では、最近出されたPRのうちサイクルタイムが長かったものを参考にし、以下のテーマについて図8のように付箋に意見を書き出し、アイデアを出し合いました。
- レビューに時間がかかる要因は何か？
- 時間がかかる原因はどこにあるのか？
- その対策案は何か？
ブレスト会の結果、レビューに時間がかかる理由として、「なぜそのPRが必要かメンバーの理解度が一致していない」ことや「設計時に見落とした考慮漏れにより、実装時に手戻りが発生する」ことが挙げられました。それに対する対策として、本実装の前に必要最低限の実装（PoC）を行い、その内容について口頭での説明会を実施することにしました。PoC共有会を行うことで、なぜその対応が必要なのかについてチーム内で共有し、実装方針について事前に合意を得ることができるようになりました。
さらに、PoCの取り組みは別の課題も解決しました。会員基盤ブロックではPRの変更行数を少なくする取り組みを行っていました。しかし、これにより「PRが小さすぎて全体の変更内容が把握できない」という問題が発生していました。例えば、ある関数を実装する際にその関数の利用方法が不明瞭なため、レビューが難しくなるといった問題です。PoC共有会では実装したい機能全体をチームに共有するため、細かい単位でのPRであってもその機能の利用方法についてレビュアが理解できるようになり、スムーズなレビューが可能となりました。
品質向上についての取り組み
私たちの部署内では開発生産性の向上に加え、「品質を維持しながら効率を高める」ことも目標として挙げられています。会員基盤ブロックでは以前からCIによるLintチェックなどは導入していますが、追加で次のような品質向上につながる取り組みを行いました。
Goガイドラインの策定
会員基盤ブロックでは、Goを使用してマイクロサービスの開発をしています。ZOZOではバックエンドの開発言語としてJavaまたはGoの利用を推奨していることもあり、会員基盤ブロックが中心となって全社的に利用できるGoガイドラインを策定しています。ガイドラインには、コーディング規約、パフォーマンス向上のためのベストプラクティス、テストの書き方などが含まれています。現在、ガイドラインは策定中ですが、これにより実装速度の向上、レビュー時間の短縮、そして品質の向上が期待できます。
テストカバレッジレポートの導入
品質を維持するための取り組みとして、図9のようなテストカバレッジレポートの導入も行いました。PRを出す際に、mainブランチと比較して全体のテストカバレッジの上昇率を確認できます。また、全体ではなく、変更があったファイル単位でのテストカバレッジの上昇率も確認可能です。テストカバレッジレポートの導入により、テストの不足部分を一目で把握できるようになりました。
半年間の取り組みの結果
会員基盤ブロックでは、約半年間にわたって開発生産性の向上に取り組んできました。ここではその取り組みの結果について紹介します。
まず、サイクルタイムが大きく改善しました。次の図は2月から8月まで約半年間のサイクルタイムを示しています。棒グラフの長さはサイクルタイムの合計平均値を表しています。取り組みを始める前の2024年2月や3月には、サイクルタイムがほとんど100時間を超えており、その中には300時間を超えるケースも見られました。しかし、取り組みを始めた4月以降、サイクルタイムは徐々に短縮され始めました。7月のある週には150時間を超えることもありましたが、それ以外の週はほぼ30〜40時間程度に改善しています。
同様の傾向はレビューサマリでも確認できます。以下の図は2月から8月までのレビューサマリです。7月に若干の上昇が見られますが、オープンからレビューまでの平均時間およびレビューからアプルーブまでの平均時間は減少傾向にあります。また、変更行数の平均も以前は400行を超えるものがありましたが、現在はおおよそ100〜150行程度に収まっています。
取り組みに関するメンバーからのフィードバック
ここまで紹介してきた開発生産性の向上の取り組みについて、メンバーからのフィードバックをアンケートで収集しました。ここでは、その中からいくつかの意見を紹介します。
ポジティブだったこと
レビューを優先する取り組みやPRの粒度を小さくする取り組みが効果的だったという意見が多く寄せられました。具体的には、レビュー速度が向上したことで開発者体験が改善されたという意見がありました。また、PRの粒度を小さくすることでレビューに対する心理的負担が軽減し、レビュー時間も短縮されたと感じる人が多かったようです。さらに、PoCの導入についても好印象を持つ人も多く、事前に実装イメージを共有することで、PRレビューがスムーズに進んだという意見がありました。
また、Findy Team+は様々な指標やKPTふりかえりなどの機能を提供するため、Findy Team+だけで開発生産性を向上できたことが良かったという意見がありました。特にふりかえり会を行うことにポジティブな意見が多数ありました。ふりかえり会を通じて現在の課題を確認し、チーム全体で改善意識が高まったとの声がありました。他にもPRのサイクルタイムが可視化されたことで、時間短縮に向けた取り組みが促進されたという意見もありました。さらに、Findy Team+のスコアの向上がモチベーションとなり、継続的な改善への意欲が向上したという意見もありました。
ネガティブだったこと
一方で、品質への配慮が不十分であったとの懸念もありました。例えば、開発速度や時間短縮にフォーカスするあまり、十分なレビューが行われていないという懸念や、テストカバレッジレポートのような品質を数値化して注視する仕組みが必要であるという意見がありました。また、Findy Team+のスコア向上を意識した動き方に疑問を持つ声もありました。例えば、夕方にPRをオープンするとレビュー担当者がすでに退勤しているため、PRのオープンを翌日に行うといった動き方です。
品質への配慮が不十分であるとの懸念に対しては、策定したGoガイドラインに基づいたLinterを用意するなど、コードの一貫性と品質を向上させる仕組みをさらに整備していく予定です。Findy Team+のスコア向上を意識した動き方に関しては、スコア向上を目指す際にどのような行動が適切かをチームで定義し、実質的な開発生産性の向上につながる取り組みを進めていきたいと考えています。
まとめ
会員基盤ブロックが約半年間にわたって実施してきた開発生産性の向上の取り組みについて紹介しました。これらの取り組みにより、サイクルタイムは平均200時間を超えていたものが、平均41.5時間程度まで短縮されました。また、サイクルタイムの短縮だけではなく、テストカバレッジレポートの仕組みの構築やGoガイドラインの策定など、品質向上に関する取り組みも行えました。
しかし、Findy Team+のスコアはまだ十分に高いとは言えず、改善の余地があります。特に、レビューからアプルーブまでの時間は他チームと比べて依然として時間がかかっています。今後も定期的なふりかえり会やKPTを続け、さらに開発生産性の向上を目指していきたいと考えています。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
