連載FastGrow Conference 2022

実はIPO後の方が、手を広げやすい?
「技術力+α」を実現するエンジニアキャリアを、IT組織の長3者が語り合う

登壇者
岡本 健

株式会社シンプレクス・テクノロジー(現シンプレクス株式会社)にて、大手証券会社への債券向けフロントシステムの導入、大手銀行へのデリバティブ商品向けミドルシステムの導入をプロジェクトマネージャとして推進。その後、2015年12月にウェルスナビに入社。リードエンジニアとして、サービスの設計・開発・運用を推進。2018年12月に執行役員、2020年7月にCTOに就任。主にロボアドバイザー「WealthNavi」のシステム開発、セキュリティを統括。

山下 貴史

1999年に慶應義塾大学経済学部卒業後、 通信業界での研究開発を経て、インターネット広告企業にて、自社サービス開発や開発部門の統括、子会社の役員としてオフショア開発立ち上げ等を担当。2014年に株式会社ネットプロテクションズに入社。IT部門の組織開発、NP後払いのサービス改善等を担っていたが、現在は人事労務、総務、法務、コーポレートガバナンス領域の各施策を推進している。

平松 達矢

サーバーサイドエンジニアを経験後、モバイルサイト開発経験を経て株式会社コロプラに入社。2017年10月に株式会社カオナビへ入社し、プロダクトマネージャーとして開発を牽引。2018年にはプロダクト本部長へ就任、現在はエンジニア部門の組織開発やプロダクトの開発責任を担っている。

関連タグ

エンジニアが最速で成長できる環境として、上場前のスタートアップをイメージする人は少なくないだろう。与えられる裁量も大きく、幅広い技術、業務に携わりながら、事業を成長させる経験を積むことができる。そんなイメージを抱く読者も多いだろう。しかし、本当にそうだろうか?

2022年2月に開催したFastGrow Conference 2022では『【After IPOの世界】上場後も事業成長を牽引するエンジニアとは』をテーマにセッションを実施。

上場後の、事業も組織も拡大・複雑化する環境だからこそ得られる経験や面白さ、そして「プロダクトの価値を高めて、事業を伸ばし続ける力」について考える。

登壇したのは、全自動の資産運用サービス『WealthNavi』を展開するウェルスナビCTOの岡本 健氏、国内BNPLサービスのリーディングカンパニーとしてプラットフォーム事業を行うネットプロテクションズ執行役員の山下 貴史氏、タレントマネジメントシステムのSaaS『カオナビ』を展開するカオナビの執行役員プロダクト本部長の平松 達矢氏だ。

  • TEXT BY HARUKA FUJIKAWA
SECTION
/

「持っている技術力+α」の実現は、100名超組織でこそ

最初に話題に上ったのは「上場前後でエンジニアの働き方がどう変わるのか」について。この2年以内に新規上場を果たした三社で、どのような変化があったのだろうか。

2020年12月に東証マザーズへ上場したウェルスナビの岡本氏は、「以前とは、直面する仕事の面白さの質が、明らかに変わってきた」と述べる。

岡本入社した頃の社員数は20名ほどでしたが、現在は約100名ほど。社員数が増えるにつれ、業務整理や役割分担がかなり進んでいます。

20名くらいの頃は、サーバーサイドエンジニアとして入社しても、それだけ考えていればいいわけではないのです。やったことのないフロント領域の開発などにも取り組む必要があり、私もかなり苦労しました(笑)。これはこれで良い経験になるのですが、大多数のエンジニアさんについては、そういうキャリアを経験する必要まではないのかなとも思います。

その点、社全体で100名を超えた今のタイミングは、良い具合に整理が進んでいて。個々人の強みをきちんと活かした業務に向き合いながら、適切に影響範囲を広げていけます。例えば、プロジェクトマネジャーをしたり、UXデザインをしたりなど、開発現場に留まらずに、「既に持っている技術力+α」で事業に貢献できる道を描きやすくなっています。

上場したかどうか、というより、社員規模が重要になってくるのですが、これが「面白さが変わってきた」と言える要因かなと思います。

2021年12月に東証一部への新規上場を果たしたばかりのネットプロテクションズ。BNPL(Buy Now, Pay Later、いわゆる後払いサービス)領域では国内でマーケットリーダーの地位を築いてきた同社の現状について、山下氏は「社会的責任の実感が高まるとともに、新たな面白みも出てくるのでは」と期待を込めつつ語る。

山下社内の雰囲気や事業自体に変わりはないのですが、決済インフラを運営していることもあり、社外に対する責任は増していると実感します。上場前からもそうですが、トランザクションの増大に比して、セキュリティや技術的負債など、取り組む課題も増えています。

と同時に、BNPLへの注目度も高まり続けてると思いますし、いかにミッションクリティカルなシステムを構築するのかなど、技術的な面白さも増してきています。

弊社はミッションに「つぎのアタリマエをつくる」を掲げており、責務を果たすとともに、創造的な発想、斬新な企画も奨励していきたい。そんな空気を作っていければと思っています。

2019年3月に東証マザーズへ上場したカオナビの平松氏は、IPO後の組織について「長期的な目線で議論ができるようになった」と切り出した。

平松上場前は、IPOそれ自体が次の大きなマイルストーンになりますよね。だから、例えば2年後にIPOを狙うなら、「2年後までに何をするのか」の議論に集中しがちだと思います。

なので、上場してからのほうが、持続的かつ長期的に、全体最適をするためには何が必要かを、議論しやすくなったと感じます。具体的には、短期的には技術負債が増えるとしても、長期的には最適解になるほうを選ぶ、という意思決定がしやすくなっていますね。

SECTION
/

エンジニアの役割は、事業貢献から逆算すべき

続いて、エンジニアが強みやスキルを活かして活躍できるよう、各社ではどのようなキャリアパスや制度を用意しているのかについて共有した。

カオナビは、入社時にマネジメントコースやスペシャリストコースを自ら選択する仕組みを取り入れているという。

平松最初にどちらかを選び、安定した頃に、マネジメントコースならエンジニアリングマネージャーへ、スペシャリストコースならテックリードやヘッドエンジニアリングへ、と分かれる形です。

いずれの場合も「会社としてこうなってほしい」ではなく、エンジニア個々人の希望に応じてフラットに選択できます。

ネットプロテクションズでは、「ビジネスを設計、企画、実装する力」を軸に、得意領域や専門性を自由に伸ばせるよう、明確なキャリアパスを敢えて規定していない。

山下ITはあくまで手段であって、重要なのは事業目線で考えることだと考えています。エンジニアの美学として「このアーキテクチャがいい」というのも大事ですが、それが必ず事業成長に寄与するわけではないと思います。私自身も、社内のメンバーも、あくまで「事業成長のためのエンジニアリング」を意識してきました。

その一環として、2013年にはエンジニアが属する部署名を「システムグループ」から「ビジネスアーキテクトグループ」に変更しました。メンバー全員がシステムだけでなく、ビジネス全体を設計、企画、実装、実現する役割を担っています。

その中で、一人ひとりが強みを生かした働き方を実現しています。テックリード的に動くのが得意な人もいれば、手を動かして開発をリードする人、プロダクトマネジメントに優れた人もいる。ビジネスへの貢献をしつつ、得意領域を伸ばし、リードエンジニアやPdMのラベルに収まらないT字型、π字型の人材になっていけるように志向しています。

ウェルスナビでも、「リードエンジニアやプロダクトマネージャー」といった役職は明確に定義していないのだという。

岡本ITは手段でしかないと山下さんが言ったことに、強く共感します。弊社でもかなり意識しており、エンジニアは常に「いかにして事業に貢献するか」を考えるべき。だから、役職や職種が先に規定されるというよりも、「事業への貢献を考えると、この役割が必要」という考え方をしていますね。

先ほども述べた通り、「持っている技術力+α」として、プロジェクトマネジメントやプロダクトマネジメント、UXデザイン、アーキテクトなども担うことがあります。現状の役割に縛られることなく、複数の領域で貢献していくこともぜひ考えてほしいと伝えています。

事業に貢献すること、それに技術でアプローチすること、その結果として組織を成長させること。この3つが重なる領域で価値を発揮できるように、環境を整備しています。

山下氏や岡本氏から「エンジニアの事業貢献」がキーワードに挙がったのを受けて、視聴者からは「ビジネス側とエンジニア側の乖離を乗り越えるにはどうしているのか?」と質問が上がった。

平松氏は、事業への貢献実感を持てるように「お客様が喜んでくれた時に、感謝の言葉をSlackで共有する」などをこまめに行っていたと紹介。同時に、技術の向上を追求したいエンジニアのために「中間KPI」を設定していた。

平松自分の仕事が事業につながっていると伝えるのは重要だと思う一方、エンジニアのなかには、事業やビジネスへの興味がない人もいる。それはそれで受け入れる必要があると思っています。

そうしたエンジニア向けには、事業につながる目標とは別に、アジリティやベロシティなど、生産性を示す「中間KPI」を設けるようにしました。そうすることで、エンジニア側の貢献がビジネスサイドからも見て取れるようになりました。

岡本氏は小さな成功体験を積み上げ、ボトムアップで少しずつ乖離を乗り越えていくことが重要と語った。

岡本これは難しくて、永遠の課題とも言えますが……その中でも始めるべき第一歩は、エンジニアも含め、一人ひとりが事業も含む会社の課題について、できる範囲で解決していくことではないかと思います。

エンジニアはコードを書くことしかできないと考えているうちは、何も変わりません。どのようにコードを書くか、周りとどのようなコミュニケーションを取るかなどといった細かい点でも、事業貢献につながることはあるはずです。

小さな成功体験でもいいので、積み上げていくこと。そしてそれが肯定され、支持される文化をつくることが、重要なのではないかなと思いますね。

SECTION
/

職域に囚われては、事業貢献など不可能

最後に、それぞれが上場後に活躍する「伸びるエンジニア」の条件について語り合った。平松氏は「周りの人が何を目指しているのかを洞察できること」と答える。

平松SaaS事業ではエンジニアが作るプロダクトが肝になります。良いソースコードを書く、便利なUXを提供するといったことはもちろん、一緒に働くセールスやマーケターなど、エンジニア以外の人々や会社が「何を目指しているのか」を洞察することにぜひ取り組んでほしいですね。

洞察していると、会社や組織のプライオリティが理解できるようになります。さらに組織を超えたコミュニケーションも速くなる。そんなエンジニアは、アーリーフェーズでもIPO後でも強く求められますし、事業貢献し続けられると思いますよ。

山下氏は、事業とエンジニアリングの垣根を超えて関心を持ち、課題を乗り越えていけることを挙げる。

山下ネットプロテクションズは、事業とエンジニアリングに境界は存在しないと考え、取り組んできました。部署名に則して、事業に興味を持って取り組んでもらえると、自ずと成果も上がっていると感じます。

例えば「エンジニアだから事業貢献は難しい」など、職種を理由に事業貢献ができないと思っているとしたら、当人か周囲が職種名に囚われているだけ。心持ち次第で、できることはどんどん変えられると感じます。職種は関係なく、当人がどのような視座で現実や課題を捉えて、どのように課題を乗り越えていけるのか。そのビジネスセンスが重要なのではないでしょうか。

ウェルスナビの岡本氏も、「山下さんのお話は真理だと感じる」と語り、エンジニアならではの強みを解説する。

岡本職種に限定するという意図はないのですが、エンジニアはコードを書くとき、物事を抽象化して、役割や機能に分ける、分岐させるといった部分に、非常に気を配っていると思うんです。この思考法は、ビジネスに広く活かせるはずなんですよ。

というのも、最近は、役割や機能を細かく分け、特定の領域に特化してサービスを提供するプロダクトも増えています。エンジニアの思考を、事業側とのコミュニケーションやビジネス設計に活かしていける余地がどんどん増えているわけです。そうした関わりを持ってみると、きっとより大きな活躍ができます。

まさに『WealthNavi』は資産運用という特定の領域に特化したサービスだが、いわゆるドメイン知識は「伸びるエンジニア」の必須条件ではないという。

岡本もちろん、社内に金融系出身者も少なくはないです。ですが、私たちが求めているのは、知識や技術よりも「お客様の課題を解決すること」を一番に考えられるようなメンバーです。

むしろ、金融系の知識がないほうが、ターゲットの気持ちに共感でき、開発の場において活躍できるのではないかと思います。つまり、事業貢献には、知識やスキルというよりも、貢献範囲を広げようと考えるマインドこそが肝心なんです。

そしてそういう気持ちを強くお持ちのあなたは、人数の少ない未上場スタートアップよりも、我々のように少し整い始めた環境のほうが面白さを感じるかもしれません。上場しているから、とそれだけで転職や副業の選択肢から外してしまうのは、もったいないですよ(笑)。

IT技術は、あくまで手段。それを繰り返すように語った3人。得意領域や専門性を伸ばし、事業とエンジニアリングを横断して事業に貢献する、そんなキャリアに興味関心を感じない読者はほとんどいないだろう。3社の実例から、自身のどんな未来を想像するだろうか。

岡本氏も語ったように、「IPO後」というだけで目を背けてしまうスタートアップ志望者が増えつつある。だが、自身に最適な環境がどこにあるのかを考える上で、IPOというのは本来関係ないはず。取り組む仕事の変化はほとんどないのだ。少しでも視野を広く持ち、フラットに見極める、そんな意識が、理想のキャリアを描いていく一歩目になるだろう。

SECTION
/

技術だけでなく、成功体験を身に着けることが重要

セッション中には視聴者から、質問がいくつも届いた。その中で、答えきれなかったものがあったので、終了後に3社からコメントをいただいた。

質問は、「技術力があまりない状態でPdMや企画側に異動しても生かせる知識がないと思うんですが、最低限求める技術力ってどのあたりでしょうか」というもの。

岡本まず、PdMや企画に望んで異動していることを前提とさせていだきます。つまり、その領域で活躍できるという自信が一定あることとさせていただきます。

どんな技術でも構わないのですが、どういった課題を解決するためにどのような技術を用いてその課題を解決したのか、その経験値が似た課題の解決や、あるいは違う課題への応用が効くように引き出しとして身についているのか、という点が重要だと思います。

表面的な技術であればGoogleで検索すればだいたいのことは書いてありますが、それを実際の業務でどのように使いこなすかは経験がものを言います。

そうして身になったというある種の成功体験があれば、なぜその技術要素が必要で、なぜその技術要素が課題の解決に繋がったかということをサービス開発やプロジェクトについて一気通貫で考えることができるようになると思います。

そのような経験があれば、違う責任領域でも同じ成功体験を得ることができると思います。

山下技術力を何と捉えるかにもよると思いますが、IT領域における各スキルの中で技術力がある、と言い切れない状態であっても、開発に携わってきた中でのQCDの感性やバランス感覚、これらはPdMや企画側でも活かせるのではないでしょうか。

かかる工期、開発難易度、品質状態(リスク状態)、これらを人を介することなく、ご自身で把握できることも技術力、と言えると思います。

また、サービスを開発をするのはあくまでも人であって、PdMや企画側でも開発メンバーと直にやりとりできるような知見があれば、それだけでもコミュニケーションコスト省力化に繋がると思います。

平松PdMが行う業務の中で技術に関わる業務は一部ですので、実装を行うチーム(技術者)の気持ちを理解するスタンスが十分あるならば、PdMをしながら学んでいくスタイルでも大丈夫です。

敢えて言うのであれば、ユーザーとプロダクトとチーム、この3要素をPdMは深く理解する必要があるので、「技術がわからなくてユーザーの状態が正しく理解できない……」のようにいずれかの理解に対して技術を障壁と感じない程度に習得していることが望ましいです。

こちらの記事は2022年03月15日に公開しており、
記載されている情報が異なる場合がございます。

次の記事

記事を共有する
記事をいいねする

1998年生まれ、広島県出身。早稲田大学文化構想学部在学中。HRのスタートアップで働きながら、inquireに所属している。興味分野は甘いものと雑誌と旅行。

おすすめの関連記事

会員登録/ログインすると
以下の機能を利用することが可能です。

When you log in

新規会員登録/ログイン