私がスタートアップでVPoEになった事情

株式会社iCAREで今年（2020年）7月からVPoEになりました安田です。
今日はiCAREでなぜ自分がVPoEになったか、またVPoEとしての仕事の魅力についてお話したいと思います。

CTO → COO & VPoE

iCAREはここ数年、サービス(Carely)導入企業数、従業員数ともに年2倍の成長をしており、開発組織もここ数年でふくれあがり、これからも採用を通してさらに増える見通しです。
現在、開発メンバーはデザイナー含めて18名います。

2020年7月までは長らく石野がCTOを努め、開発組織のトップを務めていました。
が、組織の拡大に伴い、8月より石野はCOOとなり、開発組織だけでなく、iCARE全体の業務を指揮することになりました。

それに伴い、それまでテックリードの一人として業務を進めてきた私がVPoEを担うことになりました。
なので、VPoEが必要になった事情の一面を簡単に言ってしまうと、CTOがCOOに昇格したのに伴い、その穴を埋めるために自分がVPoEになったと言えるかと思います。

なんとなく理解し合えていたものが理解し合えなくなる

ただ、それと同時にエンジニア同士がそれまでなんとなく理解しあい、なんとなく協調できていたことが、エンジニア数の増加に伴い段々できなくなってきていたという状況も生まれていました。
つまりエンジニアたちが、なんとなくではなく、いわば明示的にそれぞれの役割を担い、明確なチャンネルを通してコミュニケーションをしないと、うまく立ち行かなくなってきたとも言えます。

エンジニアの増加に伴って生じるようになった問題としては、以下のようなものがあります。

1. 分業が進み、メンバー間の仕事がお互い見えにくくなる
2. メンバー間に多様性が生まれ、スキル、価値観、コミットメントの意識にギャップが生じる

1に対しては、情報共有のための枠組みやいろいろな仕掛け必要になります。
2に対しては、各メンバー間で強調してシナジーを生む、チームを構成する必要があります。

今、私はVPoEとしてiCAREで生まれてきたそうした組織的課題に取り組んでいます。

テクノロジーだけでなく組織（人）もマネージする必要が出てきた

上記のような課題にアプローチするためには、プログラム言語やアルゴリズムといった「テクノロジー」を扱うのとは異なるアプローチが必要になります。
簡単に言ってしまえば、「人」を扱う「技術」が必要になります。
開発組織が20人程度になってきた段階で、これまでなんとなくできてきた「人」のマネジメントが、専任の責任者を必要とするようになってきた、とも言えるかと思います。
あとは当然のことながら組織をスケールさせるための「採用」も重要になってきており、そこも「人」のマネジメントとして重要になってきたという事情もあります。
あとは自分個人が「技術」よりも「組織」に対して強い課題感、興味を持って仕事をしてきた、という背景もあります。

エンジニア組織を扱う魅力

ここまでは、iCAREという組織においてなぜ自分がVPoEになったかという事情についてお話してきましたが、少し視点をかえて、エンジニアをマネジメントする魅力についてお話してみたいと思います。

多くのエンジニアは、人のマネージメントに対して消極的です。
マネージメントは、組織にとって必要だから仕方なくするけれども、「本当はプログラムコードを書いていたいんだよね」という話もエンジニアからはよく聞きます。
自分も数ヶ月前まではバリバリプログラムコードを書いていましたので、その気持ち、価値観はよく理解できます。

「マネージメントはできれば避けて通りたいが、避けられないので引き受けるもの」
エンジニア界隈では、そういう受け止め方をする人が多いです。

エンジニアは、テクノロジーやロジックといった、一定の入力に対して、必ず一定の出力が約束されているようなソリッドで安定した世界を好む傾向があるようです。
その逆に、人や組織のように、一定の入力を与えても、どんな出力が得られるかわからない、もしくはそもそも出力を何も得られないかもしれないような予測困難で不安定な世界を忌避する傾向もあります。
その意味では、「テクノロジー」と「人」は対極的な世界とも言えるかと思います。

ただ、「部分を組み合わせて全体を形作り、問題解決を図る」という意味では同じ技術（エンジニアリング）と言えるかと思います。
もちろん、その部分（パーツ）の性質は全く異なります。
例えば、コンピュータープログラムは、実装して実行すれば、すぐに結果が得られるのに対して、人（エンジニア）の場合は、仕事を依頼して、それが実現するまでに長い時間がかかります。
また、コンピュータープログラムは1文字でも誤りがあると動きませんが、人（エンジニア）の場合は、多少の誤りは許容してくれます。
その他にも、コンピュータープログラムは何度でも同じ処理を実行できるのに対して、人（エンジニア）に同一の作業をお願いすると、おそらくその人は怒るか、疲弊するかして機能してくれなくなる、等の違いもあります。

プログラミングとマネージメントに求められる資質の違い

同じエンジニアリングとはいえ、「テクノロジー」を扱う「プログラミング」と「人」を扱う「マネージメント」に必要な資質は

プログラミング → 論理的構築力、曖昧さを受け入れない正確さ
マネージメント → 人（時間）に対する忍耐力、曖昧さを受け入れるファジーさ

のように大きく異なります。
そこが、多くのエンジニアにマネージメントが忌避される理由かと思います。

ただ、逆に言えばそのどちらのスキルも身につけることは、組織や市場にとって大きな価値を持つことにもなりますし、個人にとっても取り組みがいのある大きなチャレンジとも言えるかと思います。
私は特にその点をもっとも取り組みがいのあるチャレンジとして受け止め、VPoEという仕事に楽しく取り組んでいます。

エンジニアとして事業と関わる

ここまでは「テクノロジー」と対比した「マネージメント」について語ってきましたが、ここからは「事業」についてもお話してみたいと思います。
VPoEとして開発組織に対して責任を持つ以上、その「部分」となる個々のエンジニアに責任を持つと同時に、その「全体」を方向づける「事業」に対しても責任を持つ必要があります。
開発組織の仕事は、開発組織以外の部署の仕事と組み合わせることではじめて「事業」として成立します。また「事業」の観点からは、お金の問題、競合他社の動向など、単なるテクノロジーでは完結しない広大な世界が広がっています。
そうした「事業」全体の中に「開発」を位置づけ、リソースをコントロールしていくこともVPoEとしての役割だと考えています。
まだまだ経験の浅い自分には、事業について語れる内容はそれほどありませんが、そうしたマクロな視点に立って、エンジニアリングと関わることができる点もVPoEとしての仕事の魅力かと思います。

まとめ

以上、とりとめのない感じにはなってしまいましたが、自分がiCAREのVPoEになった事情と、VPoEの仕事の魅力について語ってみました。
VPoEという仕事について語るには早すぎたかもしれませんが、自分が一人前のVPoEになるためにも、まずVPoEについて語ることは重要なことかと思います。
このエントリにおいて、自分の未熟さも含めて語ることができたかと思っています。
皆様からいろいろご意見をいただいたり、ご指導いただけることを期待しています。
皆様からの意見、指導をいただきながら　VPoEとして大きく成長していきたいと思います。

あと、iCARE開発部では毎月ミートアップをやっております。今月のテーマはこのブログエントリと同じ「VPoE」です。もし、このエントリにご興味お持ちいただけましたら、ミートアップにもご参加いただけると嬉しいです。
https://icare.connpass.com/event/186557/