事業成長にコミットするエンジニア組織への道のり

事業成長にコミットするエンジニア組織への道のり

1. 1. 事業成⻑にコミットするエンジニア組織への道のり 2017年2⽉16⽇ 株式会社リクルートライフスタイル ネットビジネス本部 ディベロップメントデザインユニット プロダクト開発3G ⼩川 健太郎 1
2. 2. ⾬降って、地固まった という話をします 2
3. 3. ケーススタディ としてお役に⽴てると幸いです 3
4. 4. Agenda •  リクルートライフスタイルの紹介 •  エンジニア組織黎明期の話 •  急拡⼤とその先に待っていたもの •  社員エンジニアの価値とは •  チャレンジをする組織へ •  ⽂化を作るための⽇々 •  エンジニアドリヴンで組織を変える •  まとめ 4
5. 5. ⾃⼰紹介 ＜略歴＞ •  〜2012年 –  受託系開発会社でCS -> PG -> SE -> MGRとして勤務 •  2012年5⽉〜 –  株式会社リクルートに転職 –  新規⽴ち上げ、サービス運⽤改善に携わる •  2015年4⽉〜 –  ネットビジネス本部 グループマネジャー就任 –  新規開発、スマホアプリ開発、ホットペッパービューティー開発の部署を担当 5 ⼩川 健太郎 ネットビジネス本部 ディベロップメントデザインユニット プロダクト開発3G グループマネジャー
6. 6. リクルートでの時系列6 2014年 2015年 2017年2012年 エンジニア マネジャー 2013年 2016年 •  エンジニア時代は⼤規模案件SEの後、新規⽴ち上げがメイン •  2015年に新規領域、スマートフォン領域のマネジャー •  2016年からホットペッパービューティー（開発）のマネジャー
7. 7. 今回のお話スコープ •  2012年頃（5年くらい前）から現在に⾄るまでの道程を話します •  事業数値などには触れず、組織の話がメインとなります 7
8. 8. グループ理念とRLSの使命 リクルートライフスタイルの紹介
9. 9. ㈱リクルートスタッフィング ㈱スタッフサービス・HD ㈱リクルート住まいカンパニー ㈱リクルートマーケティングパートナーズ HR事業 機能会社 （株）リクルート ホールディングス ㈱リクルートキャリア ㈱リクルートジョブズ ㈱リクルートライフスタイル ㈱リクルートアドミニストレーション ㈱リクルートテクノロジーズ ㈱リクルートコミュニケーションズ 住宅事業 結婚・学び事業 ⽇常消費領域事業 全社内でのRLSの位置づけ ㈱リクルートマネジメントソリューションズ 販促事業
10. 10. RLSの事業領域
11. 11. RLSの主な展開プロダクト・メディア
12. 12. RLSの主な展開プロダクト・メディア
13. 13. 数値でみるリクルートライフスタイル
14. 14. ベンチャーマインドがあるが歴史ある企業 1960 2017 ⼤学新聞広告社創業 2000 「Hot Pepper」創刊 「じゃらんNet」サービス開始 2005 「HotPepper.jp」 （現・「ホットペッパーグルメ」）サービス開始 2007 「ホットペッパービューティー」サービス開始 〜省略〜 2012 （社員エンジニア採⽤し始める） 紙の会社 WEBの会社 創業50年⽬の 新⼈類
15. 15. グループ理念とRLSの使命 エンジニア組織黎明期の話
16. 16. 社員エンジニアは⽚⼿で数えられる •  私が⼊社した2012年の頃は、社員エンジニアは数名でした 16 受託時代 転職後 1チーム 3⼈くらい 数⼗名内の1名
17. 17. 当時のアーキテクチャと開発プロセス17 オンプレミス DB Solr Java(独⾃FW) HTML/ CSS/ JavaScript アーキテクチャ構成 •  アーキテクチャ / インフラともに 共通化して全体最適を図っていた 開発プロセス 要件定義 基本設計 実装・UT 結合テスト 受⼊テスト ビジネス検討 効果振り返り V字モデル +a •  社員はビジネス検討と効果振り返りに注⼒ •  開発は常駐パートナーがメイン
18. 18. 社員の仕事 = 管理18 企画者 開発者 (管理)(調整)
19. 19. グループ理念とRLSの使命 急拡⼤とその先に待っていたもの
20. 20. エンジニア採⽤が本格化 •  2014年頃、リクルート全体でエンジニア採⽤が本格化 •  新卒採⽤/中途採⽤ともにエンジニアが急増した 20 2012 2014 2016 社員 エンジニア数 急増 開発G 開発1G 開発2G 開発3G 組織拡⼤
21. 21. いろんなタイプのエンジニアが増えた21 調整とか したくない コードだけ 書いてたい マネジメントが やりがい リーダー やりたい 管理とか したくない 少⼈数で 働きたい
22. 22. 同時に指針（ビジョン）が不明瞭 •  社員エンジニアはこうあるべき という指針がふわっとしていた •  リクルートの⽂化として『なにがしたい？』『きみはどうしたい？』と Will中⼼で仕事を組み⽴てるというものがあるが、指針や仕事の基準も 曖昧だったので迷ってしまうエンジニアが増えてきてしまった 22
23. 23. 社員エンジニアの 価値ってなんなんだ？
24. 24. 組織コンディションの低下… •  思っていた仕事と違う！ •  やりたいことができない！ •  エンジニア増加にともない、ネガティブな意⾒も増えてきてしまった 24
25. 25. 暗 雲
26. 26. グループ理念とRLSの使命 社員エンジニアの価値とは
27. 27. エンジニアを社内に構える意味 •  売上最⼤化 あるいは 利益最⼤化 させること •  事業成⻑に負けないように技術的な成⻑をすること 27 時間軸 成⻑度 事業成⻑ 開発成⻑ ・機能追加スピードアップ ・より多く、より質のいいシステム ・売上UP ・⼿作業を⾃動化 ・個別最適、全体最適への取り組み ・コストDOWN、利益UP このギャップを解消
28. 28. リクルートならでは難しさ •  事業規模と組織規模が両⽅⼤きい •  事業課題だけでなく組織課題にも ⽴ち向かわなければいけない 28 事業規模⼤きい 事業規模⼩さい 組織規模 ⼩さい 組織規模 ⼤きい 事業課題 事業課題 ＆ 組織課題
29. 29. 事業会社におけるエンジニア像とは •  技術で課題を解決する⼈ •  プロダクト志向で開発をする⼈ •  あくまで “プロダクト側” として動く 29 課題解決 成⻑へのコミット
30. 30. 技術 × 熱意 × プロダクト理解 30
31. 31. プロダクトを理解して適切な打ち⼿を理解し、 それらを実現する⼿段（技術）をもち、 やり遂げる情熱を持ち続けられるエンジニア 31 技術 × 熱意 × プロダクト理解
32. 32. エンジニアリングは⼿段 •  管理 = 悪じゃない •  管理をする⼈だって必要 •  コードを書く⼈も必要 •  運⽤する⼈だって分析する⼈だって必要 •  エンジニアリングは⼿段 32
33. 33. （従来）社員の仕事 = 管理33 企画者 開発者 (管理)(調整)
34. 34. 社員の仕事 = 管理もするしコードも書く34 企画者 開発者 (管理) (協働) 事業に近づくエンジニア 開発マネジメント/ 開発エンジニア
35. 35. 事業の成⻑に対して、 エンジニアリングでコミットする 35
36. 36. グループ理念とRLSの使命 チャレンジする組織へ
37. 37. 時代の進化と事業成⻑ •  SPの利⽤率急拡⼤、WebUIのリッチ化など環境が劇的に変化してきた •  カスタマの多様性に対応していくために事業要望も⽐例して向上 •  事業要望 > 開発成⻑ = カスタマ価値低下の恐れ •  システム⾯で多くのPDCAサイクルを回せるようにしないといけない 37 Plan Do Check Ac0on
38. 38. 新規で⾵⽳を開ける •  ⼤規模かつサービスレベルが ⾼い事業はリスク/デリバリ観点で 困難と判断 •  新規事業にターゲットを絞って ⾵⽳をあけることを決めた 38 サービスレベル⾼ サービスレベル低 ⼤規模⼩規模 新規事業
39. 39. ある案件の事例39 オンプレミス DB Solr Java(独⾃FW) HTML/ CSS/ JavaScript AWS MySQL Cloud Search Backend(API) Java(独⾃FW) FrontEnd HTML/CSS/ JavaScript FrontSrv Ruby (Padrino) Redis
40. 40. ：新しいものがえらい ：事業に適切なものを選ぶ 40
41. 41. 技術チャレンジを歓迎する組織へ •  新しいチャレンジをすることでさらに別のチャレンジが歓迎されるようになった 41 2年前くらい 最近
42. 42. ⼈材の考え⽅を変える42 •  フロント寄り •  アーキテクトが到達点ではない •  ⾼速開発やCVR寄与を⽬的とする Backend スプリンタータイプ マラソンタイプ •  バックエンド、インフラ寄り •  アーキテクト志向 •  ⾼難易度案件で価値を発揮する Frontend
43. 43. ⼈材の考え⽅を変える43 •  フロント寄り •  アーキテクトが到達点ではない •  ⾼速開発やCVR寄与を⽬的とする Backend スプリンタータイプ マラソンタイプ •  バックエンド、インフラ寄り •  アーキテクト志向 •  ⾼難易度案件で価値を発揮する Frontend ユーザに近いところで価値を出す or ⾼難易度ロジックで価値を出す ＼どちらも⼤事／
44. 44. ⼤切なことは、いかに⽂化をつくるか 44
45. 45. グループ理念とRLSの使命 ⽂化を作るための⽇々
46. 46. ⼿探りの⽇々 •  ⼈事制度の変更（テックリード制の導⼊） •  エンジニア部隊で合宿 •  テックブログ開設 •  エンジニアポータルサイト構築 •  オライリー本全巻購⼊ •  OSSへのチャレンジ •  社内LT会/社内ハッカソン/社内ISUCONの実施 •  Slack化 •  採⽤のチャレンジ •  and more… 46
47. 47. ⼈事制度の変更（テックリード制の導⼊） •  100名規模にスケールする エンジニア組織にするために テックリードという職務を定義 •  事業に対してエンジニアリングで コミットするだけでなく、 メンバー育成もおこなう •  事業貢献、キャリア形成、 ⼈員育成の3軸を狙った 47
48. 48. エンジニア部隊で合宿 •  ”開発合宿ではなく” 組織テーマを 深掘りするための合宿 •  模造紙と付箋とペンで組織の いいところわるいところを議論 •  課題共有とアクションプラン⽴案 •  ディベロップメントデザインユニット エンジニア合宿レポート http://engineer.recruit-lifestyle.co.jp/techblog/2015-10-06-dev- camp-1/ 48
49. 49. テックブログ開設 •  2015年頃から本格発⾜ •  60記事以上 •  停滞期もあったが 1記事/2week で 運⽤が回っている •  採⽤⾯接などで『ブログ⾒た』と ⾔われた時の喜びを覚えています 49
50. 50. エンジニアポータルサイトを構築50 •  2015年頃初版、2016年第2版 •  Tech Blog,Media Archive, Recruiting •  どういうエンジニアがいるのか •  どういう仕事をしているのか •  定期的なアップデートで社内外に向けて 代表するエンジニア達を露出 •  求職者へのアピール⼒向上
51. 51. オライリー本全巻購⼊ •  Slackでのやりとりをキッカケにし てオライリー本を全巻購⼊ •  新刊も定期的に追加されています •  ふらっと技術書を読める場所として ⼈気スポットになってます •  ぼくらのオフィスにオライリー・ジャパンの本がやってきた http://engineer.recruit-lifestyle.co.jp/techblog/ 2015-12-07-oreilly-books/ 51
52. 52. OSSへのチャレンジ •  プロダクト開発の中で汎⽤化できる 部品を積極的にOSS化 •  なかには1,500Starに迫ったものも •  エンジニアとして、 世間に公開できるものを意識的に 出していこうという⽂化醸成 52
53. 53. OSSコミュニティへの貢献 •  OSSやイベントなどへのスポンサー •  エンジニアが実際に登壇するなどの 実績もでてきた •  社内のエンジニアがイベントに 参加したり、コミュニティとの交流 53
54. 54. 社内LT/社内ハッカソン/社内ISUCONの実施 •  LT、テーマを決めたハッカソン、 社内版ISUCONなどを実施 •  普段業務で絡まないメンバーと 触れ合いつつ本気の戦い •  業務改善ツールの構築や、ひとりひ とりのレベルアップにもつながる •  社内ISUCONを開催してみた所感 http://engineer.recruit-lifestyle.co.jp/techblog/ 2016-11-25-rls-isucon/ •  社内で開催されたSwiftハッカソンに参加しました http://engineer.recruit-lifestyle.co.jp/techblog/ 2016-02-19-swiftparty201601/ 54
55. 55. 採⽤のチャレンジ •  チャレンジ事例を切り⼝に採⽤ •  仕事の内容をイメージしやすく •  案件に取り組んでいるメンバー⾃⾝も ⾃分がやっていることを体系的に 語って価値を再認識したりしている •  応募数への寄与、社内への好影響 55 必要な⼈材に遡及
56. 56. トップダウンとボトムアップの適切な融合 56
57. 57. グループ理念とRLSの使命 エンジニアドリヴンで組織を変える
58. 58. この先に⾏くために必要なこと •  リスク/デリバリ観点で避けてきた 既存⼤規模事業への取り組み •  数百億を売り上げる事業かつ、 型化された運⽤⽅法もあるので 変えに⾏くハードルが⾼い •  本当の意味で組織を変えるには ここを改善する必要がある 58 サービスレベル⾼ サービスレベル低 ⼤規模⼩規模 既存⼤規模 事業
59. 59. 仲間が増えたいまなら⽴ち向かえる59 ⽚⼿で 数えられる 組織で⽴ち向かう！！
60. 60. いくつもの切り⼝から案件化 •  技術的負債を解消する案件 •  システムを⼀部からリプレイスしていく案件 •  事業の成⻑と技術の成⻑にギャップがあった部分を解消する 60 時間軸 成⻑度 事業成⻑ 開発成⻑ このギャップを解消 短期成⻑のために 中期視点が抜けた場合、 導くのはエンジニアの役割
61. 61. ⼤きくて巨⼤なものを⼩さくする •  いきなり⿊を⽩にはできない •  ⼤きくて⿊い箱 を細切れにして 改善しやすくしていく •  改善サイクルをいかに早く回せるか （失敗したっていい） 61 巨⼤ 課題1 課題2 課題3 課題4 課題5
62. 62. システムも分離して変えやすくしていく •  システム分離をしつつ、 技術スタックの最新化やそれに伴う 開発フロー整備などをおこなう •  いきなり全部は難しいので、 ⼿の⼊りやすいところや事業戦略上 重要である機能をターゲットにする 62
63. 63. ⼈、事業、組織の成⻑スパイラルを回す •  ⼈ –  アウトプットで事業を成⻑させる •  事業 –  売上、利益で組織を成⻑ •  組織 –  ⼈が成⻑できる仕事の創出 63 ⼈ 事業 組織 教育 売上、利益 貢献
64. 64. 指標（ビジョン）と社⾵のマッチング •  指標（ビジョン）の浸透がおこなわれてきた。 •  リクルートの⽂化として『なにがしたい？』『きみはどうしたい？』と Will中⼼で仕事を組み⽴てるというものがある。 ひとりひとりがやりたいことを発信、⼿挙げ、⾃発的に改善が⾛ってきた。 （※エンジニアとリクルートの⽂化は実は相性がよかった） 64
65. 65. 少しずつだが、結果がでてきている •  タレント的なエンジニアの台頭 •  エンジニアひとりひとりからの積極的な提案 •  サービスを “⾒る” ようになった •  プロダクトアウト型のシステム開発へ挑戦 •  プロダクト志向エンジニア組織へ少しずつだが近づいている 65
66. 66. 事業貢献にコミットする組織に近づいてきた 66
67. 67. グループ理念とRLSの使命 まとめ
68. 68. スタート ゴール
69. 69. スタート ゴール
70. 70. スタート ゴール
71. 71. スタート ゴール 意⾒が割れる ステークホルダー が増える ⾃分の価値が わからなくなる ゴールに たどり着けない ゴールまで がんばれない
72. 72. 組織マネジメントとは ひとりひとりが輝ける場所を定義すること
73. 73. スタート ゴールゴール ゴール ゴール ゴール ゴール ゴール
74. 74. すべてがゴール = 多様性を許容
75. 75. まとめ •  ⼤切なことは、いかに⽂化をつくるか •  ⽂化をつくるために必要な施策をひたすら打つ –  PDCAサイクルを回し続ける •  組織が⼤きくなれば考え⽅が散らばるのは当たり前 •  変化を楽しもう、多様性を許容しよう 75
76. 76. 仲間を募集しています！！76
77. 77. ご清聴ありがとうございました