『ゼクシィNet』大規模エンハンス体制における​ 開発生産性改善アプローチ​

2024/05/23実施の、findy社connpassイベントで発表した、小林と荒川の資料です。

Transcript

1. 1 (C) Recruit Co., Ltd. All rights reserved. 『ゼクシィNet』大規模エンハンス体制における 開発生産性改善アプローチ 2024年5月23日
2. 2 (C) Recruit Co., Ltd. All rights reserved. 自己紹介 株式会社リクルートプロダクト統括本部 販促領域プロダクトディベロップメント２ユニット（マリッジ＆ファミリー・自動車・旅行） マリッジ＆ファミリー・自動車・旅行 エンジニアリング部 部長 小林 洋介 マリッジ＆ファミリー・自動車・旅行 開発ディレクション部 開発ディレクショングループ 荒川 真帆
3. 3 (C) Recruit Co., Ltd. All rights reserved. 本日お話しすること • 『ゼクシィNet』の開発改善施策の一環として開発生産性改善のためのモ ニタリングの装着~改善をおこなっている • 開発生産性モニタリングの考え方/アプローチとその仕組みについて • 一般的な概念を押さえつつも現場での試行錯誤を中心にお話ししたい
4. 4 (C) Recruit Co., Ltd. All rights reserved. Outline 1.『ゼクシィNet』における開発生産性改善の背景 2.開発生産性のモニタリングのアプローチ 3.開発生産性モニタリングと施策の実例
5. 5 『ゼクシィNet』における開発生産性改善の背景
6. 6 (C) Recruit Co., Ltd. All rights reserved. 『ゼクシィNet』と開発体制について ブライダル関連メディアとしては長い歴史 をもつ Netサービスがローンチしてから10年以上 経過 10を超えるJava系サブシステム群 最大時で100人前後の開発者がアサインさ れることもある
7. 7 (C) Recruit Co., Ltd. All rights reserved. 開発生産性改善へ取り組む背景 • 2021年頃の時点で将来的に大幅な機能追加が計画されていた(2024年3月 時点で計画どおり完遂) • 当初は、生産性だけでなく保守運用の品質も含めた技術ガバナンス強化を 目的とした、中長期の開発改善の取り組みとしてスタートした • テーマの一つとして、開発生産性について継続してモニタリング~改善の PDCAが回るようにするということがあった☆本日のテーマ
8. 8 (C) Recruit Co., Ltd. All rights reserved. しかし 当初は思うように進まず。。。 • 保守担当チームが空いた時間で課題出しから各種改善施策をやろうとして いたが、定常作業に追われて時間を割けなかった • 生産性改善（≒開発が遅い）というテーマが明確な指標なしで独り歩きし て一部の開発者のモチベーションを下げてしまっていた
9. 9 (C) Recruit Co., Ltd. All rights reserved. しかし 当初は思うように進まず。。。 • 保守担当チームが空いた時間で課題出しから各種改善施策をやろうとして いたが、定常作業に追われて時間を割けなかった → 保守チームからメンバーを数名切り出す形で専任チーム化 • 生産性改善（≒開発が遅い）というテーマが明確な指標なしで独り歩きし て一部の開発者のモチベーションを下げてしまっていた → 優秀なエンジニアがチームを去ることが最も開発生産性を下げるは ず。改めて目的やモニタリングする指標を明確に策定することにした
10. 10 開発生産性改善のモニタリングのアプローチ
11. 11 (C) Recruit Co., Ltd. All rights reserved. 開発生産性改善のアプローチ 事業価値と開発指標 の結びつきを構造化 して追いかける指標 を決める 1 開発者へアンケート をとり、1で決めた指 標に対して明らかに ブロッカーとなってい る課題をつぶしていく 2 継続した改善のため 開発指標をモニタリン グできる仕組みを構 築 3
12. 12 (C) Recruit Co., Ltd. All rights reserved. 事業価値と開発指標の結びつきを構造化して追いかける指標を決める • 開発生産性 = アウトプット(量ｘ質）/ 投資(時間ｘ人ｘコスト） • 事業価値や特性とアウトプットの相関によって、生産性改善において追い かける指標も異なってくる • 量: 一定時間x人あたりの開発量（スループット的アプローチ）が重要なのか、１案件 をこなすのにかかる時間・コスト(リードタイム的アプローチ）が重要なのか • 質: 障害の定義とデプロイ毎の障害発生率、発生から検知までのリードタイム(LT)、発 生から復旧までのLT
13. 13 (C) Recruit Co., Ltd. All rights reserved. 事業のVMV(Vision/Mission/Values)を起点として関係者全員が把 握できるように開発指標を構造化して追いかける指標を決める イメージ）
14. 14 (C) Recruit Co., Ltd. All rights reserved. 何を測っているのか（現在計測しているもの） 開発プロジェクト毎のLT 障害発生から復旧までの時間 一定期間における障害数 一定期間におけるリリース数 • 大小様々な開発プロジェクトが並走し、それ ぞれにROIが見立てられていることから案件ご とのリードタイム(LT)を指標の一つにおいた • クライアント様の業務にも関わるシステムの ため継続して安全な基盤も求められることか ら、障害発生から復旧までの時間と一定期間 における障害数も同時に指標としておいた。 • 障害が多発した際に案件の並走度も合わせて 分析するためにリリース数もチケットから追 うことにした
15. 15 (C) Recruit Co., Ltd. All rights reserved. 開発リードタイム(LT)は組織のレイヤーによって見る指標が異な るためどのタイミングから測るのかが一つの論点 プロダクトチーム: 要件定義開始からのLT 開発チーム: 開発着手からのLT エンジニア: ブランチ作成からのLT 計測難度:難 計測難度:易 事業全体: 検討開始からのLT
16. 16 (C) Recruit Co., Ltd. All rights reserved. 全工程で企画と開発ディレクションが密に協働するスタイルのた めなるべく広く取りたいが計測の現実性から要件定義開始からの LTを取得することにした プロダクトチーム: 要件定義開始からのLT 開発チーム: 開発着手からのLT エンジニア: ブランチ作成からのLT 計測難度:難 計測難度:易 事業全体: 検討開始からのLT
17. 17 (C) Recruit Co., Ltd. All rights reserved. 開発指標が定まったら開発者へのアンケートも活用しながら明ら かなブロッカーはつぶしていく • 出てきた課題の中で開発指標に対して効果 が期待できるものを優先的に実施 例） • 単体テスト自動化 • ローカル環境仮想化 • アンケート自体は定性的だが目指す指標が 明確であったため優先度の合意形成はス ムーズだった。
18. 18 (C) Recruit Co., Ltd. All rights reserved. 継続した改善のため開発指標をモニタリングできる仕組みを構築 • 開発LT計測は当初は手運用で入力をしている部分が多かったが形骸化し てしまっていた • 生産性可視化のための営みの生産性が良くない問題 • 各チームのタスク管理をJiraへ統一し、CI基盤で取得できるようにした ※詳細を次のセクションでご紹介します
19. 19 開発生産性改善のモニタリングと施策の実例
20. 20 (C) Recruit Co., Ltd. All rights reserved. ローカル開発環境仮想化 • 課題 • ブランチを最新化するとライブラリの依存関係が変わ りローカルで動かなくなる現象が発生。再構築に丸一 日潰すことも。 • 改善内容 • WSL2を使うことで環境丸ごとimport/exportができる • 環境の設定を変更し、動かなくなった場合でも容易に 前の環境に戻せる • 仮想マシン上で動いているので異なる環境を複数作成 できる • 結果 • 環境のインポートは3分でできるようになった • Gitレスポンスも改善 コマンド pull commit push wsl平均÷Win平均×100 Windows経過時間の 30.2％ Windows経過時間の 9.0％ Windows経過時間の 57.5％ 適当なjavaファイル10個に100行ほどコメントを追加して計測
21. 21 (C) Recruit Co., Ltd. All rights reserved. Kibanaでの性能監視による障害検知速度改善 • 課題 • エラーごとにメール受信しており、重要な障害が埋もれていた • 大きな性能問題が発生するまで性能劣化に気付けなかった • 改善内容 • 影響が大きい重要機能、なぜ性能問題を防ぎたいのか、何を検知したいのかを定義 し、Kibanaダッシュボードを作成 • 月に1回性能について議論をする場を設定 • ダッシュボードを確認し、改善案件策定 • 結果 • モニタリングから性能劣化を検知して、障害になる前にSQL改善を実施できた • 開発時も性能影響がないかを確認するマインドが身に付いた
22. 22 (C) Recruit Co., Ltd. All rights reserved. 単体テスト自動化 • 課題 • 単体テストがほぼ手動で実施されており、過去のテストの資産を流用できていな い • 改善内容 • GithubActionsを利用 • Pushごとにテストを駆動 • 全てのテストが完了しないとマージできない • 結果 • PRマージ前の最終チェックのテストを自動化 • テスト実行が失敗するコードがあればすぐ気づくことができる • テストコード実装ボリュームに課題あり、Microsoft Copilotを用いたテストコー ド自動生成にトライ中
23. 23 (C) Recruit Co., Ltd. All rights reserved. 開発LT可視化仕組み • 課題 • 過去、手動でLT取得をやっていたが集計に手間がかかり形骸化していた • 改善内容 • Jiraチケットにて工程ごとにステータスを定義し、ステータス変更日とサブタスクの 完了日付を取得することで、工程完了を自動把握 • Microsoft Power Automateでデータ集計しグラフ表示 • 資料更新をTeams通知 • 結果 • 20-30人のエンハンスチームに適用済 • 週次で通知、リーダーが確認
24. 24 まとめ
25. 25 (C) Recruit Co., Ltd. All rights reserved. Findings • アウトプットの量と質が事業の価値とどう紐づくかを自 分たちで構造化することが関係者間での速やかな合意形 成につながった • 結果としてはDevOps Research and Assessment(DORA) という研究プロジェクトが提唱しているFour Keysと近い 指標を追いかけることになったのは学びだった • ただし、組織のレイヤーによって開発生産性の見ている 範囲が異なる(特にLT)。企画と開発が密に協業している 場合は上流からの計測も必要だった • 継続して開発指標をモニタリングするためにはバージョ ン管理をはじめとしたCI環境の整備が必要だった ※出典: https://dora.dev