VPoEの転職

こんばんは、今日は転職についてです。ご要望もいただき、たしかに母数が少なすぎてイメージがわかないトピックなので書きました。おそらくVPoE handbookの最後のアップデートになると思います。

具体的な社名やその評価についての内容はなく、一個抽象化した

- この職種特有の職探しを実際やってみての気付き
- そこから見えたVPoEが求められそうな会社のパターン
- この職種でミスマッチをなくすためにやってよかったこと
- 年収や条件について

などを書いた記事です。

似た立場で転職するとき、事前にこれを読んで追体験することで、半歩先を見据えながら上手に転職活動を進められたーとなってくれるのが一番嬉しいです。あくまでN=1の所感、事例にすぎなずそれをただ共有しているだけの記事であることは予めご了承ください。

要点を列挙していく形で淡々と書いていこうと思います。

需要はあるが求めている会社の母数は多くない

これはそうだろうなと考えていましたが、実際にもそう感じました。ポジションがあっても1社に1つという事情もありますが、後述する役割の部分で一致する会社が少ない印象でした。多いほど可能性も競争も増えるので残念なポイントではありますし、入りたい会社があってもやりたいことがない可能性がそこそこあるということにもなります。
一個受け入れておいたほうがいいことでしたので書きました。

肩書に固執しない

当たり前のことですが難しいことだと思います。一度VPなどの冠を持ってしまうと、きっとそれを捨てる怖さや不安を持つ人もいると思います。自分も抵抗がゼロではなかったです。

ですがやはり肩書つきのJoinというのは双方にリスクがあるもので、マネジメントできるかをまずチームにEMやTLとして入って数ヶ月なり半年後にVPに自然となってほしいと考えているところも一定あるようです。

もちろん同時に、いきなりVPoEで、CTOでという会社さんもあったので、ケースバイケースです。ですので候補者側のこちらがこだわりを持ちすぎず相手方のニーズをしっかり聞いて決めるスタンスが一番いいと思います。

役割の確認を入念にして見極める

これが一番重要と感じた点です。VPoEの転職で一番難しいのはこの役割のニーズと希望のマッチングだと思います。

というのもやってみて、この不一致するケースが多々ありそうだなとおもったからです。

早すぎるケース・遅すぎるケース・丁度いいタイミングの３つのパターンについてふれていきます。

早すぎるケース：

VPoEを必要とするフェーズがかなり先。具体的にいえば最小限の人数で構成された開発チームがまだ一個ない、もしくはパートタイムの方でまわりている外注状態で主軸のメンバーがいない、内製メンバーがいても古いアーキテクチャーやpivot後にフィットしない負債が多いコードベースで開発している、など。ビジネスがシステムより先行して成長した少人数チームなどによくあります。

こういったケースはそもそもマネジメントうんぬんの前に半年から一年かけていい人材・いいプロセス・いいチームをまず最小単位で一個つくることが求められています。できることではあると思いますが、今までの経験を活かす・チャンレンジするまでには2,3年時間がかかりそうなケースです。良し悪しは人それぞれですがしっかり考えて入る必要があります。

遅すぎるケース：

もうVPoEを必要とあまりしていないフェーズ。人は数十人以上いて揃いつつあり、あとは安定的に回すためのマネジメントがもとめられていたり、大きな変化が必要とされていないケース。やれることはもちろんあると思いますが、チャレンジングな仕事が相対的にすくなそうなケースです。平和ともとれますが、人によっては期待はずれともなりやすいと思います。

丁度いいタイミング：

もちろん丁度よいタイミングだなと思う会社のパターンもありました。

組織のフェーズｘニーズである程度わけられます。3つに分けました。

1.組織が10人前後ｘ20人になりそうだがマネジメントがいないケース。
このケースではCTOはいるがCTOは組織をあまり見るのが得意じゃないというケースは特によくあると思います。このケースはチャンスで、スケールする過程で今後VPoEの必要性は強まりつつ、少人数のためオンボーディングで難点となる既存メンバーとの関係性構築も相対的に素早くできる規模です。

2.組織が30名〜ｘチームを複数にしたい等の組織が複雑化するタイミングのケース。
既存のマネジメントラインはうまくまわっているが、拡大にともなって増員がお求められ、存在しない新しいチーム・マネジメントラインがうまれそうなタイミングの会社です。このケースもチャレンジングな仕事がありつつ、経験者にとって比較的動きやすい新しいチームの立ち上げの機会があります。事業が拡大、予算も広がりそうとなればなおよいタイミングだと思います。

3.組織が100人以上になった成長企業のケース。
エンジニアだけというよりプロダクト関連のメンバーがそのくらいになると、プロダクトチームだけで大きな組織の課題がでてきて、改革が必要とされることも多くなると思います。メンバーはそろっているが、少しレガシーな開発文化を変えたい（内製比率を高めたい、ウォーターフォールからアジャイルに一気にかえたい、情報発信やアウトプットが活発な組織にしたい等）ときなどは片手間でなく専任で開発チーム全体のマネジメントの責任をもつ人が必要になるので、少し大きすぎるかな？とおもっていても意外と中を見るとがらっと変化しそうというところはVPoEの経験がフィットするポジションがあると思います。

VPoEのニーズがある会社の4パターン

役割のところのとやや重複しますが、まとめておきます。

- 上場前で開発が20人前後でマネジメントがはじめて必要になったところ。
- 上場前で開発が30人以上でイケイケで組織拡大中のところ。
- 上場企業でビジネスは急成長で成功したが開発は弱く、これから盤石な開発組織をつくりたいところ。
- 上場して一定たって、経営戦略から開発組織の一新や根本的な改革をしたいところ。

この４つのパターンがエンジニアリングの高度なマネジメント課題を抱えてやすいケースだと思います。

自分が会社選びで今回必ずやったこと

最後に個人的にですが、具体的にどういったことに気をつけて上記のすり合わせをおこなったかについてふれます。4点です。

1.経営陣やVPと直接話す

マネジメントの職種でいくなら、会社のカルチャーやそれを体現する経営陣やエースクラスの人たちとの相性はとても大事だと思います。もっと端的にいえばチームメンバーとではなく、上司や経営陣と相性が悪くてうまくいかない、というリスクがわりとあるからです。人の相性はもうどうしようもないところもありますし、どうしても譲れないものというのはそれぞれにあります。ですので実際に関わるチームメンバー以上に上位のレイヤーの人との相性を細かくお互いのために確認することは必須だと思っています。

2.具体的な課題のディスカッションをする

入ってからでないと難しいと感じる人もいるかもしれませんが、自分は基本的に入る前にかなり具体的な課題とそれを取り囲む現状を詳しく教えてもらい議論するようにしていました。これも双方にとってミスマッチを防ぐ方法の一つで、ここでお互いに信頼して手札を見せあい、お互いにできること・できないこと、役に立つこと・立たないことをイメージしておかないと入ってから痛い目をみる可能性があるからです。
マネジメント職種といえど最初の数ヶ月で人の印象というのは決まってくるので、短期である程度成果はほしいところです。高い待遇を出して採用したことを採用した側もよしとしたいところなので、一定の成果を出してもらいたいと思うものです。
また具体的な課題のディスカッションの中で、実際に働いたときのイメージはおそらくプレイヤーよりもマネジメントの役割の方のほうが双方よくわかるからです。実際の現場でも少し抽象的な戦略や戦術についての方針についてすり合わせたり、議論を通して互いの考え方やスタンスを理解したうえで働くことになります。そのあたりは面接の会話よりもよりも実践的な議論のほうがわかりやすいです。
またトップや経営陣の方と話せるなら、かならずVCに説明をしているような単中長期の一通りの成長戦略の話も質問します。その戦略が妥当で自分が納得できるかはもちろん、そこに自分がアドオンで価値を出していけるか、積極的に関わっていけるかをみるためにも必ず十二分に話すようにしています。

3.JDの裏にある責務・権限の詳細を話し合う、もしくは言葉(文字)に落としてみる

ジョブディスクリプションもあるかもしれませんが、おそらくもっと流動的で、言語化されてないポジションへの期待も話してみると意外とでてくるものだとおもっています。

- どこまで意思決定を任せたいのか
- 具体的にどんな成果を出してほしいのか
- 中長期で会社が成長したときにどこを担ってほしいのか
- 逆にどこは任せてついてきてほしいのか

など、遠慮せずに聞けるなら聞いておきたいことというのはけっこうあると思います。ふわっと一緒に会社を大きくしていこう！そこは同じ夢を追いかけられれば解決できる！とふわふわとした意気込みで終わらせることもできますが、僕は将来の言ってしまえば本質的でない役割分担に関する課題やリスクは先に取り除けるならとっておきたいと思うので、わりと細かく話すようにしています。
このポジションではとくに、役割の定義がそもそも曖昧（なのでVPoE handbookを書いたくらい）なので、共通認識はないとおもって互いに話さないといけません。
加えてここではこちら側も「予算からアロケーションまで最終的には自分で判断できるようにしたい」「将来は開発だけでなくプロダクト全体まで見ていきたい」のように”欲を言えば求めたいもの”も出しておくことです。コミュニケーションの仕方はもちろん大事ですが、上手に心をの中を見せておくことがお互いに腹のさぐりあいがその後怒らずいいですし、うまくいけばお互いに信頼しやすくなると思います。謙虚さは必要ですが遠慮はせずに話すことが大事だと思います。

もちろん今決められないこと、不確実性のなかで判断せざるをえないことをはっきりさせてくれというコミュニケーションになってはNGです。むしろ悪印象を与えてしまいます。そもそもそういった不確実性に一緒に向き合おうという期待で一定の裁量や待遇を用意してくれるのですから、ここを履き違えてはいけません。
ここはもう難しい塩梅のところとしか言いようがありませんが、互いに機微を察しながら相手の立場になってコミュニケーションすることができれば失敗はしないと思います。個人的にはこれができないとそもそもマネジメントで裁量あるポジションができないとおもっています。そういったことには当然注意しながらお互いに必要なことをはっきりさせておく、というのが自分がここで意識していたことです。

4.長期コミットできるテーマなのか深く考える

これはもう個人の趣向の問題かもしれませんが、自分は個人の成長やリターン云々よりも、まず自分が長く取り組む、自分の人生の時間を多大に投資してでもやる価値があると思えるものかを一番といってもいいくらい大事にしていました。

どこのスタートアップやベンチャーにいっても一定のリスクからは逃れられませんが、それでもかなりの時間や自分の労力をそれに注ぐわけです。一番不運なのは途中で自分が真剣に取り組めなくなってしまったり、または事業の方向転換や外部環境の変化でそのテーマに向き合い続けるのが厳しくなってしまうケースです。

そんなケースにならないためにも、そのテーマが一つは世の中にどれだけ必要とされていて今見ている方向性でどんなインパクトが出せるのか？という社会的意義と事業性、それに加えて自分がコミットしたいテーマなのか？なぜこれに人生の時間を使うのか？という自分の人生においてこのテーマに取り組む意義、の２つを自分は見ています。

VPoEにもはや関係なくなってしまう点ですが、強いて紐付ければマネジメントのトップレベルに近いところで仕事をするほど、大変なことや理不尽なこととも向き合い、そこから逃げれないことも多いと思います。だからこそ自分の中で社会性・事業性・人生における意義を確かめて、なにがあっても折れずに取り組める場所を選ぶことが大事なのではないかと思います。

年収

このトピックのために見てくださっている人もいると思うので書いておきます。

結論からいくと、自分がお話をした会社さんから頂いたオファーの年俸レンジは