バックエンドエンジニアはきつい？障害対応が評価されない会社の見分け方

自社 SaaS でバックエンドを 4 年担当している人がいるとします（架空の例です）。半年前にバックエンドの担当が 7 人から 4 人に減り、障害の一次対応も開発チームが持っていて、4 人で週替わりの当番を回している。先月、給与計算の締めの夜に 8 年前に書かれた集計バッチが止まり、深夜 2 時に呼ばれた。書いた人はもう社内にいない。朝 5 時に直してそのまま 9 時の定例に出た。翌月の評価面談では「今期は新機能のリリースが少なかった」と言われた。負債の解消を提案しても、毎回来期に回される。

バックエンドを続ける限りこうなのか、会社を変えれば違うのか。

直す仕事そのものは、どこへ行っても残ります。 動いているサービスの不具合を、他人が昔書いたコードまでさかのぼって直すのは、自社サービスでも受託でもバックエンドの仕事です。一方で、夜中に誰が最初に受けるか、何人で当番を回すか、技術的負債を解消する時間をもらえるか、直したことが評価に入るかは、会社で変わります。

この例では、直す仕事に、開発チームが夜の一次対応を持つこと、4 人での当番、負債の後回し、新機能の数で決まる評価が全部重なっています。中でもこたえているのは、深夜に呼ばれたことより、朝 5 時に直したことが翌月の面談で「新機能が少ない」と言われたことのほうだと当サイトは見ています。

どこまでが仕事で、どこからが会社の事情か

バックエンドでよく挙がるきつさを、会社を変えたらどうなるかで並べるとこうなります。

きつさ	場面	会社を変えたら
動いているサービスの問題を直す	公開後に出たエラーを、ログとコードから追って直す。自分が書いていない箇所でも調べる	残る
既存のコードの改修に時間を取られる	新しく作る仕事より、動いているものを直したり機能を足したりする仕事が多い。昔のコードを読んでから手を入れる	残る。改修の割合は会社で変わる
技術を追い続ける	言語・フレームワーク・クラウドの更新を追う	残る。業務時間内に学べるかは会社で変わる
リリース前の残業	新サービスのリリース前や納期前に残業が増える	忙しい時期があることは残る。どこまで膨らむかは人数と仕様変更の決め方で変わる
夜中の呼び出し	夜や休日に障害の連絡が来て、自宅から調べて直す	会社で変わる。一次対応を誰が持つか、当番の人数、待機手当、翌朝の扱い
技術的負債を解消する時間が無い	古いコードが原因の障害を直しても、作り直しは来期に回る	会社で変わる
人が減って仕事が一人に集まる	補充が遅れ、障害対応・改修・新機能が残った人に集中する	会社で変わる
評価が新機能の数で決まる	障害の予防や改修が評価項目に無い。評価者が技術の中身を見ない	会社で変わる。ただし、障害の予防や改修が外から見えにくいことは変わらない

厚生労働省の job tag も、Web サービス開発の SE の説明に、開発した Web サービスで起きる問題について「その後生じた問題の解決やアフターケアを行う仕事もある」と書き、「既に提供されているWebサービスがあり、それをどのように改善していくかといった開発も多い」とも書いています（「システムエンジニア（Webサービス開発） - 職業詳細」、2026 年 10 月 9 日確認）。受託開発の SE の説明でも、稼働後の問題解決は SE の仕事とされています（「システムエンジニア（受託開発） - 職業詳細」、同日確認）。

一方で、同じ Web サービス開発の SE の説明には「運用は別会社となることも多い」ともあります。夜中に最初に電話を受けるのが開発チームかどうかは、会社の体制で決まります。

一次対応のチームがある会社でも、呼ばれなくなるわけではない

運用や SRE のチームが一次対応を持つ会社に移っても、夜中の電話が無くなるとは言えません。

最初の切り分けや、再起動で戻る・サーバーが落ちたといった問題は、一次対応のチームが受けます。けれど、アプリの不具合、データの不整合、バッチの処理ロジックのように、コードを読まないと直せない問題はバックエンドに回ってきます。変わるのは、呼ばれる回数と、自分が最初に起こされるかどうかです。

毎週のように最初に起こされるのと、切り分けが済んだ後に必要な時だけ呼ばれるのとでは、当番の週の負担はかなり違うと考えます。

転職の前に、直す時間と評価での扱いを今の会社で頼める

夜の当番の回し方、負債を解消する時間、評価の付け方は、会社を変えなくても変わる可能性があります。転職を決める前に一度今の会社で頼むと、その返事がそのまま判断材料になります。

上長が技術に詳しくないなら、コードの話より、お客さんへの影響と会社が負うリスクとして伝えるほうが通りやすいと考えます。冒頭の例なら、先月の件で起きたことを次の 4 つにまとめます。

給与計算の締めの夜に勤怠の集計が止まり、復旧は朝 5 時だった
間に合わなければ、お客さんの給与計算が遅れていた
そのコードを書いた人は社内におらず、今の 4 人の誰が当番でも同じことが起きる
毎月の締めで再発しうる

作り直しの日数は最初から出さず、まず調べる時間だけをもらいます。この集計処理を読んで、直す範囲と日数を出すために 3 日ほしい、と頼む形です。読み終えたら、全部作り直す場合と、締めの夜に止まる箇所だけ直す場合の日数を 2 つ並べて出せば、上長はどちらかを選ぶだけで済みます。8 年前のコードを読まずに日数を見積もると、少なめに言えば作業が延び、多めに言えば認めてもらえません。調べる時間なら、上限を決めて頼めます。

あわせて、この対応が今期の評価でどう扱われるかも聞いておきます。評価の話を正面から出せる機会になります。

これで 3 日もらえて、止まる原因を直し、次の締めから再発しなくなれば、締めの夜に止まる原因を突き止めて直し、その後は再発していない、と言えるようになります。朝までに復旧させた、というだけの話より強い実績で、面接でもそのまま話せるので、今の会社で頼んだことが転職の材料にもなります。

また来期に回されたら、それも一つの答えです。上長に決める権限が無いこともあるので、誰が決めるのかを聞いておくと、会社のどこで止まっているかが分かります。返事を待つ間に、求人を見始めても構いません。

当番の負担を軽くしてほしいと頼むなら、家庭の事情ではなく体制の問題として出せます。4 人で週替わりなら 1 人あたり月に 1 週は当番で、深夜対応の翌日は定例も開発も質が落ちる。だから当番明けの午前休か待機手当を検討してほしい、という形です。

求人票で分かることは少ない。体制や負債に触れている会社から先に見る

転職するとして、今と同じような会社かどうかは、求人票ではほとんど見分けられません。

当サイトの掲載求人（バックエンドの求人、会社単位）で、次のことを書いている会社の割合はこうでした。

求人票に書いていること	書いている会社
時間外・休日の障害対応やオンコール（仕事の内容か手当として）	5%未満（手当まで書く会社はごくわずか）
障害対応を仕事の内容として	10%未満
エンジニア向けの評価の仕組み（技術を分かる評価者など）	5%未満
技術的負債（多くは解消を仕事の内容として）	約 10%
チーム・部署の人数（部署全体の人数のこともある）	約 20%
技術選定に関われること	約 25%

書いていないことは、無いことを意味しません。オンコールの記載が無い求人も、安心材料にはならず、書いていない会社を候補から外す理由にもなりません。

それでも使い道はあります。負債の解消、障害対応の体制、チームの人数、技術選定のどれかを書いている会社は、その話題に自分から触れている会社です。求人を見ていく段階では、こうした会社から先に見て面接で確かめる順にすると、確かめる会社を絞れます。

障害対応が評価されるかは、面接で直近の出来事を聞くと見えてくる

求人票ではほとんど分かりませんが、面接で直近の出来事を聞くと、障害対応が評価される会社かを見分ける手がかりになります。方針を聞くと、どの会社も整った答えを返せるので、聞くのは実際にあったことです。質問は大事な順に 4 つです。

前回の評価で、障害の予防や改修はどう扱われましたか。 直したことが評価に入るかは、ここで見えてきます。評価の対象になった具体例が出てくるかを見ます
一番最近、当番の人が夜間に呼ばれたのはいつで、原因は何でしたか。一次対応はどのチームですか。 一次対応のチームがある会社なら、開発に回ってくるのはどんな時で、直近で何回あったかも聞きます
最後に負債の解消に時間を使ったのはいつで、誰が決めましたか
バックエンドは今何人で、この 1 年で何人抜けましたか

正直に答えてもらえる保証はありませんが、答えの細かさである程度は見えてきます。回数、原因、翌朝どう扱ったかまで出てくるなら、実際にあった話として聞けます。ほとんど無いと言うだけで最近の 1 件が出てこない時は、一番最近呼ばれたのはいつで原因は何だったか、と 1 件に絞って聞き直してください。面接官が人事やマネージャーなら、当番に入っている現場のエンジニアと話す場をもらえないか頼むのも手です。

呼ばれた回数を聞くと当番を嫌がっているように見えないか、が気になるなら、先に自分の経験を話します。今の会社で週替わりの当番に入り深夜の対応もしてきたこと、入社後の動き方をイメージしたいので体制と回数を知りたいこと、の順で話せば、体制を気にする経験者の質問として自然に聞こえます。

面接で話す自分の実績も、直した件数より、その後に何が起きなくなったかで話すと伝わりやすいと考えます。同じ障害が再発しなくなった、夜間の呼び出しが減った、他の人も触れる状態になった、です。

全部そろう会社は少ない。優先するなら夜中に呼ばれる回数

一次対応の体制、当番の人数、負債を解消する時間、評価の付け方が全部良い会社は少ないはずです。優先するなら、夜中に呼ばれる回数（当番の人数と、一次対応をどのチームが持つか）を先に見るのが当サイトの考えです。評価の方が引っかかっていても、当番の週ごとに削られているのは睡眠と家族の時間で、こちらは後から取り戻せません。負債を解消する時間はその次で、評価は最後でよいと考えます。直したことをその後に起きなくなったこととして話せれば、評価項目が十分でない会社でも、ある程度は伝わるからです。

年収については、当番の重さと年収の関係を示す材料を当サイトは持っていません。比べる時は、今の年収のうち、障害対応などで付いた時間外手当がいくらかを分けておくと、他社の提示額と比べやすくなります。水準はバックエンドエンジニアの年収の記事で扱っています。

直しても評価が変わらないなら、そこで決めていい

今の会社で頼み、3 日もらえて直し、再発も止めた。それでも次の面談でまた新機能が少ないとだけ言われたなら、障害を直して再発を止めた仕事は評価に入らないと受け取って、そこで決めていいと考えます。次の評価期間まで待っても、変わると考える材料がありません。頼む時に評価での扱いを聞いておけば、ここで迷いにくくなります。最初から評価の対象にならないと言われたなら、面談を待たずにその時点で分かります。

決めるといっても、すぐ辞めることではありません。本気で面接を受け始めることです。退職は内定が出てからで十分で、家族の事情で動きにくい時期があるなら、入社の時期をそこからずらせます。

よくある質問

自社サービスの会社に移れば、障害対応や納期から解放されますか？

解放はされません。job tag は Web サービス開発の SE についても「新サービスのリリース前など、残業が多くなる」と書き、公開後の問題の解決も仕事に含めています。違うのは、当番の人数、一次対応を誰が持つか、仕様変更の決め方で、これは自社サービスか受託かより会社ごとの差です。

バックエンドに向いているのはどんな人ですか？

動いているものを壊さずに直すことと、他人の書いたコードを読むことが苦にならない人です。改修と障害の調査は、どの会社に行っても仕事の多くを占めます。直す仕事そのものは嫌ではなく、夜中に最初に起こされることや、直しても評価されないことがつらいなら、それは向き不向きより会社の体制の問題です。

当番の週のつらさを、上長に家庭の事情として伝えるべきですか？

頼みごとの中には入れない方が話がそれにくいと考えます。体制の問題（当番の人数、深夜対応の翌日の質）として出せば、個人の都合として返されにくくなります。ただ、家庭に響いていることそのものは、会社を選ぶ時の一番大事な判断材料です。

この記事の数字と判断の根拠

当サイトの数字は、2026 年 9 月 29 日時点で当サイト PREVIO に掲載していたバックエンドエンジニアの求人を、会社単位で数えたものです。その話題を書いた求人を 1 件以上出している会社の割合で、5% 単位に丸めています。日本の求人全体の数字ではありません。求人票に書いてあるかで判定しており、書いていないことは無いことを意味しません
仕事に残るきつさと会社で変わるきつさの分け方は、厚生労働省の job tag「システムエンジニア（Webサービス開発）」「システムエンジニア（受託開発）」（2026 年 10 月 9 日確認）と、転職情報の記事、働いている人が書いた体験談をもとに、当サイトがまとめた分け方です。job tag に「バックエンドエンジニア」という職業は無いため、近い 2 つの職業の説明を使っています
次の点は、当サイトの見立てと助言です
- 冒頭の例で一番こたえているのは、評価の面談で言われたことだという読み
- 一次対応のチームがある会社で、どんな問題がバックエンドに回ってくるか
- 上長への伝え方と、調べる時間を 3 日もらう頼み方
- 面接の答えの受け取り方と、当番の回数の聞き方
- 実績を、その後に起きなくなったことで話すと伝わりやすいこと
- 夜中に呼ばれる回数を先に見る優先順位
- 決めてよい時と、退職の時期の考え方