データベースエンジニアはやめとけ？開発から移る前に知りたいこと

アプリ開発で SQL を毎日書いている人が、遅いバッチの実行計画を読んでインデックスを足し、SQL を書き直したら何倍も速くなった。それが今までの仕事でいちばん面白かった、としましょう（架空の例です）。DB エンジニアの求人が気になって調べると、「やめとけ」という言葉が出てきて、1 人配属で孤独、データを消したら終わり、深夜・休日の移行と緊急対応、といった理由が挙がっている。家庭の事情で、夜と休日がなくなるのは困る。これはどこの会社に行っても同じなのか。

先に答えます。SQL を読んで直す面白さは、アプリ側に残っても DB 側に移っても続けられます。DB 専任に移って新しく増えるのは、データをバックアップから戻す作業、取り消せない本番操作、夜間・休日の作業の 3 つです。

このうち戻す作業と取り消せない操作は DB の仕事そのものなので、どの会社に移っても付いてきます。夜間・休日の作業も、あること自体はどの会社に移っても付いてきます。会社で大きく変わるのは、夜間作業の回数と、それを 1 人で背負うかどうかです。求人票ではほとんど読めないので、入る前に数字で聞くことになります。

夜間・休日の作業は、計画した作業と予定外の呼び出しの 2 種類

DB の夜間・休日の作業は、性格の違う 2 つに分かれます。

種類	どんな時に起きるか	前もって分かるか
計画した作業	止められないシステムの移行・更改・メンテナンスを、使う人のいない夜間や連休にやる。大きな移行の前にはリハーサルもする	予定が立つ。年に何回あるかは会社とシステムで変わる
予定外の呼び出し	「遅くなった」「止まった」と言われ、原因を調べてサービスを元に戻す	予定が立たない。回数も当番の回し方も会社で変わる

年末年始にサーバー更改で出社する、というのは計画した作業のほうです。

どちらの量も、会社の種類（自社サービスか、SIer か）より、そのシステムをいつなら止められるかで決まります。24 時間止められないサービスなら、触れるのは夜間か連休になります。夜に止まっても翌朝直せば済むシステムなら、作業は日中に寄せやすくなります。客先常駐や派遣では、時間帯も体制も常駐先が決めます。

当サイトの掲載求人で、DB の仕事を求人名に掲げている会社を数えると、時間外・休日の DB の作業を担当者の仕事として書いている会社は約 5% でした。ある会社は休日の勤務を「週末のリリース作業時のため、頻度は少ない」と書き、別の会社は仕事の中身に「オンコール業務、監視、トラブルシューティング」と並べている、といった書き方です。書いていない会社に夜間作業が無い、という意味ではありません。

夜中の呼び出しでやるのは、原因の切り分けと暫定対応

予定外の呼び出しでやることには、開発の時にやってきたチューニングと地続きの部分と、そうでない部分があります。

最初は切り分けです。原因が DB なのか、アプリなのか、ネットワークなのかを、他の担当と同時に調べます。早く戻せと急かされながら、DB 側では今どんな SQL が実行されているか、ロック待ちで止まっている処理がないかを見ます。原因が重い SQL だと分かれば、実行計画を読むところは開発でやってきたのと同じです。ただ夜中に求められるのはまず暫定対応で、きちんと直すのは翌日以降になります。

重くなるのは、データを戻すところまで行った時です。戻せば、その時点より後の変更は消えます。戻した後は件数と中身を確認用の SQL で確かめ、止めていたバッチを流し直すまでが仕事です。大手 SIer で基盤の仕事を 20 年以上続けてきた人の声があります。DB に限らずシステム全体をバックアップから戻した時の話で、連休中だったこと、その後のバッチの流し直しだけで約 10 時間かかり徹夜になったこと、テスト環境でリストア試験をしていても本番を戻すのは「非常に緊張しました」ということが書かれています。

「消したら終わり」は DELETE の条件ミスだけではない

取り消せない操作は、条件を間違えた DELETE に限りません。テーブル定義を変える（DDL）、大量のデータを消す・書き換える、といった操作はどれも、サービスの停止やデータの破損につながります。巨大なテーブルで DDL の途中に長いロックがかかり、サービスが止まるのも、データを消すのと同じ重さの事故です。だから実行の前に、手順と対象を何度も確かめます。

DB 側に移ると、SQL を見てもらう側から、開発チームが書いた SQL を見る側に回ります。遅い SQL を見つけて、開発チームに直してもらうのも DB 側の仕事です。IPA もデータベーススペシャリストの役割に、個別システムの開発でデータベース関連の技術支援を行うことを挙げています（「データベーススペシャリスト試験」、2026 年 9 月 30 日確認）。当サイトの掲載求人では、開発チームとの SQL レビュー・協力・調整を仕事として書く会社は約 10% で、SQL レビューそのものを書く会社はごく一部でした。

本番で DDL や削除を実行する時に、1 人で実行するのか、別の人がもう一度確かめるのかは、会社の仕組みで決まります。これは面接で聞く質問にも入れました。

DB の担当が 1 人きりの職場もあれば、チームで見る職場もある

1 人配属で孤独になるとは限りません。「やめとけ」を扱う記事でも、1 人配属が基本だと書くものもあれば、現場や会社の規模によって違うと書くものもあります。

厚生労働省の job tag は、IT インフラの開発について「大規模なシステムでは、専門のネットワークエンジニア、データベースエンジニア等が分担して行う場合もあるが、ITインフラの開発として一人で行う場合もある」と書いています（「システムエンジニア（基盤システム） - 職業詳細」、2026 年 10 月 9 日確認）。DB 専任を置かず、インフラの担当が DB も含めてまとめて受け持つ場合がある、ということです。そうした職場では、DB 以外のインフラの仕事も一緒に受け持つことになります。

求人票で配属先の人数が分かる会社は約 20% で、DB の担当が何人かまで書く会社はごく少数でした。書いている会社でも、DB 担当が 1 名という会社もあれば、部署の大半が DB エンジニアという会社もありました。

避けたいのは、DB の担当が自分 1 人で、休みの時に代わる人がいない職場

条件の中で 1 つだけ断る理由にするなら、ここです。DB の担当が自分 1 人で、休みの時に代わる人がいないと、夜間・休日の呼び出しは全部自分に来ます。今は回数が少なくても、増えた時に代わってもらえる人がいません。

夜間作業の回数のようなほかの条件は、内容によっては受け入れられます。年に数回の計画作業で代休が出る、という形なら、家族と相談して決められる範囲です。次に重く見るのは、回数を数字で答えてもらえない場合です。少ないとだけ言われて数字が出てこないなら、判断の材料が無いまま入ることになります。

夜間作業の回数と DB の人数は、面接でどう聞けば分かる？

方針を聞くと、頻度は少ない、という答えのまま数字が出てきません。直近の出来事を数字で答えてもらう形にします。大事な順に 4 つです。

DB は何人で担当していて、自分は誰と組むのか。DB の担当者が休みの時は、誰が代わりに見ているのか
直近 1 年で、夜間・休日の計画作業と障害の呼び出しはそれぞれ何回あったか。いちばん長かった時は何時間かかったか。代休や手当はあるか
本番で DDL や削除を実行する時、別の人が確認するか
障害対応の当番に当たっている週は、自宅待機か。呼ばれてから何分以内に対応する決まりで、外出はできるか

回数がすぐに出てこない会社は、回数を数えていないか、答えにくい事情があると考えられ、それ自体が判断の材料になります。バックアップや移行の経験が無いなら、それを伝えたうえで、最初の 1 年はチューニングと移行のどちらが中心かも聞いておくと、入ってすぐ何を任されるかが見えます。

移る前に、今の職場でもバックアップからの復旧は試せて、移行作業はそばで見られる

DB 専任に移らず、今の会社でアプリを書きながらチューニングを担当する道もあります。遅い SQL を読んで直すことはアプリ側でも続くので、移るかどうかを決める前に、DB 側の仕事が合うかを今の職場で試せます。

テスト環境で、バックアップから戻すところまでやる。 バックアップは「取れている」ことと「戻せる」ことが別です。触ってよいと許可をもらったテスト環境で、戻した後に件数と中身を SQL で確かめるところまでやると、地味な確認作業が苦でないかが分かります。Oracle を使っている職場なら、たとえば表の書き出しと読み込みをする Data Pump から始め、丸ごとのバックアップと復旧をする RMAN に進む、という順で試せます
DB 担当が受け持つ移行・更改作業のリハーサルに、同席させてもらう。 手順と対象を何度も確かめてから実行する様子を、そばで見られます

やってみて苦にならなければ、仕事の中身は合っていると見てよいでしょう。ただ、分かるのは中身が合うかまでです。夜間作業が年に何回あるかは会社の条件なので、試しても分からず、面接で聞いた数字で判断することになります。

よくある質問

夜間・休日がほぼ無い DB の仕事はありますか？

夜に止まっても翌朝直せば済む社内システムや分析用の基盤なら、夜間作業は軽くなりそうです。ただ、そうした仕事がどれくらいあるかを示す資料は手元に無く、ここでは言えません。また、バックアップや障害時の早期復旧は、運用の仕事の中身として job tag「運用・管理（IT）」に挙がっています。夜間作業が全く無いと見込むより、回数を確かめてから決めるほうが安全です。

DB エンジニアに移ると年収は上がりますか？

開発から DB 専任に移った時に年収がどう動くかは、比べた資料が無く、この記事では示せません。スカウトや応募先から提示された額を、面接で夜間作業や任される範囲を確かめたうえで、今の年収と比べるのが確実です。

クラウドの DB なら、夜間作業や復旧は無くなりますか？

無くなるとは言えません。マネージドの DB ではバックアップやパッチ当てを自動化しやすくなった、と書く記事はありますが、戻すかどうかの判断や、移行の作業まで自動になるわけではありません。クラウドでは、サービスや機能の変化を追い続けることも求められます（job tag「システムエンジニア（基盤システム）」）。

移行やバックアップの経験が無くても採用されますか？

会社によります。経験が無いことは隠さず伝え、最初の 1 年で何を任せるつもりかを聞いてください。その答えが、最初から DB を 1 人で担当してもらう、というものなら、上で書いた避けたい職場に当たります。

この記事の数字と出典について

当サイトの数字は、2026 年 9 月 30 日時点で当サイト PREVIO に掲載していた求人のうち、DB の仕事を求人名に掲げている会社を数えた割合です。仕事内容などの欄に該当する言葉があるかで判定し、該当した会社は求人票を読んで確かめました。割合は 5% 単位に丸めています。対象の会社が多くないため、1 社の違いで割合が 2 ポイント動きます。書いていないことは、無いことを意味しません。日本の求人全体の数字でもありません
夜間・休日の作業の種類、取り消せない操作、開発への技術支援、1 人配属が会社とシステムの規模で変わることは、厚生労働省の job tag「システムエンジニア（基盤システム）」「運用・管理（IT）」、IPA の試験区分の説明、転職情報の記事をもとに当サイトがまとめたものです。IPA の説明は試験の対象者像で、職場の実態の調査ではありません
本番をバックアップから戻した例は、働いている人 1 人の声として紹介しています。DB 担当としてではなく、基盤の担当としての復旧の話です。1 人で DB を担当している人や、夜間作業の回数を本人が書いた声は見つかっていません
次の点は、当サイトの見立てです
- 夜間作業の量が、システムをいつ止められるかで決まること
- 夜中の呼び出しで見るもの（実行中の SQL、ロック待ち）と、夜中は暫定対応までという線
- DDL の長いロックを、データを消すのと同じ重さの事故としたこと
- 分析基盤や社内システムなら夜間作業が軽くなりうること、夜間作業が全く無い職場を見込まないほうがよいこと
- クラウドの DB でも、戻す判断や移行は自動にならないこと
次の点は、当サイトの助言です。どこに線を引くかは、家族の事情などで人によって変わります
- 避けたい職場の決め方と、質問の順番
- 回数がすぐに出てこない会社の受け取り方
- テスト環境での試し方（Data Pump・RMAN の順番を含む）と、それで仕事の中身が合うかが分かるという判断