Skip to content

Instantly share code, notes, and snippets.

@noto
Last active March 21, 2024 10:33
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save noto/b497719a9961581148f0eff89290e8ac to your computer and use it in GitHub Desktop.
Save noto/b497719a9961581148f0eff89290e8ac to your computer and use it in GitHub Desktop.
VPoE の役割やスキル要件はどうあるべきか

VPoE の役割やスキル要件はどうあるべきか

  • 「エンジニアリング職能の全社リーダー」の役割があって、それを CTO と VPoE で分け合う形
    • 一般的に CTO は全社で 1 名、VP は複数名でも良い
    • CTO と VPoE が両方設置される場合の例
      • CTO が全体責任を担い、VPoE が組織面を移譲される形
      • 両者対等で技術面を CTO が、組織面を VPoE が担う形
    • 両者を統合した「職能の全社リーダー」の役割を定義し、それをどう分担するかという捉え方をすればいい

「エンジニアリング職能の全社リーダー」の役割とは?

会社によって、解決したい課題によっても変わる

  • エンジニアリング職能の質的・量的な拡大を担う
    • 全社エンジニアリングの方向性、戦略 (短期的/中長期的な計画) 策定・実行
      • 他社とは異なる「健全な偏り」「魅力」「ここで働く意味」を作る
      • 目線を上げる
        • 社内の最適ではなく、社外も見渡して、事業ドメイン内の最適を図る
      • 分解すると
        • 技術面
        • 人事・組織面
        • プロジェクト・マネジメント面
        • 品質保証面
    • 自律的、自己組織化された改善体制の構築・運営 (= 職能の自治組織)
      • cf. スクラム開発は自分たちで定期的に振り返り、自分たちで改善し続けるところに本質があり、それを「自己組織化」と呼ぶ
      • 間接的/直接的民主主義で現場の要望、課題を吸い上げ、整理、調整、優先順位付け
        • 間接的であれば、組織単位に代表者を出して、会議体を運営
        • 全社施策としての実施
      • 自分たちの裁量の範囲で解決できない場合 = 上位レイヤ (経営) に対して関与する必要があれば、そちらに持っていって決裁をとる (下記参照)
        • 施策予算の確保、支援制度づくりなど
    • 職能人事
      • 専門性の理解 (感情含め) が必要な部分が大きく、いわゆる「ビジネスパーソン」の感覚が通用しにくい
      • 分解すると
        • 採用
        • 育成
        • 異動調整、再配置
        • 評価 (特に全社横通しの評価調整)
          • 評価制度の職能単位の基準作成、改善も含む
    • リーダー陣に対するメンタリング (1 on 1 など)
      • 事業部の中にエンジニアリンググループがあると、GL の上長が事業部長になり、キャリア相談などが成り立ちにくい
      • リーダー陣を通して、全社的な 1 on 1 のネットワークを構築し、信頼関係、心理的安全性を構築する
        • 共通する課題発見を通して、自治組織での問題解決につなげる
        • 退職抑制の側面も
      • エンジニアリング領域の先頭を走るものとして、キャリアの方向性を背中で示す
  • 経営と職能をつなぐ、対話させる
    • 関係性は会社による
      • 経営陣に入り込んで、職能の観点を経営に反映させる
        • 経営陣に迎えたいレベルにあるかどうかにも依存する
      • 経営陣から見た、統一的な窓口
        • 経営 → 職能 の方向
        • 職能 → 経営 の方向
    • 経営陣と職能の通訳
      • それぞれ別の言語を話しがちなので、両方を理解して、両者が対話できるようにする、言語化する
        • 経営者から見ると、エンジニアは過大な要求をしがち
        • エンジニアから見ると、経営者はエンジニアリングについてあまりに不理解
  • 職能領域間で抜け落ちるものをカバーする、境界領域を超える
    • 例: エンジニアリングだけの問題ではなくて、実はプロダクト・マネジメントの問題でもある場合
    • エンジニアリング領域のベストプラクティスを、他職種に展開する

人材要件

  • 人物像
    • 経営陣から見て信頼できる人物か
      • 評価、異動調整など、重要な部分を任せることになる
      • この人との関係が崩れると、職能と経営との関係が崩れる単一障害点になる
    • 現場のエンジニアから信頼され、リスペクトされる人物か
      • いくら経営陣が信頼していても、現場の人が話を聞いてくれないと意味がない
      • 何らかの深さ、専門性がある方がリスペクトしてもらいやすいという面も
        • 下記の「ジェネラリストのおばけ」との関連だと「T 字型人材」
  • スキル
    • 上記の役割を担えるスキル・経験があれば OK
      • 全部経験している人は少ないので、領域を広げていけそうか? 人を巻き込みながらうまく分担できそうか?
      • 小さい規模でやってもらっている人に、より大きな規模にチャレンジしてもらう
      • メンタリングに関しては、賢さ、ロジカルさだけでなく、共感能力、傾聴力なども必要になる
    • 「広くエンジニアリング領域をすべてお任せする」という観点では、「ジェネラリストのおばけ」である必要がある
      • その問題を解決するために CTO と VPoE に分担されてきた
        • 現場レベルだと Tech Lead と Engineering Manager の分離
      • 視野・経験の広さと深さ、目線の高さ
      • 継続的な学習力、変化に対する柔軟性
    • 現状を深く理解し、それにリスペクトを払いながら、理想像 (現状からの目指すべき差分) を描いて、みんなを納得させ、巻き込みながら漸進的に変化させる力、粘り強さ
      • 一般に権力だけでトップダウンに変化を起こすことを、エンジニアは嫌う
        • 書籍『Team Geek』で紹介されている HRT (humility = 謙虚, respect = 尊敬, trust = 信頼) をベースにできるかどうかが、ベースラインになりつつある
      • 技術で第一線に立ち続けながら、上記をすべて担うのは難しいので、どのような役割分担をする人か?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment