多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略

by Recruit Technologies

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 リクルートキャリアリクルート住まいカンパニーリクルートライフスタイルリクルートジョブズリクルートマーケティングパートナーズリクルートテクノロジーズリクルートアドミニストレーションリクルートコミュニケーションズメディア＆ソリューション Staﬃng 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 来⽉の案件となるので、リリースは２ヶ⽉後になります。なんでそんなにかかる！？

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ヶ⽉の開発期間中に８回のイテレーションを回し、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

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