こんにちは、ヘンリーの山口です。2026年4月にVPoEに就任しました。
年末にVPoEの打診を受けてから就任までの数ヶ月、「VPoEとして自分は何をやる人なのか」を探していました。一般的にイメージされるVPoEの仕事と、自分が実際にやり始めた仕事がどうにも噛み合わなかったからです。ようやく自分なりの答えに辿り着いたので、その結論とそこに至るまでの考え方を書き残しておきます。
違和感：一般的なVPoE像と、私が始めていた仕事
VPoEと聞いて多くの人が想像するのは、たぶんこういう仕事です。
- エンジニアの採用戦略を立てる
- エンジニアのキャリア開発や評価制度を設計する
- 技術的な方針を決める
- 開発チームの生産性を上げる
- エンジニアリング組織全体を率いる
一方で、打診を受けた後、私が実際に始めていたのはこういう仕事でした。
- 製品本部の横断チームが、それぞれ「やること・やらないこと」を定義できるように支援する
- 横断チームと開発チームの関わり方を設計する
- 営業や導入など、ビジネス側のプロセスとの接合面を整理する
「これは本当にVPoEの仕事なのか？」という疑問がずっとありました。答えを出すために、まず「Engineering」という言葉を自分なりに定義し直すところから始めました。
Engineeringとは何か
そもそもEngineeringとは何か。多くの人はコードを書くことを想像すると思います。ただ、エンジニアがコードを書いて何をしているかというと、手作業でやっていたことを自動化したり、曖昧だったルールを明確なロジックに落とし込んだり、属人的な判断を再現可能なプロセスにしたりしている。こうした一つひとつが、不確実性や非効率を減らしていく営みです。
Engineeringは本来、与えられた制約の中で現実的な解を作り上げる営みです。私はその本質を不確実なものを確実にし、非効率なものを効率化することだと捉えています。コードを書くのはその手段の一つにすぎない。
この定義に立つと、私の仕事も説明できるようになります。
個人の知識と経験に依存していた判断プロセスを、組織としてスケールできる形にしていく。状況ごとに異なっていた関わり方を、再現可能なパターンとして設計する。こういった不確実性を下げ、効率性を上げる仕事が私のEngineeringです。
ヘンリーのエンジニアは、自ずと不確実性を下げていけるメンバーが揃っています。採用や予算の戦略はVPoPが、技術的な方針はVPoTと現場のエンジニアが担っていて、日々のマネジメントも各チームのリーダーが見ています。そもそも自走できるメンバーが多く、手厚いマネジメントを必要とする状況ではありません。
しかし、不確実性や非効率はエンジニアにだけ発生するわけではありません。QAのチーム、ドメインエキスパートのチーム、カスタマーサクセスに関わるチーム——こうした横断的なチームが開発チームとどう噛み合うのか。営業や導入プロセスといったビジネス側との接合面をどう設計するのか。こういった領域は今のところ個人の力でうまく回っています。ただ、組織が拡大していく中で特定の人に頼り続ける構造のままでは回らなくなり始めています。
横断チームと開発チーム、そしてビジネス側との接合面で不確実性を下げて効率性を上げることが、私のVPoEとしての仕事です。
仕組み化そのものが目的ではありません。組織の中にある不確実性と非効率をほどいて、全体が前に進みやすくなる状態を作る。その手段として、仕組みや定義や設計を使っているだけです。
実際にやっていること
今やっていることは、大きく2つあります。
ひとつ目は、横断チームの「やること・やらないこと」を定義する仕事です。横断的な役割を担うチームは日々の活動が多岐にわたる分、スコープが曖昧になりがちです。各チームのリーダーにボールを持ってもらいつつ、私はその言語化と構造化を伴走する形で関わっています。
あるチームでは、日々の行動の裏にある意思決定や意図を形式知にしながら、「一番大事な仕事は何か」を探るワークショップを重ねています。リーダー自身の言葉で、核心に近い表現が生まれつつあるところです。別のチームでは、「何をするチームなのか」がすでに明文化され、全社への展開も終わって、実績作りのフェーズに入っています。
定義ができてくると面白い副作用が出てきます。「やらないと決めたこと」の受け皿をどこに作るかという次の論点が現れるのです。これは私がVPoEとして引き受けるべき仕事になります。やらないと決めたものを宙ぶらりんにしないで、適切な場所やプロセスに移す。移す先がなければ、新しく作るか、既存の定義を見直す。ここまで含めて「定義する」ということだと考えています。
ふたつ目は、営業案件のリスク評価プロセスの再設計です。これまで属人的な運用で回していた領域ですが、組織の拡大と事業環境の変化でそのままでは立ち行かなくなり始めていました。実務の一部を私が一時的に巻き取りながら、営業側と一緒に属人的な判断を形式知として取り出し、再現可能な仕組みに落とし込んでいるところです。営業側にも同じ課題意識があり、進めやすい状況です。
また、開発チームの機能の作り方が多様化していく中で、横断チームが各開発チームとどう関わるかの設計も、これからの論点です。すでに各方面で具体的な動きが始まっているので、それらの意図を理解した上で、パターンとして整理していくつもりです。
目指している状態
これらを通じて目指しているのは、顧客が1年間で感じる価値の総量を増やすことです。
使える機能がより早く手元に届く。存在を知らなかった機能が見つかる。ヘンリーとの付き合い方自体が時間とともに良くなっていく。そういう状態を作りたい。開発のアウトプットが増えなくても顧客が受け取る価値は増やせる、という前提を私は持っています。横断チームと開発チームとビジネス側の接合面が滑らかになれば、すでに作られた価値がきちんと届くようになり、次に作るべき価値の解像度も上がっていく。
VPoEというロールは会社やフェーズによって中身がかなり違うものだと思います。ヘンリーの今のフェーズと組織の形に対して、私が担うべきEngineeringはこういうものだというのが現時点の答えです。まだ手探りの部分も多いですが、一つずつ形にしていきます。
同じようにVPoEの役割を探している方や、組織の接合面に課題感を持っている方と意見交換できたら嬉しいです。Xでも発信しているので、気軽に声をかけてください: @tyamaguc07
