Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

2d85ecf421bba1cde3ddb5c22dd775ab?s=47 Kenji Sakai
October 31, 2019

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

EOF2019で登壇した際の資料になります。
入社してから2年間のエンジニア組織の改革について書きました。

2d85ecf421bba1cde3ddb5c22dd775ab?s=128

Kenji Sakai

October 31, 2019
Tweet

More Decks by Kenji Sakai

Other Decks in Programming

Transcript

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

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

    2017年10月 株式会社メディアドゥへ入社 About Me 2 株式会社メディアドゥ
  3. 3 今日の目的 Today’s purpose 0

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

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

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

    まとめ 5 会社紹介 6
  7. 7 2年前入社当時の技術本部 2 years ago 1

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

  9. 9 2017年度メディアドゥ 右肩上がりで成長中! • 2017年度 売上高 372億円 • 電子書籍市場規模は2017年度2556億円に。2011年度の約4倍 •

    業界二位の当社が、業界一位の出版デジタル機構を買収 • 次の事業を模索中
  10. 10 2017年度 主要プロダクト 難易度高めのプロダクト開発 • 基幹システム(電子書籍取次)の統合・刷新 ◦ 安定稼働はしていたが、10年以上構造に変化がなく、運用にか かるコストが高かった ◦

    買収した出版デジタル機構の基幹システムと統合 • 新事業に向けたサービス開発 • 2つをやりながらの既存システムの運用・保守
  11. 11 2017年度 技術本部 人材面の課題山積み • 基幹システムの統合・刷新と新事業に向けたサービス開発をリード するエンジニアがいない • エンジニア50名のうち、約半数が新卒2〜3年目 •

    新卒はプログラミング未経験者 • 中途エンジニアほとんど採用できていない • 社外イベントにて「Media Doってエンジニアいたんですね。」
  12. 12 2017年度 技術本部 開発面の課題山積み • 会社を支える電子書籍取次事業の既存システムの運用・保守が大変 • 10年以上前と変わらない技術スタック ◦ Javaと自社フレームワーク

    ◦ オンプレミス ◦ CIなし • 開発手法は、ウォーターフォールでもアジャイルでもない、行き当 たりばったりな開発
  13. 13 こういう状況になった背景 • マネジメントが苦手な職人系CTOと、50名のエンジニア組織 • マネジメント・採用が機能していなかった • 外部との交流がなく、ガラパゴス化 • 事業は成長していたので、社内では大きく問題視されてこなかった

    事業と組織の拡大についていけてなかった
  14. 14 改革をスタート • CTOは人間的には素晴らしかったので、先導してもらいつつ、足り ないところをやるつもりだった • 2018年5月末、CTOが退任 • 「え、俺やるんですか?」 •

    結局、新米VPoEと残ったメンバーで旧態依然とした組織を改革する ことに CTOが退任し、新米VPoEが改革することに
  15. 15 2年間で変えてきたこと Changes made in 2 years 2

  16. 16 技術スタック・開発手法 2年前 • Javaと自社フレーム ワーク • オンプレミス • ウォーターフォールで

    もアジャイルでもな い、行き当たりばった りな開発 現在 • Go • AWS • スクラム導入
  17. 17 AWS Summit 2019 Tokyoで登壇

  18. 18 エンジニア向け制度 2年前 • 何もなし 現在 • 研修受講、資格取得、 書籍購入の支援 •

    PCの買い替え制度 • 海外カンファレンス参 加 ◦ GopherCon 2019 ◦ AWS re:Invent
  19. 19 GopherCon 2019へ参加

  20. 20 技術広報 2年前 • 何もなし 現在 • 勉強会「MediaDo.go」 の開催 •

    技術書典「Tech Do Book」の執筆 • エンジニアブログ • 技術カンファレンスへ のスポンサー
  21. 21 技術書典 - Tech Do Book

  22. 22 採用 2年前 • 「Media Doってエンジ ニアいたんですね。」 • 中途エンジニア採用は エージェント経由のみ

    現在 • 応募者数 約10倍 • 採用人数 約8倍 • リファラル採用、ダイ レクトリクルーティン グ、Wantedly等の採用 メディア
  23. 23 プロダクト 2年前 • 基幹システムの運用・ 保守 • 基幹システムの統合・ 刷新と新事業に向けた サービス開発が難航…

    現在 • 基幹システムの統合・ 刷新が順調に進行 • ブロックチェーンを利 用した新規コンテンツ 流通プラットフォーム を開発中 • 他の新規サービス開発 も進行中
  24. 24 まんまとはまった落とし穴 Traps we met 3

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

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

  27. 27 要件の変更多発 多発する経営層・事業側との認識のズレ • 基幹システムの統合・刷新について、進捗を経営層から何度も確認 される ◦ 経営層からみたときに、全く要求のずれたプロジェクトになっ てしまっていたことが判明する •

    ある日突然「これからある事業に注力するので、エンジニアが数人 ほしい」というリクエスト • 事業側から、聞いたことのないプロダクトを運用・保守してほしい と言われる
  28. 28 何が問題だったか 経営層・事業部との関係構築ができていなかった • 経営層・事業部と定期的にコミュニケーションする機会がなかった ◦ 技術本部のマネージャーが独断で要件定義をしていた ◦ 経営層が今後やろうとしていることを把握していなかった •

    CTO退任以前は、CTOと経営層・事業部でMTGをしていたが、CTOの 開発案件の精査が厳しすぎて、上手くいっていなかった ◦ 経営層・事業部が、外部の会社に開発を依頼していた ◦ 事業部に、技術本部所属ではないエンジニアが数名いた ◦ 技術本部で開発していないプロダクトの運用・保守を依頼された
  29. 29 やったこと 事業部側との関係を再構築した • 経営層・事業部との定例MTGを開催 • 事業部側のエンジニアは全員技術本部に異動。エンジニアは全員技 術本部所属に • 開発を、まずは技術本部に依頼してもらうことにした。精査をし

    て、その上で外部の開発会社を使うか判断した
  30. 30 なぜ問題が起きたか 経営層・事業部との関係性は最初は見えにくい • 適切な会議体がないとそもそもキャッチできない ◦ 前CTOの引き継ぎが十分ではなかった • 組織内部の不満の声のほうが大きく聞こえてしまう •

    経営層・事業部はエンジニアと見るポイントも違うし、共通言語も 違うので理解を得るのが大変。心理的にはエンジニアとコミュニ ケーションしたくなる
  31. 31 学んだこと エンジニアリングはビジネスを実現するもの • 開発した製品の価値=ビジネス、お客様への貢献 • 開発内部の生産性や働きやすさを考える前に、エンジニアがしてい る開発が、100%ビジネスに貢献しているかを検討するべき

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

  33. 33 改革スタートをした直後 とにかく最新にしたくなる • 外部の勉強会に行ったり、書籍読んで、最新の情報に触れると現状 が駄目に思えてくる • とくに改革時は、現状の組織と最新とのギャップが大きいので、最 新がより魅力的に思える •

    VPoEを惑わす最新の情報は溢れている ◦ PM-TL-EM 体制、スクラム開発、リファラル採用、新規ツール 導入等々
  34. 34 組織課題が足を引っ張る 例えば、PM・TL・EM体制導入する • 約半数が新卒2〜3年目で、TL・EMできる人不在。採用したいが、 すぐに採用できる体制がない • 経営層・事業部とのコミュニケーションがうまくいっていないの で、PM置けない。置いても機能しない •

    周囲の同意が得られない。それよりも解決してほしいことがある • 結果、周囲をかき乱しただけで、成果を出さずに終わる
  35. 35 学び まずは組織課題の解決を! • いきなり最新にしようとしても、進まずに頓挫する • 大きくやっかいな組織課題は、目を背けたくなるが、本当にいろん なところで足を引っ張る(体験談) • まずは大きな組織課題を一掃することを第一優先にする。

    • 旧態依然とした組織にいてここに来てる方、要注意!
  36. 36 落とし穴③ リファラル採用やりすぎ

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

  38. 38 内部から批判の声 VPoEとしての信頼を失う • そもそも優秀だと分かって採用しているし、意思伝達が早いので、 リファラルしたエンジニアを要所で使いがちになる • リファラル採用した人のSlackチャンネルつくってしまった • リファラル採用してきた人を優遇しているように見える。派閥に見

    える • エンジニア「坂井さんそういう人だったんですね。がっかり…」 • VPoE「会社のためにやってるはずなのに…」メンタル削られる
  39. 39 学び 覚悟した上でリファラル採用を • リファラル採用が最も有効だったのは確か • 今いる社員に配慮した行動・発言を • リファラル採用したエンジニアが結果をだして、信頼を集めていけ ば解決する。時間かかるので、辛抱する必要ある

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

  41. 41 技術スタックの大胆な変更 Java・オンプレミスの会社から、Go・AWSの会社へ • システムの安定性・継続性を重視するマネジメントの理解を得るの は苦労した • パフォーマンス良好・みんなの開発スピードもあがった(詳しくは Go Conference

    2018 Springの登壇資料みてください) • 採用時に非常に好印象
  42. 42 技術本部全員で考える働く環境改善 イケTech会議の開催! • エンジニア向け制度が何もなかったので、どこから着手していいの か困った。工数もかかるし優先順位もつけたい • エンジニア全員から「どのような制度があれば社員が働きやすい か」アイデアを募る。アイデアを幸福度10段階とコスト10段階で評 価。全員投票してどれを実現するか決める。

    • エンジニア全員の総意なので、納得感がある。人事と調整必要なと きに説明しやすい。 • みんなが主導してくれるので、VPoEの工数もあまりかからない
  43. 43 イケTech会議

  44. 44 数字で判断する eNPS(従業員エンゲージメント)の測定 • 課題多めの組織を改革していると、不満の声が目立つ • 変化することに抵抗あるメンバーもいる • 一部の大きな声に過剰に反応しがちになる •

    数字をみると、いま組織がどういう状態か、客観的にわかる。大き な声に惑わされない • みんなの意見に一喜一憂しない。VPoEの精神安定剤になる
  45. 45 技術顧問の利用 経験豊富なCTO・VPoEにアドバイスしてもらう • 元メガベンチャーの技術責任者を技術顧問として起用 • 客観的なレビューと今後直面する課題・解決策の先取り • 困ったときに人や会社の紹介も依頼できる •

    ニーズに合った技術顧問をみつける必要がある ◦ 会社のフェーズ・風土によって直面する課題が異なる ◦ 弊社でスタートアップのCTOは機能しない ◦ 技術課題を見てほしいか、マネジメント課題を見てほしいか
  46. 46 まとめ Conclude 5

  47. 47 まとめ • 組織内部のことをやりすぎ • とにかく最新にしたくなる • リファラル採用やりすぎ 新人VPoEは3つの落とし穴に注意 落とし穴にはまるのは悪いことではない

    その後の対応を責任もってやるのが大事
  48. 48 会社紹介 Introduction of Media Do 6

  49. 49 作 者 電 子 書 店 読 者 情報の集積

    出 版 社 電子書籍の取次事業
  50. 50 メディアドゥの歴史 505億 当社沿革 1996 年 : 名古屋市に有限会社フジテクノを設立 1999 年;名古屋市中村区名駅に株式会社メディアドゥ

    を設立 ( その後、2 社が合併 ) 2006 年:電子書籍事業スタート 2013 年:東証マザーズに上場 2014 年:名古屋から東京へ本社移転 2016 年:東証第 1 部に市場変更 2017 年:株式会社出版デジタル機構を完全子会社化、持株会社体制へ移行
  51. MISSION 著作物の健全なる創造サイクルの実現 VISION ひとつでも多くのコンテンツを、ひとりでも多くの人へ

  52. 52 メディアドゥグループ

  53. 53 電子書店 書 誌 デ   タ を 提 供

    ー 探 す ・ 買 う 読者 読む (70,000req/sec)
 100万冊、 1億ページの コンテンツを CDN上に配置 電子書籍の取次システム
  54. BLOCKCHAIN ブロックチェーン技術を用いた 新たな電子書籍流通プラットフォーム開発

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

    PM-TL-EM 体制つくる
  56. 56 日本を代表するテクノロジーの会社へ

  57. We’re Hiring ! • Engineer • Engineering Manager • Product

    Owner https://www.mediado.jp/mediado/recruit/
  58. None