【エンジニア採用】採用担当者が押さえるべき プロダクト・開発チームの4つのステージ

ども、LAPRASで働く中島（@nakashimayugo）です。

エンジニア採用において、採用背景や採用要件を深堀りするためは、プロダクトと開発チームについても理解を深める必要があります。

以前公開したこちらのスライドが好評だったので、少し細かい内容を記事にまとめました。かなりボリュームのある内容ですが、よかったら読んでみてください。

■なぜプロダクト・開発チームについて理解を深めるべきか

採用背景や採用要件は、事業やサービスの課題から、プロダクトの課題、そして開発するチームの課題へと段階的におちてきて、「なぜ採用したいのか」という採用背景や、「どんな人を採用したいか」という採用要件が発生します。

一方で、これをすっ飛ばし、「事業成長に伴い」「人が足りないから」と曖昧な表現になりがちです。曖昧な表現では訴求力も弱く、ターゲットの設定も大雑把になってしまいます。

エンジニアが協力してくれるからといって、エンジニアに言われたことをそのまま書き起こしても、現場の人は採用のプロではありません。

そのため、採用担当者がヒアリングを通じて、採用市場で戦える様に内容をブラッシュアップしたり、採用市場に鑑みて修正を行う必要があります。

そして、上記を行う上で重要なことが、本記事の主旨であるプロダクトや開発チームについて理解を深めることです。

■この記事の概要と、できるようになること

この記事では最終的に上記の深堀りができるよう、プロダクトと開発チームの成長を4つのステージに分け紹介し、それぞれのステージで必要になる人材、行うべき採用活動について解説していきます。

この記事を理解することで、このようなことができるようになるでしょう。
・現場へのヒアリング力、コミュニケーション力が高まる。
・ペルソナが明確になり、求人票やスカウトの訴求力も高まる。
・中長期の戦略が立てられるようになる。

■理解しておくべき4つのステージ

プロダクトや開発チームがどのように拡大・成長していくかは、もちろん個社ごとに異なります。

一方で、「サービスが成長すれば保守性が重要になりシニアクラスのエンジニアが必要」といった一般論があることも事実であり、基本的な変化を以下の図のように4つのステージでまとめました。

(1)立ち上げ期
(2)チーム開発の始動期
(3)開発対象の分割期
(4)組織の複雑化期

ここから、一つずつ詳細を解説していきます。

【Stage.1 立ち上げ期】 1 Product – 1 Engineer

-プロダクト・開発チームの状況 -

立ち上げ期 / 1 Product – 1 Engineer

＜プロダクト＞
・初期フェーズ

＜開発チーム＞
・1プロダクトに対し1~2名のエンジニアが開発を行う

この時点での開発の目的はサービスのコンセプト探しやテストマーケティングであることが多く、本当に開発を進めて良いのか、いち早く確認することが求められます。「とにかく動くものを早く作る」ことが重要視されますので、必要な人材もそれに対応できるエンジニアです。

- 必要な人材 -

フルスタックに近いエンジニア / 市場価値は非常に高い

＜Must＞
・インフラの構築、フロント・サーバサイドの開発に対応でき、
　一人でも必要最低限のプロトモデルを作れるエンジニア。

＜Want＞
・サービスのグロース経験がある。
・業務委託や外注に指示が出せる。ビジネスについても興味がある。
・今後のプロダクト、チームの拡大について考えられる。
・UXデザイン、もしくはUIデザインのスキルがある。

このタイミングでの採用は「未経験者でもとりあえずコードが書ければいいんじゃないか」とも思われがちです。しかし立ち上げ時はとにかくやらなければならないことが多岐に渡ります。そのため、最終的に修正も含めた開発スピードを求めるのであれば、一人で広く開発でき、かつ一定のスキルレベルのあるエンジニアがよいでしょう。

また2人目の採用もフルスタックよりとなることが多いです。フルスタック寄りのエンジニアといっても皆どこかの領域に強みがあるはずですので、一人目とは違った得意領域のあるエンジニアの採用となることが多いです。

正社員の採用はやはり難易度も高くなりますので、業務委託や外注を利用することも一つの手です。

ただし、たとえば知り合いの未経験者やクラウドソーシングといった比較的費用の安い業務委託や外注方法をとることには注意が必要です。

明確な機能や仕様が決まっていればよいですが、開発の指揮・主導をする必要もでてきますしセキュリティやデータ管理、作り直しのコストもその後に必要になることもあります。無料サービスのテストマーケティングであればよいですが、有料サービスとして展開する予定であれば、安易に「安さ」「手軽さ」を求めてしまうと、コミュニケーションコストやその後のメンテナンスコスト等が高くつく可能性がありますので、指揮をする人が非エンジニアであれば、しっかりとサポートをしてくれる業務委託、外注サービスを選ぶほうが良いでしょう。

- 採用活動 -

初期フェーズであることのメリットを最大限打ち出し、ツテから始める

＜訴求内容＞
・技術選定を含めた裁量
・開発がビジネスに与えるインパクトが大きいこと（やりがい）
・ビジネスモデルや企業ビジョン
・ストックオプション

＜採用施策＞
・リファラル
・Twitter採用
・個人のエージェントやVCの紹介

この採用は、求める人材の市場価値が高いことに対し、賃金・開発環境などの魅力付けは難しく非常に難易度の高い採用といえます。そのためチャレンジングな開発を取り入れたり（候補者に自由に選んでもらったり）、ビジネスモデルやビジョンに共感してもらうなど、とにかく初期フェーズであることのメリットや投資価値に魅力を感じてもらうことが必要です。

採用の手法としてはリファラル採用となることがほとんどです。

そういったツテがない場合は、Twitter採用など費用を抑えながら1to1でアプローチできる方法がおすすめです。この時点では、求人票の掲載などのマス向けの広告施策では発見、検索される可能性も低く、また一般的な比較検討の指標である給与や企業知名度が横並びの企業よりも弱く十分な効果は得にくいでしょう。

一方でストックオプションなどの提示ができるのであれば、スタートアップやベンチャーに興味のあるエンジニアには魅力に映ることも多いでしょう。

また、既に企業としては別サービスで給与や知名度があるという場合でも、ビジネス職しかいない会社であればエンジニアの一人目の採用は上記と同じ考えをした方がよいです。エンジニアは「エンジニア組織」に入りたいという要望を持つ候補者も多いため、他の職種では人気があるからといって安易な計画や施策では採用の成功は見込めないでしょう。

このタイミングでは、採用コストとして多くの工数がかかることを覚悟しておきましょう。

【Stage.2 チーム開発の始動期】 1 Product – 1 Team + Manager

-プロダクト・開発チームの状況 -

チーム開発の始動期 / 1 Product – 1 Team + Manager

＜プロダクト＞
・方向性が見え開発スピードを上げたいニーズが強くなる

＜開発チーム＞
・「チーム」としての開発が始まる

目安として3人目のエンジニアがジョインすると、次のステージとして3名から最大でも8人程度といわれています。マネジメントコストや、コミュニケーションコストの観点もあり、スイートスポットは4~6名ともいわれます。

「チーム」としての開発効率を上げるためには、タスクの割り振りや、誰がどこまで開発するのかといった役割分担が重要になります。またチーム開発を進めるにあたり様々なことを考えなければなりませんが、例えば一種の開発の進め方のフレームワークとして、開発手法はどうするか、バージョン管理のルールや、その他ツールの利用はどうするかなども考え、チームのメンバーに説明し、浸透させる必要があります。

この時に、これまでウォータフォール型で開発していた人を、なにも考えずにアジャイル型の開発チームに入れてしまうと混乱を招きますし、Gitなどの開発ツールの運用には社内ルールもあるでしょう。人数が増え開発のスピードが上がる一方、“チームとしてちゃんと成立すること”には、一層気をつけなければなりません。

- 必要な人材 -

開発も行えるリーダー

＜Must＞
・目標や業務管理の意欲を持つエンジニア

＜Want＞
・自社よりも規模の大きい企業でのマネジメント経験

このステージでは単に開発のできるエンジニアだけでなく、集団のまとめ役として、目的や目標を掲げたり、業務を管理したりするリーダーが必要になります。ここではマネージャーというよりチームを牽引するリーダーというイメージが強いでしょう。このタイミングのマネージャーは、手を動かさないということは少なく、多くの場合自分でも開発を行いながら、皆を牽引していくイメージです。

欲を言えば今後の拡大を見越してより大きな規模でのマネジメント経験があり、今現場にいるメンバーをチームマネージャーとして育成でき、自身はもう一つ上の階層を見れる人が良いでしょう。また「社内の一人目のマネージャー」という役割は負担がとても大きいものですので、できることならマネジメント経験者を起用することがおすすめです。

ちなみに、エンジニア職は、技術力の高いメンバーがリーダーやマネージャーになるというものではありません。昨今のキャリアパスや評価軸としてマネジメントではなく技術に焦点が当たることが一般化しています。そのため、フルスタックな開発スキルを持っていたり、年長者であるからといった理由で、無理に押し付けることはせず本人の意向を重視してください。

開発メンバー

＜Must＞
・特になし

＜Want＞
・チームでの開発経験
・何らかの得意領域
・マネジメントにも挑戦したい意欲

 既存のメンバーがリーダーを務める場合は、メンバーレイヤーの採用も必要となります。

多くの場合「既存のプログラミング言語とフレームワークの経験者」という設定をしがちですが、昨今使われるJavaやRuby、PHP、Pythonなどは乗り換えもそこまで大変なものではないために、ここでセグメントを切ってしまうことはもったいないです。

この段階では開発スピードが求められますし、今後チームも柔軟に変わることから比較的広めの採用要件としてもよいでしょう。一方で、広めに設定した採用要件では候補者に魅力に映りにくいこともありますので注意が必要です。このことについては後述します。

このフェーズでは業務委託やインターンなどを活用しても効果的です。

また毎回マネージャーを外から採用することは、今の採用市場では非常に難易度が高いため、メンバーの採用では将来的にマネジメントにも挑戦したいかどうかを重視してもよいでしょう。そういった方を1、2名入れておくと、チームを増やした際に会社の歴史を知っている人が新しいチームのリーダー・マネージャーになれるためおすすめです。

- 採用活動 -

開発も行えるリーダー

＜訴求内容＞
・特徴のある開発環境（チャレンジングな開発課題をしている等）
・高待遇
＜採用施策＞
・求人広告
・潜在層の採用（採用広報、タレントプール運用）

今もっとも需給バランスが崩れ需要過多なのはこのポジションかもしれません。「とりあえず経験豊富で優秀な人」となりがちですが、Web系企業でこのような方は引っ張りだこで、リファラルやスカウトですぐにいなくなってしまいますし、自ら職務経歴書を書いて転職サイトに登録するといったエンジニアは少なくなっています。

そのため、「すぐに採用できる」とは思わずに、潜在層のタイミングから声をかけておき、中長期で採用を目指す方が良いでしょう。

カルチャーや待遇、働きやすさといったことはもちろん比較検討の要素の一つですが、技術職のエンジニアにとって、チャレンジングな開発課題があるかは非常に重要です。（今使っている技術が数年で廃れる可能性もあるため）

一般的に動画配信やアドテクの開発でいかにレスポンスを早くするかといったものや、独自性あるサービスの開発などは人気がありますが、ビジネスモデルが先行していて「〇〇のサイトのようなものを作ってほしい」といった既にある答えを目指す開発はあまり人気がありません。メディアやECサービスはこういった開発になることも多いです。

単に自社がこのポジションを募集していることを伝えるだけでは一方通行になっていまいますので、他のポジションに比べて、自社に来てくれる理由が何なのかはしっかり考える必要があります。

開発メンバー

＜訴求内容＞
・既存メンバーの能力の高さ
・技術的な経験値を得られること（比較的新しい技術や取り組み等）
・技術力に応じた報酬制度、その他福利厚生面での訴求

＜採用施策＞
・転職エージェント
・求人広告

メンバーレイヤーの採用は他のポジションと比べて比較的採用倍率は低いです。しかしレベル感は企業により非常に幅が広いため、開発未経験者から、マネージャーはやりたくないという理由で技術力は非常に高いメンバーもいることに注意してください。

ここで「誰でも歓迎」といった間口の広い訴求をしては、結局誰にも刺さらない訴求となりがちです。

そのため、成長を望むエンジニアにはしっかりと経験として得られることを。既に経験のあるエンジニアに対しては柔軟な報酬制度や働きやすさといったことを訴求し、各ペルソナに合わせた訴求を心がけてください。

多くの場合、既存メンバーが優秀であること、また付随して開発体制がしっかりしていることなどはプラスに働きますので、自社の既存メンバーにスポットライトを当てることはおすすめです。

採用施策は、比較的広く浅くアプローチできる施策がよいでしょう。できるだけ手間のかからないもので、接触できる母集団を変えたり、訴求内容を変えたりと改善を早く回すことで相性のよいものを見つけてください。

【Stage.3 / 開発対象の分割期】 1 Product – N Team + Expert

-プロダクト・開発チームの状況 -

開発対象の分割期 / 1 Product – N Team + Expert

＜プロダクト＞
・マーケットフィット、成長フェーズ
・機能やサービスごとの切り出し

＜開発チーム＞
・チームとしての切り出し
・技術負債への対策

次のステージとして、一つのプロダクトが成長し、ユーザーが増え、機能が多様化してきます。このような大きなプロダクトを一つのチームで全体を開発することは大変ですので、機能別（切り出し方はそれぞれ）に開発することが多いです。例えば決済機能だけ、検索機能だけ、認証機能だけ、といったものです。それにより複数のチーム編成が必要になり、それぞれの専門性や役割分担、よりマネージャー寄りの人材が必要になります。今後の拡大に向けてマイクロサービス化を進めたり、設計を見直すこともあるでしょう。

他には、モバイルへの対応や、外部への機能提供を目的としたAPI、機械学習を用いたレコメンド機能の開発、toB向けに展開していた事業をtoC向けにも展開するなど、ビジネス上の目的が多様化することによる拡張も増えてきます。

チームの分割としては、上記のようにそれぞれの機能ベースでチームが組まれたり、会社によっては、たとえば「インフラチーム」のような担当領域ごとにチームを編成したりといったケースが見られます。

プロダクトやチームが分割されるだけでなく、特定の専門性が高まるということになります。後述しますが、新しく入るメンバーもより各領域に強いメンバーが求められることにもなるでしょう。

また、この頃には開発をはじめて数年がたっていることが多いため、初期のコードに負債を抱えているケースも多くあります。この技術負債は、事業やビジネスが次のステージに行くために必要な成長痛のようなものですので、どこかのタイミングで改修しなければなりません。

- 必要な人材 -

専門色の強いメンバー

＜Must＞
・フロント、サーバイサイド、インフラ、DB等の開発領域で特に専門性の高いエンジニア
・モバイル開発やブロックチェーン、機械学習など専門分野に特化したエンジニア

＜Want＞
・技術面だけでなく、類似するサービスでのマネジメントや業務経験
・各専門領域以外のスキル

プロダクトやチームが分割すれば、それぞれの開発における専門知識（ドメイン知識や経験など）を持った人材が必要になります。（もちろん、チームメンバー全員がその専門性を持っている必要はありません。）

ここでの専門性とは非常に広義な意味での専門性を指します。たとえば、レコメンド機能の性能向上を目的にアルゴリズムに強い機械学習エンジニアを採用したり、決済周りの機能の拡張性を上げるために会計知識のあるエンジニアを採用したり。その他アドテクサービスであれば高速化が得意なエンジニアや、クローラー開発であれば類似サービスでの経験のあるエンジニアが求められるでしょう。

新しい専門性を勉強したいエンジニアもたくさんいますので、既存の知識をそのまま活かして転職する人は学習できる機会が少ない分待遇を良くする。一方で新しい専門性に挑戦したい人は学習機会が多い分少し前者と比較し待遇を落とすなどの対応ができれば、コストを掛けすぎずメンバーを揃えることができるでしょう。

専門性を細かく分けることもできますが、ここで重要なことは、このステージでは「スキルの幅の広さだけでなく、深さを持ったメンバーが重要になる」ということです。

非エンジニアの採用担当者であれば、職務経歴書等を見た際に様々なスキルが使えることに魅力を感じることも多いでしょう。しかしこのフェーズでは求められることが異なりますので注意が必要です。

開発メンバー

＜Must＞
・特になし

＜Want＞
・チームでの開発経験
・学習意欲

基本的にステージ2と同じですが、プロダクトやチームが分割すればその分「人数」も必要になります。これにより後述する採用課題も発生しやすくなります。

この時期には仕組みや組織制度もある程度整っているはずですので、受動的に成りすぎない自立し学習意欲の高いメンバーが求められるでしょう。

- 採用活動 -

専門色の強いメンバー

＜訴求内容＞
・専門性を活かして解きたくなるような開発課題がある
・より専門性を磨ける環境
・高待遇

＜採用施策＞
・潜在層の採用（採用広報、タレントプール運用）
・求人メディア

専門的な知識や経験はそれらを活かす課題や場があるはずですので、しっかりとその内容を表現しましょう。

採用担当者がそれらを理解していないことも多く、候補者には専門性を求めている一方、「なぜその人が必要か」という本記事の主旨でもある採用背景を伝えていない求人票も多いように思えます。

また専門的な知識や経験をもつエンジニアはやはり市場価値が高く、早く・安く・楽にといった三拍子の揃った採用施策はないでしょう。そのため、三つの要素の内の優先度を決めておくことが重要です。早く採用することがもっとも重要なことなのか、安く採用することが最も重要なことなのか、この優先度が決まらないがために中途半端な施策を実施し、結果的に全て叶わないという悲しいケースも多く見かけます。

特にプロダクト主体の事業会社であれば、開発の遅れによる事業の損失は非常に大きいものですので、費用と工数をかけてでも早く採用できることが求められるでしょう。

開発メンバー

＜訴求内容＞
・既存メンバーの能力の高さ
・技術的な経験値を得られること（比較的新しい技術や取り組み等）
・技術力に応じた報酬制度、その他福利厚生面での訴求

＜採用施策＞
・転職エージェント
・求人広告
・業務効率化（ATSやRPOの利用等）

基本的にステージ2と同じですが、このステージのメンバーレイヤーの採用は「採用人数」が膨らみやすく、採用担当者の業務は指数関数的に増えがちです。そのため、少し気を抜いてしまうと業務の質がおろそかになりがちです。

その結果発生するアンチパターンが、チーム内に入るエンジニアと、マネージャーや専門分野のエンジニアをごちゃまぜにして採用計画や採用単価を設定してしまうことです。ひどい場合はエンジニア職とそれ以外の職種も全て混ぜてしまい、同じ媒体で採用を目指すこともあります。

このような方法で採用できている事例はほとんど見かけません。ポジションごとに計画と戦略をたてて実施することが必要です。

とはいっても工数が足りなくなることも多く、ATSやRPO等を利用した業務効率化が求められます。採用担当者の採用も同時に考えるべきでしょう。

【Stage.4 / 組織の複雑化期】 N Product – N Team + Manager of other layers

-プロダクト・開発チームの状況 -

組織の複雑化期 / N Product – N Team + Manager of other layers

＜プロダクト＞
・保守、運用

＜開発チーム＞
・「組織」としての動き

このステージではサービスがグロースしているはずで、ビジネスステージ的には上場を見据えていたり、既に上場をしている企業も多いはずです。組織全体としては40名〜多くても100名、業務委託なども含め関わっているエンジニアの人数で言えば15名〜になればこの点について考える必要性が出てくるでしょう。

このステージでは資金も潤沢になることから、外部から高額で経験者を引き入れるケースも増えます。カルチャーや既存社員との相性を意識していても、どうしても予期しない退職や必要性に迫られ、組織として明文化したルールや制度が求められます。ここで発生するのが、2層以上の階層構造です。それぞれ意思決定できる範囲が限定され、何かしら予算や採用権限について承認を得なければならないフローも発生するでしょう。ここで発生するのは、「組織」としての動きです。

この段階は、これまでのステージよりも各企業ごとに様々なプロダクト・チームの形をとります。

-必要な人材 -

上位レイヤーのマネージャー

＜Must＞
・マネジメント階層に適したマネジメント能力

＜Want＞
・幅広いレイヤーのマネジメント能力
・開発課題や組織に対してしっかりと理由付けをして判断してきた経験それ以外にもビジネスチームとの折衝や、様々なトレードオフの関係の中での難しい意思決定など、より上位のマネジメント職には経営視点やより長期目線で事業・プロダクト・開発チームについて考えられる必要があるでしょう。

このステージでは、複数のチームをまとめるためにマネジメントの階層が多層化します。組織として意思決定や目標管理の階層を構築しなければなりません。

ステージ1~3の採用を行いつつ、CTOやVPoEなど「上位レイヤーのマネージャー」の採用が必要です。

この頃には人件費も大きくなっているはずですので、収益構造やマーケット、顧客を理解した上で、開発の優先順位をつけたり、人数が増えることによる帰属意識やモチベーションの低下などにも対応が必要です。

それ以外にもビジネスチームとの折衝や、様々なトレードオフの関係の中での難しい意思決定など、より上位のマネジメント職には経営視点やより長期目線で事業・プロダクト・開発チームについて考えられる必要があるでしょう。

- 採用活動 -

上位レイヤーのマネージャー

＜訴求内容＞
・ビジネスやチーム体制などにしっかりとロジックがあること
・エンジニアリング組織であること（ビジネスサイドとの人数比等）
・待遇

＜採用施策＞
・役員のリファラル
・ヘッドハンティング
・ハイクラスの転職エージェント

経営視点（もしくはそれに近しい業務レイヤー）を持ったエンジニアは非常に少ないでしょう。

経験者が求められる一方、規模が大きくなるほどその規模のマネジメント経験者少なくなります。特にメガベンチャーやマザーズやその他上場企業などの経験者となるとその界隈の中でぐるぐると流通している場合もあります。経験者は希少で、各社経験者を求め、更に市場価値が上がりその分給与も高額になりがちです。

こういった経験者を採用することはやはり非常に難易度が高いため、下のマネジメントレイヤーから抜擢するという意思決定も重要でしょう。

このレベルになると自社の訴求方法は様々でしょう。ただし、これまで自社がビジネスや開発の進め方、採用の方針など様々な面においてどういった考え方、ロジックで進めてきたのかといったことは候補者としても気にするところでしょう。候補者に対して論理的な思考能力や経験を求めることは一般的ですが、マネジメントレイヤーが上がるほど、候補者側も企業側のビジネス・開発のこれまでの思考能力を見ていることは、採用担当者は意識しましょう。つまりは本記事の主旨である採用背景をしっかりと理解するということに繋がります。

まとめ・参考記事

この記事では、大きく4つのステージからプロダクト・開発チームについて解説し、それぞれのステージで必要な人材と採用活動を解説しました。

自社は今どのステージか。本記事と見比べた時に、実際にはどのようなプロダクト、開発チームになっているのか。そして採用要件や採用活動はしっかりと採用背景を反映したものになっているかを確認してみてください。

ぜひこのステージモデルを意識しながら今募集している採用要件の解像度を高め、そして中長期の採用戦略をつくり、先んじた採用活動をしてみてください。

こちらの記事もわかりやすいので合わせて読んでみてください。

Scaling Engineering Teams