「Webエンジニア」の見分け方と隣接職種の分類について

エンジニア採用を任された採用担当が最初に困惑することの一つが、「Webエンジニア」という言葉の中に細かい呼称が乱立していて、自社の募集をどの名前で出せばいいか判断できないことではないでしょうか。

この記事は、採用する側が「自社のこのポジションは何エンジニアとして募集すべきか」を判断できるようになることを目的にしています。まずWebエンジニアの範囲を定義し、各呼称がどんな観点で名付けられ、何を主な責務とするのかを押さえていきます。

Webエンジニアとは何を指すのか

WebアプリケーションやWebサービスの開発を担うエンジニアの総称です。

主にブラウザからアクセスするWebサイト・Webサービスの開発に携わります。中核となるのは、ブラウザ側の表示を担うフロントエンド、サーバー側の処理を担うバックエンドです。

ここで採用担当が最初に押さえておきたいのは、Webサービスの開発に関わるからといって全員がWebエンジニアではない、ということです。例えば、インフラエンジニア・SRE（Site Reliability Engineering）、AIエンジニア、セキュリティエンジニア、モバイルアプリエンジニアを思い浮かべてみてください。いずれもWebサービスを提供するに当たって関わりますが、担当領域や専門性が異なります。

なぜWebエンジニアの呼称は分かりにくいのか

技術レイヤー・担当範囲の広さ・役割という別々の観点で名前が付けられ、混在しているためです。

Webエンジニアの呼称が分かりにくいのは、知識が足りないからではありません。同じ「〇〇エンジニア」という形をしていても、実は別々の観点（軸）で名付けられた言葉が、一列に並んで見えているのが原因です。

呼称を生み出している観点は、大きく3つあります。

• ①技術レイヤー軸（どこを担当するか）：フロントエンドかバックエンドか。アプリケーションのどの層を受け持つかで分ける見方です

• ②担当範囲の広さ：ここはさらに2方向に分かれます。フロント〜バックという「領域（横方向）」の広さがフルスタック、設計から運用までという「工程（縦方向）」の広さがフルサイクルです

• ③役割・スタンス軸（何にコミットするか・どう働くか）：プロダクトエンジニアやBuilderのように、技術以外への踏み込み方や働き方で分ける見方です

これらの観点は互いに別の観点であるため、重複した表現も成立します。「フルスタックかつフルサイクルなプロダクトエンジニア」という人も成立します。さらにやっかいなのは、同じ呼称でも会社ごとに任せる業務範囲が違うことです。「フルスタックエンジニア」という求人タイトルが、A社とB社で別の働き方を指している場面も普通に起こります。

つまり「呼称が多すぎる」のではなく、「複数の物差しが同じ言葉の形で混ざっている」と捉えると、整理がしやすくなります。

範疇内の主要な呼称は何がどう違うのか

技術レイヤー・領域の広さ・工程の広さ・役割という、それぞれ別の軸で名付けられています。

前のセクションで挙げた3つの観点を、呼称ごとに対応させたのが次の表です。まず前置きとして、ここでの「主な責務」は会社によって境界が異なります。一律にこうだと言い切れるものではなく、自社の業務と照らし合わせる際のたたき台として読んでください。

フルスタックとフルサイクルは測る軸が違う

求人で「フルスタックで募集」と書いたつもりが運用まで任せられず、採用後にすれ違う。このミスは、フルスタックとフルサイクルを同じ「広さ」だと思い込むことから生まれます。表では別の行に分けましたが、なぜ別軸なのかを押さえておくと、要件を書き分けられるようになります。

フルスタックは「領域（横方向）」の広さを表し、フロントエンドからバックエンドまで複数のレイヤーを担えることを意味します。一方のフルサイクルは「工程（縦方向）」の広さで、設計・実装からデプロイ・運用・監視まで、開発ライフサイクルの全工程を一貫して担うことを指します。フルサイクルはNetflixが提唱した「Full Cycle Developers」という考え方が広く知られています（Full Cycle Developers at Netflix（Netflix Technology Blog・2018））。

この2つは独立していて、重なることもあります。領域も工程も広い「フルスタックなフルサイクルエンジニア」もいれば、バックエンド専任でも自分が作った機能を運用まで持つ「フルサイクルなバックエンド」もいます。

ここは要件のすり合わせで効いてきます。求人で「フルスタック募集」とだけ書いても、運用まで任せたいのか（＝フルサイクルを求めるのか）は候補者に伝わりません。レイヤーの広さと工程の広さは別途明示しないと、入社後に「運用は聞いていない」というすれ違いが起きやすくなります。

なお、フルサイクルとあわせてよく引用される「You build it, you run it（作った者が運用する）」という標語があります。これはAmazonのワーナー・ヴォゲルス氏の発言として広まったDevOpsの考え方で、Netflixのフルサイクルとは出典が異なります（A Conversation with Werner Vogels（ACM Queue Vol.4 No.4・2006））。外部に説明する際は混同しないようにしておくと安心です。

プロダクトエンジニアは「何にコミットするか」で名付けられている

プロダクトエンジニアは、技術レイヤーの軸ではなく役割・スタンスの軸で名付けられた呼称です。フロントかバックかではなく、技術実装にとどまらず仕様・UX・事業価値まで踏み込んで、プロダクトを良くすることにコミットする働き方を指します。

そのため「フルスタックエンジニア」と「プロダクトエンジニア」は対立する概念ではありません。求人で両方を求めるなら、技術の担当範囲（軸①②）と、プロダクトへの踏み込み（軸③）を分けて要件に落とすのが現実的だと思います。

Webエンジニアと混同しやすい隣接職種は何か

Webサービスに関わるが担当領域や専門性が異なるため、Webエンジニアの範疇には含めず別職種として扱います。

最初のセクションで触れた線引きを、ここで一覧にします。次の職種はWebサービスの運営に深く関わりますが、求められる専門性が異なるため、Webエンジニアとは分けて募集を設計するのが基本です。

これらの職種は、それぞれ単独で要件設計やスカウトの考え方が変わります。Webエンジニアの枠で募集すると、求める人材像がぼやけて候補者にも伝わりにくくなります。AIエンジニアやセキュリティエンジニアなど、隣接職種そのものの詳細はそれぞれの専門記事で扱っています。自社の募集がこちら側だと気づいた場合は、あわせて参照してみてください。

自社の募集はどの呼称で出すべきか

社内の実際の業務範囲から、まず技術レイヤーを決め、次に必要な役割・スタンスを足して、市場で通じる呼称に合わせます。

呼称の整理ができたら、最後は自社の募集名を決める番です。考える順番をシンプルにすると、迷いが減ります。

まず①技術レイヤー軸で、このポジションはどこを担当するのかを決めます。フロントエンド中心か、バックエンド中心か、複数レイヤーを横断してほしいのか（フルスタック）。あわせて、運用まで任せたいのか（フルサイクル）も、この段階で言語化しておきます。

次に③役割・スタンス軸で、技術以外にどこまで踏み込んでほしいかを足します。仕様やUX、事業価値まで踏み込んでほしいならプロダクトエンジニア寄り、AI活用や職種を越えたスピード重視ならBuilder寄り、という具合です。

ここまで決めたら、社内の呼び方と、市場で通じる呼称を分けて考えます。社内で独自の役職名を使っていても、求人を出すときはFindyやLAPRASなどの媒体で候補者が検索する職種カテゴリに合わせないと、母集団に届きません。「自社では〇〇と呼んでいるが、市場ではフルスタックエンジニアとして募集する」といった翻訳を一段挟むイメージです。

採用支援に入る現場でも、最初のつまずきはここに集中します。業務の実態を技術レイヤーと役割の2軸に分解せず、いきなり「フルスタックで」と募集名から入ってしまうと、候補者像が定まらず、スカウト文面も検索条件も曖昧になります。呼称はゴールではなく、業務の実態から逆算して当てはめるものだと捉えると、ポジション設計がぶれにくくなります。

呼称が決まれば、次は要件定義です。どの技術課題に取り組んでほしいか、どんな振る舞いを期待するかまで言語化できると、スカウトの精度が一段上がります。

具体的な進め方はエンジニア採用の要件定義ガイドで扱っていますのでよかったらそちらもご覧ください。