エンジニア職種を徹底解説｜1つのサービスを、だれがどこまで作るのか

「フロントエンドとバックエンドの違いが分からない」「インフラって何をする人ですか」という質問を、うちでは本当によく受けます。職種の一覧表を見ても分からないのは当然で、名前だけ並べても、どこで手が切り替わるのかが見えないからです。

そこでこの記事では、職種を1つずつ説明する代わりに、1つのWebサービスができあがるまでを最初から最後まで追います。追いかけながら、その段階でどの職種が何を持ち、何を次の人に渡すのかを見ていきます。

例として使うのは、美容室やクリニックの空き枠を、お客さんが自分のスマホから押さえられる「予約サービス」です。実在するサービスの話ではなく、説明のために置いた架空の例ですが、ネットショップでも社内の勤怠管理でも、作られ方の骨組みはほぼ同じです。

職種とは「役割の名前」ではなく、「サービスのどの層を持つか」の名前です。 ここが分かると、求人票の職種名も、勉強の順番も、急に読めるようになります。

要件定義と設計｜「何を作るか」を決めて、図に落とす人

予約サービスを作りたい、という話は、最初はたいてい一文です。「お客さんがスマホから予約できるようにしたい」。これだけでは作れません。

• 予約は会員登録が必要なのか、名前と電話番号だけでよいのか
• 当日キャンセルはできるのか、できるなら何時までか
• 店側は予約をどの画面で見て、どう変更するのか
• 予約が入ったら、誰にどんな通知が飛ぶのか

こうした「決めないと作れないこと」を、依頼する側と話しながら一つずつ決めていくのが要件定義です。受託の現場では、営業や PM(プロジェクトマネージャー)が窓口になり、経験の長いエンジニアが同席して「それは技術的にこういう作りになります」と翻訳することが多いです。

決まった要件は、設計に落ちます。ここでやることは大きく3つです。

1. 画面の一覧と、画面どうしのつながり(画面遷移)
2. データの形。予約、店舗、お客さん、メニューといった「記録するもの」の一覧と、それぞれの関係
3. 画面と裏側がやりとりする「窓口」(API)の一覧。「空き枠を返す」「予約を作る」「予約を取り消す」など

この工程にいる人の1日は、打ち合わせと、図と、文章です。依頼する側の言葉を聞き、それを画面遷移図やデータの図に描き直し、仕様書として文章に残し、次の日にまた「ここはどうしますか」と確かめに行きます。コードを書く時間は少なく、決めることと書き残すことが仕事の中心です。

設計の成果物は、次の全職種が同じものを見て作業するための「共通の地図」です。 フロントエンドは画面一覧とAPI一覧を、バックエンドはAPI一覧とデータの形を、インフラはデータの量や想定アクセス数を、それぞれこの地図から受け取ります。地図が曖昧なまま進むと、あとの全工程で手戻りが起きます。

この工程を専任でやる職種名は、会社によって違います。「システムエンジニア(SE)」「アーキテクト」「テックリード」などと呼ばれますが、いずれも未経験で最初に就く役割ではなく、フロントかバックを数年やった人が上がってくる場所です。だからこの記事では、ここは「行き先」として覚えておく程度で先に進みます。

フロントエンド｜画面を作り、ブラウザで動かす人

設計の地図を受け取って、最初にお客さんの目に触れる部分を作るのがフロントエンドエンジニアです。

持つ範囲は「ブラウザ(とスマホのブラウザ)の中で起きること全部」です。予約サービスなら、カレンダーの見た目、空き枠を押したときの色の変化、名前と電話番号の入力欄、入力が足りないときの赤いメッセージ、送信ボタンを押したあとの「予約を受け付けました」の画面。ここまでがフロントの仕事です。

使う言語は HTML、CSS、JavaScript、そして JavaScript に型を足した TypeScript です。実務では素の JavaScript で画面を組み立てることは少なく、React や Vue といった「画面を部品として組み立てるための道具(フレームワーク)」を使います。道具はいくつかありますが、どれか1つを深くやれば、他は書き方の違いとして吸収できます。

1日の仕事を大まかに言うと、デザイナーが作った画面のデザイン(Figma などで渡されることが多いです)をコードに起こし、バックエンドが用意した API から返ってくるデータを画面に流し込み、いろいろな画面幅で崩れないかをブラウザで確かめる、この繰り返しです。加えて、「押したのに反応がない」「入力したのに消えた」といった不具合の報告が来れば、原因が画面側にあるのか裏側にあるのかを切り分けるところまでがフロントの範囲です。

渡す先と受け取る先は、はっきりしています。デザイナーから見た目を受け取り、バックエンドから「この URL を叩けば空き枠が JSON で返ってきます」という API を受け取り、それを合体させて画面にします。フロントエンドの仕事は「見た目を作ること」ではなく、「見た目とデータをつないで、押したら正しく動く状態にすること」です。 見た目だけならデザイナーの領域で、そこの違いについてはWebデザイナーについて書いた記事で触れています。

未経験から目指すなら、最初に学ぶのは HTML と CSS で静的なページを1枚作ること、次に JavaScript でボタンを押したら何かが変わる体験をすること、その次に React などで「データの一覧を画面に出す」ところまでです。ここまでできると、フロントエンドの求人票に書いてある言葉のほとんどが読めるようになります。

バックエンドとデータベース｜画面の裏で処理をして、記録を守る人

お客さんが「予約する」ボタンを押した瞬間、画面から裏側へ「この店の、この日のこの枠を、この人が予約したい」というリクエストが飛びます。そこから先を持つのがバックエンドエンジニアです。

持つ範囲は、リクエストを受け取ってから答えを返すまでの「処理」と、その処理が読み書きする「記録」です。予約サービスなら、次のことを全部、お客さんには見えないところで行います。

• その枠がまだ空いているかを確かめる
• 同じ瞬間に別の人が同じ枠を押していたら、先に押した方だけを通す
• 予約を記録して、予約番号を発行する
• 店側と本人に通知を送る
• 画面に「成功しました」か「その枠は埋まりました」を返す

言語は Java、Python、Go、PHP、Ruby などが使われます。どの言語かは会社や案件で決まっていて、言語ごとに定番のフレームワーク(Java なら Spring、Python なら Django や FastAPI、PHP なら Laravel、Ruby なら Rails)があります。受託の現場では、新しく作るものと、長く動いているものとで言語が違うことが多く、1人のエンジニアが案件ごとに複数の言語を触ることも珍しくありません。「この言語でないと就職できない」という話ではないです。

データベースは、バックエンドと一体で語られることが多い領域です。予約、店舗、お客さん、メニュー。こうした「記録するもの」を表(テーブル)として定義し、消えないように、矛盾しないように保管するのがデータベースの役目で、それを操作する言語が SQL です。製品としては PostgreSQL や MySQL がよく使われます。

大きな会社では「データベースエンジニア」や「DBA(データベース管理者)」という専任がいて、表の設計、性能の調整、バックアップを担いますが、多くの現場ではバックエンドエンジニアが表の設計まで持ちます。バックエンドの仕事は「動くこと」ではなく、「間違った記録が1件も残らないこと」を保証する仕事です。 二重予約が1件でも起きれば、画面がどれだけきれいでもサービスとしては失敗なので、ここの責任は重いです。

1日の仕事は、API を1本ずつ実装し、その API に対して「正しい入力なら成功する」「不正な入力なら弾く」というテストを書き、フロントエンドに「この形で返します」と仕様を伝え、インフラに「この構成で、このくらいの記録量で動かしたい」と要件を渡す、という流れが中心です。

未経験から目指すなら、最初に学ぶのは言語を1つ(Python か JavaScript が入り口として多いです)、それに SQL で「表を作って、入れて、取り出す」までです。SQL はどの言語を選んでも避けて通れないので、後回しにしないほうがよいです。

インフラ／クラウド｜動く場所を用意して、落とさない人

フロントとバックのコードができても、それは「手元のパソコンで動く」だけです。世界中の誰かがスマホから予約できる状態にするには、インターネット上の「動く場所」が要ります。そこを持つのがインフラエンジニアです。

持つ範囲は、サーバー(コードを動かす機械)、ネットワーク(そこへ届くまでの道)、そしてアクセスが増減しても止まらないための仕組みです。昔は物理的な機械を買ってデータセンターに置きましたが、いまは AWS や GCP のようなクラウドで、画面や設定ファイルから機械を借ります。だから「クラウドエンジニア」と呼ばれることも増えました。

使う道具は Linux(サーバーのほとんどがこれで動いています)、Docker(コードと動作環境を1つの箱にまとめる道具)、そして AWS や GCP の各サービスです。設定を手作業でなくコードで書く「Infrastructure as Code」の道具(Terraform など)も、いまは当たり前に使います。

1日の仕事は、バックエンドから「この構成で動かしたい」という要件を受け取り、クラウド上に環境を組み、コードが自動で配備される流れ(CI/CD)を作り、アクセスが増えたときに自動で台数が増える設定を入れ、それらが期待どおりに動くかを確かめる、というものです。障害が起きたときの一次対応も、この職種に来ることが多いです。

インフラの仕事は「作ること」より「落とさないこと」に重心があります。 作るのは最初の数週間で、そのあと何年も「止まらない」「遅くならない」「侵入されない」を守り続ける仕事です。フロントやバックが「動いた」で一区切り付くのに対して、インフラの区切りは「今日も止まらなかった」なので、仕事の感触がかなり違います。

未経験から目指すなら、最初に学ぶのは Linux のコマンド操作と、Docker で自分の書いたコードを箱に入れて動かすところまでです。AWS の資格から入る人もいますが、Linux が触れないと資格が「言葉だけ知っている」状態で止まるので、順番は Linux が先です。

テスト／QAと運用・保守／SRE｜出す前に壊し、出した後に見張る人

ここまでで、予約サービスは「動く」状態になりました。しかし、動くことと、お客さんに出せることは別です。

出す前に、あらゆる方法で壊しにかかるのがテスト／QA(品質保証)エンジニアです。「過去の日付を選んだらどうなるか」「電話番号にひらがなを入れたら」「予約完了の画面でブラウザの戻るボタンを押したら」。作った本人が思いつかない使い方を、仕様書を読みながら網羅的に試します。作った本人は「正しい使い方」を知りすぎているので、別の人が見ることに意味があります。

見つけた不具合は、「どの画面で、何をしたら、何が起きたか、本来はどうあるべきか」を揃えて、フロントかバックの担当に戻します。この戻し方が雑だと直す側が再現できないので、テストの仕事は「壊すこと」と同じくらい「正確に書き残すこと」でできています。

手で試す部分と、コードで自動化する部分があり、後者は「テスト自動化エンジニア」「SET(Software Engineer in Test)」と呼ばれることもあります。使う道具は、ブラウザを自動で操作する Playwright や Selenium、テストの項目を管理する表計算やテスト管理ツールです。

出した後に見張るのが、運用・保守、あるいは SRE(Site Reliability Engineering)です。予約サービスは出した瞬間から、深夜も休日も動き続けます。「朝の8時だけ遅い」「特定の店舗だけ予約が入らない」「メールが届かないという問い合わせが来た」。こうした声を受けて、ログ(サービスが吐く記録)を読み、原因の場所を特定し、直して、また出します。

SRE はこの運用を「気合いで見張る」のではなく、「どれだけの時間、正常に動いているか」を数字で決め、その数字を守る仕組み(監視、自動復旧、負荷対策)を作る考え方です。インフラエンジニアと重なる部分が大きく、会社によっては同じ人が両方を持ちます。

サービスの寿命のうち、「作っている期間」より「動かし続けている期間」の方がずっと長いです。 だから運用の仕事は地味に見えて、エンジニアの仕事時間の中では大きな割合を占めます。受託の現場でも、納品して終わりではなく、そのあとの保守契約で何年も付き合う案件が多いです。

未経験からテストや運用を目指す場合、入り口は「仕様書を読んで、書いてあるとおりに動くかを確かめる」役割から始まることが多く、そこからログが読める、コードが読める側へ育っていく道筋です。最初に学ぶのは、エラーメッセージとログを読んで「どこで何が起きたか」を文章にすることで、これは他のどの職種に移っても効きます。

主な職種の比較表と、隣にある職種

ここまでの主な職種を1枚にまとめます。

表の「最初に学ぶこと」の列を見ると、どの職種も入り口は驚くほど近いところにあります。 HTML と CSS、言語を1つ、SQL、Linux、ログを読む。全部やっても、最初の数か月で通る範囲です。

隣にある職種にも触れておきます。深く入りませんが、名前と「どこの層か」だけ知っておくと求人票が読めます。

• モバイルエンジニア。予約サービスを「アプリ」として出すときの、iPhone や Android の中で起きることを持ちます。フロントエンドの親戚で、言語は Swift や Kotlin、両方を一度に作る Flutter や React Native があります
• データエンジニア／データアナリスト。予約の記録が溜まってきたときに、「どの曜日に予約が集中するか」を出せる形に整える人と、そこから店の判断に使える数字を出す人です。SQL と Python が中心です
• セキュリティエンジニア。予約サービスに他人の予約が見えてしまう穴がないか、外から侵入できないかを確かめ、防ぐ人です。バックエンドとインフラの両方を知っている必要があり、未経験の入り口としては遠い方です
• PM／PdM。PM(プロジェクトマネージャー)は納期と人と予算を持ち、PdM(プロダクトマネージャー)は「そもそも何を作れば使われるか」を持ちます。どちらもコードを書く職種ではありませんが、エンジニアと一番長く話す相手です

小さなチームと受託では、境界がにじむ

ここまで、職種を1つずつ切り分けて説明してきました。ただ、この切り分けが教科書どおりに存在するのは、大きな会社か、大きなサービスの話です。

受託の現場では、1つの案件に付くエンジニアが2人か3人ということが珍しくありません。その場合、1人が予約画面(フロント)と予約 API(バック)の両方を書き、もう1人が AWS の環境とテストを見る、という分け方になります。フロントとバックの両方を1人で持つ働き方を「フルスタック」と呼びます。

スタートアップや社内の小さな開発チームでも同じで、職種の名前より「いま足りないところを埋められる人」が求められます。求人票に「フルスタックエンジニア」と書いてあるのは、たいてい「フロントもバックも両方見てほしい」という意味で、両方を極めた達人を探しているわけではありません。

境界がにじむのは、悪いことばかりではありません。フロントを書きながら API の裏側も書くと、「なぜこの形で返してほしいか」が自分で分かるので、設計の会話が速くなります。逆に、大きな会社でフロントだけを何年もやると、深さは出ますが、隣の層がブラックボックスのままになります。どちらが良いという話ではなく、働く場所の大きさで、持つ範囲の広さが決まるということです。

どの職種を名乗っていても、隣の層を「読める」ことは求められます。 フロントエンドがバックエンドの API を書けなくてもいいですが、返ってきたエラーがフロントの問題か API の問題かを切り分けられないと、自分の仕事が終わったかどうかも判定できません。

もう1つ、小さなチームで重要になるのが、書いて伝える力です。境界がにじむほど、「ここまでやりました、ここは確かめました、ここが分かりません」を文章で残せるかどうかが、任せられる範囲を決めます。この点は在宅を任せるかどうかについての記事で詳しく書いています。

未経験のうちは、職種を決めなくていい

ここまで読んで、「じゃあ自分はどれを目指せばいいのか」と思ったかもしれません。結論から言うと、学び始める前に決める必要はありません。

理由は2つあります。

1つ目は、どの職種も土台が同じだからです。HTML と CSS で画面が1枚作れること、JavaScript で「押したら変わる」が書けること、SQL で表から取り出せること、Git でコードの履歴を残せること、そしてエラーメッセージを読んで原因の場所に当たりが付けられること。この5つは、フロントを目指しても、バックを目指しても、インフラを目指しても、最初の数か月でやることは変わりません。

2つ目は、未経験で採用される側に、最初から職種の専門性は期待されていないからです。未経験採用の求人は「土台があって、育つ見込みがある人」を探していて、入ってから会社の案件に合わせて役割に育てていく前提です。入社時にフロント志望だった人が、配属先の都合でバックから始まることは普通にあります。受託の現場では、案件が変われば持つ層も変わるので、なおさらです。

未経験のうちに決めるべきなのは職種ではなく、「土台を最後まで作りきるかどうか」です。 そこが終わってから、自分がどの層で手が動くのが楽しかったかで決めれば、遅くありません。

未経験からエンジニアになるまでの段階そのものについては、未経験からエンジニアになる現実について書いた記事で分けて書いています。また、AI がコードを書く時代に土台がなぜ効くのかは、AI時代にエンジニアを目指す意味についての記事を読んでください。

職種の名前は、サービスのどの層を持つかの名前です。まず1つのサービスが層に分かれていることを知り、土台を作り、それから自分の層を選ぶ。この順番で進めば、職種名に振り回されずに済みます。

※この記事はゆめさくエンジニアの代表が書いています。