EOF2019で登壇した際の資料になります。 入社してから2年間のエンジニア組織の改革について書きました。
新米VPoEがまんまと落とし穴にはまったお話Oct 31, 2019 / #EOF2019坂井 健治株式会社メディアドゥ
View Slide
坂井 健治VP of Engineering@saka0ken2012年 4月 業務システム開発会社にエンジニアとして入社Java・フロントエンドとか炎上プロジェクト多数経験2017年10月 株式会社メディアドゥへ入社About Me2株式会社メディアドゥ
3今日の目的Today’s purpose0
4何でDeNAさん, mixiさんの方に行かなかったんですか？笑
今日の目的1. 旧態依然としたエンジニア組織を改革する際のハマりどころや・うまくいったことを紹介するので、同じ状況にいるマネージャーの方に参考にしてもらいたい2. もう改革を終えてしまった方は、過去を懐かしみながら聞いてください(笑)5
6Agenda2年前入社当時の技術本部12年間で変えてきたこと2まんまとはまった落とし穴3意外とうまくいったこと4まとめ5会社紹介6
72年前入社当時の技術本部2 years ago1
8メディアドゥとは電子書籍の取次事業のシェア No1東証一部上場 ※エンジニアは約70名東京本社は竹橋駅直結、窓には皇居の緑※ メディアドゥホールディングスが東証一部上場企業
92017年度メディアドゥ右肩上がりで成長中！● 2017年度 売上高 372億円● 電子書籍市場規模は2017年度2556億円に。2011年度の約4倍● 業界二位の当社が、業界一位の出版デジタル機構を買収● 次の事業を模索中
102017年度 主要プロダクト難易度高めのプロダクト開発● 基幹システム（電子書籍取次）の統合・刷新○ 安定稼働はしていたが、10年以上構造に変化がなく、運用にかかるコストが高かった○ 買収した出版デジタル機構の基幹システムと統合● 新事業に向けたサービス開発● ２つをやりながらの既存システムの運用・保守
112017年度 技術本部人材面の課題山積み● 基幹システムの統合・刷新と新事業に向けたサービス開発をリードするエンジニアがいない● エンジニア50名のうち、約半数が新卒2〜3年目● 新卒はプログラミング未経験者● 中途エンジニアほとんど採用できていない● 社外イベントにて「Media Doってエンジニアいたんですね。」
122017年度 技術本部開発面の課題山積み● 会社を支える電子書籍取次事業の既存システムの運用・保守が大変● 10年以上前と変わらない技術スタック○ Javaと自社フレームワーク○ オンプレミス○ CIなし● 開発手法は、ウォーターフォールでもアジャイルでもない、行き当たりばったりな開発
13こういう状況になった背景● マネジメントが苦手な職人系CTOと、50名のエンジニア組織● マネジメント・採用が機能していなかった● 外部との交流がなく、ガラパゴス化● 事業は成長していたので、社内では大きく問題視されてこなかった事業と組織の拡大についていけてなかった
14改革をスタート● CTOは人間的には素晴らしかったので、先導してもらいつつ、足りないところをやるつもりだった● 2018年5月末、CTOが退任● 「え、俺やるんですか？」● 結局、新米VPoEと残ったメンバーで旧態依然とした組織を改革することにCTOが退任し、新米VPoEが改革することに
152年間で変えてきたことChanges made in 2 years2
16技術スタック・開発手法2年前● Javaと自社フレームワーク● オンプレミス● ウォーターフォールでもアジャイルでもない、行き当たりばったりな開発現在● Go● AWS● スクラム導入
17AWS Summit 2019 Tokyoで登壇
18エンジニア向け制度2年前● 何もなし現在● 研修受講、資格取得、書籍購入の支援● PCの買い替え制度● 海外カンファレンス参加○ GopherCon 2019○ AWS re:Invent
19GopherCon 2019へ参加
20技術広報2年前● 何もなし現在● 勉強会「MediaDo.go」の開催● 技術書典「Tech DoBook」の執筆● エンジニアブログ● 技術カンファレンスへのスポンサー
21技術書典 - Tech Do Book
22採用2年前● 「Media Doってエンジニアいたんですね。」● 中途エンジニア採用はエージェント経由のみ現在● 応募者数 約10倍● 採用人数 約8倍● リファラル採用、ダイレクトリクルーティング、Wantedly等の採用メディア
23プロダクト2年前● 基幹システムの運用・保守● 基幹システムの統合・刷新と新事業に向けたサービス開発が難航…現在● 基幹システムの統合・刷新が順調に進行● ブロックチェーンを利用した新規コンテンツ流通プラットフォームを開発中● 他の新規サービス開発も進行中
24まんまとはまった落とし穴Traps we met3
25落とし穴① 組織内部のことをやりがち
26改革スタートをした直後組織内部の課題解決に躍起になる● VPoE就任して、改革開始！● まず目につくのはエンジニアからの不満、技術本部内部の課題● 組織の見直し、スクラム導入、エンジニア採用等々いろんなことを推進し始める
27要件の変更多発多発する経営層・事業側との認識のズレ● 基幹システムの統合・刷新について、進捗を経営層から何度も確認される○ 経営層からみたときに、全く要求のずれたプロジェクトになってしまっていたことが判明する● ある日突然「これからある事業に注力するので、エンジニアが数人ほしい」というリクエスト● 事業側から、聞いたことのないプロダクトを運用・保守してほしいと言われる
28何が問題だったか経営層・事業部との関係構築ができていなかった● 経営層・事業部と定期的にコミュニケーションする機会がなかった○ 技術本部のマネージャーが独断で要件定義をしていた○ 経営層が今後やろうとしていることを把握していなかった● CTO退任以前は、CTOと経営層・事業部でMTGをしていたが、CTOの開発案件の精査が厳しすぎて、上手くいっていなかった○ 経営層・事業部が、外部の会社に開発を依頼していた○ 事業部に、技術本部所属ではないエンジニアが数名いた○ 技術本部で開発していないプロダクトの運用・保守を依頼された
29やったこと事業部側との関係を再構築した● 経営層・事業部との定例MTGを開催● 事業部側のエンジニアは全員技術本部に異動。エンジニアは全員技術本部所属に● 開発を、まずは技術本部に依頼してもらうことにした。精査をして、その上で外部の開発会社を使うか判断した
30なぜ問題が起きたか経営層・事業部との関係性は最初は見えにくい● 適切な会議体がないとそもそもキャッチできない○ 前CTOの引き継ぎが十分ではなかった● 組織内部の不満の声のほうが大きく聞こえてしまう● 経営層・事業部はエンジニアと見るポイントも違うし、共通言語も違うので理解を得るのが大変。心理的にはエンジニアとコミュニケーションしたくなる
31学んだことエンジニアリングはビジネスを実現するもの● 開発した製品の価値＝ビジネス、お客様への貢献● 開発内部の生産性や働きやすさを考える前に、エンジニアがしている開発が、100%ビジネスに貢献しているかを検討するべき
32落とし穴② とにかく最新にしたくなる
33改革スタートをした直後とにかく最新にしたくなる● 外部の勉強会に行ったり、書籍読んで、最新の情報に触れると現状が駄目に思えてくる● とくに改革時は、現状の組織と最新とのギャップが大きいので、最新がより魅力的に思える● VPoEを惑わす最新の情報は溢れている○ PM-TL-EM 体制、スクラム開発、リファラル採用、新規ツール導入等々
34組織課題が足を引っ張る例えば、PM・TL・EM体制導入する● 約半数が新卒2〜3年目で、TL・EMできる人不在。採用したいが、すぐに採用できる体制がない● 経営層・事業部とのコミュニケーションがうまくいっていないので、PM置けない。置いても機能しない● 周囲の同意が得られない。それよりも解決してほしいことがある● 結果、周囲をかき乱しただけで、成果を出さずに終わる
35学びまずは組織課題の解決を！● いきなり最新にしようとしても、進まずに頓挫する● 大きくやっかいな組織課題は、目を背けたくなるが、本当にいろんなところで足を引っ張る（体験談）● まずは大きな組織課題を一掃することを第一優先にする。● 旧態依然とした組織にいてここに来てる方、要注意！
36落とし穴③ リファラル採用やりすぎ
37改革スタートをした直後VPoE経由のリファラル採用やりすぎた● 本当にエンジニア採用は厳しい● エンジニア採用で成果を出すには時間がかかるので、すぐに採用したい場合、即効性のあるリファラル採用に注力する● VPoEの経由でテックリード・テックリード候補を6名採用
38内部から批判の声VPoEとしての信頼を失う● そもそも優秀だと分かって採用しているし、意思伝達が早いので、リファラルしたエンジニアを要所で使いがちになる● リファラル採用した人のSlackチャンネルつくってしまった● リファラル採用してきた人を優遇しているように見える。派閥に見える● エンジニア「坂井さんそういう人だったんですね。がっかり…」● VPoE「会社のためにやってるはずなのに…」メンタル削られる
39学び覚悟した上でリファラル採用を● リファラル採用が最も有効だったのは確か● 今いる社員に配慮した行動・発言を● リファラル採用したエンジニアが結果をだして、信頼を集めていけば解決する。時間かかるので、辛抱する必要ある
40意外とうまくいったことUnexpected achivements4
41技術スタックの大胆な変更Java・オンプレミスの会社から、Go・AWSの会社へ● システムの安定性・継続性を重視するマネジメントの理解を得るのは苦労した● パフォーマンス良好・みんなの開発スピードもあがった（詳しくはGo Conference 2018 Springの登壇資料みてください）● 採用時に非常に好印象
42技術本部全員で考える働く環境改善イケTech会議の開催！● エンジニア向け制度が何もなかったので、どこから着手していいのか困った。工数もかかるし優先順位もつけたい● エンジニア全員から「どのような制度があれば社員が働きやすいか」アイデアを募る。アイデアを幸福度10段階とコスト10段階で評価。全員投票してどれを実現するか決める。● エンジニア全員の総意なので、納得感がある。人事と調整必要なときに説明しやすい。● みんなが主導してくれるので、VPoEの工数もあまりかからない
43イケTech会議
44数字で判断するeNPS（従業員エンゲージメント）の測定● 課題多めの組織を改革していると、不満の声が目立つ● 変化することに抵抗あるメンバーもいる● 一部の大きな声に過剰に反応しがちになる● 数字をみると、いま組織がどういう状態か、客観的にわかる。大きな声に惑わされない● みんなの意見に一喜一憂しない。VPoEの精神安定剤になる
45技術顧問の利用経験豊富なCTO・VPoEにアドバイスしてもらう● 元メガベンチャーの技術責任者を技術顧問として起用● 客観的なレビューと今後直面する課題・解決策の先取り● 困ったときに人や会社の紹介も依頼できる● ニーズに合った技術顧問をみつける必要がある○ 会社のフェーズ・風土によって直面する課題が異なる○ 弊社でスタートアップのCTOは機能しない○ 技術課題を見てほしいか、マネジメント課題を見てほしいか
46まとめConclude5
47まとめ● 組織内部のことをやりすぎ● とにかく最新にしたくなる● リファラル採用やりすぎ新人VPoEは3つの落とし穴に注意落とし穴にはまるのは悪いことではないその後の対応を責任もってやるのが大事
48会社紹介Introduction of Media Do6
49作者電子書店読者情報の集積出版社電子書籍の取次事業
50メディアドゥの歴史505億当社沿革1996 年 : 名古屋市に有限会社フジテクノを設立1999 年；名古屋市中村区名駅に株式会社メディアドゥ を設立 ( その後、2 社が合併 )2006 年：電子書籍事業スタート2013 年：東証マザーズに上場2014 年：名古屋から東京へ本社移転2016 年：東証第 1 部に市場変更2017 年：株式会社出版デジタル機構を完全子会社化、持株会社体制へ移行
MISSION著作物の健全なる創造サイクルの実現VISIONひとつでも多くのコンテンツを、ひとりでも多くの人へ
52メディアドゥグループ
53電子書店書誌デ タを提供ー探す・買う読者読む (70,000req/sec) 100万冊、1億ページのコンテンツをCDN上に配置電子書籍の取次システム
BLOCKCHAINブロックチェーン技術を用いた新たな電子書籍流通プラットフォーム開発
55今後の課題● 電子書籍流通システム統合・刷新後の開発● ブロックチェーンを利用した新規コンテンツ流通プラットフォーム開発を成功させる● 新規製品の開発を継続的に実現できる開発体制の構築● PM-TL-EM 体制つくる
56日本を代表するテクノロジーの会社へ
We’re Hiring !● Engineer● Engineering Manager● Product Ownerhttps://www.mediado.jp/mediado/recruit/
saka0ken
yui_knk
mraible
track3jyo
kokuyouwind
os1ma
masatoshiitoh
syumai
hideg
shimataro
kinocoboy2
ufoo68
m_seki
colly
lemiorhan
swwweet
roundedbygravity
ufuk
brad_frost
skipperchong
rocio
akmur
sachag
cherdarchuk
aarron