omuronの備忘録

個人的な備忘録

「VPoEが語るエンジニア組織づくり最前線vol.2」 #vpoe_findy 受講メモ

【エムスリー×マネーフォワード】VPoEが語るエンジニア組織づくり最前線vol.2

findy.connpass.com

「エンジニア組織ってどうやって作っていくの?」ということで聞いてました。

登壇者

  • スピーカー
    • 山崎聡さん/(エムスリー株式会社) @yamamuteking
    • 渋谷 亮さん/(株式会社マネーフォワード) @ryoff
  • モデレーター
    • 佐藤 将高(ファインディ株式会社)/ @ma3tk

パネルディスカッション

VPoE ってどんな職種?ミッションや課題と取り組みは?

  • 山崎さん
    • ざっくり2種類に分けれる
      • 創業 CTO の責務を分割して VPoE が配置される
      • 創業 CTO が卒業していなくなり VPoE が組織を引っ張る
        • 山崎さんはこっちのパターン
        • エンジニアリング組織と経営を結びつける
        • エンジニアリング組織のパフォーマンスを出す/収益を出す
        • 収益責任を持つ立場
    • 課題は自分で見つけて解決する
      • 自分で考えるのがミッション、上から指示しない
      • 成果が出るチャンスを与える、一緒に考えてあげる
    • エンジニアは売れなくても作るのは楽しい
      • 顧客に良いサービスを届けるために売れる方向に導くようにする
  • 渋谷さん
    • 山崎さんと同じく課題は自分で見つける、経営にコミット
    • VPoE は正解がない問に立ち向かう仕事
      • 時代や世の中によって正解が変わる
      • 壁打ち相手になる
  • 山崎さん
    • VPoE に気軽にチャレンジしてほしい
      • 重要だけどいないと困る仕事

エンジニア組織で困ったことやこうすればよかったというエピソードは?

  • 渋谷さん
    • 目の前の仕事に夢中になっているとき課題があるはずなのに見えてない
      • 上手くいってそうなときは課題が見つけられてない可能性
      • 例えば新卒採用でバランスをとるのが難しかった
        • 数年後にマネジメント層が足りなくなる
        • プロダクトの構造と同じ
          • 個別最適で採用を続けたりすると数年後に困る
          • 2〜3年後の組織構造を意識する
    • エンジニア70名ほどで VPoE を複数名配置
      • 任命されたけど多すぎじゃないかと思った
        • 採用を増やして組織を大きくしたときに CTO と同じ目線になるように増やしておきたかったと
      • 現場で見えない課題を見ることができる人が増えるのは大事
  • 山崎さん
    • エンジニアが退職するとき
      • エースが抜けると困るが、辞める人の応援はしたい
      • 退職原因は我々側にあるから反省すべき
        • 就職するためには厳しい条件があるのに辞めてしまう
      • チームリーダーなどの中間層の育成問題
        • 中間層でチャレンジが十分に行き渡ってない
        • リーダー育成を早いうちに行うべきだった
        • CTO がアーキテクトを育てるというのと同じ
        • 勇気を持って任せていく、自分で何でも解決しない

EM やテックリードの育成についてどのような取り組み?

  • 山崎さん
    • 小さいチームをたくさん作る
      • 縦じゃなくて横方向へ広げる
      • チームリーダーがチームの数だけ必要になる
        • 16チームある
        • 事業が新規に立ち上がるとチームを増やす
          • 最初は兼任チーム、起動にのると事業専任チーム
          • 半分は兼任で横断(QA,インフラ,AIなど)、半分は事業付きチーム
    • 技術が好きで入る人が多い
      • CTO タイプが多い、マネージャーを嫌がる
      • VPoE がいなくなる、チームリーダーは貴重
      • EM 適正がある人をマークして協力依頼する
  • 渋谷さん
    • 四半期に一度合宿して1日中未来を考える日がある
      • エンジニア組織とアーキテクチャを考える
      • EM やテックリードの数の候補が見える
        • 数年後そこに行けそうな人がチャレンジできる機会を作る

いいエンジニア組織に共通する要素は?

  • 渋谷さん
    • 事業がちゃんと伸びている
    • 組織と自分の成長が感じられる
    • 課題を一気に解決できる人
  • 山崎さん
    • 医療を前進させるのが我々にとって良い組織
    • ミッションに楽しくヒットするのが条件
      • ビジネスと噛み合わずエンジニアが満足するだけな状況は避ける
      • エンジニアが尊敬されているのは、ビジネスを支えているからこそ
      • ビジネスサイドに認められる働きをしている
        • とにかくスピードが大事
        • ビジネスサイドの考えるスピード感を超えると何より喜ばれる

FAQ

  • CTO と VPoE で違う点は?
    • 山崎さん
      • 技術ははっきりしていることが多い
      • ピープルマネジメントは曖昧なケースが多い
  • EM やテックリードにもとめていることは?
    • 渋谷さん
      • おまかせしたい領域の理想と現実のギャップを把握して解決していく人
      • EM とテックリードは領域が違う
        • ギャップを探すという点では同じ
    • 山崎さん
      • メンバーがイキイキ働く仕掛けをしていくことが大事
        • メンバーにチャレンジを与えれるようにする
  • 経営経験の無い人が EM になったとき売上/利益をどうコミット?
    • 山崎さん
      • 会社の利益を背負ってもらう
      • 利益の何割を達成するのを目標にするとか
  • EM ってなりたくてなれる?
    • 渋谷さん
      • なりたい人ならチャレンジの機会を与える
      • なろうと思ってもらうのが大変
      • 資質は生まれ持ったものではないので経験すればつく
        • Try&Error で学びの機会を与えて成長してもらう

所感

VPoE ってなりたい人を見つけるのが本当に難しそう。
EM も VPoE も「現場で手を動かすエンジニアを続けるのが辛くなった」から逃げて向かう先ではなさそうだし。
チームを動かしてピープルマネジメントもして、この辺りの仕事がおもしろいと感じれて、経営人との橋渡しをできるコミュ/語彙力も必要だろうし。
1か0で動かせない世界の仕事は大変だ。