LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

リリースの日は動かせないのに、総合テスト（システム全体を通して確かめる試験）で見つかった不具合の修正が終わらない。残業を続けても残りの作業が減らないので、開発要員を増やしたい——。システム開発の現場では、こうした状況が起こりがちです。厚生労働省の調査でも、回答したITエンジニアの44.1%が、最も忙しかった月に週50時間を超えて働いていました。^*1 リリース前の増員とは、予定の日までに作業を終えるために、完成間近の段階で開発要員を加えることを指します。

増員は、残りの作業を手分けして任せられるときには使いどころのある方法です。ただし万能ではなく、残業の理由が仕様変更や顧客との調整にあるなら、人を増やしても作業そのものは減りません。本記事では、開発の現場を預かるマネージャーに向けて、繁忙期の労働時間、残業が発生する理由、残業で乗り切るときの上限、増員を決める前に確かめること、そして外部に頼むときに確認しておきたい点を整理します。

リリース前の増員とは

リリース前の増員には、いくつかの形があります。社内の別の案件から人を異動させる、協力会社に追加の要員を頼む、業務委託で働く専門人材に加わってもらう、といった形です。どの形でも、加わった人がすぐに担当できる作業と、説明を受けてからでないと担当できない作業があります。

すぐに担当できるのは、作業の中身と、何をもって終わりとするか（完了の条件）を書き出せるものです。仕様がまだ決まっていない機能の設計や、顧客との仕様の調整は、それまでの経緯を知らない人には任せにくい作業です。

このため、リリース前に開発要員の増員を考えるときは、何人増やすかより先に、残っている作業の中身を見ます。残りの工数（作業にかかる人数×時間）と工期の関係は、IPA（情報処理推進機構）の統計をもとにした関連記事「工数と工期の関係」や「リリース前の開発要員」で扱っています。本記事では、残業の理由をもとに、増員で進む作業かどうかを見分ける方法を整理します。

繁忙期の労働時間

厚生労働省が委託した「過労死等に関する実態把握のための労働・社会面の調査研究事業」は、2017年11月から12月にかけて、情報サービス業の企業と、そこで働くITエンジニアに労働時間と働き方を尋ねています。回答したのは企業423社、ITエンジニア2,465人です。^*1 調査から時間がたっていますが、残業の理由を20を超える選択肢で細かく尋ねた調査として参考になります。

通常期の1週間の実労働時間は「35時間超～40時間以下」が52.7%で最も多く、50時間を超える人は区分の割合を足しても1.6%でした。ところが、過去1年間で最も忙しかった月（繁忙期）になると「45時間超～50時間以下」が25.6%で最も多くなり、50時間を超える人は44.1%、60時間を超える人も12.5%にのぼります。^*1

繁忙期の月として最も多く挙がったのは3月の20.1%で、10月の11.3%、12月の10.1%が続きます。^*1 3月は多くの企業で年度末にあたる月です。どの月であっても、繁忙期の働き方が何週間も続くと、法律が定める時間外労働の上限に近づいていきます。この点は後の節で見ます。

なぜ残業が発生するのか

同じ調査は、所定外労働（会社が決めた勤務時間を超えて働くこと）が発生する理由を、ITエンジニアに複数回答で尋ねています。最も多いのは「トラブル等の緊急対応のため」の59.1%で、「顧客の問題に対応するため」47.9%、「仕様変更に対応するため」42.6%、「納期・予算に無理があるため」40.1%が続きます。^*1

「プロジェクトに当てられる人員が足りないため」は35.5%で、選択肢の中では5番目でした。^*1 人が足りないことを残業の理由に挙げた人は、回答者の3分の1ほどです。上位の4つは、どれも人数が足りないこととは別の理由です。

企業に尋ねた設問でも、同じような結果が出ています。過重労働を防ぐ取り組みを進めるうえでの課題として最も多く挙がったのは「顧客の理解・協力が必要である」の56.0%で、「納期などの契約条件を満たすことができなくなる恐れがある」も35.7%ありました。一方、「人員不足のため対策を取ることができない」は17.3%です。^*1 残業を減らせるかどうかは、社内の人数だけでは決まらないことが分かります。

増員で減らせる残業と減らせない残業

理由ごとに見ると、増員で減らしやすい残業と、減らしにくい残業に分けられます。減らしやすいのは、作業の量が決まっていて、手分けできるものです。たとえば、原因の調査が済んだ不具合の修正が20件残っているなら、修正と再テストを何人かで分けて担当できます。テストの実施も、手順書と期待する結果がそろっていれば、新しく加わった人に任せられます。

減らしにくいのは、作業の量が顧客との話し合いで決まるものです。仕様変更への対応は、変更の中身が決まるまで作業の量が決まりません。顧客の問題への対応や連絡調整も、これまでの経緯を知っているメンバーが担当することになります。新しく加わった人に経緯を説明するあいだ、元からいるメンバーは自分の作業を進められません。

「納期・予算に無理があるため」は、どちらにも当てはまります。作業の量に対して日数が足りないだけなら、増員で進められる部分があります。見積もりの前提そのものがずれているなら、人を増やす前に、納期やリリースに含める機能を顧客と話し合い直すことが先になります。緊急対応も同じで、障害の原因が分かるまでは、調べる人を増やしても作業が進むとは言えません。

残業で乗り切るときの上限

増員をせずに残業で乗り切る場合も、労働時間には上限があります。労働基準法は、休憩を除いて1週40時間、1日8時間を超えて働かせてはならないと定めています。これを超えて働いてもらうには、労働者の過半数で組織する労働組合、または労働者の過半数を代表する者と書面で協定を結び、労働基準監督署に届け出る必要があります。この協定は、根拠の条文から36協定（時間外労働の労使協定）と呼ばれます。^*2

協定で延ばせる時間にも限度があり、原則は1か月45時間、1年360時間です。臨時的な事情に備えた特別な定め（特別条項）を置いても、休日労働を含めて1か月100時間未満、2〜6か月の平均で80時間以内に収める必要があり、1年の時間外労働は720時間以内、1か月45時間を超えられるのは1年に6か月までです。^*2

前の節で見た繁忙期の数字に当てはめると、週60時間を超える働き方が4週続けば、時間外労働（週40時間を超えた時間）だけで80時間を超えます。1か月だけなら特別条項の上限に収まることがあっても、2か月、3か月と続けば平均80時間の上限に近づきます。リリースが延びる見込みがあるなら、残業の見通しと増員の要否を同じ時期に考えておくと、日程を組み直しやすくなります。

増員を決める前に確かめること

増員を決める前に、残っている作業を理由ごとに書き出します。作業ごとに次の3点を確かめると、増員で進む作業とそうでない作業が分かれます。

• 作業の中身と完了の条件を書けるか
• 新しく加わった人に説明するのは誰か、その人の時間をどれだけ空けられるか
• 作業の量を決めるのに、顧客との話し合いが要るか

たとえば「結合テスト（部品を組み合わせて確かめる試験）で見つかった不具合のうち、原因が特定済みの15件について、修正と再テストを2週間で終える」と書ける作業は、増員で進めやすい作業です。「帳票の出力形式を顧客と相談する」のような作業は、終わりの基準を顧客が決めるため、増員より先に顧客との打ち合わせを設けます。

調査に答えた企業でも、過重労働を防ぐために「業務内容やプロジェクト進捗状況把握の推進を行っている」企業は48.0%、「ITエンジニア間の業務量調整を管理者が積極的に実施している」企業は33.6%でした。一方で「業務負担をITエンジニア間で平準化することが難しい」ことを課題に挙げた企業も37.1%あります。^*1 作業を書き出しておけば、増員するかどうかにかかわらず、社内のメンバーの間で作業を分け直すときの材料になります。

「契約や仕様等の変更など、顧客に対して考え方を変えてもらう取組を推進している」企業は18.0%にとどまります。^*1 仕様変更が残業の理由になっているなら、変更を受け付ける締め切りや、リリースの後に回す機能を顧客と決めることも、増員と並ぶ選択肢になります。

外部に頼むときに確認しておきたい点

社内で人を回せず、外部の専門人材に加わってもらう場合は、依頼の段階で作業名と期間を書いて伝えます。「総合テストで見つかった不具合の修正を、リリース予定日の1週間前まで」「画面の応答時間を測る性能試験の実施と結果の報告を3週間」のように書けていれば、候補者も自分の経験と比べて判断できます。依頼する側も、面談で何を確かめればよいかがはっきりします。

受け入れの準備にも日数がかかります。開発環境のアカウント、ソースコードを置く場所へのアクセス権、秘密保持契約は、加わってもらう日より前にそろえておきます。準備の進め方は「業務委託エンジニアの受け入れ準備」で扱っています。質問に答える担当者を1人決め、その人の担当作業を減らしておくと、加わった人が作業に入りやすくなります。

つまずきやすいのは、仕様変更への対応まで外部の人に任せようとすることです。仕様の経緯を知らない人には、変更がどの機能にまで影響するかを判断する材料がありません。外部の人に任せるのは完了の条件が書ける作業にとどめ、仕様の判断と顧客との調整は社内のメンバーが担うと、役割の食い違いを防げます。

まとめ：リリース前の増員で確かめておきたい3つの点

リリース前の開発要員の増員を判断するうえで、確かめておきたい点は3つに整理できます。第一に、残業の理由を書き出し、人が足りないことが理由になっている作業を分けること。第二に、作業の中身と完了の条件が書ける作業を、新しく加わる人に任せること。第三に、仕様変更や見積もりの前提がずれているなら、増員より先に顧客と話し合うことです。この3点を踏まえておけば、「人を増やしたのに、リリース前の残業が減らなかった」という事態を避けやすくなります。増員する作業の切り分けに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：厚生労働省「平成29年度 過労死等に関する実態把握のための労働・社会面の調査研究事業 報告書（IT産業に関する調査）」（https://www.mhlw.go.jp/content/11200000/000511978.pdf）。出典：厚生労働省・文部科学省委託、みずほ情報総研株式会社（平成30年3月）。調査期間2017年11月20日〜12月22日、有効回収 企業調査423件・労働者調査2,465件。労働者調査 図表82（実労働時間・通常期）、図表84（実労働時間・繁忙期）、図表86（繁忙期の月）、図表97（所定外労働が発生する理由、複数回答）、企業調査 図表54（過重労働の防止に向けて実施している取組、複数回答）、図表55（過重労働の防止に向けた取組を実施するに当たっての課題、複数回答）を参照。50時間超・60時間超の割合は区分の割合を足し合わせた値（2026年9月確認）
2. *2　参考：e-Gov法令検索「労働基準法」（https://laws.e-gov.go.jp/law/322AC0000000049）。出典：労働基準法（昭和22年法律第49号）第32条（労働時間）、第36条（時間外及び休日の労働）、第37条（時間外、休日及び深夜の割増賃金）を参照（2026年9月確認）

Tweet