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

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

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

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

先に2つだけ言っておきます。どの職種を名乗っていても、隣の層を「読める」ことは求められます。そして、私が受託の現場で見てきた範囲では、未経験で採用される側に、最初から職種の専門性は期待されていません。どちらも理由は後半に書くので、途中の職種の説明は「どれを選ぶか」を決めるためではなく、手が切り替わる場所を知るために読んでください。

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

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

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

こうした「決めないと作れないこと」を、依頼する側と話しながら一つずつ決めていくのが要件定義です。

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

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

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

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

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

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

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

使う言語は HTML、CSS、JavaScript、そして JavaScript に型を足した TypeScript です。実務では素の JavaScript で画面を組み立てることは少なく、React や Vue といった「画面を部品として組み立てるための道具(フレームワーク)」を使います。

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

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

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

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

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

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

言語は Java、Python、Go、PHP、Ruby などが使われます。言語ごとに定番のフレームワーク(Java なら Spring、Python なら Django や FastAPI、PHP なら Laravel、Ruby なら Rails)があります。

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

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

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

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

フロントとバックのコードができても、それは「手元のパソコンで動く」だけです。

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

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

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

未経験から目指すなら、最初に学ぶのは Linux のコマンド操作と、Docker で自分の書いたコードを箱に入れて動かすところまでです。

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

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

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

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

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

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

サービスの寿命のうち、「作っている期間」より「動かし続けている期間」の方がずっと長いです。 だから運用の仕事は、見た目ほど小さくありません。

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

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

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

表の「最初に学ぶこと」の列を見ると、どの職種も入り口は驚くほど近いところにあります。

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

• モバイルエンジニア。予約サービスを「アプリ」として出すときの、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つは、フロントを目指しても、バックを目指しても、インフラを目指しても、最初の数か月でやることは変わりません。この5つを何の順に学ぶかは、Webエンジニアになるためのロードマップ に書いています。

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

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

あわせて読みたい

Webエンジニアになるためのロードマップ｜未経験からの最短ルート

Webエンジニアになるための学習ロードマップを解説。フロントエンド・バックエンドの違い、必要なスキル、ポートフォリオ作成まで網羅。

記事を読む

未経験からエンジニアになる、現実の全部｜仕事・学習・費用・最初の一歩

「エンジニアになる」を、教材を終える・求人に応募できる・仕事を納められる・在宅で任される、の4段に分けます。転職・現職でのIT活用・副業を同じ物差しで比べ、時間と費用の制約を空欄の表で書き出すところまで。

記事を読む

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