エンジニア職種マップ

01 · 開発プロセスを体験

予約アプリができるまで

工程の見出しをタップすると詳細が切り替わります。スイッチで体制を変えると、関わる人が変わる様子が見えます。

フロントとバックを分業する QAが仕様の段階から参加（シフトレフト） QAがリリース可否を判定する

02 · たとえるなら

レストランに置きかえると

バックエンドは「お客さんから見えない厨房」。見えないので伝わりにくいですが、予約や決済など、アプリの重要な処理の多くはここで動いています。

企画オーナー店のコンセプトとメニューを決める

デザイナー内装・メニュー表のデザイン見やすさ、注文しやすさを設計する

フロントエンドホールお客さんが見て触る場所。席案内、注文の受付

バックエンド厨房と在庫台帳注文を受けて調理、在庫や予約台帳（データベース）を管理

API注文伝票ホールと厨房の約束ごと。ここがズレると「頼んだ料理と違う」が起きる

QA味見・衛生チェック役開店前に確かめる。シフトレフトなら、メニュー開発の段階で「アレルギー表示は？」と指摘する

03 · 体制のパターン

フロントとバックは、分かれている現場も、一緒の現場もある

分けるか一体にするかは規模と要件で決まり、いつでも分業が正解ではありません。案件票の職種名だけでは判別できないので、使う技術で見分けます。

A. 分業型

フロント⇄ API ⇄バック

画面とデータ処理を別の人が担当。間をつなぐ「API仕様」の取り決めが要になります。

向いている：中〜大規模、Webとスマホアプリの両方がある、チームが大きい

B. フルスタック型

フロント＋バック＝ 1人

1人（または同じチーム）が画面も裏側も担当。スタートアップや社内ツールで多い形です。

向いている：小規模、立ち上げ期、スピード重視

C. デザイン＋フロント兼任

デザイナー＋フロント

デザインと画面実装を一手に担う「デザインエンジニア」。デザイナー出身のフロントエンドも多い領域です。

向いている：見た目の作り込みが重要なサービス、LP制作

見分けのヒント：React・Vue・Next.js・HTML/CSS が並ぶならフロント寄り。Java・Go・PHP・Ruby・Python と DB（MySQL など）が並ぶならバック寄り。TypeScript や Node.js はどちらにも使われるので、他の単語とセットで判断してください。

04 · QAのこと

「テスト」と書いてあっても、仕事の中身はさまざま

一般にテスターは「仕様どおり動くかを確かめて不具合を報告する人」、QAエンジニアは「何をどれだけテストするかを決め、開発プロセス全体の品質を管理する人」と整理されます。ただし会社ごとに定義が揺れていて、境目はあいまいです。

↑ コードを書く量が多い関わる工程が広い →

テスター手順書どおりに実行・報告

QAエンジニアテスト計画・設計・分析

SET / SDETテスト自動化の仕組みを開発する

QAマネージャー体制づくり・プロセス改善

注釈

「テストを依頼されるだけ」ならテスターと同じ。
考え方しだいで「品質ゲート」になる。

品質ゲートは、あらかじめ決めた基準を満たさないと次の工程に進めない関所のことです。QAが「どの機能をどの手法でどれだけ試すか」を決め、その結果で「出してよいか」を判断する立場にあれば、QAは関所の役割を担っています。

実行のみ渡された手順を消化

設計する観点・手法・量を決める

判定する基準に満たなければ止める

案件票で「テスト計画」「リリース判定」「品質基準の策定」があれば右寄り、「テスト実施」「手順書あり」だけなら左寄りの案件です。

シフトレフト

工程表の左（＝早い段階）にテストや品質のチェックを寄せる考え方。QAが仕様を考える段階から入り、矛盾や抜けをその場で指摘します。問題は後の工程で見つかるほど直す手間が大きくなる傾向があるため、早く見つけるほど手戻りを減らせます。

仕様

設計

実装

テスト

リリース後

直す手間のイメージ（実数ではありません）

シフトライト

反対に、リリース後の本番環境で品質を確かめる考え方。利用状況の監視や、一部のユーザーにだけ新機能を出して様子を見る方法などがあります。リリース後の監視や改善に関わる案件は、こちらの考え方に近いです。

SET / SDET

テスト専門の「開発者」。テストを自動で回す仕組みをコードで作ります。SDETはMicrosoftが広めた呼び名で、SETと呼ぶ会社もあります。手動テスト中心のQAとは求められるスキルが大きく異なるため、別の職種として扱われることが多いです。

画面の自動テスト（E2E）PlaywrightSeleniumCypress

スマホアプリAppium

APIのテストPostmanREST Assured

単体テストJestJUnitpytest

自動実行の仕組み（CI）GitHub ActionsJenkins

負荷テストJMeterk6

よく使う言語TypeScript / JavaScriptPythonJava

案件票にこれらの名前が並んでいたら、自動化に関わる案件の可能性が高いです。ただしAutifyやMagicPodのようなノーコードツールは、コードをほとんど書かずに自動化できます。

05 · 案件票チェック

このキーワードがあったら、この職種

案件票のキーワードから想定される職種をまとめました。判断に迷うときは、右列の質問をクライアントへの確認にお使いください。実際の現場では職種の境目がはっきりしていないため、1つのキーワードが複数の職種にまたがることがよくあります。

（　）内は、現場によって同じ仕事を担当することが多い職種です。

案件票のキーワード	想定される職種	確認したい質問

06 · 募集要項を判定する

募集要項から、近い職種と確認したいことを洗い出す

募集要項や案件票の文章を貼り付けるか、ファイルを読み込むと、書かれているキーワードから近い職種を判定し、企業に確認したい質問をまとめます。最初はサンプルの募集要項が入っています。

入力した文章はこのブラウザの中だけで処理されます。どこにも送信されず、保存もされません。（仕組みと確かめ方）

ファイルを読み込む

対応ファイル：テキスト（.txt）、PDF、Word（.docx）。画像やスキャンしたPDFの文字は読み取れません。

判定に使った箇所

色つき判定に使用点線歓迎・経験不問など（重みを半分に）取り消し線対象外（判定に使わない）

07 · ミニ用語集

よく出る言葉

要件定義: 「何をつくるか」を決める最初の工程。基本設計などとあわせて「上流工程」と呼ばれる
PdM（プロダクトマネージャー）: 「何をつくるか」を決める職種。市場やユーザーを見て、機能の優先順位を判断する
PO（プロダクトオーナー）: スクラム開発での役割の名前。開発チームに「次に何をつくるか」を示す。PdMが兼ねることも多い
PM（プロジェクトマネージャー）: 予定・人・予算を管理して、プロジェクトを期限どおりに進める職種。PdMとは別の仕事。「PM」とだけ書かれていたら、多くはこちらを指す
API: 画面側と裏側がデータをやりとりする約束ごと。レストランの注文伝票
データベース（DB）: 予約や会員などの情報を保存する場所。バックエンドの担当範囲
テスト設計: 何を、どの手法で、どれだけ試すかを決める作業。テストエンジニアやQAエンジニアの中心業務
第三者検証: 開発会社とは別の会社がテストを請け負う形態
CI/CD: コードを変更するたびに自動でテスト・反映する仕組み。SET/SDETが関わることが多い
アジャイル / スクラム: 「作って確かめる」を短い期間で繰り返す開発スタイル。QAも開発チームの一員として動くことが多い
ウォーターフォール: 工程を順番に進める開発スタイル。テストは後半にまとめて行うことが多い

参考