「リーダー育成は早いうちから」エムスリーとマネーフォワードのVPoEが組織づくりの教訓を語る
近年、スタートアップの大規模調達や企業のDX投資増加によって、エンジニア組織は拡大、開発のプロセス自体も複雑化するなど、組織づくりを担うVPoEの重要性が高まっています。
とりわけ一定規模のエンジニア組織を抱えるメガベンチャーでは、VPoEがエンジニアの事業貢献や生産性の向上、組織づくりなどに幅広い領域で重要な役割を果たしています。
2021年10月20日に開催した「エンジニア組織づくり最前線 vol.2」ではエムスリー株式会社・山崎様と株式会社マネーフォワード・渋谷様をお招きし、メガベンチャーにおけるVPoEの役割や直面している課題、解決の取り組みなど語っていただきました。ファシリテーターはファインディ株式会社CTOの佐藤が務めました。
目次
登壇者プロフィール
山崎聡さん(エムスリー株式会社)@yamamuteking
大学院博士課程中退後、ベンチャー企業、フリーランスを経て、2006年、臨床研究を手がけるメビックスに入社。2009年、メビックスのエムスリーグループ入り以降、エムスリーグループ内で主にプロダクトマネジメントを担当する。2018年からエムスリーの執行役員。2020年4月からはエンジニアリンググループに加えて、ネイティブアプリ企画部門のマルチデバイスプラットフォームグループと全プロダクトのデザインを推進するデザイングループも統括。2020年10月より初代CDOに就任。
渋谷 亮さん(株式会社マネーフォワード)@ryoff
新卒にて株式会社アドウェイズに入社し、広告システムの開発を担当。その後GREEに入社し、広告システムの開発や新規事業開発を経験したのち、マネーフォワード入社。 クラウド請求書、会計・確定申告などの開発に携わり、クラウド給与・マイナンバーなど立ち上げを経験。 2018年よりクラウド開発本部長、VP of Engineeringを兼務。2020年より執行役員に就任。
事業成長や組織拡大に向けて「正解」が変わり続ける仕事
イベント冒頭では、お二人にとってVPoEとはどのような職種や役割なのか、ミッションや注力している課題について伺いました。 エムスリーの山崎さんは、VPoEという職種には大きく分けて二つあると説明し、自身が担う役割を語りました。
山崎さん：「一つ目は、創業時から在籍するCTOの責務を分割し、受け継ぐ形でVPoEが配置されるケースです。CTOのもとVPoEはEMのトップとして主に組織づくりへコミットします。
二つ目は、CTOが卒業してVPoEが立場を引き継ぐケースです。VPoEはエンジニア組織全体のトップを務めます。
私は元々前者でしたが、今は後者にあてはまります。エンジニア組織全体のトップとして、エンジニアリング組織と経営を接続し、組織全体をマネジメントする役割を担ってきました。
VPoEとしてのミッションは、エンジニア組織の力を最大化し、その力で医療従事者や患者、製薬企業の困りごとを解決すること。エムスリーは医療業界における課題解決に取り組む会社ですから、そこにエンジニアが貢献できているか、利益や投資対効果も含め、責任を負っていると捉えています」
今VPoEとして注力しているのは「エンジニアが解決すべき課題やユーザーの価値提供のために、力を発揮できるよう導くこと」と語ります。
山崎さん：「私自身も含め、エンジニアは基本的に『何を作っていても楽しい』と感じる人が多いと思うんです。売れないサービスを作っていても、作るプロセスは楽しめてしまう。それはエンジニアという仕事の魅力であり、悪魔の誘いでもあると思います（笑）
その誘惑に負けず、ちゃんと医療問題の解決やユーザーによりよいサービスを届けるという方向にメンバーを導くことに最も注力してきました。成果が出るチャンスを与えたいし、掴んでもらいたいし、見つけてもらいたい。そのためにメンバーが何にチャレンジすべきか、組織として何が必要か、常に考えています」
渋谷さん：「VPoEは単一の正解がない仕事だと思います。同じVPoEでもフェーズや事業形態、エンジニアの特性、新卒と中途のバランス、カルチャーなどによって取り組むべき課題は違う。
自分自身が色んなフェーズの組織を経験する中で、その正解のなさに向き合うのがVPoEなのかもしれないと感じています」
数年後も見据えて、組織を俯瞰するリーダー層を育成する重要性
続いて、VPoEとして働くなかで、困ったことや「あの時こうしておけば…」と後悔したことを佐藤がたずねます。
渋谷さんは「うまくいっていると思っていたが、単に課題を見つけられていないだけだった」という経験を振り返ります。
渋谷さん：「例えば、新卒採用を始めて優秀な方が大勢入社してくれていたとき。当然『よかった、うまくいっている』と認識しますよね。ですが、新卒が増えると、その分意識的にマネジメントレイヤーの中途社員を採用しないと、若手とマネジメントレイヤーのバランスが崩れてしまう。
あるいは、そこそこの人数を採用して組織を拡大したいとき、社内で採用にコミットしてくれる人を増やしたりしますよね。そうすると、その人たちは自分が現場で『必要だ』と感じているメンバーを採用する。その結果、現場で価値を発揮できる人ばかり増えて、マネジメントレイヤーとの均衡が取れなくなることもあります。
いずれも採用できた人数自体は増えていますから、一見順調に見えてしまう。ですが2、3年も続くと、課題が出てきて『あの時気がついていれば…』となる。
プロダクト開発において、数年後のデータ量を予測してアーキテクチャを設計しないと、知らず知らずのうちに負債が溜まってしまいますよね。組織もきっと同じなのだろうと感じています」
だからこそ、中長期での組織のバランスなども含め「現場では見えていない課題を見られる」VPoEを置くことが重要なのではと渋谷さんは付け加えます。
渋谷さん：「マネーフォワードでは、エンジニアが70名ぐらいのときに複数名のVPoEを配置したんです。私もそのタイミングで打診を受けました。
正直70人のエンジニア組織にVPoEが複数人って多すぎじゃない？と思ってたんです。でも、CTOとしては、3、4年後の採用人数を見据え、今のうちに同じ目線で課題を語れる人を増やすという意図があったそうです。
実際に数年が経つと、当時想定した人数と同じくらいのエンジニア組織になって、BtoBやBtoCなど扱う課題やビジネスコードの違うチームに分かれている状態。VPoEとして全体を見る人が一定数いるのは非常に意味があったと思っています」
「自分で何とかしなければ」と感じたら、誰かに任せてみるチャンス
続いて、山崎さんは最も困ったこととして「メンバーの退職」を挙げます。
山崎さん：「本人を応援したい気持ちが一番にあるとはいえ、組織を強化したり、事業を伸ばしたりするためにメンバーは宝です。一人でも欠けてしまうと正直『困ったな』と感じます。エースクラスのメンバーなら尚更です。
何より退職するにいたる原因はほとんどの場合、自分たちの側にある。エムスリーで言えば、相当に厳しい採用基準を設けていて、そこを乗り越えて仲間に入ってきてくれている。その仲間が辞めたいと思うのは、チャレンジできる環境を提供できなかったケースもあるのではと。
そこで浮上するのが、チームリーダーやEMなど中間層の育成課題です。退職の責任が一番重いのはVPoEですが、直接メンバーをマネジメントする中間層のメンバーがチャレンジ機会を提供できていないケースもあるからです。
表出しているのは退職という事象であっても、その根っこにリーダー育成の遅れなど組織の課題がある。これにどう対処するのかは最も困ったことであり、今も考えていますね」
そのうえで山崎さんは「早いうちにリーダー層を育てておくべき」と強調します。
山崎さん：「マネーフォワードで数年後を見据えてVPoEを複数人任命したというのは、素晴らしいエピソードだと思います。
VPoEをやっているとどうしても『自分で何とかしなければ』と感じて、問題解決に向き合ってしまいます。その場その場を何とかするために自分で動いて解決した気になってしまう。ですが振り返ってみると、その時に人を育成しておくべきだったとかは往々にしてあります。
CTOが数年先を見据えてアーキテクチャを構築するのと同じように、VPoEは組織のアーキテクチャを決めるのが仕事です。何とかせねばと手を動かしそうなときこそ、チームリーダーやEMに勇気を持って任せる、育てるチャンスなのだと思います」
チームの数を増やし、EMやテックリードを経験する機会を提供する
エムスリーやマネーフォワードではVPoEを担い得るEMやテックリードをどのように育成しているのか。二人が意識していることや実際の取り組みを共有しました。
山崎さんは「組織を細分化してチームを増やし、リーダー育成の環境を作り出している」と言います。
山崎さん：「エムスリーでは、階層の深い組織構造ではなく、横並びのチームが並ぶ文鎮型の組織構造を採っています。
総勢100名ほどのエンジニアリングチームですが、大きく16組のチームに分かれています。特定の事業を担当する8組と、横断的にエンジニアを支えるSREやAI機械学習のチームが8組という内訳です。16チームあれば少なくとも16人にはチームリーダーやEMを経験してもらう機会を提供できます」
リーダー育成の環境を生み出す仕掛けがあるという話を聞き、佐藤は「EMをやりたくないエンジニアも一定数いると思うが、誰に、どのように依頼をしているのか」と尋ねます。
山崎さん：「EMになりたい人が少ない問題はVPoEが直面する最大の壁ですよね（笑）
オライリーの『エンジニアのためのマネジメントキャリアパス』にも書かれていますが、基本的にエンジニアにはCTOタイプとVPoEタイプがいるそうです。
私の個人的な体感ですが、エンジニアには圧倒的にCTOタイプが多い。特にエムスリーはマネージャーを強制しない環境で、技術を探究したくて入社する人も歓迎しているので、EMやVPoEタイプの人は貴重です。
なのでEMやVPoEタイプの人は採用面接時からマークして、タイミングを見計らって本人のWillを確認します。その際は正直に『うちの会社はCTOタイプが多いので、EMが少なく大変なんだけど、協力してもらえないか？』と頼みますね」
マネーフォワードでも同じように、スモールチームを設け、機会を増やすよう意識してきたそうです。加えて育成については、3ヶ月や四半期に一度ほど、EMやテックリードと徹底的に話し合う場も設けていると言います。
渋谷さん：「丸一日かけて事業計画やビジネス状況、市場状況からマネーフォワードの未来を構想し、その未来におけるエンジニア組織とアーキテクチャについて議論します。
『EMやテックリードの数が何人ずつ必要か』や『10人、20人単位のチームをマネジメントできる人は何人必要か』などがみえてきたら『社内からアサインできるのか、外部から加わってもらうのか』や『アサインするなら今は若手だけど2、3年後にはスキルや経験が追いつく人はいるのか』などまで具体的に掘り下げ、見込みのある若手をチームから選んで機会を与えるなどのネクストアクションまで繋げています」
事業成長と個人の成長が噛み合い、生き生きと働ける“良い”エンジニア組織
具体的な育成方法の後は、少し抽象的な「良いエンジニア組織に共通する要素は？」というテーマについて意見を交わしました。
渋谷さんは「良い」の定義から、自身の考えを共有します。
渋谷さん：「事業が成長している状態、ユーザーの課題が解決できてる状態を『良い』と定義するなら、やはり『事業や組織自体の成長と、個人の成長を、両方感じられる組織であるか』は大事な要素だと思います。
この前『問題解決ブルドーザー』という記事を社内のエンジニアがシェアしてくれていました。記事では『問題の指摘、解決策の提示で止まっていたことを、ブルドーザーのようになぎ倒して解決していく』人をブルドーザーと呼んでいます。
こうした人がいるエンジニア組織は良い、強いと言えると思います。事業課題だけではなく、アーキテクチャや技術課題についても最後まで持っていく力のある人がいるかどうかですね」
山崎さんも渋谷さんの発言を受け、エムスリーにとっての「良い組織」の定義から、自身の考える良い組織を共有します。
山崎さん：「私たちにとっての良い組織とは、世界の医療を前進させられる組織です。これを実現することがエムスリーのゴールであり『良い』の定義だと捉えています。
と同時に、エンジニアが楽しく生き生きと働いていることも重要です。ビジネス的な価値とエンジニアが生き生きと働くことがうまく噛み合っている状態が、私たちにとっての『良い組織』を構成する大切な要素です。
現状、嬉しいことにエムスリーはエンジニアが非常に尊重される環境です。それはエンジニアがしっかり事業に貢献しており、ビジネスサイドが『エンジニアと一緒に事業を作っている』と認識しているからなんですよね。ビジネス的に価値を出さず、作っていて楽しいものばかり作っていても、その認識は生まれなかったでしょう」
山崎さんの回答を踏まえ、佐藤が「エンジニアがエンジニアリングに集中しながらも社内受託にならないような関係を築くのは大事ですよね」と言うと、山崎さんが「ビジネスサイドの心を一発で掴める方法」を紹介してくれました。
山崎さん：「もちろん全部が全部これで解決できるわけではないのですが、信頼を築くにあたって、スピード感は重要です。ビジネスサイドが期待するスピードより早く作る。当然早く作るためには品質が重要なので、品質とスピードがセットなんですけど。両立できると非常に喜ばれる。
例えば、外注すると2ヶ月かかるものを1、2週間で作っちゃうとか。ぜひ全国のVPoEやEMの方には、必殺技として覚えておいてもらえれば（笑）」
EMやVPoEの仲間と、正解のない“茨の道”を楽しみながら切り拓く
イベント終盤では、EMやVPoEの役割、KPIや目標設定をどう考えるかなど、多くの質問が上がりました。
まずは「二人がEMやテックリードに求めること、期待すること」についてです。
渋谷さん：「『ここを何とかしてほしい』という領域について、理想と現実のギャップから課題を発見し、解決していくこと。それによってEMはエンジニアが成長実感を得られる組織を実現する部分、テックリードは優れたアーキテクチャを作る部分を担ってもらえると嬉しいと思っています。
EMであってもテックリードであっても求めること、期待することは大きく変わらないと捉えています。“何か”の解決を任せたいときに、その“何か”が組織やプロダクト、アーキテクチャなのか。あるいはGoやRuby、JavaScriptなのかの違いなのかなと」
山崎さんは「エムスリーでは会社の文化として『こうしなきゃダメ』が存在せず、それぞれ自分が課題だと思う領域で解決に取り組んでもらっている」と語ります。あえてEMに一番求められることとしては「メンバーがイキイキとチャレンジできる仕組みづくり」を挙げました。
続いて「経営経験のないエンジニアがVPoE になった場合、目標やKPIはどのように設定すれば良いのでしょうか？」と具体的な質問が挙がりました。山崎さんは「エンジニアリング部門で「〇〇万円達成して欲しい」といった設定は難しいかもしれません」と語ります。
山崎さん：「売り上げのうち、エンジニアの貢献が何%とか、エンジニアだけで達成しなきゃいけないのかとか、話が複雑になってしまうので、私たちはもう少し大雑把に、会社全体の利益をエンジニアが支援する形で設定しています。まずは『会社全体の利益達成をVPoEの20％の評価にする』などから始めてみるのがいいのではと思います」
イベントの最後には、二人からVPoEとして働く同志や今後VPoEとして働いてみたい人へのメッセージを共有してもらいました。
山崎さん：「採用面接をしていると『今の会社でマネージャーになることを求められるが、現場で手を動かしたい』と転職を考えている人は本当に多い。社内にいるEMやVPoEタイプの人は貴重な存在ですから、私はVPoEとしてそうした人たちが価値を発揮しやすいよう最大限支援していきたい。
きっと今日見てくださっている皆さんも同じような状況を経験しているのではと思います。VPoEは茨の道ですが同志は沢山いるので、情報交換しながら頑張っていきましょう」
渋谷さん：「VPoEやEMが立ち向かう課題は正解・不正解があるのものではなく、フェーズによって正解が変わることすらある。だから『チームでこの課題を考えているの自分だけじゃないか？』と孤独感を感じる場面もあるはずです。
でも色んな会社の人が悩みながら同じ課題の解決に取り組んでいます。私自身も、社外の勉強会などでアイデアの壁打ちをさせてもらって、非常に参考になる意見をいただくことが多々あるので。ぜひVPoEとして頑張る人たちと、課題解決を楽しむ仲間になれたらと思っています」
