事業成長にコミットするエンジニア組織への道のり
•
43 likes•30,045 views
デブサミ2017「事業成長にコミットするエンジニア組織への道のり」講演資料
事業成長にコミットするエンジニア組織への道のり
- 1. 事業成⻑にコミットするエンジニア組織への道のり 2017年2⽉16⽇ 株式会社リクルートライフスタイル ネットビジネス本部 ディベロップメントデザインユニット プロダクト開発3G ⼩川 健太郎 1
- 4. Agenda • リクルートライフスタイルの紹介 • エンジニア組織黎明期の話 • 急拡⼤とその先に待っていたもの • 社員エンジニアの価値とは • チャレンジをする組織へ • ⽂化を作るための⽇々 • エンジニアドリヴンで組織を変える • まとめ 4
- 5. ⾃⼰紹介 ＜略歴＞ • 〜2012年 – 受託系開発会社でCS -> PG -> SE -> MGRとして勤務 • 2012年5⽉〜 – 株式会社リクルートに転職 – 新規⽴ち上げ、サービス運⽤改善に携わる • 2015年4⽉〜 – ネットビジネス本部 グループマネジャー就任 – 新規開発、スマホアプリ開発、ホットペッパービューティー開発の部署を担当 5 ⼩川 健太郎 ネットビジネス本部 ディベロップメントデザインユニット プロダクト開発3G グループマネジャー
- 6. リクルートでの時系列6 2014年 2015年 2017年2012年 エンジニア マネジャー 2013年 2016年 • エンジニア時代は⼤規模案件SEの後、新規⽴ち上げがメイン • 2015年に新規領域、スマートフォン領域のマネジャー • 2016年からホットペッパービューティー（開発）のマネジャー
- 10. RLSの事業領域
- 14. ベンチャーマインドがあるが歴史ある企業 1960 2017 ⼤学新聞広告社創業 2000 「Hot Pepper」創刊 「じゃらんNet」サービス開始 2005 「HotPepper.jp」 （現・「ホットペッパーグルメ」）サービス開始 2007 「ホットペッパービューティー」サービス開始 〜省略〜 2012 （社員エンジニア採⽤し始める） 紙の会社 WEBの会社 創業50年⽬の 新⼈類
- 17. 当時のアーキテクチャと開発プロセス17 オンプレミス DB Solr Java(独⾃FW) HTML/ CSS/ JavaScript アーキテクチャ構成 • アーキテクチャ / インフラともに 共通化して全体最適を図っていた 開発プロセス 要件定義 基本設計 実装・UT 結合テスト 受⼊テスト ビジネス検討 効果振り返り V字モデル +a • 社員はビジネス検討と効果振り返りに注⼒ • 開発は常駐パートナーがメイン
- 20. エンジニア採⽤が本格化 • 2014年頃、リクルート全体でエンジニア採⽤が本格化 • 新卒採⽤/中途採⽤ともにエンジニアが急増した 20 2012 2014 2016 社員 エンジニア数 急増 開発G 開発1G 開発2G 開発3G 組織拡⼤
- 24. 組織コンディションの低下… • 思っていた仕事と違う！ • やりたいことができない！ • エンジニア増加にともない、ネガティブな意⾒も増えてきてしまった 24
- 25. 暗 雲
- 29. 事業会社におけるエンジニア像とは • 技術で課題を解決する⼈ • プロダクト志向で開発をする⼈ • あくまで “プロダクト側” として動く 29 課題解決 成⻑へのコミット
- 32. エンジニアリングは⼿段 • 管理 = 悪じゃない • 管理をする⼈だって必要 • コードを書く⼈も必要 • 運⽤する⼈だって分析する⼈だって必要 • エンジニアリングは⼿段 32
- 34. 社員の仕事 = 管理もするしコードも書く34 企画者 開発者 (管理) (協働) 事業に近づくエンジニア 開発マネジメント/ 開発エンジニア
- 37. 時代の進化と事業成⻑ • SPの利⽤率急拡⼤、WebUIのリッチ化など環境が劇的に変化してきた • カスタマの多様性に対応していくために事業要望も⽐例して向上 • 事業要望 > 開発成⻑ = カスタマ価値低下の恐れ • システム⾯で多くのPDCAサイクルを回せるようにしないといけない 37 Plan Do Check Ac0on
- 42. ⼈材の考え⽅を変える42 • フロント寄り • アーキテクトが到達点ではない • ⾼速開発やCVR寄与を⽬的とする Backend スプリンタータイプ マラソンタイプ • バックエンド、インフラ寄り • アーキテクト志向 • ⾼難易度案件で価値を発揮する Frontend
- 43. ⼈材の考え⽅を変える43 • フロント寄り • アーキテクトが到達点ではない • ⾼速開発やCVR寄与を⽬的とする Backend スプリンタータイプ マラソンタイプ • バックエンド、インフラ寄り • アーキテクト志向 • ⾼難易度案件で価値を発揮する Frontend ユーザに近いところで価値を出す or ⾼難易度ロジックで価値を出す ＼どちらも⼤事／
- 46. ⼿探りの⽇々 • ⼈事制度の変更（テックリード制の導⼊） • エンジニア部隊で合宿 • テックブログ開設 • エンジニアポータルサイト構築 • オライリー本全巻購⼊ • OSSへのチャレンジ • 社内LT会/社内ハッカソン/社内ISUCONの実施 • Slack化 • 採⽤のチャレンジ • and more… 46
- 47. ⼈事制度の変更（テックリード制の導⼊） • 100名規模にスケールする エンジニア組織にするために テックリードという職務を定義 • 事業に対してエンジニアリングで コミットするだけでなく、 メンバー育成もおこなう • 事業貢献、キャリア形成、 ⼈員育成の3軸を狙った 47
- 48. エンジニア部隊で合宿 • ”開発合宿ではなく” 組織テーマを 深掘りするための合宿 • 模造紙と付箋とペンで組織の いいところわるいところを議論 • 課題共有とアクションプラン⽴案 • ディベロップメントデザインユニット エンジニア合宿レポート http://engineer.recruit-lifestyle.co.jp/techblog/2015-10-06-dev- camp-1/ 48
- 49. テックブログ開設 • 2015年頃から本格発⾜ • 60記事以上 • 停滞期もあったが 1記事/2week で 運⽤が回っている • 採⽤⾯接などで『ブログ⾒た』と ⾔われた時の喜びを覚えています 49
- 50. エンジニアポータルサイトを構築50 • 2015年頃初版、2016年第2版 • Tech Blog,Media Archive, Recruiting • どういうエンジニアがいるのか • どういう仕事をしているのか • 定期的なアップデートで社内外に向けて 代表するエンジニア達を露出 • 求職者へのアピール⼒向上
- 51. オライリー本全巻購⼊ • Slackでのやりとりをキッカケにし てオライリー本を全巻購⼊ • 新刊も定期的に追加されています • ふらっと技術書を読める場所として ⼈気スポットになってます • ぼくらのオフィスにオライリー・ジャパンの本がやってきた http://engineer.recruit-lifestyle.co.jp/techblog/ 2015-12-07-oreilly-books/ 51
- 52. OSSへのチャレンジ • プロダクト開発の中で汎⽤化できる 部品を積極的にOSS化 • なかには1,500Starに迫ったものも • エンジニアとして、 世間に公開できるものを意識的に 出していこうという⽂化醸成 52
- 53. OSSコミュニティへの貢献 • OSSやイベントなどへのスポンサー • エンジニアが実際に登壇するなどの 実績もでてきた • 社内のエンジニアがイベントに 参加したり、コミュニティとの交流 53
- 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 必要な⼈材に遡及
- 58. この先に⾏くために必要なこと • リスク/デリバリ観点で避けてきた 既存⼤規模事業への取り組み • 数百億を売り上げる事業かつ、 型化された運⽤⽅法もあるので 変えに⾏くハードルが⾼い • 本当の意味で組織を変えるには ここを改善する必要がある 58 サービスレベル⾼ サービスレベル低 ⼤規模⼩規模 既存⼤規模 事業
- 60. いくつもの切り⼝から案件化 • 技術的負債を解消する案件 • システムを⼀部からリプレイスしていく案件 • 事業の成⻑と技術の成⻑にギャップがあった部分を解消する 60 時間軸 成⻑度 事業成⻑ 開発成⻑ このギャップを解消 短期成⻑のために 中期視点が抜けた場合、 導くのはエンジニアの役割
- 61. ⼤きくて巨⼤なものを⼩さくする • いきなり⿊を⽩にはできない • ⼤きくて⿊い箱 を細切れにして 改善しやすくしていく • 改善サイクルをいかに早く回せるか （失敗したっていい） 61 巨⼤ 課題1 課題2 課題3 課題4 課題5
- 63. ⼈、事業、組織の成⻑スパイラルを回す • ⼈ – アウトプットで事業を成⻑させる • 事業 – 売上、利益で組織を成⻑ • 組織 – ⼈が成⻑できる仕事の創出 63 ⼈ 事業 組織 教育 売上、利益 貢献
- 65. 少しずつだが、結果がでてきている • タレント的なエンジニアの台頭 • エンジニアひとりひとりからの積極的な提案 • サービスを “⾒る” ようになった • プロダクトアウト型のシステム開発へ挑戦 • プロダクト志向エンジニア組織へ少しずつだが近づいている 65
- 68. スタート ゴール
- 69. スタート ゴール
- 70. スタート ゴール
- 73. スタート ゴールゴール ゴール ゴール ゴール ゴール ゴール
- 74. すべてがゴール = 多様性を許容
- 75. まとめ • ⼤切なことは、いかに⽂化をつくるか • ⽂化をつくるために必要な施策をひたすら打つ – PDCAサイクルを回し続ける • 組織が⼤きくなれば考え⽅が散らばるのは当たり前 • 変化を楽しもう、多様性を許容しよう 75
- 76. 仲間を募集しています！！76
- 77. ご清聴ありがとうございました