海外では、「なぜ日本人は頼まれてもいないのに残業（しかも無給で）をするのか？」と不思議がられることがあります。 日本国内では、その理由として「同調圧力」がよく挙げられます。 「上司が帰らないから帰りにくい」「付き合い残業」といったものです。
しかし、現在24歳でSIerに勤務している私の実感は、少し違います。
そこにあるのは、単なる空気の読み合いではなく、 もっと根深い 「システム上の欠陥」 と 「真面目なエンジニアほど陥る心理的な罠」 です。
今回はあえてこのタブーに切り込み、 私たちがなぜサービス残業という“自滅”を選んでしまうのか──そのメカニズムを紐解いていきます。
1. 「絶対納期」と「障害対応」からは逃げられない
まず前提として、SIerの仕事には 絶対に逃げられないデッドライン が存在します。
Web系（自社開発）の一部であれば、「機能リリースを延期する」という判断が可能な場合があります。 しかし、SIerが多く担当する 業務システム の世界では、それはほぼ許されません。
理由はシンプルで、業務システムの法改正対応や障害対応が遅れれば、顧客の業務そのものが止まってしまうためです。 特に金融システムのようなミッションクリティカルな領域では、その傾向が顕著です。
ここでは例として、新NISA制度の施行に伴うシステム改修を取り上げます。
1.1 新NISA制度（2024年1月1日施行）の裏側
新NISAに対応するシステム改修は、次のような流れで進みました。
-
2022年8月頃：税制改正要望（要望段階）
金融庁が「税制改正要望」を出した段階で、「NISAが恒久化されるらしい」
「枠が増えるらしい」といった情報は入ってきます。しかし正式決定ではないため、
予算確保 や 要員計画（人員の確保） を水面下で進める程度に留まります。 -
2022年12月16日：令和5年度税制改正大綱（正式決定）
このタイミングで仕様が確定し、 「生涯上限1800万円」「成長枠とつみたて枠の併用可」などの具体的なルールが明らかになります。 ここから本格的に要件定義・設計がスタートします。「旧NISAのデータをどう移行するか」
「残り枠の計算ロジックをどう設計するか」といった詳細を詰める作業が、2023年初頭〜春にかけてピークとなります。
-
2023年中盤〜年末：開発・テスト・プレリリース
実質、開発期間は1年弱しかありません。
法律の施行日は2024年1月1日ですが、 実際には2023年11月頃から証券会社が利用者向けに「積立予約」機能を提供する必要があるためです。楽天証券やSBI証券などの大手も、このスケジュールに合わせて早期リリースを行っていたようです。
※楽天証券やSBI証券が自社開発しているのか、ベンダーを利用しているかは分かりません。
このように、法改正対応においては納期遅延は避けされないのです。
そして、障害の中身にもよりますが、障害対応の原則、即時対応が求められます。 これも顧客の実務に直結するためですね。
2. 効率化するほど損をする「賽の河原」現象
「タスクが多いなら、スキルアップして効率化すればいい」
そう思うかもしれません。 私も最初はそう思って、必死にショートカットを覚えたり、pythonで自動化ツールを作りました。 しかし、SIerの構造には「効率化した人間が損をする」というバグがあります。
早くタスクを終わらせて定時で帰ろうとすると、何が起こるか。 「あ、手空いてる？ じゃあ、あの案件の手伝いをお願い」 と、別の仕事が降ってくるだけです。
日本のメンバーシップ型雇用では、個人の職務範囲（Job Description）が明確ではありません。 「終わった人」は「終わっていない人」を助けるのが通常です。
- 早く終わらせても、給料は変わらない（むしろ残業代が減る）。
- 早く終わらせると、さらに重いタスクが積まれる（賽の河原）。
この構造の中にいると、「死ぬ気で効率化して定時で帰る」モチベーションは消え失せます。「定時ギリギリまでゆっくりやる」か、あるいは「キャパオーバーの仕事を引き受けてパンクする（サビ残）」の二極化が進むのです。
さらにタチが悪いのが、「生活残業」の存在です。 成果が見えにくい構造を悪用して、わざとダラダラ仕事をして残業代を稼ぐ人が現れます。 真面目に効率化した人が損をし、ダラダラ残る人が得をする。 これが構造的なバグです。
また、この生活残業の存在があるからこそ、上司は部下の残業量という勤怠アプリを開けばすぐに分かる値ではなく、 自分の直感で部下に対して仕事を振ることになります。
3. 上司の「時短ハラスメント」とアリバイ作り
これが、私が最近もっとも憤りを感じているポイントです。
昨今の働き方改革の影響で、上司からは 「残業を減らせ」「早く帰れ」と口酸っぱく言われます。 しかし、その一方で、午前中に残業を減らせと言われたのに、、午後に別のタスクを渡してきます。
- タスク量：100
- 定時リソース：60
- 上司の指示：「残業せずに100やれ」
これは物理的に不可能です。 本来なら、上司（マネージャー）がタスクを60に減らすか、人を増やしてリソースを100にする調整を行うべきです。 しかし、多くの現場上司はそれを行わず、現場の「工夫」に丸投げしたり、無理なら部下から上司に調整を依頼するように指示を出します。
なぜか？
彼らは 「自分を守るためのアリバイ」を作っているからです。
もし部下が過労で倒れたり、労基署が入ったりした時、彼らはこう言うためです。 「私は常に『早く帰るように』と指導していました。彼が勝手に残業したんです」
矛盾した命令（ダブルバインド）を出されている部下は、板挟みになります。
「終わらせないと詰められる。でも残業申請すると怒られる」
その結果、選ばれるのが 「退勤ボタンを押してから仕事をする（サービス残業）」という最悪の選択肢なのです。
4. 最大の罠：「調査時間は作業時間ではない」という自責の念
最後に、私たちエンジニア自身の心の問題です。 これが最も根深く、厄介な要因です。
私たち技術者は、真面目すぎるがゆえに、以下のような思考に陥りがちです。
「この実装、知っている人なら1時間で終わるはずだ。自分が未経験だから調査に2時間かかって、計3時間かかってしまった。 余計にかかった2時間は『自分の勉強不足』のせいだから、会社に請求するのは申し訳ない」
こうして、調査時間やバグの原因究明にかかった時間を、「自己研鑽」と脳内変換して勤怠から除外してしまいます。
しかし、これは間違っています。 業務に必要な技術を調査する時間は、立派な「業務」です。 レガシーコードの解読に時間がかかるのは、あなたのせいではなく「技術的負債」の問題です。
この「過剰な責任感」と「自責の念」が、日本のSIerの不健全な構造を、皮肉にも支えてしまっているのです。
結論：この「責任感」をどこに向けるべきか
構造的な欠陥、上司の自己保身、そして自分自身の自責癖。 これらが絡み合って、日本の「サービス残業」はなくなりません。
会社という組織の中にいる限り、この不条理と戦うのは非常に消耗します。 上司に正論をぶつけても、「アリバイ」でかわされるのがオチです。
だからこそ、私は 「SIer社員の生存戦略・逆転戦略」を考え、実行しています。
会社のために「いい人」になって、自分の寿命（時間）をタダで差し出すのはやめました。 その余剰の責任感と熱量は、すべて 「自分自身の資産（ブログ・個人開発・スキル獲得）」に向けようと決めました。
私が年収1億を目指し、個人開発や情報発信に没頭しているのは、単なる野心ではありません。 この「構造的に搾取される場所」から、自分の足で抜け出すための唯一の手段だと確信しているからです。
もし、あなたが今、タイムカードを切った後にPCを開いているなら、一度手を止めて考えてみてください。 その時間は、本当に会社に捧げるべき時間ですか？ それとも、未来の自分のために使うべき時間ですか？
