職種の求人市場
データベースエンジニアはやめとけ？ 復旧のつらさは残りうる。製品は求人票、DBの人数は面接
データベースエンジニアを辞めたい場面を、DBを続けても残る側・会社で変わる側・今は分からない側に置きます。障害時の復旧や開発への技術支援は残りうる一方、製品とクラウドは求人票で読み、DBを何人で見て休みの時に誰が代わるか、夜間メンテ、障害の呼び出し、繁忙月の残業、SQLレビューは面接で確かめます。
公開 2026年9月30日 · 集計 2026年9月30日 · PREVIO 編集部
この記事で分かること
- ・辞めたい場面を3〜5個、今の職場のDBの人数、休みの時の代わり、回数、時間帯、平常月と繁忙月の残業と一緒に書き、DBを続けても残る側、会社で変わる側、今は分からない側へ置く
- ・障害対応、バックアップ・復旧、開発への技術支援、クラウドを含む学習は残りうる。残業・常駐は会社で変わり、DBの人数、夜間メンテ、障害の呼び出し、SQLレビューの仕組みは面接で確かめる
- ・DBの仕事を題名に含む求人を1件開き、製品・クラウド・移行・チューニングを読み、DBの人数、休みの時の代わり、時間外対応、繁忙月の残業などを今の職場と同じ単位の面接質問にする
目次開く閉じる
辞めたい場面を3〜5個、値つきで書いてください。「データベースエンジニアはやめとけ」への答えは、一律にやめるべきとは言えません。DBを続けても残る側・会社で変わる側・今は分からない側の三つへ置きます。復旧・技術支援は残りうる一方、製品は求人票、DBの人数・夜間メンテは面接で聞きます。2026年9月30日、当サイトで題名がDBの仕事と読める求人を会社ごとに数え、割合を5%単位に丸めると、配属先の人数を書く会社は約20%です。
例は、EC事業会社のDB担当3年目で、MySQLからAuroraへの移行を担う架空の社員です。DBは2人で見ますが、先輩が休む日は一人になり、移行作業の月が繁忙月です。
辞めたい場面を、今の職場の値と一緒に3〜5個書く
まず、辞めたい理由を評価語のままにせず、応募先と比べられる値にします。夜がつらいなら、計画した夜間メンテと、障害時の呼び出しを分けます。一人でつらいなら、DBを見る人数だけでなく、休暇中の代わりと本番作業の確認者を書きます。
例の社員の5場面は次の形です。値は架空ですが、後で求人票と面接を読むときも同じ期間と単位を使います。
| 辞めたい場面 | 今の職場の値 | 比べる単位 | 確認先 |
|---|---|---|---|
| 先輩が休むとDBを見るのが自分1人になる | DB担当は2人。先輩の休みは本人だけで対応。本番作業の確認者は先輩 | DB担当の人数、休暇中の代わり、本番作業の確認者 | 担当表、休暇中の連絡記録 |
| 夜間メンテが直近1年で24回ある | 直近1年で24回。終了時刻と代休は未記録 | 年間回数、時間帯、人数、代休・手当 | 作業予定、勤怠 |
| 障害の呼び出しが直近1年で6回ある | 直近1年で6回。当番と手当は未記録 | 年間回数、時間帯、当番、手当 | 障害記録、勤怠 |
| スロークエリ相談の後追い対応が週5件ある | 本人に週5件。リリース前の確認はなし | 一人あたり週の件数、相談の時点、確認する人 | チケット、レビュー記録 |
| 移行案件が走る月の残業が45時間になる | 平常月20時間、移行作業の月45時間 | 同じ担当者の平常月と移行月の実残業 | 勤怠、移行計画 |
記録がなければ推測で埋めず、直近1年の予定表、障害記録、チケット、勤怠から分かる範囲だけ書きます。夜間メンテと障害対応を一つの回数にまとめません。
先に「DBを続けても残る側」「会社で変わる側」「今は分からない側」を決める
求人を開く前に、書いた場面の置き場所を決めます。三つの意味は次のとおりです。
- DBを続けても残る側: 障害時の復旧や開発へのDBの技術支援など、DBの役割そのものです。会社を移ってもゼロになるとは見込みません。この側がいちばんつらければ、次の候補をDBの仕事だけに絞らず考えます。
- 会社で変わる側: DBの人数、休暇中の代わり、本番作業の確認方法、残業、常駐、SQLレビューの時点と担当者など、会社や配属先が決め、違いを比べられる側です。今の値より望む方向へ変わる求人を残し、読めない値は面接へ回します。
- 今は分からない側: 夜間メンテや障害呼び出しの頻度、評価など、起こりうることは分かっても、会社による違いや今のつらさの原因を手元の資料だけでは決められない側です。面接で実態を聞くまでは、応募先を残す・外す判断に使いません。
会社で変わる側は今の値との差を比べ、今は分からない側は応募先の実態が分かってから比べます。
厚生労働省job tagにはDBエンジニア単独の職業項目がありません。「システムエンジニア（基盤システム） - 職業詳細」では、DBエンジニアなどが分担する場合も、インフラ担当がDBを含むITインフラの開発を一人で担う場合もあると説明しています（2026年9月30日確認）。これはDB担当が一人という根拠ではなく、DB専任を置かず、インフラ担当が兼務する場合があるという範囲で読みます。今の職場の人数を応募先にも当てはめず、DBを見る人数と休暇中の代わりを直接確かめます。
例のDB担当は、夜間メンテと障害の呼び出しを分けて置く
例の社員の場面を、最初の置き場所へ振り分けます。理由欄には、場面の言い換えではなく、その置き場所を選ぶ根拠を書きます。
| 辞めたい場面 | 最初に置く側 | そう置く理由 | 次に確かめる値 |
|---|---|---|---|
| 先輩が休むとDBを見るのが自分1人になる | 会社で変わる側 | 人数と休暇中の代わりは会社・配属先の体制で決まる | DB担当の人数、休暇中の代わり、本番作業の確認者 |
| 夜間メンテが直近1年で24回ある | 今は分からない側 | 求人票だけでは回数・時間帯・手当まで確認できず、今の職場が多いか判断できないため | 直近1年の回数、時間帯、人数、代休・手当 |
| 障害の呼び出しが直近1年で6回ある | 今は分からない側 | 復旧は仕事に含まれうるが、呼び出しの回数は職種名だけでは決まらないため | 直近1年の回数、時間帯、当番、手当 |
| スロークエリ相談の後追い対応が週5件ある | 会社で変わる側 | SQLレビューの時点と担当者は会社が決めるため | 一人あたり週の相談件数、リリース前にSQLを見る人 |
| 移行案件が走る月の残業が45時間になる | 会社で変わる側 | 配属先の人数・移行計画・分担によって比べる実績だから | 平常月と、直近で移行案件が走った月の実残業 |
DBの技術支援そのものは残りうるものの、この場面でつらいのは問題が出てから相談が届く仕組みです。開発側のSQLをリリース前に誰が見るかは、会社で変わりうる項目として面接で確かめます。
ほかの場面を置くための早見表
例の社員にない場面は、次の表から最初の置き場所を決めます。二つの原因が混じるときは行を分けます。
| 場面 | 最初に置く側 | そう置く理由 | 確かめること |
|---|---|---|---|
| 障害時にDBを復旧する | DBを続けても残る側 | job tagが運用・管理の仕事に障害時の復旧を挙げるため | 担当する範囲 |
| データを消す・止める責任が重い | DBを続けても残る側 | IPAが信頼性・安全性を考えたDBの運用・保守を役割に挙げるため | 自分が担う判断 |
| 本番作業を一人で実施する | 会社で変わる側 | 権限、手順、複数人確認は会社の運用だから | 実施者、承認者、確認方法 |
| 開発側のSQLを事前にレビューする仕組みがない | 会社で変わる側 | 技術支援は残るが、レビューの時点と担当者は会社で決めるため | リリース前に見る人、対象のSQL |
| クラウドを含めて学び続ける | DBを続けても残る側 | job tagがクラウドの変化を追う必要を説明し、IPAもDB技術の動向を見通して目的に応じた技術を選ぶことを期待する技術水準に挙げるため | 学ぶ対象 |
| Oracle、MySQL、PostgreSQL、クラウドDBのどれを扱うか | 会社で変わる側 | 仕事内容と使う環境は求人ごとに異なるため | 入社直後に扱うDB、移行予定 |
| 客先常駐・派遣がつらい | 会社で変わる側 | 勤務地と配属の仕組みは会社・案件によるため | 配属予定の案件、働く場所 |
| 地味で評価されにくい | 今は分からない側 | 会社差はありうるが、手元の資料では応募先の評価の仕組みを判断できないため | DB担当の評価項目、評価者 |
常駐や配属先で変わる働き方を中心に確かめる場合は、インフラエンジニアの求人票の読み方も分けて使えます。
バックアップ・復旧、開発への技術支援、学び続けることはDBに残りうる
会社を選び直しても、DBの仕事として残りうる部分があります。厚生労働省job tagの「運用・管理（IT） - 職業詳細」は、定期的なデータやシステムのバックアップと、障害時の早期復旧を運用・管理の仕事に挙げています（2026年9月30日確認）。これは運用・管理全般の説明で、DBエンジニアだけを調べた結果ではありません。ただし、DB運用にバックアップと復旧が含まれると考える根拠にはなります。
厚生労働省job tagの「システムエンジニア（基盤システム） - 職業詳細」は、クラウドのサービスや機能が日々発展し、その変化を追うことも求められると説明しています（2026年9月30日確認）。これは基盤システム全般の説明であり、DBエンジニアだけの実態調査ではありません。
IPAの「データベーススペシャリスト試験」は、信頼性・安全性を考えたDBの企画・開発・運用・保守と、個別システム開発へのDBの技術支援を対象者の役割に挙げています。DB技術の動向を見通し、目的に応じて技術を選べることも期待する技術水準に含めています（2026年9月30日確認）。これは試験の対象者像であり、実際の職場で各作業をどれだけ担うかを示す調査ではありません。
このため、障害対応や復旧そのもの、開発への技術支援、クラウドを含めて学び続けることが最もつらいなら、会社を移るだけでなく、DBの仕事を続けるかも分けて考え、本番復旧やDBの技術支援を担わない社内異動や近い職種も次の候補に加えます。一方、復旧時の権限、作業手順、複数人確認は会社で変わる側へ、呼び出しの回数は今は分からない側へ分けます。
製品は求人票で読み、DBの人数・夜間メンテ・SQLレビューは面接へ回す
求人票で先に読むのは、扱う製品、クラウド、移行、チューニングです。DBの人数、休暇中の代わり、夜間メンテ、障害の呼び出し、SQLレビューの仕組みは、書かれていなければ面接へ回します。次の表は、求人票で読めるものと面接へ回すものを分けるために使います。
以下の割合は、2026年9月30日時点で当サイトPREVIOに掲載中の求人から、サイト上の職種分類にかかわらず、題名がDBの仕事と読める求人を勤務地で絞らず集計したものです。データエンジニア・データ基盤、地図DB、DB以外のOracle ERPを主題にした求人は除き、DBとERPの両方を扱う求人はDBの運用・移行が主な仕事と読める場合だけ含めました。会社単位で、対象求人のどれか1件に書く場合を「書いてある」、どの求人にも書かない場合を「書いていない」とし、約50社規模の母集団から割合を5%単位に丸め、5%未満はそのまま「5%未満」としています。これは求人票の記載率であり、職場で実際に起きる割合ではありません。
| 求人票で探す内容 | 書いてある会社 | 求人票で読めること | 面接へ回すこと |
|---|---|---|---|
| Oracle | 約50% | 仕事内容に製品名が出る | 入社直後に扱うDB、担当する割合 |
| PostgreSQL・MySQLなど | 約35% | 仕事内容に製品名が出る | 入社直後に扱うDB、移行予定 |
| 仕事・環境としてのクラウド | 約55〜60% | クラウドを使う仕事・環境の手がかり | サービス名、オンプレとの割合 |
| 移行・更改・バージョンアップ | 約35〜40% | 移行に関わる可能性 | 直近の移行、担当人数、時間帯 |
| チューニング・性能改善 | 約35% | 性能改善に関わる仕事 | 相談件数、事前レビューの有無 |
| 配属先の人数 | 約20% | 部署・チーム全体の人数の手がかり | DB担当の人数、休暇中の代わり |
| DB担当の人数 | 5%未満 | DB担当人数を明記した例 | 入社時の人数、本番作業の確認者 |
| 時間外・休日のDB作業 | 5%未満 | 本人の仕事としての記載 | 夜間メンテと障害呼び出しの回数・時間帯 |
| SQLレビュー | 5%未満 | SQLレビューを仕事に含む記載 | 誰がいつ、どのSQLを見るか |
| 実際・平均・想定の残業時間 | 約40% | 書かれた対象と期間 | 配属先の平常月・繁忙月の実残業 |
| 客先常駐・派遣・案件で変わる | 約20% | 働く場所や配属の手がかり | 配属予定の案件での人数・働き方 |
クラウドは、会社紹介や資格手当ではなく、仕事や使う環境として読める記載を目で確認した範囲です。移行は、DBの移行と断定できない記載を含むかで幅があります。SQLレビューそのものとは別に、開発チームとの協力・調整まで広げると約10%ですが、その数字をSQLレビューがある会社の割合には使いません。
残業時間には、会社全体や別部門の平均、想定値が混じります。給与欄の固定残業時間は給与計算の前提で、実際に残業した時間ではありません。年収例や想定年収を計算するために残業時間が置かれている場合も、実績から外します。応募先と比べるのは、配属予定先の平常月と繁忙月の実残業です。例の社員は、繁忙月のうち移行案件が走った月を比べます。
求人を1件読み、書かれていない値を同じ単位の質問にする
最初に書いた場面から、会社で変わる側か今は分からない側を一つ選び、DBの仕事を題名に含む求人を1件開きます。求人票は欄の名前だけでなく、全文から必要な語を探します。
1. 応募できる求人かを先に確かめる
仕事内容と応募条件で、DBの仕事か、製品経験、DBの運用経験、資格などの必須条件をすべて満たすかを見ます。求人サービス上でDBに分類されていても、題名と仕事内容がデータ基盤・BI・Oracle ERPなど別の仕事なら、この記事の比較対象から外します。DBとERPの両方が出る求人は、DBの運用・移行が主な仕事なら残し、ERP導入が主なら外します。
企業がOracle経験を必須としていて、自分がMySQLしか扱っていないなど、代わりの経験を認める記載もない場合は、その求人を比較対象から外します。製品名が歓迎条件にあるだけなら必須とは読みません。応募条件に製品名があっても、入社後にその製品を担当するとは限らないため、仕事内容にも同じ製品があるかを分けます。
2. 欄ではなく、全文から語を探す
仕事内容だけでなく、福利厚生欄のその他、PRポイント、募集背景、組織の説明、仕事内容の中の小見出しまで見ます。勤務地・在宅・フレックス・組織・募集背景の欄が空でも、別の場所に同じ情報が書かれている場合があります。
全文から探す語は、次のように場面ごとに決めます。
- 製品とクラウド:
Oracle、MySQL、PostgreSQL、AWS、Azure、GCP、OCI、RDS、Aurora - 担当する仕事:
移行、更改、バージョンアップ、チューニング、性能改善、バックアップ、リストア、障害、インシデント - 体制:
DBチーム、データベースチーム、DB担当、データベース担当、配属、組織、部署、名体制 - 開発との関係:
SQLレビュー、開発チーム、技術支援、協力、連携 - 働く時間と場所:
夜間、深夜、休日、オンコール、シフト、残業、常駐、派遣、案件
人数がなくても、DB専任のチームがあると読める記載は手がかりとして残します。部署全体の人数をDB担当人数にはしません。題名と本文、勤務地と配属の説明が食い違う場合も、都合のよい方を選ばず、両方を面接の質問にします。
求人票で値を読めたら、今の職場の値と同じ期間・単位で並べます。チームで常駐、残業少なめのような数字のない表記はそのまま同じと判断せず、DBを見る人数や月の実残業を数字で聞く質問に直します。
3. 配属予定先か、配属予定の案件へ絞って聞く
書かれていない値は、会社全体ではなく配属予定先について聞きます。案件で配属が決まる求人では、SES・派遣・常駐だけでなく、請負・プライム（元請け）のSIerも、自社のチーム人数と、配属予定の案件でDBを見る人数を分けます。案件がまだ決まっていなければ、決まった後に誰へ、いつ確認できるかを聞き、その時点では応募先との違いを確定しません。
例の社員なら、最初の表と同じ場面名・期間・単位で質問を作れます。
| 辞めたい場面 | 今の職場の値 | 求人票で読むこと | 面接で聞く質問 |
|---|---|---|---|
| 先輩が休むとDBを見るのが自分1人になる | DB担当2人。先輩の休みは本人だけ。本番作業の確認者は先輩 | DB専任チーム、部署・チーム人数 | 配属予定先でDBを見る人は何人ですか。担当者が休む時は誰が代わり、本番作業は誰が確認しますか |
| 夜間メンテが直近1年で24回ある | 直近1年で24回 | 夜間・休日の作業、移行、リリース | 直近1年の夜間メンテは何回で、何時から何時まで、何人で行いましたか。代休と手当はどう扱いましたか |
| 障害の呼び出しが直近1年で6回ある | 直近1年で6回 | 障害対応、オンコール、シフト | 直近1年の障害による呼び出しは何回で、誰が当番を回し、何時まで対応しましたか。手当はどう扱いましたか |
| スロークエリ相談の後追い対応が週5件ある | 本人に週5件。リリース前の確認はなし | チューニング、SQLレビュー、開発との連携 | 直近4週間、DB担当一人あたり週平均で何件のSQL相談に対応しましたか。開発のSQLをリリース前に誰が見ますか |
| 移行案件が走る月の残業が45時間になる | 平常月20時間、移行月45時間 | 移行、残業時間とその対象 | 配属予定先の直近の平常月と、移行案件が走った月の実残業は何時間でしたか。その月は何人で移行を担当しましたか |
回答が全社平均なら配属予定先へ、案件で配属が決まる求人なら配属予定の案件へ絞り直します。答えが得られない項目は、応募先にないとは決めず、比較できない値として残します。
この見分け方で分からないこと
求人票と面接で分かるのは、書かれた内容と説明時点の体制・実績までです。入社後も同じ人数、休暇中の代わり、製品、夜間メンテ、障害の呼び出し、SQLレビュー、残業が続くとは限りません。
当サイトの集計対象は、掲載中で題名がDBの仕事と読める求人です。題名にDBの語がないインフラ・基盤求人に含まれるDBの仕事は拾っておらず、日本のDB求人全体を表しません。1社で2ポイント、5%単位に丸めた値は1〜2社で変わります。会社単位では、対象求人を多く出す会社ほど、少なくとも1件が「書いてある」に入りやすい数え方です。
求人票の記載率から、一人配属の会社、夜間作業がある会社、SQLレビューがある会社の割合は分かりません。書いていない会社の実態を読めないためです。クラウドも、仕事や使う環境として求人票に書く会社の目安であり、クラウドを使う会社すべての割合ではありません。
job tagの基盤システムと運用・管理は近い職業の説明で、DBエンジニアだけの実態調査ではありません。IPAの資料も試験の対象者像です。これらと求人票だけで、会社を変えれば全部解けるとも、DBの仕事を辞めるしかないとも判定できません。
よくある質問
データベースエンジニアはなぜ「やめとけ」「きつい」と言われるのですか？
職種解説では、データを消す・止める責任、一人でDBを抱えること、地道で評価されにくいこと、クラウドを含めて学び続けること、開発側との調整、障害や夜間・休日の対応、専任求人の少なさがつらい理由として挙げられています。ただし、復旧や技術支援のようにDBに残りうる仕事と、人数・手順・残業のように会社で変わる項目は分けて考えます。
DBを一人で見るのは、どの会社でも同じですか？
どの会社でも同じとは言えません。応募先では、DBを見る人数、休暇中の代わり、本番作業の確認者を聞きます。
夜間メンテや障害の呼び出しは、どの会社でもありますか？
求人票からは判定できません。計画した夜間メンテは予定して行う作業で、障害の呼び出しは予定外の復旧対応です。起きる理由と頻度が異なるため、直近1年について、それぞれの回数、時間帯、人数、当番、代休・手当を分けて聞きます。
OracleやMySQLの経験は、クラウド化で古くなりますか？
OracleやMySQLの経験だけで一律に古いとは判断できません。求人票の仕事内容で、Oracle、MySQL、OCI、AWS、Azure、GCP、RDS、Auroraなど、入社後に扱う製品と環境を読みます。クラウドの変化を学び続けることは残りうるため、今の経験を使えるかだけでなく、次に何を扱えるかを比べます。
DBエンジニアの求人は少ないのですか？
当サイトの掲載求人では、題名がDBの仕事と読める求人は多くありません。ただし、題名にDBの語がないインフラ・基盤求人にDBの仕事が含まれる場合があり、日本全体で少ないとは言えません。専任の求人だけでなく、仕事内容にDB、製品名、移行、チューニングがある求人も分けて探します。
会社で変わる側か今は分からない側を一つ選び、求人を開く
最初に書いた3〜5場面のうち、会社で変わる側か今は分からない側から、いちばん変えたい場面を一つ選んでください。必須条件を満たす求人を1件開き、全文から製品・クラウド・移行・チューニングを探します。DBの人数、休暇中の代わり、夜間メンテ、障害の呼び出し、繁忙月の実残業、SQLレビューのうち読めない値を、配属予定先か配属予定の案件について今の職場と同じ単位の質問にします。