Slide 1

Slide 1 text

2017年2⽉15⽇ リクルートテクノロジーズ 宮川 典久 多様なビジネスドメイン、サービスフェーズが 混在する中での組織戦略と技術戦略

Slide 2

Slide 2 text

2 ⾃⼰紹介 宮川 典久 株式会社リクルートテクノロジーズ 執⾏役員 テクノロジープラットフォーム部 プロダクトエンジニアリング部 サイトリライアビリティエンジニアリング部 ■経歴  SIer(2004/04〜2012/10) Ø  アーキテクト兼プログラマー  リクルートテクノロジーズ(2012/11〜) Ø  グループマネージャー(2014/04〜) Ø  シニアマネージャー(2016/04〜) Ø  執⾏役員(2017/04〜) ■主な役割  内製開発、技術部⾨、インフラ部⾨の責任者

Slide 3

Slide 3 text

3 はじめに

Slide 4

Slide 4 text

4 リクルートの概要 リクルートは2012年10⽉に分社化、2014年10⽉に上場しています。 創⽴ 1960年3⽉31⽇  「⼤学新聞広告社」としてスタート グループ 従業員数 45,688 名 連結売上⾼ 18,399億87百万円 連結経常利益 1,317億18百万円 グループ 関連企業数 357社 ⽬指す世界観 果たす役割           (2017年3⽉31⽇時点) (連結対象⼦会社、2017年3⽉31⽇時点) (2016年4⽉1⽇〜2017年3⽉31⽇) (2016年4⽉1⽇〜2017年3⽉31⽇) リクルートについて

Slide 5

Slide 5 text

5 リクルートの主な事業 リボン図モデルを活⽤したビジネスを展開

Slide 6

Slide 6 text

6 リクルートの主な事業 旅⾏ ビジネス⽀援 ⽣活/地域情報 グルメ・美容 ライフスタイル領域 ライフイベント領域 進学 就職 結婚 転職 住宅購⼊ ⾞購⼊ 出産/育児

Slide 7

Slide 7 text

7 リクルートテクノロジーズとは リクルート HD リクルートキャリア リクルート住まいカンパニー リクルートライフスタイル リクルートジョブズ リクルートマーケティングパートナーズ リクルートテクノロジーズ リクルートアドミニストレーション リクルートコミュニケーションズ メディア& ソリューション Staffing HR Technology SBU Company Holding Company and more... (Strategic Business Unit)

Slide 8

Slide 8 text

8 リクルートの開発についての取り組み

Slide 9

Slide 9 text

9 リクルートの⽂化 ボトムアップ

Slide 10

Slide 10 text

10 リクルートの⽂化 こっちが 正解 トップダウン 上司

Slide 11

Slide 11 text

11 リクルートの⽂化 リクルートの場合 こっち じゃね? こっち じゃね? こっち じゃね? こっち じゃね?

Slide 12

Slide 12 text

12 リクルートの⽂化 リクルートの場合 みんな やってみ

Slide 13

Slide 13 text

13 リクルートの⽂化 ボトムアップであるがゆえに、 様々な失敗も有るが、学びを得ることが出来る 失敗 失敗 ⼤成功! なんとか なってる…

Slide 14

Slide 14 text

14 リクルートの⽂化 開発についても様々な取組を各組織で実施 プロジェクトマ ネジメント! オフショア 開発! 完全内製化! Scrum開発!

Slide 15

Slide 15 text

15 ⾏ってきた取組 内製化の推進に向けて、エンジニア採⽤を急激に拡⼤ 新卒採⽤ 中途採⽤ 内製化!!

Slide 16

Slide 16 text

16 ⾏ってきた取組 Scrum開発を全社的に推進 スクラム開発!! •  スクラムマスター研修 やプロダクトオーナー 研修を社内でも実施 •  様々なプロダクトで導 ⼊を推進

Slide 17

Slide 17 text

17 ⾏ってきた取組 ⼤規模プロジェクトの専⾨組織、プロ推を構築、拡⼤ プロジェクト マネジメント!! ⼤規模プロジェクト推進スキームを確⽴

Slide 18

Slide 18 text

18 ⾏ってきた取組 オフショア開発 オフショアだ!! ✕

Slide 19

Slide 19 text

19 振り返り •  エンジニアの⼤幅な増加 •  様々な開発パターンへの対応 上⼿く⾏ったこと 各サイトの進化や、多くの新規サービスの構築など、 リクルートの成⻑に貢献! •  各開発機能としての進化

Slide 20

Slide 20 text

一方で…

Slide 21

Slide 21 text

21 現場で上がる声 案件のリリースを急ぎたいという要望に答えられない… 画⾯のUIを⼀部直 して検証してみた いんだけど? 企画T 開発T 来⽉の案件となるので、 リリースは2ヶ⽉後に なります。 なんでそんなにか かる!?

Slide 22

Slide 22 text

22 現場で上がる声 スクラム開発なのに納期が定められる… 企画T 開発T この案件はどうし てのこの⽇までに リリースする必要 が有る! スクラム開発を⾏って いるので、納期へのコ ミットは難しいです こういう事情がある から、どうしてもお 願い! うーん…

Slide 23

Slide 23 text

23 現場で上がる声 技術的な負債が蓄積しすぎている… 開発T この画⾯直してお いたよ そのコード、実はこの 画⾯でも使っているか らこっち側にも影響出 るよ! え、そんなところ に影響出るの!?

Slide 24

Slide 24 text

24 現場で上がる声 ステークホルダーが多く調整が困難 開発T こんな案件をやろう! ステークホルダーA ステークホルダーB ステークホルダーC いいね、やろう! ここへの影響⼤丈 夫? こっちの案件のほ うが優先順位⾼く ない?

Slide 25

Slide 25 text

25 現場で上がる声 新しい技術を採⽤しにくい基盤 開発T インフラT 今のインフラだと対応 が難しいです… こんな技術を使い たい え、何故!?

Slide 26

Slide 26 text

拡大を広げていく中で うまくいかないことが増えてきた

Slide 27

Slide 27 text

27 このような状況の中で実施してきた 取り組みについて共有ます。 正解は無い中での事例の一つとして 捉えてもらえればと思います。 今⽇の話

Slide 28

Slide 28 text

28 開発が置かれている状況

Slide 29

Slide 29 text

29 ビジネス観点 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー リボン図モデルの中での開発

Slide 30

Slide 30 text

30 ビジネス観点 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー リボン図モデルの中での開発 2種類の開発が求められる •  営業が売るための商品開発 •  カスタマー/クライアントの継続利⽤に向けたサイト改善 CVR 向 上 業 務 効 率 向 上 商品開発 営業

Slide 31

Slide 31 text

31 ビジネス観点 案件によって開発に求められるQCDが⼤きく異なる 案件タイプ 規模(コスト) 納期の重要度 品質の重要度 (例) 営業商品 ⼤ ⾼ ⾼ 詳細ページに動画広 告を⼊れたい サイト 改善 カスタマー ⼩ 低 中 ボタンを四⾓から丸 に変えたい クライアン ト 中 低 ⾼ ⼊⼒バリデーション を追加したい

Slide 32

Slide 32 text

32 ビジネス観点 SoR(System of Record) SoE(System of Engagement) •  記録のためのシステム •  安定性、継続性が重要となるシステム •  リクルートの開発における主な要素 •  広告商品、アクション処理、ポイント •  繋がりのためのシステム •  顧客との繋がりや新たな価値提供が重要なシステム •  リクルートの開発における主な要素 •  UI/UX、Webフロント、スマホアプリ

Slide 33

Slide 33 text

33 ビジネス観点 SoR SoE 性質 求められる開発⼿法 •  安定性重視 •  予測可能 •  リスクを抑える •  速度重視 •  探索型 •  トライアンドエラー •  ウォーターフォール •  事前に要件を確定させるこ とが重要 •  確実な品質を担保してリ リース •  アジャイル •  正しい仕様は存在しない •  迅速なリリースを繰り返す ことが重要

Slide 34

Slide 34 text

34 ビジネス観点 案件によって開発に求められるQCDが⼤きく異なる 案件タイプ 規模(コスト) 納期の重要度 品質の重要度 (例) 営業商品 ⼤ ⾼ ⾼ 詳細ページに動画広 告を⼊れたい サイト 改善 カスタマー ⼩ 低 中 ボタンを四⾓から丸 に変えたい クライアン ト 中 低 ⾼ ⼊⼒バリデーション を追加したい SoE的な開発 SoR的な開発 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している

Slide 35

Slide 35 text

35 ビジネス観点

Slide 36

Slide 36 text

36 ビジネス観点 複数の領域に分かれており、且つ規模が⼤きい 優先順位を付けにくいため、リソースを集中させにくい IR資料:「2018年3⽉期 第2四半期決裁説明資料」より抜粋

Slide 37

Slide 37 text

37 ビジネス観点 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 UXデザイン マーケティング 営業推進 商品企画 ・・・ 開発組織 ⼤規模なプロダクト故に、多くの関連組織が存在する ステークホルダーが多いため仕様調整が難しい

Slide 38

Slide 38 text

38 ビジネス観点 ビジネス領域の拡⼤が進んでいる IR資料:「メディア&ソリューション事業のご紹介」より抜粋

Slide 39

Slide 39 text

39 ビジネス観点 ビジネス領域の拡⼤が進んでいる IR資料:「メディア&ソリューション事業のご紹介」より抜粋 新規プロダクトの⽴ち上げも進んでいる

Slide 40

Slide 40 text

40 アーキテクチャ観点 同様のビジネスモデルに対応するために“型化”されたAP基盤とインフラ 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 構成から外れたアーキテクチャにするのは困難な基盤

Slide 41

Slide 41 text

41 アーキテクチャ観点 “型化”されていく中で開発体制と基盤・インフラ体制の距離が開いてしまった 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 基盤、インフラ体制 開発体制 開発体制 開発体制 依頼 依頼 依頼 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい

Slide 42

Slide 42 text

42 アーキテクチャ観点 通常のプロダクト成⻑フェーズ 導⼊期 成⻑期 成熟期 成熟期 導⼊期 成⻑期 リクルートで求められるプロダクト成⻑ ⾒込みのあるプロダクトに対して⼀気に投資を⾏う

Slide 43

Slide 43 text

43 アーキテクチャ観点 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 カスタマー、クライアント双⽅を繋げるモノリシックなアプリケーション クライアントWeb カスタマーWeb 急激に機能拡張を⾏うので、技術的負債が蓄積される

Slide 44

Slide 44 text

44 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤

Slide 45

Slide 45 text

45 どう取り組んできたか

Slide 46

Slide 46 text

46 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤

Slide 47

Slide 47 text

47 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離

Slide 48

Slide 48 text

48 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE

Slide 49

Slide 49 text

49 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE チケットの粒度を細 かくして納期へ対応 できるように ⽇本側を厚くするこ とでエンハンスにも 対応できるように

Slide 50

Slide 50 text

50 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE Scrum開発で納期をコミット/オフショア開発で⾼速リリースといった 本来チームに向かない開発を⾏う中で元々の強みが失われていった Scrum開発チーム オフショア開発チーム

Slide 51

Slide 51 text

51 現在⽬指している体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム SoR SoR SoE SoE 各開発チームの強みを活かせるようにしていく Scrum開発チーム SoE/SoRに応じて、性質が向く開発チームが担当していくように

Slide 52

Slide 52 text

52 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤

Slide 53

Slide 53 text

53 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE

Slide 54

Slide 54 text

54 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE リーダー リーダー リーダー リーダー

Slide 55

Slide 55 text

55 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE リーダー リーダー リーダー リーダー 開発チームのマネージャーやリーダーが調整業務に奔⾛

Slide 56

Slide 56 text

56 開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー UXデザイン マーケティング データサイエンス 営業推進 ディレクション組織 ディレクション専⾨の組織が最適な形で開発案件をコントロール SoR SoR SoE SoE

Slide 57

Slide 57 text

57 学び •  開発チームは自分たちで何とかするために、苦手 な事を出来るように頑張る •  その中で本来の強みが失われていくため、組織 的なフォローが必要

Slide 58

Slide 58 text

58 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤

Slide 59

Slide 59 text

59 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 開 発 体 制 内製開発チーム中⼼ オフショア・ディレク ション組織中⼼

Slide 60

Slide 60 text

60 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 開 発 体 制 内製開発チーム中⼼ オフショア・ディレク ション組織中⼼ 成⻑フェーズからチー ムに求められることが ⼤きく変わってくる

Slide 61

Slide 61 text

61 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 ⾼速なMVP検証 技術負債の抑制 商品開発 技術負債の解消 商品開発 競合追従 業務効率化 開 発 に 求 め ら れ る 要 素 スケールへの対応 グロースハック グロースハック

Slide 62

Slide 62 text

62 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア 開 発 に 求 め ら れ る 要 素 SoEの要素 SoRの要素 フェーズに応じてチームの構成を変えていく必要がある

Slide 63

Slide 63 text

63 学び •  フェーズの変化に応じて実施しなければならない 案件の特性はどんどん変わっていく •  先の学び通り、チームだけでは急激な変化に対 応することは難しいので、先を見越した体制を 作っていくことが大事

Slide 64

Slide 64 text

64 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤

Slide 65

Slide 65 text

65 これまでの組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum/内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 機能別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D 機能別のチーム 機能別のチーム 機能別のチーム

Slide 66

Slide 66 text

66 バイモーダル戦略に則った体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web SoR 開発T SoR 開発T SoE 開発T ク ラ イ ア ン ト カ ス タ マ ー UXデザイン マーケティング データサイエンス 営業推進 ディレクション組織 技術基盤チーム SRE SoE 開発T

Slide 67

Slide 67 text

67 機能と事業でのマトリックス組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum/内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 技術別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D

Slide 68

Slide 68 text

68 機能と事業でのマトリックス組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum/内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 技術別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D ⼀⽅で流動性の担保は 難しくなっており、 試⾏錯誤中です

Slide 69

Slide 69 text

69 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤 事例を通しての紹介!

Slide 70

Slide 70 text

70 事例紹介

Slide 71

Slide 71 text

71 Airシフトとは

Slide 72

Slide 72 text

72 Airシフトとは 店⻑のシフト調整業務の負荷軽減のためのプロダクト 店⻑ スタッフ チャットを介して コミュニケーション

Slide 73

Slide 73 text

73 Airシフトとは 通常のプロダクト成⻑フェーズ 創業期 成⻑期 成熟期 成熟期 創業期 成⻑期 リクルートで求められるプロダクト成⻑ MVP検証に⽬処が付き、⼀気に拡⼤を⾏いたいフェーズ

Slide 74

Slide 74 text

74 開発として必要となったこと チャットを業務に組み込むためのUI/UXの磨き込み シフト業務全体を成⽴させるための機能開発 •  多くの機能と組み合わせた上で、業務で使えるUIを実現するにはUIの磨き 込みが必須 •  シフト管理業務を実現するためにはステータス管理やシフト表の閲覧など、 チャット以外にも多くの機能要素が必要 出来る限り早期の⽴ち上げ •  MVP検証にて勝ち筋が⾒えている以上、出来る限り早く⽴ち上げ、ビジネ スを開始したい

Slide 75

Slide 75 text

75 開発プロセス 全体としてはウォーターフォール、UIの磨き込みのためフロントのみイテレー ション開発を採⽤ イテレーション開発 ウォーターフォール開発 API IF定義 API 設計 API 製造 API テスト フロント 開発1 フロント 開発2 フロント 開発3 フロント 開発4 フロント 開発5 結合 テスト 総合 テスト 要件 定義 フロント 内部設計 SoE開発 SoR開発

Slide 76

Slide 76 text

76 開発プロセス 全体としてはウォーターフォール、UIの磨き込みのためフロントのみイテレー ション開発を採⽤ イテレーション開発 ウォーターフォール開発 API IF定義 API 設計 API 製造 API テスト フロント 開発1 フロント 開発2 フロント 開発3 フロント 開発4 フロント 開発5 結合 テスト 総合 テスト 要件 定義 フロント 内部設計 内製チーム オフショア開発チーム

Slide 77

Slide 77 text

77 アーキテクチャ⽅針 開発体制を分けた際の既存アーキテクチャでの課題 モノリシックなアプリケーションの弊害 バックエンド­フロントエンド間の認識齟齬 SoEチーム SoRチーム Web Server Controller View Model RDBMS Search Engine × •  同⼀のソースコードを触る必要があるた め、異なるリリースサイクルに対応する のは難しい ロック 触れない Back End Front End HTTP 画⾯ API API API HTTP HTTP SoEチーム SoRチーム × × APIを使おうとし たが、レスポンス が認識と異なる APIの要件が 頻繁に変わる •  開発が進む中でAPI仕様の認識がバック エンド-フロントエンド間でズレてしま う

Slide 78

Slide 78 text

78 アーキテクチャ⽅針 フロントエンドとバックエンドの接続が課題となる BackEnd For Frontサーバ(BFF)の採⽤ Consumer Driven Contractの活⽤ •  API仕様を提供側ではなく利⽤側が決め ていくConsumer Driven Contractをフ ロントエンド開発に適⽤。 •  Agreedというツールを開発し双⽅の開 発チームでAPI仕様を共有。 •  API層とView層の間にBFF層というフロ ントエンドに特化したバックエンドサー バを挟むことにより、APIと画⾯仕様を 分離。 •  ユースケースに合わせてAPIを統合し、 画⾯に返却する。 API仕様 フ ロ ン ト エ ン ド バ ク エ ン ド API の モ ク サ ー バ と し て 機 能 API の テ ス ト コ ー ド と し て 機 能 BFF Server Backend Server View 画⾯ API API API API

Slide 79

Slide 79 text

79 アーキテクチャ⽅針 BFF Server プレゼンテーション ロジック Backend Server ビジネス ロジック Backend Frontend Client Server Controller View Model RDBMS Search Engine iOS/Android Browser プレゼンテーション ロジック Controller プレゼンテーション ロジック View Controller View BFF Server プレゼンテーション ロジック Controller View React Redux Swift kotlin HTTP HTTP Spring Boot

Slide 80

Slide 80 text

80 アーキテクチャ⽅針 BFF Server プレゼンテーション ロジック Backend Server ビジネス ロジック Backend Frontend Client Server Controller View Model RDBMS Search Engine iOS/Android Browser プレゼンテーション ロジック Controller プレゼンテーション ロジック View Controller View BFF Server プレゼンテーション ロジック Controller View React Redux Swift kotlin HTTP HTTP Spring Boot オフショア開発チーム 内製開発チーム

Slide 81

Slide 81 text

81 アーキテクチャ⽅針 BFF Server プレゼンテーション ロジック Backend Server ビジネス ロジック Backend Frontend Client Server Controller View Model RDBMS Search Engine iOS/Android Browser プレゼンテーション ロジック Controller プレゼンテーション ロジック View Controller View BFF Server プレゼンテーション ロジック Controller View React Redux Swift kotlin HTTP HTTP Spring Boot ディレクション組織 技術基盤チーム SRE 内製開発チーム オフショア開発チーム

Slide 82

Slide 82 text

82 基盤体制 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 基盤、インフラ体制 開発体制 開発体制 開発体制 依頼 依頼 依頼

Slide 83

Slide 83 text

83 基盤体制 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 インフラ 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 SRE 開発体制 開発体制 開発体制 SRE SRE 技術基盤 連携 連携 連携 インフラ インフラ インフラ体制はSREとして事業別体制に変更 FWなどを担当していた技術基盤は開発体制と⼀体化

Slide 84

Slide 84 text

84 Airシフト開発結果 内製開発チーム •  6ヶ⽉の開発期間中に8回のイ テレーションを回し、UIを磨 き込み オフショア開発チーム •  QCDを担保しながら100本を超 えるAPIを開発 技術基盤、SRE •  アーキテクチャを実現するイン フラ、技術基盤を構築

Slide 85

Slide 85 text

85 BFF Server アーキテクチャ戦略 ク ラ イ ア ン ト Web カ ス タ マ ー Web SoR SoR SoE ク ラ イ ア ン ト カ ス タ マ ー SoE Backend Server View BFF Server Backend Server View カスタマーWeb カスタマーWeb モノリシックなアプリケーションを層を分割していく

Slide 86

Slide 86 text

86 技術⽅針 開拓 実装、展開 運⽤ テクノロジー ライフサイクル

Slide 87

Slide 87 text

87 技術⽅針 広範囲のビジネスに装 着し、効果を最⼤化さ せるための改善を⾏い、 事業貢献利益を追究 Ø Rグループのビジネスに 短・中期的に実活⽤の可能 性がある技術をリサーチ Ø 対象技術における事業化 への検証を⾏い、評価・選 定する 開拓(実活⽤研究) 実際に事業へ適⽤ し、より広範囲に 利⽤するための型 化やスキームを構 築 実装・展開 運⽤ 実施内容 リクルートテクノロジーズ(短・中期的視野) 利益を⽬的としない中⻑期的な 視点に⽴ち、新技術や新⼿法の 研究/発明を⾏い、論⽂発表す ることを⽬指す 要素基礎技術の研究 社外(中・⻑期的視野) 技術数の 推移イメージ 年間約200の技術をリサーチし、 約30の技術を評価・選定 年間数個〜10個の 技術を展開 運⽤フェーズまで 移⾏された技術が蓄積 無数の新技術を研究/発明

Slide 88

Slide 88 text

88 技術⽅針 BFF Server React Redux ✕ 開拓フェーズから取り⼊れた技術 開拓した技術を積極的に活⽤ t_wada yosuke-furukawa 技術基盤チーム

Slide 89

Slide 89 text

89 学び •  モノリシックなアーキテクチャでリリースサイクル の異なる開発を行うのは難しいため、アプリケー ションの分離が重要 •  アーキテクチャを変えていくにはインフラや開発技 術に特化した組織の協力が必要

Slide 90

Slide 90 text

90 まとめ

Slide 91

Slide 91 text

91 まとめ 組織戦略 •  SoE/SoRに対応するためにバイモーダルな開発体制 •  インフラや技術基盤など横断的な組織も事業別のチームへ移⾏ •  機能軸と事業軸をマトリックスにすることで流動性を担保 •  プロダクトフェーズに応じて開発体制をコントロール 技術戦略 •  SoE/SoRに対応を⾏いやすいようBFF層を導⼊ •  積極的な技術開拓と、開拓した技術の活⽤を推進

Slide 92

Slide 92 text

92 まとめ 組織戦略 •  SoE/SoRに対応するためにバイモーダルな開発体制 •  インフラや技術基盤など横断的な組織も事業別のチームへ移⾏ •  機能軸と事業軸をマトリックスにすることで流動性を担保 •  プロダクトフェーズに応じて開発体制をコントロール 技術戦略 •  SoE/SoRに対応を⾏いやすいようBFF層を導⼊ •  積極的な技術開拓と、開拓した技術の活⽤を推進 まだまだ道半ばですが、 継続して進めていきます!

Slide 93

Slide 93 text

93 最後に

Slide 94

Slide 94 text

94 リクルートの⽂化 失敗 失敗 なんとか なってる… ⼤成功! ボトムアップ

Slide 95

Slide 95 text

95 リクルートの⽂化 ボトムアップ 失敗 失敗 ⼤成功! あっちが より良いっぽい! なんとか なってる…

Slide 96

Slide 96 text

96 リクルートの⽂化 こっち かー! だろー! ボトムアップ

Slide 97

Slide 97 text

97 リクルートの⽂化 ボトムアップ トップダウン 失敗経験(学び) オーナーシップ

Slide 98

Slide 98 text

98 リクルートの⽂化 開発についても各組織でバラバラに機能を磨いてきた プロジェクトマ ネジメント! オフショア 開発! 完全内製化! Scrum開発!

Slide 99

Slide 99 text

99 リクルートの⽂化 苦⼿なことも明確になってきた 仮説検証的な開 発は苦⼿ ⼀定の規模がな いと厳しい ⼤規模なプロ ジェクトは無理 納期マストが多 い領域は苦⼿

Slide 100

Slide 100 text

100 リクルートの⽂化 Scrum開発 内製開発 オフショア開発 プロジェクトマネジメント 連携して強みを活かし弱みを補っていくていく!

Slide 101

Slide 101 text

101 ⽂化に共感してくれる仲間を募集中です! リクルートテクノロジーズ 検索

Slide 102

Slide 102 text

ご清聴ありがとうございました