【EOF2019】新米VPoEがまんまと落とし穴にはまったお話

by Kenji Sakai

Slide 1

Slide 1 text

新米VPoEがまんまと落とし穴にはまったお話 Oct 31, 2019 / #EOF2019 坂井　健治株式会社メディアドゥ

Slide 2

Slide 2 text

坂井　健治 VP of Engineering @saka0ken 2012年 4月　業務システム開発会社にエンジニアとして入社 Java・フロントエンドとか炎上プロジェクト多数経験 2017年10月　株式会社メディアドゥへ入社 About Me 2 株式会社メディアドゥ

Slide 3

Slide 3 text

3 今日の目的 Today’s purpose 0

Slide 4

Slide 4 text

4 何でDeNAさん, mixiさんの方に行かなかったんですか？笑

Slide 5

Slide 5 text

今日の目的 1. 旧態依然としたエンジニア組織を改革する際のハマりどころや・うまくいったことを紹介するので、同じ状況にいるマネージャーの方に参考にしてもらいたい 2. もう改革を終えてしまった方は、過去を懐かしみながら聞いてください(笑) 5

Slide 6

Slide 6 text

6 Agenda 2年前入社当時の技術本部 1 2年間で変えてきたこと 2 まんまとはまった落とし穴 3 意外とうまくいったこと 4 まとめ 5 会社紹介 6

Slide 7

Slide 7 text

7 2年前入社当時の技術本部 2 years ago 1

Slide 8

Slide 8 text

8 メディアドゥとは電子書籍の取次事業のシェア No1 東証一部上場 ※ エンジニアは約70名東京本社は竹橋駅直結、窓には皇居の緑 ※ メディアドゥホールディングスが東証一部上場企業

Slide 9

Slide 9 text

9 2017年度メディアドゥ右肩上がりで成長中！ ● 2017年度売上高 372億円 ● 電子書籍市場規模は2017年度2556億円に。2011年度の約4倍 ● 業界二位の当社が、業界一位の出版デジタル機構を買収 ● 次の事業を模索中

Slide 10

Slide 10 text

10 2017年度主要プロダクト難易度高めのプロダクト開発 ● 基幹システム（電子書籍取次）の統合・刷新 ○ 安定稼働はしていたが、10年以上構造に変化がなく、運用にかかるコストが高かった ○ 買収した出版デジタル機構の基幹システムと統合 ● 新事業に向けたサービス開発 ● ２つをやりながらの既存システムの運用・保守

Slide 11

Slide 11 text

11 2017年度技術本部人材面の課題山積み ● 基幹システムの統合・刷新と新事業に向けたサービス開発をリードするエンジニアがいない ● エンジニア50名のうち、約半数が新卒2〜3年目 ● 新卒はプログラミング未経験者 ● 中途エンジニアほとんど採用できていない ● 社外イベントにて「Media Doってエンジニアいたんですね。」

Slide 12

Slide 12 text

12 2017年度技術本部開発面の課題山積み ● 会社を支える電子書籍取次事業の既存システムの運用・保守が大変 ● 10年以上前と変わらない技術スタック ○ Javaと自社フレームワーク ○ オンプレミス ○ CIなし ● 開発手法は、ウォーターフォールでもアジャイルでもない、行き当たりばったりな開発

Slide 13

Slide 13 text

13 こういう状況になった背景 ● マネジメントが苦手な職人系CTOと、50名のエンジニア組織 ● マネジメント・採用が機能していなかった ● 外部との交流がなく、ガラパゴス化 ● 事業は成長していたので、社内では大きく問題視されてこなかった事業と組織の拡大についていけてなかった

Slide 14

Slide 14 text

14 改革をスタート ● CTOは人間的には素晴らしかったので、先導してもらいつつ、足りないところをやるつもりだった ● 2018年5月末、CTOが退任 ● 「え、俺やるんですか？」 ● 結局、新米VPoEと残ったメンバーで旧態依然とした組織を改革することに CTOが退任し、新米VPoEが改革することに

Slide 15

Slide 15 text

15 2年間で変えてきたこと Changes made in 2 years 2

Slide 16

Slide 16 text

16 技術スタック・開発手法 2年前 ● Javaと自社フレームワーク ● オンプレミス ● ウォーターフォールでもアジャイルでもない、行き当たりばったりな開発現在 ● Go ● AWS ● スクラム導入

Slide 17

Slide 17 text

17 AWS Summit 2019 Tokyoで登壇

Slide 18

Slide 18 text

18 エンジニア向け制度 2年前 ● 何もなし現在 ● 研修受講、資格取得、書籍購入の支援 ● PCの買い替え制度 ● 海外カンファレンス参加 ○ GopherCon 2019 ○ AWS re:Invent

Slide 19

Slide 19 text

19 GopherCon 2019へ参加

Slide 20

Slide 20 text

20 技術広報 2年前 ● 何もなし現在 ● 勉強会「MediaDo.go」の開催 ● 技術書典「Tech Do Book」の執筆 ● エンジニアブログ ● 技術カンファレンスへのスポンサー

Slide 21

Slide 21 text

21 技術書典 - Tech Do Book

Slide 22

Slide 22 text

22 採用 2年前 ● 「Media Doってエンジニアいたんですね。」 ● 中途エンジニア採用はエージェント経由のみ現在 ● 応募者数約10倍 ● 採用人数約8倍 ● リファラル採用、ダイレクトリクルーティング、Wantedly等の採用メディア

Slide 23

Slide 23 text

23 プロダクト 2年前 ● 基幹システムの運用・保守 ● 基幹システムの統合・刷新と新事業に向けたサービス開発が難航… 現在 ● 基幹システムの統合・刷新が順調に進行 ● ブロックチェーンを利用した新規コンテンツ流通プラットフォームを開発中 ● 他の新規サービス開発も進行中

Slide 24

Slide 24 text

24 まんまとはまった落とし穴 Traps we met 3

Slide 25

Slide 25 text

25 落とし穴① 組織内部のことをやりがち

Slide 26

Slide 26 text

26 改革スタートをした直後組織内部の課題解決に躍起になる ● VPoE就任して、改革開始！ ● まず目につくのはエンジニアからの不満、技術本部内部の課題 ● 組織の見直し、スクラム導入、エンジニア採用等々いろんなことを推進し始める

Slide 27

Slide 27 text

27 要件の変更多発多発する経営層・事業側との認識のズレ ● 基幹システムの統合・刷新について、進捗を経営層から何度も確認される ○ 経営層からみたときに、全く要求のずれたプロジェクトになってしまっていたことが判明する ● ある日突然「これからある事業に注力するので、エンジニアが数人ほしい」というリクエスト ● 事業側から、聞いたことのないプロダクトを運用・保守してほしいと言われる

Slide 28

Slide 28 text

28 何が問題だったか経営層・事業部との関係構築ができていなかった ● 経営層・事業部と定期的にコミュニケーションする機会がなかった ○ 技術本部のマネージャーが独断で要件定義をしていた ○ 経営層が今後やろうとしていることを把握していなかった ● CTO退任以前は、CTOと経営層・事業部でMTGをしていたが、CTOの開発案件の精査が厳しすぎて、上手くいっていなかった ○ 経営層・事業部が、外部の会社に開発を依頼していた ○ 事業部に、技術本部所属ではないエンジニアが数名いた ○ 技術本部で開発していないプロダクトの運用・保守を依頼された

Slide 29

Slide 29 text

29 やったこと事業部側との関係を再構築した ● 経営層・事業部との定例MTGを開催 ● 事業部側のエンジニアは全員技術本部に異動。エンジニアは全員技術本部所属に ● 開発を、まずは技術本部に依頼してもらうことにした。精査をして、その上で外部の開発会社を使うか判断した

Slide 30

Slide 30 text

30 なぜ問題が起きたか経営層・事業部との関係性は最初は見えにくい ● 適切な会議体がないとそもそもキャッチできない ○ 前CTOの引き継ぎが十分ではなかった ● 組織内部の不満の声のほうが大きく聞こえてしまう ● 経営層・事業部はエンジニアと見るポイントも違うし、共通言語も違うので理解を得るのが大変。心理的にはエンジニアとコミュニケーションしたくなる

Slide 31

Slide 31 text

31 学んだことエンジニアリングはビジネスを実現するもの ● 開発した製品の価値＝ビジネス、お客様への貢献 ● 開発内部の生産性や働きやすさを考える前に、エンジニアがしている開発が、100%ビジネスに貢献しているかを検討するべき

Slide 32

Slide 32 text

32 落とし穴② とにかく最新にしたくなる

Slide 33

Slide 33 text

33 改革スタートをした直後とにかく最新にしたくなる ● 外部の勉強会に行ったり、書籍読んで、最新の情報に触れると現状が駄目に思えてくる ● とくに改革時は、現状の組織と最新とのギャップが大きいので、最新がより魅力的に思える ● VPoEを惑わす最新の情報は溢れている ○ PM-TL-EM 体制、スクラム開発、リファラル採用、新規ツール導入等々

Slide 34

Slide 34 text

34 組織課題が足を引っ張る例えば、PM・TL・EM体制導入する ● 約半数が新卒2〜3年目で、TL・EMできる人不在。採用したいが、すぐに採用できる体制がない ● 経営層・事業部とのコミュニケーションがうまくいっていないので、PM置けない。置いても機能しない ● 周囲の同意が得られない。それよりも解決してほしいことがある ● 結果、周囲をかき乱しただけで、成果を出さずに終わる

Slide 35

Slide 35 text

35 学びまずは組織課題の解決を！ ● いきなり最新にしようとしても、進まずに頓挫する ● 大きくやっかいな組織課題は、目を背けたくなるが、本当にいろんなところで足を引っ張る（体験談） ● まずは大きな組織課題を一掃することを第一優先にする。 ● 旧態依然とした組織にいてここに来てる方、要注意！

Slide 36

Slide 36 text

36 落とし穴③ リファラル採用やりすぎ

Slide 37

Slide 37 text

37 改革スタートをした直後 VPoE経由のリファラル採用やりすぎた ● 本当にエンジニア採用は厳しい ● エンジニア採用で成果を出すには時間がかかるので、すぐに採用したい場合、即効性のあるリファラル採用に注力する ● VPoEの経由でテックリード・テックリード候補を6名採用

Slide 38

Slide 38 text

38 内部から批判の声 VPoEとしての信頼を失う ● そもそも優秀だと分かって採用しているし、意思伝達が早いので、リファラルしたエンジニアを要所で使いがちになる ● リファラル採用した人のSlackチャンネルつくってしまった ● リファラル採用してきた人を優遇しているように見える。派閥に見える ● エンジニア「坂井さんそういう人だったんですね。がっかり…」 ● VPoE「会社のためにやってるはずなのに…」メンタル削られる

Slide 39

Slide 39 text

39 学び覚悟した上でリファラル採用を ● リファラル採用が最も有効だったのは確か ● 今いる社員に配慮した行動・発言を ● リファラル採用したエンジニアが結果をだして、信頼を集めていけば解決する。時間かかるので、辛抱する必要ある

Slide 40

Slide 40 text

40 意外とうまくいったこと Unexpected achivements 4

Slide 41

Slide 41 text

41 技術スタックの大胆な変更 Java・オンプレミスの会社から、Go・AWSの会社へ ● システムの安定性・継続性を重視するマネジメントの理解を得るのは苦労した ● パフォーマンス良好・みんなの開発スピードもあがった（詳しくは Go Conference 2018 Springの登壇資料みてください） ● 採用時に非常に好印象

Slide 42

Slide 42 text

42 技術本部全員で考える働く環境改善イケTech会議の開催！ ● エンジニア向け制度が何もなかったので、どこから着手していいのか困った。工数もかかるし優先順位もつけたい ● エンジニア全員から「どのような制度があれば社員が働きやすいか」アイデアを募る。アイデアを幸福度10段階とコスト10段階で評価。全員投票してどれを実現するか決める。 ● エンジニア全員の総意なので、納得感がある。人事と調整必要なときに説明しやすい。 ● みんなが主導してくれるので、VPoEの工数もあまりかからない

Slide 43

Slide 43 text

43 イケTech会議

Slide 44

Slide 44 text

44 数字で判断する eNPS（従業員エンゲージメント）の測定 ● 課題多めの組織を改革していると、不満の声が目立つ ● 変化することに抵抗あるメンバーもいる ● 一部の大きな声に過剰に反応しがちになる ● 数字をみると、いま組織がどういう状態か、客観的にわかる。大きな声に惑わされない ● みんなの意見に一喜一憂しない。VPoEの精神安定剤になる

Slide 45

Slide 45 text

45 技術顧問の利用経験豊富なCTO・VPoEにアドバイスしてもらう ● 元メガベンチャーの技術責任者を技術顧問として起用 ● 客観的なレビューと今後直面する課題・解決策の先取り ● 困ったときに人や会社の紹介も依頼できる ● ニーズに合った技術顧問をみつける必要がある ○ 会社のフェーズ・風土によって直面する課題が異なる ○ 弊社でスタートアップのCTOは機能しない ○ 技術課題を見てほしいか、マネジメント課題を見てほしいか

Slide 46

Slide 46 text

46 まとめ Conclude 5

Slide 47

Slide 47 text

47 まとめ ● 組織内部のことをやりすぎ ● とにかく最新にしたくなる ● リファラル採用やりすぎ新人VPoEは3つの落とし穴に注意落とし穴にはまるのは悪いことではないその後の対応を責任もってやるのが大事

Slide 48

Slide 48 text

48 会社紹介 Introduction of Media Do 6

Slide 49

Slide 49 text

49 作者電子書店読者情報の集積出版社電子書籍の取次事業

Slide 50

Slide 50 text

50 メディアドゥの歴史 505億当社沿革 1996 年 : 名古屋市に有限会社フジテクノを設立 1999 年；名古屋市中村区名駅に株式会社メディアドゥを設立 ( その後、2 社が合併 ) 2006 年：電子書籍事業スタート 2013 年：東証マザーズに上場 2014 年：名古屋から東京へ本社移転 2016 年：東証第 1 部に市場変更 2017 年：株式会社出版デジタル機構を完全子会社化、持株会社体制へ移行

Slide 51

Slide 51 text

MISSION 著作物の健全なる創造サイクルの実現 VISION ひとつでも多くのコンテンツを、ひとりでも多くの人へ

Slide 52

Slide 52 text

52 メディアドゥグループ

Slide 53

Slide 53 text

53 電子書店書誌デ　タを提供ー探す・買う読者読む (70,000req/sec)  100万冊、 1億ページのコンテンツを CDN上に配置電子書籍の取次システム

Slide 54

Slide 54 text

BLOCKCHAIN ブロックチェーン技術を用いた新たな電子書籍流通プラットフォーム開発

Slide 55

Slide 55 text

55 今後の課題 ● 電子書籍流通システム統合・刷新後の開発 ● ブロックチェーンを利用した新規コンテンツ流通プラットフォーム開発を成功させる ● 新規製品の開発を継続的に実現できる開発体制の構築 ● PM-TL-EM 体制つくる

Slide 56

Slide 56 text

56 日本を代表するテクノロジーの会社へ

Slide 57

Slide 57 text

We’re Hiring ! ● Engineer ● Engineering Manager ● Product Owner https://www.mediado.jp/mediado/recruit/

Slide 58

Slide 58 text

No content