よりよいビジネスの「実現」のために エンジニアリングを発揮する

2025/2/19に開催したRecruit Tech Conference 2025の佐々木の資料です

Transcript

1. よりよいビジネスの「実現」のために エンジニアリングを発揮する RECRUIT TECH CONFERENCE 2025 新規事業に挑む開発チームの在り方 佐々木　俊亮 株式会社リクルート プロダクトディベロップメント室
2. 本日話すこと 仕組みを作る「技術力」 x チームを動かす「影響力」 エンジニアである以上 仕組みを作る「技術力」は当然重要 その上で PdM や営業などを含めたチーム全員に 仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げることも重要 『ゼクシィ』の新規事業である 『ゼクシィ オンライン招待状』での取り組みを共有 ・事例①: 「MVPフェーズ」において PdM を巻き込む ・事例②: 「拡販フェーズ」において 営業メンバーを巻き込む
3. 佐々木 俊亮 社内の部活動「クラフトビール研究会」の副部長 二児の父 2019年にリクルートに新卒入社。 結婚領域を中心にアプリ開発、新規事業開発を担当。 現在は、 『ゼクシィ オンライン招待状』の開発リーダー 『ゼクシィ』アプリの TechLead を担当している。 経歴 / Career 趣味 / Hobbies プロダクトディベロップメント室 販促領域エンジニアリング１ユニット マリッジ＆ファミリー・自動車・旅行領域エンジニアリング部 マリッジ＆ファミリープロダクト開発グループ
4. 事業・プロダクト紹介
5. ゼクシィ 結婚式場などブライダル情報を発信するサービス 雑誌が有名ですが、Webサイトやアプリで挙式・披露宴会場を検索して ブライダルフェアの予約をすることができる 雑誌が創刊されて30年以上、 Webサイトがリリースされてから25年以上、 アプリがリリースされてから10年以上となっており ブランド認知率 85.1%* を誇る 大規模で歴史のあるサービス * 2024年12月時点 対象: 20歳-34歳の結婚意向あり未婚女性 サンプル数: 2145 (沖縄を除く全国)
6. ゼクシィ オンライン招待状 『ゼクシィ』の新規事業 結婚式の多様化、デジタル化などの変化を受け生まれた オンライン招待状・ご祝儀決済サービス スマホで簡単に招待状を作成・送付できる ゲストが希望に合わせてご祝儀をオンラインで支払える 結婚式の実施準備における カップル・ゲスト・式場それぞれの負担を軽減する 2023年6月 に本格提供開始 日本全国500以上*の式場で利用可能 * 2025年1月時点
7. 本日話すこと 仕組みを作る「技術力」 x チームを動かす「影響力」 エンジニアである以上 仕組みを作る「技術力」は当然重要 その上で PdM や営業などを含めたチーム全員に 仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げることも重要 『ゼクシィ』の新規事業である 『ゼクシィ オンライン招待状』での取り組みを共有 ・事例①: 「MVPフェーズ」において PdM を巻き込む ・事例②: 「拡販フェーズ」において 営業メンバーを巻き込む 再掲
8. 初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」
9. 初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」
10. 事例①: MVPフェーズ 常に動くモノを提供し、 作りすぎのムダを減らしたことで 早期リリースを達成
11. 当時の状況 『ゼクシィ』は歴史が長く多くの利用者がいることもあり、 「ある程度正解だと考えられる機能」の開発が主流 また、ステークホルダーが多岐に渡ることもあり、 計画を事前にしっかり立てて進めることでリスクを低減させる開発を実施 このような状況のため、「正解がわからない」 新規事業におけるプロダクトづくりの経験を持つメンバーが少なかった 事例①: MVPフェーズ
12. 課題 これまでと同様に進めることによる懸念があった ・正解がわからない中で、過剰に機能を作ってしまいリリースが遅れる ・後からの変更耐性が低く、新規にわかった情報を反映することが難しくなる → 新しい仕組みやプロダクトづくりの取り組みが必要 事例①: MVPフェーズ
13. 取り組み 継続的に日次で開発環境にデプロイし、 PdM やデザイナーが昨日までに開発したものを今日触ることができる状況に ・正解がわからない中で、過剰に機能を作ってしまいリリースが遅れる → モノを起点に「あと何がリリースするには必要か」というコミュニケーションに ・後からの変更耐性が低く、新規にわかった情報を反映することが難しくなる → 小さな変更は、いつでもフィードバックをし最短で翌日には反映できるように 結果として、 ムダが減り早期のリリースへと繋がった 事例①: MVPフェーズ 一旦作ってみて、みんなで 使ってみて、考えましょう 使ってみたら 利便性を損なうので やっぱりやめよう
14. 事例①: MVPフェーズ 取り組み 常に動くモノを提供する ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
15. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
16. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
17. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
18. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
19. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
20. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境
21. 常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 使う FB 修正 反映 このサイクルを短期間で回すことで変更に強い開発サイクルを実現 小さな変更であればほとんどが翌日には反映されていた 開発環境
22. トランクベース開発 + 継続的デプロイ トランクベース開発 長寿な feature ブランチを利用せずに main ブランチに小さく高頻度にマージしていく手法 これにより常に main ブランチの HEAD は最新の開発状況を反映 デグレに備えて、開発の初期から高いカバレッジの自動テストを整備 事例①: MVPフェーズ 常に動くモノを提供する main ブランチ feature ブランチ (1日 ~ 2日以内にマージ想定)
23. トランクベース開発 + 継続的デプロイ 継続的デプロイ main ブランチにマージされた全てのコミットに対して docker image を作成し ECR* に push 日次で自動で最新のイメージを開発環境にデプロイ *Elastic Container Registery 事例①: MVPフェーズ 常に動くモノを提供する ECR Deploy (日次) ビルド
24. 事例①: MVPフェーズ 常に動くモノを提供し、作りすぎのムダを減らしたことで早期リリースを達成 トランクベース開発 + 継続的デプロイで日次で動くモノを提供することで 事前の過剰な計画を避け、現在動いているモノを起点として進める文化が根付いた 使う FB 修正 反映
25. 初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」
26. 事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、 短期間での47都道府県への導入に貢献
27. 当時の状況 拡販を強化していくため、営業メンバーが徐々に増えた 初回のリリースしたあとも引き続き、正解がわからない状況 ただし『ゼクシィ』を運営していることもあり、 営業メンバーがすでに多くの結婚式場と接点が作れていた 営業メンバーを通して結婚式場からの フィードバックや利用状況を得ることが肝 しかし『ゼクシィ』では大規模案件を動かすために 関連組織/協力会社が多くガバナンス観点で 営業と開発の接点は少ない状況だった 事例②: 拡販フェーズ
28. なんとかフィードバックを得るべく 「気軽に要望をあげてもらうチャネル」 を作成してみたものの チャネルがあるだけでは、なかなか発言が増えることはなかった プロダクトとしては、情報を欲している 一方で営業メンバーにとってみれば、大きな利点を感じられない 開発が待ってるだけでは、 期待するスピード感で情報を得ることが難しかった 課題 事例②: 拡販フェーズ
29. 発言するインセンティブを強めるべく、 ・プロダクトの仕様についての質問を開発者が即座に回答 → ここで聞けば商談中にも仕様を知ることができ、その場で打ち返しができる ・要望やフィードバックを即座に本番に反映する仕組みを導入 → ここで発言をすればすぐにモノに反映されるという信頼関係構築 結果として、 早期での47都道府県への導入に大きく貢献した 取り組み 事例②: 拡販フェーズ 導入に必要な機能が翌週には リリースされていることも 「持ち帰ります」 が減ってスムーズに
30. リリーストレインを整備して、2回/週 の頻度で継続的に本番環境へのデプロイも実施 強制的なデプロイタイミングを設けることで開発したものを溜めずに即座に本番にもデプロイ 開発が完了していない機能がユーザーの目に触れないように Feature Toggle も整備 リリーストレイン + Feature Toggle 事例②: 拡販フェーズ 取り組み HH:mm リリース準備 HH:mm リリース準備 HH:mm デプロイ実施 HH:mm デプロイ実施 例
31. 事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、短期間での47都道府県への導入に貢献 事例①の仕組みに加えて、リリーストレイン + Feature Toggle を導入し即座に本番にも反映 また積極的なコミュニケーションが発生するための地道な活動を通した文化づくり ・プロダクトの仕様についての質問を開発者が即座に回答 → ここで聞けば商談中にも仕様を知ることができ、その場で打ち返しができる ・要望やフィードバックを即座に本番に反映する仕組みを導入 → ここで発言をすればすぐにモノに反映されるという信頼関係構築
32. まとめ
33. 事例まとめ 事例①: MVPフェーズ 常に動くモノを提供し、作りすぎのムダを減らしたことで早期リリースを達成 トランクベース開発 + 継続的デプロイで日次で動くモノを提供することで 事前の過剰な計画を避け、現在動いているモノを起点として進める文化が根付いた 事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、短期間での47都道府県への導入に貢献 事例①の仕組みに加えて、リリーストレイン + Feature Toggle を導入し即座に本番にも反映 また積極的なコミュニケーションが発生するための地道な活動を通した文化づくり 仕組みを作る「技術力」とチームを動かす「影響力」を通じて、 恩恵を享受してもらい、ビジネス成果 (アウトカム) に繋げることができた
34. 多くの新規事業では、リリース後にいかに ユーザーからのフィードバックを入手していくかが肝となる ただしそうはいっても、営業リソースの都合や 接点がそもそも少なかったりと簡単にできることではない その点、歴史のあるプロダクトの中で行う新規事業では、 すでに多くのユーザーとの接点を作れている強みが明確にある 一方でなかなか文化が根付かないので泥臭い活動が必要になる しかし一度「仕組み」の恩恵をチーム全体で享受してもらえるようになれば、 非常に強い武器となり、より早く、より多くのユーザーに価値を提供していくことができる ゆえにチームを動かす「影響力」も非常に重要であり、 ここがエンジニアとしても面白く、またチャレンジングでもあると考える 大規模プロダクトの中で行う新規事業は面白い
35. よりよいビジネスの「実現」のために エンジニアリングを発揮する 仕組みを作る「技術力」 X チームを動かす「影響力」 チーム全員に仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げる