この記事はOPENLOGI Advent Calendarの記事です。
私はVPoEという役職を通算6年間続けてきました。その中で、ここ数年でVPoEという役職が当たり前になってきたと感じています。私がVPoEを始めた当初は、VPoEがいるエンジニア組織はそれほど多くなく、今のように一般的な存在ではありませんでした。しかし、最近ではVPoEをエンジニア組織に置くのは当たり前となり、VPoE Summitといったイベントまで開催されるようになりました。
その中で、将来的にVPoEになりたいという人に出会う機会が増え、EMからVPoEになるために必要なことを質問されることも多くなっています。しかし、一般的なVPoEの定義と、実際にスタートアップやベンチャーで働いてみた際のVPoEの実態には乖離があると感じています。
そのため、スタートアップのVPoEになりたい人、VPoEを採用したい人、そしてVPoEとして自分の職務範囲に悩む方々に向けて、スタートアップのVPoEとは何なのかを整理したいと思います。
一般的なVPoEの定義
一般的には、CTOとVPoEの責任範囲は以下のように定義されることが多いと思います。
CTO : 技術への責任
- 技術戦略・方針
- 技術およびアーキテクチャの選定
- システム設計
- 品質管理
- 開発環境
- 開発手法・フローの最適化
VPoE : 組織への責任
- 組織の設計・構築
- 人員計画、アサイン
- 採用
- 人事評価
- 育成
- カルチャーの醸成
一部の領域ではCTOとVPoEの役割が重なることもあります。例えば、組織構築や育成、採用ブランディングに関しては、両者が連携して取り組むことが重要です。
CTOとVPoEの関係性は、図にすると下記のイメージになるかと思います。
一般的なVPoEの定義の問題
この定義自体には大枠で異論はありませんが、この定義にとらわれてはいけないと感じています。自分が所属している会社や事業、エンジニア組織にとって、エンジニアの採用・組織・人事評価といった要素が最も優先順位が高いのでしょうか？
VPoEはCTOと共にエンジニア組織の責任者であり、執行役員といったポジションを担うことも多いです。経営から期待されているのは、エンジニアリングやプロダクトを通じて事業成長に貢献することのはずです。
例えば、品質やパフォーマンスに課題があり、ユーザーからのチャーンが発生している状況を考えた場合、「私は組織のことしかやらない」と言ってCTOにすべてを任せるのは無責任です。課題を解決できる人が社内にいなければ、VPoEが真っ先に取り組む必要があります。
実際に私の前職では、組織や採用よりもプロダクトやプロジェクトの方針整理が最もクリティカルな課題であったため、そこから着手していきました。
現実的なVPoEの定義
現実的な定義としては、CTOにできないことを、全部やるのがVPoEだと思います。
VPoEは結局のところ、エンジニア組織のNo.2であり、CTOのパートナーです。もちろん、組織への責任を負っていますが、その上で優先順位を考え、技術に関することでも、プロダクトに関することでも、何でもやる姿勢が求められます。二人で協力して事業の成功に全力を尽くします。CTOのパートナーとして、CTOができない、あるいは苦手な部分はすべてVPoEが担当します。
現実的なCTOとVPoEの関係性は、図にすると下記のイメージになるかと思います。
前職でVPoEになった理由
例えば、私が前職でVPoEになったのは、CTOと経営層とのコミュニケーションがうまくいっていなかったことが理由でした。エンジニア組織と経営層の連携が取れていない状態だったため、会社としてやりたいことと、エンジニア組織で開発している内容が全く噛み合っていない状況でした。
そのうまくいかないコミュニケーションを改善するために、VPoEというポジションを設け、私も一緒にエンジニア組織を管掌することを提案しました。まさにCTOにできない部分を補完する役割を果たしました。
現職のVPoEとしての仕事
私の仕事は、採用や組織といった一般的なVPoEらしい業務が半分を占めていますが、残りの半分は一般的なVPoEの定義から外れる仕事です。具体的には、プロダクトの品質改善、パフォーマンス改善、QAチームの立て直し、UI/UXの方針整理、デザインチームのマネジメントなどを行ってきました。また、SREチームを自分の管掌に持ったこともあります。
事業を成功させるために、何でもやってきました。CTOが苦手と感じる優先順位が高い仕事については、自分が積極的に責任を持つようにしています。
VPoEに必要なスキルとマインド
以上の現実的なVPoEの定義を踏まえ、私がVPoEとして6年間続けてきた経験から、スタートアップのVPoEに必要なスキル・マインドをお伝えします。
事業への強いコミット
会社を成長させるため、ビジネスを成長させるためには、エンジニア組織のクリティカルな課題を見極め、それを解決するという思考が必要です。自分のできることややりたいことからスタートしてしまっては、本当に会社に貢献することはできません。
経営・ビジネスとのコミュニケーション
CTOが経営やビジネスとの連携が苦手なケースは一般的に多いと思います。そのため、VPoEには、経営・ビジネスを理解した上で、エンジニア組織のことを経営層に分かる形で説明できる必要があります。また、そのような観点から、セクショナリズムを持ち、排他的な傾向がある方は向いていないと思います。
どんなテーマでも50-70点を取る力
CTOのスキルに応じて、柔軟に様々な課題を扱う必要があります。初見のテーマであっても、それをやるべきであれば、すぐにキャッチアップし、100点満点は無理だとしても、50-70点を取る力が求められます。また、採用や育成を通じて、100点が取れる人材を生み出し、その分野を任せていくことも重要です。
圧倒的な強み
他のEMに負けない圧倒的な強みが必要です。
全ての領域で50-70点を取り続けるだけでは、大きな変化は生まれません。50-70点を維持しながらも、少なくとも1つ以上の領域で劇的な変化をもたらし、それを突破口にしていくことが求められます。
自身の強みを考える際には、下記の記事で広木さんが書かれているEM定義を軸に使う良いと思います。
メンタルタフネス
CTOが解決できないやっかいな課題は全て自分に回ってきます。6年間VPoEをしてきて、この仕事が楽だと思ったことは一度もありません。そのため、そんな大変な課題を粘り強く、そしてポジティブに解決していく必要があります。
最後に
今回は、スタートアップのVPoEの現実的な定義についてお話ししました。
この記事を読んで「スタートアップのVPoEって大変そう」と思った方もいるかもしれません。しかし、大変な分、VPoEとして課題を解決すればするほど、会社や事業も大きく変わっていくので、やりがいは大きいと思います。
VPoEの皆さん、そしてVPoEになりたい皆さん、一緒に頑張りましょう！！
Discussion