Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
『ゼクシィNet』大規模エンハンス体制における 開発生産性改善アプローチ
Search
Recruit
PRO
May 21, 2024
Business
3
750
『ゼクシィNet』大規模エンハンス体制における 開発生産性改善アプローチ
2024/05/23実施の、findy社connpassイベントで発表した、小林と荒川の資料です。
Recruit
PRO
May 21, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
100
RECRUIT TECH CONFERENCE 2025 プレイベント【関田】
recruitengineers
PRO
0
21
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
85
RECRUIT TECH CONFERENCE 2025 プレイベント【岡本】
recruitengineers
PRO
2
28
RECRUIT TECH CONFERENCE 2025 プレイベント【恒川】
recruitengineers
PRO
0
23
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
950
Asset Centric な データ変換パイプラインの攻略法
recruitengineers
PRO
1
140
Kotlin Multiplatformのポテンシャル
recruitengineers
PRO
2
210
デザイン初め新年会2025_川端_PdM Days2025
recruitengineers
PRO
1
69
Other Decks in Business
See All in Business
株式会社10X - Company Deck
10xinc
88
1.4M
アッテル会社紹介資料/culture deck
attelu
10
14k
営業職/新卒向け会社紹介資料(テックファーム株式会社)
techfirm
1
380
【株式会社Amazia】26年度新卒採用資料
amazia200910
0
160
unnameカルチャーブック 2025.01.31 update
unnameinc
6
16k
最近読んでいる本-読書シェア会vol.1
akatsuki174
2
140
コミュニティ運営の悩みはコミュニティオブコミュニティで解決しよう
yuhkoito
1
160
総合研究院の研究活動と企業等との連携促進|Science Tokyo(東京科学大学)
sciencetokyo
PRO
0
1k
ACES_エンジニア向け採用資料.pdf
aces
0
230
Mercari-Fact-book_jp
mercari_inc
3
150k
i3DESIGN_Culture_Book / We-are-hiring
i3design
0
34k
サスメド株式会社 Culture Deck
susmed
0
39k
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Agile that works and the tools we love
rasmusluckow
328
21k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Bash Introduction
62gerente
610
210k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Scaling GitHub
holman
459
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Transcript
1 (C) Recruit Co., Ltd. All rights reserved. 『ゼクシィNet』大規模エンハンス体制における 開発生産性改善アプローチ
2024年5月23日
2 (C) Recruit Co., Ltd. All rights reserved. 自己紹介 株式会社リクルートプロダクト統括本部
販促領域プロダクトディベロップメント2ユニット(マリッジ&ファミリー・自動車・旅行) マリッジ&ファミリー・自動車・旅行 エンジニアリング部 部長 小林 洋介 マリッジ&ファミリー・自動車・旅行 開発ディレクション部 開発ディレクショングループ 荒川 真帆
3 (C) Recruit Co., Ltd. All rights reserved. 本日お話しすること •
『ゼクシィNet』の開発改善施策の一環として開発生産性改善のためのモ ニタリングの装着~改善をおこなっている • 開発生産性モニタリングの考え方/アプローチとその仕組みについて • 一般的な概念を押さえつつも現場での試行錯誤を中心にお話ししたい
4 (C) Recruit Co., Ltd. All rights reserved. Outline 1.『ゼクシィNet』における開発生産性改善の背景
2.開発生産性のモニタリングのアプローチ 3.開発生産性モニタリングと施策の実例
5 『ゼクシィNet』における開発生産性改善の背景
6 (C) Recruit Co., Ltd. All rights reserved. 『ゼクシィNet』と開発体制について ブライダル関連メディアとしては長い歴史
をもつ Netサービスがローンチしてから10年以上 経過 10を超えるJava系サブシステム群 最大時で100人前後の開発者がアサインさ れることもある
7 (C) Recruit Co., Ltd. All rights reserved. 開発生産性改善へ取り組む背景 •
2021年頃の時点で将来的に大幅な機能追加が計画されていた(2024年3月 時点で計画どおり完遂) • 当初は、生産性だけでなく保守運用の品質も含めた技術ガバナンス強化を 目的とした、中長期の開発改善の取り組みとしてスタートした • テーマの一つとして、開発生産性について継続してモニタリング~改善の PDCAが回るようにするということがあった☆本日のテーマ
8 (C) Recruit Co., Ltd. All rights reserved. しかし 当初は思うように進まず。。。
• 保守担当チームが空いた時間で課題出しから各種改善施策をやろうとして いたが、定常作業に追われて時間を割けなかった • 生産性改善(≒開発が遅い)というテーマが明確な指標なしで独り歩きし て一部の開発者のモチベーションを下げてしまっていた
9 (C) Recruit Co., Ltd. All rights reserved. しかし 当初は思うように進まず。。。
• 保守担当チームが空いた時間で課題出しから各種改善施策をやろうとして いたが、定常作業に追われて時間を割けなかった → 保守チームからメンバーを数名切り出す形で専任チーム化 • 生産性改善(≒開発が遅い)というテーマが明確な指標なしで独り歩きし て一部の開発者のモチベーションを下げてしまっていた → 優秀なエンジニアがチームを去ることが最も開発生産性を下げるは ず。改めて目的やモニタリングする指標を明確に策定することにした
10 開発生産性改善のモニタリングのアプローチ
11 (C) Recruit Co., Ltd. All rights reserved. 開発生産性改善のアプローチ 事業価値と開発指標
の結びつきを構造化 して追いかける指標 を決める 1 開発者へアンケート をとり、1で決めた指 標に対して明らかに ブロッカーとなってい る課題をつぶしていく 2 継続した改善のため 開発指標をモニタリン グできる仕組みを構 築 3
12 (C) Recruit Co., Ltd. All rights reserved. 事業価値と開発指標の結びつきを構造化して追いかける指標を決める •
開発生産性 = アウトプット(量x質)/ 投資(時間x人xコスト) • 事業価値や特性とアウトプットの相関によって、生産性改善において追い かける指標も異なってくる • 量: 一定時間x人あたりの開発量(スループット的アプローチ)が重要なのか、1案件 をこなすのにかかる時間・コスト(リードタイム的アプローチ)が重要なのか • 質: 障害の定義とデプロイ毎の障害発生率、発生から検知までのリードタイム(LT)、発 生から復旧までのLT
13 (C) Recruit Co., Ltd. All rights reserved. 事業のVMV(Vision/Mission/Values)を起点として関係者全員が把 握できるように開発指標を構造化して追いかける指標を決める
イメージ)
14 (C) Recruit Co., Ltd. All rights reserved. 何を測っているのか(現在計測しているもの) 開発プロジェクト毎のLT
障害発生から復旧までの時間 一定期間における障害数 一定期間におけるリリース数 • 大小様々な開発プロジェクトが並走し、それ ぞれにROIが見立てられていることから案件ご とのリードタイム(LT)を指標の一つにおいた • クライアント様の業務にも関わるシステムの ため継続して安全な基盤も求められることか ら、障害発生から復旧までの時間と一定期間 における障害数も同時に指標としておいた。 • 障害が多発した際に案件の並走度も合わせて 分析するためにリリース数もチケットから追 うことにした
15 (C) Recruit Co., Ltd. All rights reserved. 開発リードタイム(LT)は組織のレイヤーによって見る指標が異な るためどのタイミングから測るのかが一つの論点
プロダクトチーム: 要件定義開始からのLT 開発チーム: 開発着手からのLT エンジニア: ブランチ作成からのLT 計測難度:難 計測難度:易 事業全体: 検討開始からのLT
16 (C) Recruit Co., Ltd. All rights reserved. 全工程で企画と開発ディレクションが密に協働するスタイルのた めなるべく広く取りたいが計測の現実性から要件定義開始からの
LTを取得することにした プロダクトチーム: 要件定義開始からのLT 開発チーム: 開発着手からのLT エンジニア: ブランチ作成からのLT 計測難度:難 計測難度:易 事業全体: 検討開始からのLT
17 (C) Recruit Co., Ltd. All rights reserved. 開発指標が定まったら開発者へのアンケートも活用しながら明ら かなブロッカーはつぶしていく
• 出てきた課題の中で開発指標に対して効果 が期待できるものを優先的に実施 例) • 単体テスト自動化 • ローカル環境仮想化 • アンケート自体は定性的だが目指す指標が 明確であったため優先度の合意形成はス ムーズだった。
18 (C) Recruit Co., Ltd. All rights reserved. 継続した改善のため開発指標をモニタリングできる仕組みを構築 •
開発LT計測は当初は手運用で入力をしている部分が多かったが形骸化し てしまっていた • 生産性可視化のための営みの生産性が良くない問題 • 各チームのタスク管理をJiraへ統一し、CI基盤で取得できるようにした ※詳細を次のセクションでご紹介します
19 開発生産性改善のモニタリングと施策の実例
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 (C) Recruit Co., Ltd. All rights reserved. Kibanaでの性能監視による障害検知速度改善 •
課題 • エラーごとにメール受信しており、重要な障害が埋もれていた • 大きな性能問題が発生するまで性能劣化に気付けなかった • 改善内容 • 影響が大きい重要機能、なぜ性能問題を防ぎたいのか、何を検知したいのかを定義 し、Kibanaダッシュボードを作成 • 月に1回性能について議論をする場を設定 • ダッシュボードを確認し、改善案件策定 • 結果 • モニタリングから性能劣化を検知して、障害になる前にSQL改善を実施できた • 開発時も性能影響がないかを確認するマインドが身に付いた
22 (C) Recruit Co., Ltd. All rights reserved. 単体テスト自動化 •
課題 • 単体テストがほぼ手動で実施されており、過去のテストの資産を流用できていな い • 改善内容 • GithubActionsを利用 • Pushごとにテストを駆動 • 全てのテストが完了しないとマージできない • 結果 • PRマージ前の最終チェックのテストを自動化 • テスト実行が失敗するコードがあればすぐ気づくことができる • テストコード実装ボリュームに課題あり、Microsoft Copilotを用いたテストコー ド自動生成にトライ中
23 (C) Recruit Co., Ltd. All rights reserved. 開発LT可視化仕組み •
課題 • 過去、手動でLT取得をやっていたが集計に手間がかかり形骸化していた • 改善内容 • Jiraチケットにて工程ごとにステータスを定義し、ステータス変更日とサブタスクの 完了日付を取得することで、工程完了を自動把握 • Microsoft Power Automateでデータ集計しグラフ表示 • 資料更新をTeams通知 • 結果 • 20-30人のエンハンスチームに適用済 • 週次で通知、リーダーが確認
24 まとめ
25 (C) Recruit Co., Ltd. All rights reserved. Findings •
アウトプットの量と質が事業の価値とどう紐づくかを自 分たちで構造化することが関係者間での速やかな合意形 成につながった • 結果としてはDevOps Research and Assessment(DORA) という研究プロジェクトが提唱しているFour Keysと近い 指標を追いかけることになったのは学びだった • ただし、組織のレイヤーによって開発生産性の見ている 範囲が異なる(特にLT)。企画と開発が密に協業している 場合は上流からの計測も必要だった • 継続して開発指標をモニタリングするためにはバージョ ン管理をはじめとしたCI環境の整備が必要だった ※出典: https://dora.dev