はじめに
セーフィー株式会社のVPoEを務めている谷口元信です。
2022年4月からVPoEとしてエンジニアの組織形成と運営に取り組んでいます。
今回はVPoEに何が求められるかについて私なりの解釈を伝えた上で、取り組んだ事と今後についてをお話ししたいと思います。
なぜVPoEが必要なのか？
VPoEとはVice President of Engineeringの略ですが、直訳すると技術の副責任者となります。
CTOが最高技術責任者なので、そのサポートをする立ち位置としてVPoEが存在すると私は考えています。
海外のIT企業では2000年代初頭からVPoE職が生まれたと聞いています。
インターネットの普及が1990年代から広がっていくに伴って、インターネットを通じたサービスを提供する企業も増えていきました。
そういった企業がビジネスを拡大していくにあたって、企業内のエンジニア社員数も増えていき組織の管理が既存のやり方だけでは難しくなっていきました。
そのような状況の中でエンジニア組織に直接責任を持つ立場としてCTOが全ての責任を背負っていましたが、CTOに求められる責務が大きくなってきたので責任範囲を分けていく事が企業で求められていった結果、VPoE職が必要となった訳です。
CTO：技術を使った意思決定においての経営責任
VPoE：技術を使った意思決定を遂行する組織への責任
と分ける事で、CTOは技術に対する経営責任に集中して業務を進める事が出来るようになり、技術選定や選定した技術を使ったプロダクトのビジネス展開における企業としての意思決定速度を上げる所に貢献しやすくなります。
VPoEはエンジニア組織への責任を担う事で組織内のパフォーマンス向上や組織間の連携向上に集中する事が出来、経営で意思決定された方針を元に組織の機動力向上に貢献しやすくなります。
私はどちらも大事な役割だと思いますし、CTOとVPoEが相互に理解しながら仕事を進めていく事が組織を運営する中で意識しなければならないポイントだと思っています。
なぜVPoEになったのか？
広義でのVPoE職の役割については書かせてもらいましたが、続いてセーフィーで私がVPoE職についた経緯をお話しします。
私が入社したのは2019年4月ですが、2021年11月までは概ね下記のような職能別組織となっていました。
エンジニア数は50名程で、各技術領域をグループでまとめながら開発をしていく体制となっていました。
そして、2021年12月から事業部制組織に移行しました。
ここで大きな課題が生まれました。
3つの事業部とカスタマーサービス本部に職能単位のエンジニアを配置しましたが、各事業部でビジネス展開したいプロダクトがある中で各事業に絞り込んで開発を進めるだけのマンパワーが足りなかったのです。
一般的なSaaS企業だとフロントエンド、バックエンドのフルスタックエンジニアが入れば事業部で求められるプロダクトに対して一気通貫でコミットする事が可能です。
ただ、セーフィーの場合はフロントエンド、バックエンドに加えてネットワークカメラを主としたデバイス領域も一気通貫で見れるフルスタックエンジニアが圧倒的に不足していました。
その結果、毎月のように事業部間でエンジニアのアサイン調整をして開発を進める事となったわけです。
本来であれば事業部制に移行する事でそれぞれの事業領域を深堀しながらニーズに合ったプロダクトを提供してビジネス拡大のスピードを上げられる想定でしたが、逆にスピードが下がる結果となりました。
組織拡大をしていく中での痛みだと捉えていますが、その痛みを解決するために自ら手上げをして2022年4月からエンジニア組織の改善に対して取り組みを始めました。
改善するプロセスとしては、今までの組織で課題になっていた事を現状整理しつつステップに分けて組織変更をする案を作って実施しました。
組織変更した結果のあるべき姿として2022年4月に考えた組織は以下となります。
プロダクトに対してはバーチャルな組織で横断して向き合いながら、各技術領域における生産性を向上するための組織として考えました。
これは短期的な計画で1年以内にはこの形にするために2022年内に3回の組織変更をしてハレーションが起きないように進めました。
合わせて事業部と連携して開発を進めるにあたっての会議体を再設計し、情報共有が滞る事なく進められるようにもしました。
関連する部署とも合意を取りながら経営陣に組織変更に対して納得してもらって進める事は結構な労力と時間が必要でしたが、無事に進める事が出来ました。
2022年11月には以下の組織に変更しました。
領域が近い技術領域を部としてまとめながら、グループで開発のアサインを調整しやすい形に変えました。
過去にやりやすかった組織でのやり方に近い形に一先ずは変えつつ、横串で組織改善をするためにエンジニアリングオフィスも新設しました。
なので、2022年11月がエンジニア組織の再出発と私の中では定義しています。
取り組んだ事
再出発した中でVPoEとして取り組むべき事を育成、評価、組織、採用のカテゴリに分けて言語化しました。
やるべき事はたくさんありますが、エンジニアリングオフィスのメンバーを少しずつ増やしながら優先順位をつけて取り組む事としました。
取り組めた事
年度ごとに取り組めた事を洗い出しながら書いていきます。
2022年度
主には組織変更に伴う調整に多くの時間を割きました。また、採用プロセスの改善で応募から最終面接に至るまでのプロセス全体を短くするためにエンジニアの最終面接を私に委譲してもらいつつ採用グループとの連携に力を入れました。
育成
オンボーディングの体制強化
- 各グループで代表者を選出してもらい、それぞれのグループで現在使っているオンボーディング資料を洗い出しながら、必要に応じて足りてない要素を強化するための資料を追加していけるようにしました。
- 2023年4月から新卒1期生を受け入れるにあたって、内定承諾者のインターン受け入れを行ってエンジニアとしての開発体験をしてもらう設計・運用をしました。
組織
プロダクト単位での開発体制の改善
- 事業部制から開発本部にエンジニア組織を移行するために関係部署、経営陣と合意を取りながら進めて組織変更を実施しました。移行するにあたって生産性を向上していくための会議体設計をしながら業務への影響を減らしながら進めました。
採用
採用のプロセス改善
- 最終面接をCEOから委譲してもらい、選考におけるプロセスを効率化しました。
- 採用担当とデイリーミーティングを設けながら、候補者毎でのスケジュール調整を最適化するようにしました。
2023年度
育成
オンボーディングの体制強化
- 2022年度に引き続き、内定承諾者のインターン受け入れを行いました。2023年度はエンジニアリングオフィスのメンバーに教育を委譲し、再現性のある体制作りに努めました。
- udemyを活用して技術力向上に励む事が出来る仕組みを作り始め、希望者が自学出来るようにしました。
評価
スキルマップの可視化
- テックリードやエンジニアリングマネージャの職位を定義しながら、CTOや部長と共に職位に対するランクの定義を作り開発本部内で誰でも確認出来るようにしました。
組織
プロダクト単位での開発体制の改善
- エンジニアリングオフィスのメンバーの採用を行い、エンジニアリングオフィスで取り組める事を増やせるようにしました。
- 現在の開発体制の現状整理と改善に向けての中長期の開発本部の体制を再設計しました。
採用
採用のプロセス改善
- 継続して採用担当とデイリーミーティングを設けながら、エンジニアリングオフィスのグループリーダーにも入ってもらい更なるプロセスの効率化を行いました。
エンジニア組織の認知度向上
- セーフィーで初となるアイディアソンの企画・運営を行い、学生の方々にセーフィーを知ってもらいつつアイディアを形にするプロセスを学ぶきっかけ作りを提供しました。
- 技育祭に登壇し、ネットワークカメラの将来について技術周りも含めてプレゼンテーションを行いました。結果として初めて知った企業として登壇企業の中で1位となりました。
振り返ってみると、VPoEになってから総じて採用に時間をかけている事を実感しています。
本当であればもっと育成にも時間を使いたいところではありますが、開発業務における課題にも一定の時間を使っているので年単位で取り組む業務にフォーカスして取り組んでいかなければならないという自省もあります。
今後について
2023年度までに採用に多くの時間を割いてきましたが、2024年度は特に育成にフォーカスした改善を行っていきたいと思っています。
今いるエンジニアの成長が積み重ねる事で組織の成長にもつながると私は思っています。
私自身は20数年ほど開発現場で色々な開発をしてきましたが、私が成長していくにあたって必要だった事は出来る限り言語化しながら成長に対して必要な事を各自が考えて取捨選択して成長していける組織になる事を望んでいます。
まとめ
各企業には事情の異なる課題があるのでVPoEには臨機応変な課題解決能力が必要だと思っています。
エンジニアとしてプログラムに向き合って課題解決していく経験をされていた方は組織に向き合って課題解決していく所に置き換えて考えるとVPoEという職種が理解しやすいかもしれません。
プログラム以上に不確定要素は多くありますが、VPoEという職種は今後ますます必要となりますので、興味がある方がいましたら私の体験も踏まえてお話をしますので、ぜひご連絡下さい。
最後まで読んでいただき、ありがとうございました。
