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

2018年2月15日 「Developers Summit 2018」における、弊社エグゼクティブマネジャー宮川の講演資料でございます。

Transcript

1. 2017年2⽉15⽇ リクルートテクノロジーズ 宮川 典久 多様なビジネスドメイン、サービスフェーズが 混在する中での組織戦略と技術戦略
2. 2 ⾃⼰紹介 宮川 典久 株式会社リクルートテクノロジーズ 執⾏役員 テクノロジープラットフォーム部 プロダクトエンジニアリング部 サイトリライアビリティエンジニアリング部 ▪経歴  SIer（2004/04〜2012/10） Ø  アーキテクト兼プログラマー  リクルートテクノロジーズ（2012/11〜） Ø  グループマネージャー（2014/04〜） Ø  シニアマネージャー（2016/04〜） Ø  執⾏役員（2017/04〜） ▪主な役割  内製開発、技術部⾨、インフラ部⾨の責任者
3. 3 はじめに
4. 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⽇） リクルートについて
5. 5 リクルートの主な事業 リボン図モデルを活⽤したビジネスを展開
6. 6 リクルートの主な事業 旅⾏ ビジネス⽀援 ⽣活/地域情報 グルメ・美容 ライフスタイル領域 ライフイベント領域 進学 就職 結婚 転職 住宅購⼊ ⾞購⼊ 出産/育児
7. 7 リクルートテクノロジーズとは リクルート HD リクルートキャリア リクルート住まいカンパニー リクルートライフスタイル リクルートジョブズ リクルートマーケティングパートナーズ リクルートテクノロジーズ リクルートアドミニストレーション リクルートコミュニケーションズ メディア＆ ソリューション Staffing HR Technology SBU Company Holding Company and more... (Strategic Business Unit)
8. 8 リクルートの開発についての取り組み
9. 9 リクルートの⽂化 ボトムアップ
10. 10 リクルートの⽂化 こっちが 正解 トップダウン 上司
11. 11 リクルートの⽂化 リクルートの場合 こっち じゃね？ こっち じゃね？ こっち じゃね？ こっち じゃね？
12. 12 リクルートの⽂化 リクルートの場合 みんな やってみ
13. 13 リクルートの⽂化 ボトムアップであるがゆえに、 様々な失敗も有るが、学びを得ることが出来る 失敗 失敗 ⼤成功！ なんとか なってる…
14. 14 リクルートの⽂化 開発についても様々な取組を各組織で実施 プロジェクトマ ネジメント！ オフショア 開発！ 完全内製化！ Scrum開発！
15. 15 ⾏ってきた取組 内製化の推進に向けて、エンジニア採⽤を急激に拡⼤ 新卒採⽤ 中途採⽤ 内製化！！
16. 16 ⾏ってきた取組 Scrum開発を全社的に推進 スクラム開発！！ •  スクラムマスター研修 やプロダクトオーナー 研修を社内でも実施 •  様々なプロダクトで導 ⼊を推進
17. 17 ⾏ってきた取組 ⼤規模プロジェクトの専⾨組織、プロ推を構築、拡⼤ プロジェクト マネジメント！！ ⼤規模プロジェクト推進スキームを確⽴
18. 18 ⾏ってきた取組 オフショア開発 オフショアだ！！ ✕
19. 19 振り返り •  エンジニアの⼤幅な増加 •  様々な開発パターンへの対応 上⼿く⾏ったこと 各サイトの進化や、多くの新規サービスの構築など、 リクルートの成⻑に貢献！ •  各開発機能としての進化
20. 一方で…
21. 21 現場で上がる声 案件のリリースを急ぎたいという要望に答えられない… 画⾯のUIを⼀部直 して検証してみた いんだけど？ 企画T 開発T 来⽉の案件となるので、 リリースは２ヶ⽉後に なります。 なんでそんなにか かる！？
22. 22 現場で上がる声 スクラム開発なのに納期が定められる… 企画T 開発T この案件はどうし てのこの⽇までに リリースする必要 が有る！ スクラム開発を⾏って いるので、納期へのコ ミットは難しいです こういう事情がある から、どうしてもお 願い！ うーん…
23. 23 現場で上がる声 技術的な負債が蓄積しすぎている… 開発T この画⾯直してお いたよ そのコード、実はこの 画⾯でも使っているか らこっち側にも影響出 るよ！ え、そんなところ に影響出るの！？
24. 24 現場で上がる声 ステークホルダーが多く調整が困難 開発T こんな案件をやろう！ ステークホルダーA ステークホルダーB ステークホルダーC いいね、やろう！ ここへの影響⼤丈 夫？ こっちの案件のほ うが優先順位⾼く ない？
25. 25 現場で上がる声 新しい技術を採⽤しにくい基盤 開発T インフラT 今のインフラだと対応 が難しいです… こんな技術を使い たい え、何故！？
26. 拡大を広げていく中で うまくいかないことが増えてきた
27. 27 このような状況の中で実施してきた 取り組みについて共有ます。 正解は無い中での事例の一つとして 捉えてもらえればと思います。 今⽇の話
28. 28 開発が置かれている状況
29. 29 ビジネス観点 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー リボン図モデルの中での開発
30. 30 ビジネス観点 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー リボン図モデルの中での開発 2種類の開発が求められる •  営業が売るための商品開発 •  カスタマー／クライアントの継続利⽤に向けたサイト改善 CVR 向 上 業 務 効 率 向 上 商品開発 営業
31. 31 ビジネス観点 案件によって開発に求められるQCDが⼤きく異なる 案件タイプ 規模（コスト） 納期の重要度 品質の重要度 （例） 営業商品 ⼤ ⾼ ⾼ 詳細ページに動画広 告を⼊れたい サイト 改善 カスタマー ⼩ 低 中 ボタンを四⾓から丸 に変えたい クライアン ト 中 低 ⾼ ⼊⼒バリデーション を追加したい
32. 32 ビジネス観点 SoR(System of Record) SoE(System of Engagement) •  記録のためのシステム •  安定性、継続性が重要となるシステム •  リクルートの開発における主な要素 •  広告商品、アクション処理、ポイント •  繋がりのためのシステム •  顧客との繋がりや新たな価値提供が重要なシステム •  リクルートの開発における主な要素 •  UI/UX、Webフロント、スマホアプリ
33. 33 ビジネス観点 SoR SoE 性質 求められる開発⼿法 •  安定性重視 •  予測可能 •  リスクを抑える •  速度重視 •  探索型 •  トライアンドエラー •  ウォーターフォール •  事前に要件を確定させるこ とが重要 •  確実な品質を担保してリ リース •  アジャイル •  正しい仕様は存在しない •  迅速なリリースを繰り返す ことが重要
34. 34 ビジネス観点 案件によって開発に求められるQCDが⼤きく異なる 案件タイプ 規模（コスト） 納期の重要度 品質の重要度 （例） 営業商品 ⼤ ⾼ ⾼ 詳細ページに動画広 告を⼊れたい サイト 改善 カスタマー ⼩ 低 中 ボタンを四⾓から丸 に変えたい クライアン ト 中 低 ⾼ ⼊⼒バリデーション を追加したい SoE的な開発 SoR的な開発 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している
35. 35 ビジネス観点
36. 36 ビジネス観点 複数の領域に分かれており、且つ規模が⼤きい 優先順位を付けにくいため、リソースを集中させにくい IR資料：「2018年3⽉期 第2四半期決裁説明資料」より抜粋
37. 37 ビジネス観点 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 UXデザイン マーケティング 営業推進 商品企画 ・・・ 開発組織 ⼤規模なプロダクト故に、多くの関連組織が存在する ステークホルダーが多いため仕様調整が難しい
38. 38 ビジネス観点 ビジネス領域の拡⼤が進んでいる IR資料：「メディア＆ソリューション事業のご紹介」より抜粋
39. 39 ビジネス観点 ビジネス領域の拡⼤が進んでいる IR資料：「メディア＆ソリューション事業のご紹介」より抜粋 新規プロダクトの⽴ち上げも進んでいる
40. 40 アーキテクチャ観点 同様のビジネスモデルに対応するために“型化”されたAP基盤とインフラ 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 構成から外れたアーキテクチャにするのは困難な基盤
41. 41 アーキテクチャ観点 “型化”されていく中で開発体制と基盤・インフラ体制の距離が開いてしまった 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 基盤、インフラ体制 開発体制 開発体制 開発体制 依頼 依頼 依頼 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい
42. 42 アーキテクチャ観点 通常のプロダクト成⻑フェーズ 導⼊期 成⻑期 成熟期 成熟期 導⼊期 成⻑期 リクルートで求められるプロダクト成⻑ ⾒込みのあるプロダクトに対して⼀気に投資を⾏う
43. 43 アーキテクチャ観点 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 カスタマー、クライアント双⽅を繋げるモノリシックなアプリケーション クライアントWeb カスタマーWeb 急激に機能拡張を⾏うので、技術的負債が蓄積される
44. 44 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤
45. 45 どう取り組んできたか
46. 46 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤
47. 47 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離
48. 48 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE
49. 49 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE チケットの粒度を細 かくして納期へ対応 できるように ⽇本側を厚くするこ とでエンハンスにも 対応できるように
50. 50 これまでの開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー カスタマーWeb、クライアントWebという単位で開発体制を分離 SoR SoR SoE SoE Scrum開発で納期をコミット/オフショア開発で⾼速リリースといった 本来チームに向かない開発を⾏う中で元々の強みが失われていった Scrum開発チーム オフショア開発チーム
51. 51 現在⽬指している体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー Scrum開発チーム オフショア開発チーム SoR SoR SoE SoE 各開発チームの強みを活かせるようにしていく Scrum開発チーム SoE／SoRに応じて、性質が向く開発チームが担当していくように
52. 52 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤
53. 53 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE
54. 54 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE リーダー リーダー リーダー リーダー
55. 55 開発体制 UXデザイン マーケティング 営業推進 商品企画 様々な組織からの発⽣する開発案件 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー SoR SoR SoE SoE リーダー リーダー リーダー リーダー 開発チームのマネージャーやリーダーが調整業務に奔⾛
56. 56 開発体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web ク ラ イ ア ン ト カ ス タ マ ー UXデザイン マーケティング データサイエンス 営業推進 ディレクション組織 ディレクション専⾨の組織が最適な形で開発案件をコントロール SoR SoR SoE SoE
57. 57 学び •  開発チームは自分たちで何とかするために、苦手 な事を出来るように頑張る •  その中で本来の強みが失われていくため、組織 的なフォローが必要
58. 58 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤
59. 59 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 開 発 体 制 内製開発チーム中⼼ オフショア・ディレク ション組織中⼼
60. 60 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 開 発 体 制 内製開発チーム中⼼ オフショア・ディレク ション組織中⼼ 成⻑フェーズからチー ムに求められることが ⼤きく変わってくる
61. 61 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア ⽬標 Retention CAC < LTV 売上 利益 課題解決可能な 最⼩限 売れる状態 セグメントに応じて売れる状態検証 が既存ユーザに影響与えない キードライバー値最⼤化 指標 ⾼速なMVP検証 技術負債の抑制 商品開発 技術負債の解消 商品開発 競合追従 業務効率化 開 発 に 求 め ら れ る 要 素 スケールへの対応 グロースハック グロースハック
62. 62 ビジネスフェーズによる組織戦略 顧客発⾒ 【ニーズ検証】 顧客実証 【売って検証】 顧客開拓 【リーチ検証】 組織構築 【本格拡⼤】 導⼊期 成⻑期 成熟期 フ ー ズ •  独⾃な価値提供 を出来ているか •  深い課題を抱え た顧客がいるか •  その課題の解決 策は妥当か •  顧客は本当に 買ってくれるか •  コスト構造に無 理がないか •  最適な売り⽅の検証 •  最適な価格設定の検証 •  CPA最適化、商品拡充 •  マーケットシェア 開 発 に 求 め ら れ る 要 素 SoEの要素 SoRの要素 フェーズに応じてチームの構成を変えていく必要がある
63. 63 学び •  フェーズの変化に応じて実施しなければならない 案件の特性はどんどん変わっていく •  先の学び通り、チームだけでは急激な変化に対 応することは難しいので、先を見越した体制を 作っていくことが大事
64. 64 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤
65. 65 これまでの組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum／内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 機能別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D 機能別のチーム 機能別のチーム 機能別のチーム
66. 66 バイモーダル戦略に則った体制 ク ラ イ ア ン ト Web カ ス タ マ ー Web SoR 開発T SoR 開発T SoE 開発T ク ラ イ ア ン ト カ ス タ マ ー UXデザイン マーケティング データサイエンス 営業推進 ディレクション組織 技術基盤チーム SRE SoE 開発T
67. 67 機能と事業でのマトリックス組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum／内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 技術別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D
68. 68 機能と事業でのマトリックス組織 ディレクショ ン部 プロダクトエ ンジニアリン グ部 オフショアソ リューション 部 テクノロジー プラット フォーム部 プロジェクト 推進部 SRE部 ディレクショ ン機能 Scrum／内製 開発 オフショア開 発 インフラ/SRE 技術基盤 ⼤規模プロ ジェクト推進 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 事業A 事業B 事業C 事業D … 技術別のチーム プロジェクトに応じて体制を構築 事業A 事業B 事業C 事業D ⼀⽅で流動性の担保は 難しくなっており、 試⾏錯誤中です
69. 69 開発の置かれている状況 ⼀つのサイトの中にSoR的開発とSoE的開発が同居している ビ ジ ネ ス 観 点 ア ー キ 観 点 急激な拡⼤を⾏ってきた中で、技術的負債が蓄積されている ビジネス領域の拡⼤に伴い、新たなサービスの⽴ち上げが進んでいる ステークホルダーが多いため仕様調整が難しい ⼤規模なプロダクトが多数あり、リソースを集中させにくい 型化が進む中で組織間の距離が出来てしまい、改善が進みにくい 過度な型化により構成から外れたアーキテクチャにするのは困難な基盤 事例を通しての紹介！
70. 70 事例紹介
71. 71 Airシフトとは
72. 72 Airシフトとは 店⻑のシフト調整業務の負荷軽減のためのプロダクト 店⻑ スタッフ チャットを介して コミュニケーション
73. 73 Airシフトとは 通常のプロダクト成⻑フェーズ 創業期 成⻑期 成熟期 成熟期 創業期 成⻑期 リクルートで求められるプロダクト成⻑ MVP検証に⽬処が付き、⼀気に拡⼤を⾏いたいフェーズ
74. 74 開発として必要となったこと チャットを業務に組み込むためのUI/UXの磨き込み シフト業務全体を成⽴させるための機能開発 •  多くの機能と組み合わせた上で、業務で使えるUIを実現するにはUIの磨き 込みが必須 •  シフト管理業務を実現するためにはステータス管理やシフト表の閲覧など、 チャット以外にも多くの機能要素が必要 出来る限り早期の⽴ち上げ •  MVP検証にて勝ち筋が⾒えている以上、出来る限り早く⽴ち上げ、ビジネ スを開始したい
75. 75 開発プロセス 全体としてはウォーターフォール、UIの磨き込みのためフロントのみイテレー ション開発を採⽤ イテレーション開発 ウォーターフォール開発 API IF定義 API 設計 API 製造 API テスト フロント 開発1 フロント 開発2 フロント 開発3 フロント 開発4 フロント 開発5 結合 テスト 総合 テスト 要件 定義 フロント 内部設計 SoE開発 SoR開発
76. 76 開発プロセス 全体としてはウォーターフォール、UIの磨き込みのためフロントのみイテレー ション開発を採⽤ イテレーション開発 ウォーターフォール開発 API IF定義 API 設計 API 製造 API テスト フロント 開発1 フロント 開発2 フロント 開発3 フロント 開発4 フロント 開発5 結合 テスト 総合 テスト 要件 定義 フロント 内部設計 内製チーム オフショア開発チーム
77. 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仕様の認識がバック エンド-フロントエンド間でズレてしま う
78. 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
79. 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
80. 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 オフショア開発チーム 内製開発チーム
81. 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 内製開発チーム オフショア開発チーム
82. 82 基盤体制 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 フレームワーク フレームワーク インフラ フレームワーク 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 基盤、インフラ体制 開発体制 開発体制 開発体制 依頼 依頼 依頼
83. 83 基盤体制 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 インフラ 吂 吐 吖 吵 ー 吆 呀 叻 叹 呉 吟 吂 吐 吖 吵 Web 吆 呀 叻 叹 呉 吟 SRE 開発体制 開発体制 開発体制 SRE SRE 技術基盤 連携 連携 連携 インフラ インフラ インフラ体制はSREとして事業別体制に変更 FWなどを担当していた技術基盤は開発体制と⼀体化
84. 84 Airシフト開発結果 内製開発チーム •  6ヶ⽉の開発期間中に８回のイ テレーションを回し、UIを磨 き込み オフショア開発チーム •  QCDを担保しながら100本を超 えるAPIを開発 技術基盤、SRE •  アーキテクチャを実現するイン フラ、技術基盤を構築
85. 85 BFF Server アーキテクチャ戦略 ク ラ イ ア ン ト Web カ ス タ マ ー Web SoR SoR SoE ク ラ イ ア ン ト カ ス タ マ ー SoE Backend Server View BFF Server Backend Server View カスタマーWeb カスタマーWeb モノリシックなアプリケーションを層を分割していく
86. 86 技術⽅針 開拓 実装、展開 運⽤ テクノロジー ライフサイクル
87. 87 技術⽅針 広範囲のビジネスに装 着し、効果を最⼤化さ せるための改善を⾏い、 事業貢献利益を追究 Ø Rグループのビジネスに 短・中期的に実活⽤の可能 性がある技術をリサーチ Ø 対象技術における事業化 への検証を⾏い、評価・選 定する 開拓（実活⽤研究） 実際に事業へ適⽤ し、より広範囲に 利⽤するための型 化やスキームを構 築 実装・展開 運⽤ 実施内容 リクルートテクノロジーズ（短・中期的視野） 利益を⽬的としない中⻑期的な 視点に⽴ち、新技術や新⼿法の 研究/発明を⾏い、論⽂発表す ることを⽬指す 要素基礎技術の研究 社外（中・⻑期的視野） 技術数の 推移イメージ 年間約200の技術をリサーチし、 約30の技術を評価・選定 年間数個〜10個の 技術を展開 運⽤フェーズまで 移⾏された技術が蓄積 無数の新技術を研究/発明
88. 88 技術⽅針 BFF Server React Redux ✕ 開拓フェーズから取り⼊れた技術 開拓した技術を積極的に活⽤ t_wada yosuke-furukawa 技術基盤チーム
89. 89 学び •  モノリシックなアーキテクチャでリリースサイクル の異なる開発を行うのは難しいため、アプリケー ションの分離が重要 •  アーキテクチャを変えていくにはインフラや開発技 術に特化した組織の協力が必要
90. 90 まとめ
91. 91 まとめ 組織戦略 •  SoE/SoRに対応するためにバイモーダルな開発体制 •  インフラや技術基盤など横断的な組織も事業別のチームへ移⾏ •  機能軸と事業軸をマトリックスにすることで流動性を担保 •  プロダクトフェーズに応じて開発体制をコントロール 技術戦略 •  SoE/SoRに対応を⾏いやすいようBFF層を導⼊ •  積極的な技術開拓と、開拓した技術の活⽤を推進
92. 92 まとめ 組織戦略 •  SoE/SoRに対応するためにバイモーダルな開発体制 •  インフラや技術基盤など横断的な組織も事業別のチームへ移⾏ •  機能軸と事業軸をマトリックスにすることで流動性を担保 •  プロダクトフェーズに応じて開発体制をコントロール 技術戦略 •  SoE/SoRに対応を⾏いやすいようBFF層を導⼊ •  積極的な技術開拓と、開拓した技術の活⽤を推進 まだまだ道半ばですが、 継続して進めていきます！
93. 93 最後に
94. 94 リクルートの⽂化 失敗 失敗 なんとか なってる… ⼤成功！ ボトムアップ
95. 95 リクルートの⽂化 ボトムアップ 失敗 失敗 ⼤成功！ あっちが より良いっぽい！ なんとか なってる…
96. 96 リクルートの⽂化 こっち かー！ だろー！ ボトムアップ
97. 97 リクルートの⽂化 ボトムアップ トップダウン 失敗経験（学び） オーナーシップ
98. 98 リクルートの⽂化 開発についても各組織でバラバラに機能を磨いてきた プロジェクトマ ネジメント！ オフショア 開発！ 完全内製化！ Scrum開発！
99. 99 リクルートの⽂化 苦⼿なことも明確になってきた 仮説検証的な開 発は苦⼿ ⼀定の規模がな いと厳しい ⼤規模なプロ ジェクトは無理 納期マストが多 い領域は苦⼿
100. 100 リクルートの⽂化 Scrum開発 内製開発 オフショア開発 プロジェクトマネジメント 連携して強みを活かし弱みを補っていくていく！
101. 101 ⽂化に共感してくれる仲間を募集中です！ リクルートテクノロジーズ 検索
102. ご清聴ありがとうございました