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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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