半年でテック組織が10倍に成長、VPoEの役割とEMとの違い
背景
コロナ禍を契機として、様々な企業でDX（Digital Transformation）の推進が求められています。そのため、エンジニアの需要がますます増加傾向にあり、それに伴って重要性が高まっているのが「エンジニア組織作り」です。近年では、多くの企業でこの課題を解決していくためにVPoE（Vice President of Engineering）を設置しています。
私は、これまでにスタートアップ企業における10名程度のチームのマネージャーや、大企業におけるテックリード兼チームリーダーとして5年ほどEM（Engineering Manager）を経験してきました。そして、現在はVPoEとしてエンジニア組織作りに取り組んでいます。本記事では、これまでの経験を元に、VPoEの役割についてEMやCTO（Chief Technology Officer）との違いをお話しします。
荒井 勇輔（@arara_jp）
2006年、ヤフー株式会社入社。Yahoo!コミック、Yahoo!ブックスの開発に従事。
2011年、株式会社VASILY入社。iOSアプリの開発を担当し、フロントエンド開発事業部長としてフロントエンド開発を統括。
2018年、グループ会社統合により、株式会社ZOZOテクノロジーズ（現株式会社ZOZO）に所属。テックリード、ZOZOTOWN iOSリーダーとして、同社のiOS組織開発を主導する。
2021年10月、株式会社GENDA入社。VPoE兼プロダクト開発部部長に就任。
VPoEの役割
VPoEとは、エンジニア組織のマネジメント責任者です。エンジニア組織を成功に導くために、主に以下の課題解決に注力します。
エンジニア採用・育成
組織編成
人事制度、文化醸成
環境整備
開発プロセスの構築・改善
ジョブマネジメント
ピープルマネジメント
技術広報
これらは組織の規模や状況に応じて、内容や関わり方に差がありますが、どの組織でも大枠は変わりません。会社や事業の成功に向けて、エンジニア組織の観点から解決に向かうのがVPoEです。
VPoEは必要か
前述の「VPoEの役割」から分かる通り、VPoEが担うことの大半は基本的には組織の誰かが既に担っている内容です。採用や人事制度に関することであれば人事が担うことが多く、開発プロセスの構築やメンバーのマネジメントは開発リーダーやEMが担うことが多いでしょう。また、これらをCTOがリードしている企業も多いです。そのような状況において、VPoEを設置する意義として以下の利点が挙げられます。
CTOと責務を分けることで、CTOが集中する領域が特定できる
プロジェクトやプロダクト単位ではなく、大局的な視点でエンジニア組織全体をマネジメントできる
CTOとVPoEの責務
「エンジニアの責任者」というとCTOのイメージが強いでしょう。そのCTOとVPoEはそもそもの役割が異なります。CTOは技術的な観点から経営課題の解決に取り組むのに対し、VPoEはマネジメントの観点からエンジニア組織が正しく機能してる状態にすることが求められます。役割を分離することで、CTOが集中すべき領域が明確になります。その結果、本来CTOに求められていた「技術を用いた経営課題の解決」に注力できるようになります。
明確に責務を分けられたら良いのですが、実際に責務を分けようとすると、その分け方は非常に曖昧でケースバイケースの判断が求められます。CTOがVPoEの役割を担っていることもあれば、VPoEが技術選定を行うこともあります。私が所属するGENDAでは、下図のように責務を整理しました。
分け方は千差万別ですが、「CTOとVPoEはお互いが良き理解者であり、壁打ち相手であり、互いに尊重しあえること」は共通するあるべき姿です。
EMとの違い
EMも「エンジニア組織をマネジメントする役割」を担います。VPoEは大局的な視点から組織を検討していく点でEMと異なります。EMは開発チームの能力を引き出しながら生産性を向上させ、プロダクトやチームの成功に貢献していきますが、VPoEは構造を作り、組織全体の成功に貢献していく必要があります。
例えば、キャリアに悩むメンバーがいた際に、1on1を通してメンバーの中長期的なキャリアを支援していくEMは多いでしょう。私もEMの頃は、定期的な1on1を実施し、メンバーのキャリアを一緒に考えていきました。
しかし、VPoEという立場になり、EMとして行っていなかった新たな行動が必要となります。その一例を以下に示します。
EM
組織のキャリアラダーとメンバーの能力を把握した上で、1on1や行動、スキルアップを促す
ジョブ・ディスクリプションを理解し、タスクのアサインを通して、定義を満たすような能力開発をする
VPoE
成長ビジョンとなるキャリアラダーを作成する
行動指針となるジョブ・ディスクリプションを定義する
このように、「メンバーのキャリア支援」という点だけを見ても、その対象が異なってきます。EMは個人に向き合うのに対し、VPoEはエンジニア組織の構造に向き合います。
また、これにより能力を発揮する対象も変わってきます。マネージャーの重要な能力に説明責任（アカウンタビリティ）がありますが、EMはプロジェクトや開発メンバーに対して説明責任を負うのに対し、VPoEは会社の経営陣をはじめとした様々なステークホルダーに対して組織の妥当性を示していく必要があります。
GENDAにおける組織立ち上げ事例
ここまで、VPoEの役割やCTO・EMとの違いを紹介しました。次に、私がGENDAのVPoEとして行ってきた具体的な事例を、EMの頃との差異に焦点を当てて紹介します。
株式会社GENDAの概要
まず、GENDAの企業とエンジニア組織の沿革を簡単に紹介します。GENDAは世界一のエンタメ企業を目指し、M&Aを主軸として事業の拡大をしている会社です。2018年に創業し、現在はアミューズメント施設「GiGO」の運営が大きな事業となっています。創業当初はエンジニア組織がなく、2020年から前任のCTO（現CPO）が一人でエンジニア組織化に向けた改革を進めてきました。2020年12月、大企業であるセガ エンタテインメント（現 GENDA GiGO Entertainment）がグループに参画し、事業領域・プロダクトが大幅に変化しました。会社が急速に成長する状況の中で、グループ全体をテクノロジーの力でより成長させていくため、2021年10月にエンジニア組織を立ち上げました。
入社時の状況
私がGENDAに入社した当時は、前任のCTOがエンジニア組織に関する課題をすべて担当していました。
大企業がグループに参画したことにより、情報システムの統合という優先的に取り掛かるべき課題が誕生しました。そして、それと同時にIT部門を収益の出せるプロフィットセンターにしていく必要性もありました。規模が大きくなればなるほど、一人で担える範囲の限界が顕在化してきます。技術領域、採用、マネジメントが手薄になっていく状況であり、 いわゆる「VPoEの領域」が手薄になることで、「社員採用の低迷」「開発の停滞」というエンジニア組織の問題が浮き彫りになっていました。
社員採用の低迷
当時のGENDAは、2021年10月の組織立ち上げまで、エンジニアの正社員の採用は行っていませんでした。そのため、受託プロジェクトを短期で内製化するために、業務委託のみでチームが形成され開発が進んでいました。目的を達成するためには非常に合理的なアプローチです。しかし、中長期的な視点で考えると正社員採用が必要であり、プロダクトの規模、数が増えるにつれ問題が顕在化していきます。
開発の停滞
短期間で結果を出す必要がある開発タスクを抱え、チームは短期的思考が強い傾向となり、いわゆる「レッド組織」と呼ばれる組織の特徴を持っていました。
当時のCTOのリーダーシップに依存した意思決定が中心の組織になっており、CTOの不在期間が発生すると、そのまま開発の遅延に直結し、開発効率の低下を引き起こします。このような状況に加え、業務委託という性質が合わさると組織への定着率は低くなりがちです。当時の業務委託の4ヶ月以後の定着率は50%という状況でした。よって、短期的に結果を出すためのジョブマネジメントとピープルマネジメントの両方を必要としていました。
VPoEとして取り組んだ施策
前述の問題を解決すべく、CTO・CPO・VPoEの体制に再編しました。エンジニアキャリアを持ちつつも本来の強みが事業戦略であるCTOはCPOへ役割を変え、新たに後任のCTOとVPoEが就任しました。
私がVPoEに就任し、優先的に着手したのは以下の2点です。
採用計画の立案と実施
短期的なプロダクト開発の戦略
冒頭で述べたように、VPoEは会社や事業の成功に向けて、エンジニア組織の観点から解決に向けて取り組みます。既に動いているプロダクトの組織的な課題を把握し、状況を見極め、取り掛かる優先度を随時変えて取り組んでいきました。
採用
初めに着手したのは「採用」に関する全般の業務です。エンジニア組織を立ち上げたとしても、人がいなくて意味がありません。特に、GENDAではエンジニアの正社員採用が低迷しているという課題がありました。業務委託に依存した組織ではスケールする上で限界が感じられるため、正社員の採用は最優先事項として取り掛かりました。
採用業務は、多くの会社で人事が以下のようなプロセスで取り組んでいます。
採用計画の立案
求める人材の定義
組織の魅力の言語化
応募者の選定
アトラクト
育成・定着
上記のような業務を行う際に、専門性の高い職種を採用する場合には、その専門職の知見が必要です。エンジニア採用においても、会社が必要としている技術の把握の段階から、エンジニアの協力が不可欠です。また、エンジニア組織の将来像を考えた上で、その戦略を立てて進めないといけません。
GENDAでは以下のように人事との役割を分け、採用を進めていきました。
組織立ち上げ時期で、エンジニア採用に関して何も整備されていない状態でした。そのため、多くの権限を移譲してもらい、採用を進めています。
採用計画の立案
VPoEが意識すべき点は、短期的な採用に加えて「中長期で成長を続けるエンジニア組織」にするための採用です。会社の事業計画と照らし合わせ、その上で以下のような人材をどのタイミングで採用していくべきかを検討し、立案していきます。
構想した将来の組織で、中核を担うキーパーソン
特定の領域に長けたスペシャリスト
事業拡大に伴うシステムのリプレイスを遂行するエンジニア
会社が投資していく事業のR&D人材
GENDAは、正社員のエンジニアが不在の状態でも、多くのユーザーを抱えたプロダクトが稼働している状況でした。事業の拡大も非常に早いため、短期的に数十名規模のエンジニア組織が必要になることは容易に想像できます。この状況を加味し、人員計画では各プラットフォームの中核を担うリードエンジニア獲得を優先させました。リードエンジニアはプロダクト開発部に集結させ、文化醸成とグループ全体のプラットフォーム別の開発方針を決定した後、これらのエンジニアを中心としたチーム・組織化を進めていく方針です。
採用計画の立案は、EMの時にも業務として存在していましたが、その頃は「プロダクト・チームに不足している人材を定義」し、採用計画を立てていました。しかし、VPoEとして立案する際には「会社の事業戦略を把握し、将来のエンジニア組織に不可欠なポジションを定義」し、採用計画を立てることを意識しています。現在のプロダクト開発に必要な人材を採用するのであれば、EMや現場のエンジニアが担当する方が適しています。しかし、そこにVPoEが加わることで、エンジニア組織の形成責任が明確になり、中長期的な組織ロードマップを策定して採用を進めることができます。
求める人材の定義
次に技術的な視点から、具体的な求める人材定義をしていきます。
GENDAでは、大きく分けると「不足ポジション」「技術スタック」「経験」という3つの軸で定義しました。
技術スタックを考える際には、現行で使われている言語やフレームワークを強く意識していません。例えば、いくつかのプロダクトではPHPでバックエンドのシステムが構築されていますが、将来の技術スタックにはGoを用いようとしているため、Goのスキルを持った人を採用しています。
そのため、技術スタックよりも「経験・意欲」を重要視しており、「サービスのリプレイスや新規立ち上げに前向きに取り組んでいける人」という定義をしています。また、「エンジニアの採用ができるエンジニアか」という点も初期の観点に入れておくと良いでしょう。
これらの内容をエンジニアキャリアを歩んでいない人が行うには難易度が高いため、人事はエンジニアを巻き込んだ上で採用業務を進めていく必要があると言えます。EMの頃は、プロダクト・チームに必要なポジションやスキルセットを定義して人事に伝えていくという関わり方をしていました。VPoE就任後は、数年後のエンジニア組織全体の技術スタックや役割をイメージした上で人材を定義するとともに、採用に関わるエンジニアを指名しています。
アトラクト
現在はエンジニアの売り手市場です。そのため、アトラクト、つまり会社に魅力を感じて選んでもらうことが重要です。自社のプロダクトに対する技術的な理解だけでなく、競合他社を理解した上で、自社でエンジニアになることのメリットを伝えていく必要があります。
アトラクトの手段として、以下のものが挙げられます。
チームメンバーとの会話機会のセッティング
経営陣との会話機会のセッティング
開発プロセスの説明
エンジニア組織の実績の開示
キャリアパスの説明
近年はリモート環境が主流となり、副業やフリーランスという働き方も選択しやすくなっています。自社を選んでもらうためにも、VPoEが中心になって、エンジニア採用のコミュニケーション設計を進めていくことが必須です。EMの頃は、会社の制度を理解し、面談や会食を通して自社の魅力を伝える動きをしていました。しかし、VPoEの場合は「魅力的な組織の構造を作る」ことが重要になってきます。そのため、会社として採用活動を進めていく上で、会食などの仕組み作りや、そのための予算確保をしていく必要があります。これらはEM業務の延長線ではなく、VPoEとして新たに身につけるべき知見のひとつです。
GENDAにおける採用施策の効果
前述のような採用の取り組みを実際に行い、エンジニアの正社員が不在の状態から脱却し、半年で6名のリードエンジニア採用を実現できました。VPoEの存在により、エンジニア組織の構築が進んだ事例と言えるでしょう。また、CTOが担っていた業務がCPOやVPoEに分解され、CPO直下にPdMやデジタルマーケターといった採用も進んでいます。半年でエンジニア組織の規模が10倍になりました。今後はリードエンジニアを中心としたチーム・組織化のために、さらに採用を加速させていきます。
短期的なプロダクト開発の戦略
次に、もう一つの問題である「開発の停滞」の取り組みを紹介します。採用は多くの場面で最優先で取り掛かるべき課題です。しかし、既に運用されているプロダクトがある場合、プロダクト開発の優先度が高くなることもあります。特に、期日が決まっているような開発タスクを抱えている場合は、その開発自体を遅らせるわけにはいきません。GENDAでも、エンジニア不足の不安がある状況で、システム移行日が決まった案件を抱えていました。しかし、正社員の採用では入社までのリードタイムが出てしまいます。解決策として、正社員の採用と並行して、業務開始までのリードタイムが正社員よりも短い、業務委託の採用も進めました。
また、新規の業務委託採用だけでなく、グループ会社間でエンジニアリソースの調整も実施しています。VPoEとしてグループ会社全体のエンジニア組織を見ているため、単体のプロダクトや会社ではなく、グループ会社としての過不足を把握することが可能となっています。
働く人の考え方、スキルを把握し、開発プロセスを見直す
業務委託のみで形成された組織は、特定の個人の能力に依存したものでした。各プラットフォームのチームは必要最小限の人数で構成され、短期的思考が強い集団となりがちです。「業務委託に依存した組織はスケールする上で課題がある」と述べましたが、この短期的思考が、まさに一番大きな課題だと感じていました。会社や状況によって最適な組織形態は異なります。そのため、一概に「悪い」と言い切れませんが、直面している開発課題への解決方法や、将来に想定している組織像とは異なるものでした。ほぼ組織構図を持たず「無構造」とも言える状態を整理するため、エンジニアが集まる定例ミーティングには可能な限り参加し、プロダクトの開発プロセスを把握し、業務委託全員と1on1を実施しました。そこから、現場で働くエンジニアの考え方、スキルを知る機会を得るように努めました。
なお、無構造の集団であっても、以下の4つの条件が揃えば機能する、とも言われています（こちらは「エンジニアのためのマネジメントキャリアパス」で学びました）
課題解決指向であること
小規模で均質な能力であること
コミュニケーションのレベルが非常に高いこと
専門性が低いこと
参考：無構造の暴政
これを実現するために、短期的なプロダクト開発は「タスク思考」に、業務委託の採用は「専門性を低く」することを意識しました。なお「専門性が低い」ということは、「レベルが低い」という意味ではありません。詳しくは後述します。
課題指向
短期的な思考の強い集団の場合、目の前の課題とゴールを明確にする必要があります。
ローンチ日が決まっている案件のため、機能単位で開発タスクをチケット化し、MVP（Minimum Viable Product）を定義します。その上で、すべてのチケットに優先度をつけ、明確なタスク指向で開発に臨みます。業務委託のみで構成されたチームでは、プラットフォーム間の稼働時間の差も課題でした。そのため、開発が遅延しているプラットフォームの状況を鑑みてMVPを明確に定義しました。
「必要最小限の価値提供を考えたプロダクト開発」は一般的な手法であり、目新しいものではありません。ここでお伝えしたいのは、「初期段階でジョインするVPoEは包括的にエンジニアリングと向き合う必要がある」ということです。採用活動や制度整備だけでなく、状況に応じてタスクの優先度や期限の曖昧さ、プロジェクトの遅延にも向き合う必要があります。組織が大きくなり、これらを担うTech LeadやEMが増えてきた際には、RACIチャートなどを用いて責任範囲を明確にしていく役割を担うべきです。
低い専門性
ここでいう「低い専門性」とは、言い換えれば「属人化を防ぐ」ということです。高い専門性を持った人による属人化した状態が続くと、人的な単一障害点になり得ます。副業として働いている場合は、本業の稼働に左右させることも想定されます。また、契約が短期間なこともあるので、業務委託契約での属人化は特に防ぐべきです。そこで、可能な限り、採用時には複数のプラットフォームで活躍できる方を優先しました。
専任領域を減らし、複数人が関わる状態にします。その結果、属人化を防ぐだけでなく、コードレビューなども効率的に行えます。採用時だけでなく、1on1でも定期的に話題にして本人の意思を確認しつつ進めていますが、「複数の領域に挑戦したい」という方にはとても好評です。
GENDAにおけるプロダクト開発施策の効果
MVPで開発をしていくことで、リプレイスや新規サービスのローンチなど、半年でいくつもの結果も出すことができました。すべてのプロダクト開発が業務委託のみの状況から、「正社員 + 業務委託」というチームへ再編成するとともに、人的な単一障害点も徐々に減っています。その結果、安定したプロダクト開発が可能になっています。
GENDAは「持株会社にエンジニア組織がある」という珍しい会社です。この特徴を活かし、従来とは違ったエンジニア組織を作りあげていきます。
まとめ
「VPoEは開発部門のマネジメント責任者」という認知はとれてきましたが、実際の役割は会社の規模、フェーズによって様々です。今回、比較対象にしたEMも定義が難しい役割です。そのため、私がVPoEとして行っている内容を担当しているEMの方も多いでしょう。その曖昧さもあり、VPoEをキャリアとして考えている方にとっては、目指し方がはっきりせず、迷う機会も多いのではないでしょうか。
私がVPoEとして大事にしているのは「エンジニア組織の展望と大局観」です。EMの頃は単体のプロダクト・チーム・特定のプラットフォームという限られた範囲内で向き合っていました。しかし、VPoEは全体を通してエンジニア組織を成功に導くことが求められます。スキルとしては「EMの延長線上」にあることも多いため、まずは自身の管轄範囲だけでなく、他チーム・他プロダクトの状況を把握し、エンジニア組織全体に影響を与えられる提案をすることからスタートするのはいかがでしょうか。