Tweet
Tweet

Slide 1

Slide 1 text

よりよいビジネスの「実現」のために エンジニアリングを発揮する RECRUIT TECH CONFERENCE 2025 新規事業に挑む開発チームの在り方 佐々木　俊亮 株式会社リクルート プロダクトディベロップメント室

Slide 2

Slide 2 text

本日話すこと 仕組みを作る「技術力」 x チームを動かす「影響力」 エンジニアである以上 仕組みを作る「技術力」は当然重要 その上で PdM や営業などを含めたチーム全員に 仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げることも重要 『ゼクシィ』の新規事業である 『ゼクシィ オンライン招待状』での取り組みを共有 ・事例①: 「MVPフェーズ」において PdM を巻き込む ・事例②: 「拡販フェーズ」において 営業メンバーを巻き込む

Slide 3

Slide 3 text

佐々木 俊亮 社内の部活動「クラフトビール研究会」の副部長 二児の父 2019年にリクルートに新卒入社。 結婚領域を中心にアプリ開発、新規事業開発を担当。 現在は、 『ゼクシィ オンライン招待状』の開発リーダー 『ゼクシィ』アプリの TechLead を担当している。 経歴 / Career 趣味 / Hobbies プロダクトディベロップメント室 販促領域エンジニアリング１ユニット マリッジ＆ファミリー・自動車・旅行領域エンジニアリング部 マリッジ＆ファミリープロダクト開発グループ

Slide 4

Slide 4 text

事業・プロダクト紹介

Slide 5

Slide 5 text

ゼクシィ 結婚式場などブライダル情報を発信するサービス 雑誌が有名ですが、Webサイトやアプリで挙式・披露宴会場を検索して ブライダルフェアの予約をすることができる 雑誌が創刊されて30年以上、 Webサイトがリリースされてから25年以上、 アプリがリリースされてから10年以上となっており ブランド認知率 85.1%* を誇る 大規模で歴史のあるサービス * 2024年12月時点 対象: 20歳-34歳の結婚意向あり未婚女性 サンプル数: 2145 (沖縄を除く全国)

Slide 6

Slide 6 text

ゼクシィ オンライン招待状 『ゼクシィ』の新規事業 結婚式の多様化、デジタル化などの変化を受け生まれた オンライン招待状・ご祝儀決済サービス スマホで簡単に招待状を作成・送付できる ゲストが希望に合わせてご祝儀をオンラインで支払える 結婚式の実施準備における カップル・ゲスト・式場それぞれの負担を軽減する 2023年6月 に本格提供開始 日本全国500以上*の式場で利用可能 * 2025年1月時点

Slide 7

Slide 7 text

本日話すこと 仕組みを作る「技術力」 x チームを動かす「影響力」 エンジニアである以上 仕組みを作る「技術力」は当然重要 その上で PdM や営業などを含めたチーム全員に 仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げることも重要 『ゼクシィ』の新規事業である 『ゼクシィ オンライン招待状』での取り組みを共有 ・事例①: 「MVPフェーズ」において PdM を巻き込む ・事例②: 「拡販フェーズ」において 営業メンバーを巻き込む 再掲

Slide 8

Slide 8 text

初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」

Slide 9

Slide 9 text

初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」

Slide 10

Slide 10 text

事例①: MVPフェーズ 常に動くモノを提供し、 作りすぎのムダを減らしたことで 早期リリースを達成

Slide 11

Slide 11 text

当時の状況 『ゼクシィ』は歴史が長く多くの利用者がいることもあり、 「ある程度正解だと考えられる機能」の開発が主流 また、ステークホルダーが多岐に渡ることもあり、 計画を事前にしっかり立てて進めることでリスクを低減させる開発を実施 このような状況のため、「正解がわからない」 新規事業におけるプロダクトづくりの経験を持つメンバーが少なかった 事例①: MVPフェーズ

Slide 12

Slide 12 text

課題 これまでと同様に進めることによる懸念があった ・正解がわからない中で、過剰に機能を作ってしまいリリースが遅れる ・後からの変更耐性が低く、新規にわかった情報を反映することが難しくなる → 新しい仕組みやプロダクトづくりの取り組みが必要 事例①: MVPフェーズ

Slide 13

Slide 13 text

取り組み 継続的に日次で開発環境にデプロイし、 PdM やデザイナーが昨日までに開発したものを今日触ることができる状況に ・正解がわからない中で、過剰に機能を作ってしまいリリースが遅れる → モノを起点に「あと何がリリースするには必要か」というコミュニケーションに ・後からの変更耐性が低く、新規にわかった情報を反映することが難しくなる → 小さな変更は、いつでもフィードバックをし最短で翌日には反映できるように 結果として、 ムダが減り早期のリリースへと繋がった 事例①: MVPフェーズ 一旦作ってみて、みんなで 使ってみて、考えましょう 使ってみたら 利便性を損なうので やっぱりやめよう

Slide 14

Slide 14 text

事例①: MVPフェーズ 取り組み 常に動くモノを提供する ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 15

Slide 15 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 16

Slide 16 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 17

Slide 17 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 18

Slide 18 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 19

Slide 19 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 20

Slide 20 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 開発環境

Slide 21

Slide 21 text

常に動くモノを提供する 事例①: MVPフェーズ 取り組み ECR 実際に触った結果、修正事項をフィードバック 開発者 PdM Deploy (日次) ビルド マージ 使う FB 修正 反映 このサイクルを短期間で回すことで変更に強い開発サイクルを実現 小さな変更であればほとんどが翌日には反映されていた 開発環境

Slide 22

Slide 22 text

トランクベース開発 + 継続的デプロイ トランクベース開発 長寿な feature ブランチを利用せずに main ブランチに小さく高頻度にマージしていく手法 これにより常に main ブランチの HEAD は最新の開発状況を反映 デグレに備えて、開発の初期から高いカバレッジの自動テストを整備 事例①: MVPフェーズ 常に動くモノを提供する main ブランチ feature ブランチ (1日 ~ 2日以内にマージ想定)

Slide 23

Slide 23 text

トランクベース開発 + 継続的デプロイ 継続的デプロイ main ブランチにマージされた全てのコミットに対して docker image を作成し ECR* に push 日次で自動で最新のイメージを開発環境にデプロイ *Elastic Container Registery 事例①: MVPフェーズ 常に動くモノを提供する ECR Deploy (日次) ビルド

Slide 24

Slide 24 text

事例①: MVPフェーズ 常に動くモノを提供し、作りすぎのムダを減らしたことで早期リリースを達成 トランクベース開発 + 継続的デプロイで日次で動くモノを提供することで 事前の過剰な計画を避け、現在動いているモノを起点として進める文化が根付いた 使う FB 修正 反映

Slide 25

Slide 25 text

初回リリース 【事例①】 主に PdM と開発チームで リリースを目指す「MVPフェーズ」 【事例②】 結婚式場で利用開始、 担当する営業メンバーが 参画した「拡販フェーズ」

Slide 26

Slide 26 text

事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、 短期間での47都道府県への導入に貢献

Slide 27

Slide 27 text

当時の状況 拡販を強化していくため、営業メンバーが徐々に増えた 初回のリリースしたあとも引き続き、正解がわからない状況 ただし『ゼクシィ』を運営していることもあり、 営業メンバーがすでに多くの結婚式場と接点が作れていた 営業メンバーを通して結婚式場からの フィードバックや利用状況を得ることが肝 しかし『ゼクシィ』では大規模案件を動かすために 関連組織/協力会社が多くガバナンス観点で 営業と開発の接点は少ない状況だった 事例②: 拡販フェーズ

Slide 28

Slide 28 text

なんとかフィードバックを得るべく 「気軽に要望をあげてもらうチャネル」 を作成してみたものの チャネルがあるだけでは、なかなか発言が増えることはなかった プロダクトとしては、情報を欲している 一方で営業メンバーにとってみれば、大きな利点を感じられない 開発が待ってるだけでは、 期待するスピード感で情報を得ることが難しかった 課題 事例②: 拡販フェーズ

Slide 29

Slide 29 text

発言するインセンティブを強めるべく、 ・プロダクトの仕様についての質問を開発者が即座に回答 → ここで聞けば商談中にも仕様を知ることができ、その場で打ち返しができる ・要望やフィードバックを即座に本番に反映する仕組みを導入 → ここで発言をすればすぐにモノに反映されるという信頼関係構築 結果として、 早期での47都道府県への導入に大きく貢献した 取り組み 事例②: 拡販フェーズ 導入に必要な機能が翌週には リリースされていることも 「持ち帰ります」 が減ってスムーズに

Slide 30

Slide 30 text

リリーストレインを整備して、2回/週 の頻度で継続的に本番環境へのデプロイも実施 強制的なデプロイタイミングを設けることで開発したものを溜めずに即座に本番にもデプロイ 開発が完了していない機能がユーザーの目に触れないように Feature Toggle も整備 リリーストレイン + Feature Toggle 事例②: 拡販フェーズ 取り組み HH:mm リリース準備 HH:mm リリース準備 HH:mm デプロイ実施 HH:mm デプロイ実施 例

Slide 31

Slide 31 text

事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、短期間での47都道府県への導入に貢献 事例①の仕組みに加えて、リリーストレイン + Feature Toggle を導入し即座に本番にも反映 また積極的なコミュニケーションが発生するための地道な活動を通した文化づくり ・プロダクトの仕様についての質問を開発者が即座に回答 → ここで聞けば商談中にも仕様を知ることができ、その場で打ち返しができる ・要望やフィードバックを即座に本番に反映する仕組みを導入 → ここで発言をすればすぐにモノに反映されるという信頼関係構築

Slide 32

Slide 32 text

まとめ

Slide 33

Slide 33 text

事例まとめ 事例①: MVPフェーズ 常に動くモノを提供し、作りすぎのムダを減らしたことで早期リリースを達成 トランクベース開発 + 継続的デプロイで日次で動くモノを提供することで 事前の過剰な計画を避け、現在動いているモノを起点として進める文化が根付いた 事例②: 拡販フェーズ 「要望を挙げればすぐに反映される」文化を作り、短期間での47都道府県への導入に貢献 事例①の仕組みに加えて、リリーストレイン + Feature Toggle を導入し即座に本番にも反映 また積極的なコミュニケーションが発生するための地道な活動を通した文化づくり 仕組みを作る「技術力」とチームを動かす「影響力」を通じて、 恩恵を享受してもらい、ビジネス成果 (アウトカム) に繋げることができた

Slide 34

Slide 34 text

多くの新規事業では、リリース後にいかに ユーザーからのフィードバックを入手していくかが肝となる ただしそうはいっても、営業リソースの都合や 接点がそもそも少なかったりと簡単にできることではない その点、歴史のあるプロダクトの中で行う新規事業では、 すでに多くのユーザーとの接点を作れている強みが明確にある 一方でなかなか文化が根付かないので泥臭い活動が必要になる しかし一度「仕組み」の恩恵をチーム全体で享受してもらえるようになれば、 非常に強い武器となり、より早く、より多くのユーザーに価値を提供していくことができる ゆえにチームを動かす「影響力」も非常に重要であり、 ここがエンジニアとしても面白く、またチャレンジングでもあると考える 大規模プロダクトの中で行う新規事業は面白い

Slide 35

Slide 35 text

よりよいビジネスの「実現」のために エンジニアリングを発揮する 仕組みを作る「技術力」 X チームを動かす「影響力」 チーム全員に仕組みの恩恵を享受してもらい、 ビジネス成果 (アウトカム) に繋げる