「開発の経験は、発注する側でも通じるんだろうか」
「納期に追われる生活は、移れば終わるのか」
そんな問いを抱えたまま求人票を開いているあなたへ。
結論から言えば、
入れ替わったのは、納期が決まる順番のほうでした
日付が先に立つ世界を出て、日付が最後まで動く世界へ入ります。
この記事では、同じ「納期」という一語が両側で何を指していたかを、机に残る書類に沿って並べていきます。
結論 — 変わったのは締切の重さではなく、決まる順番だった
移る前に想像していたのは、締切が緩くなる生活でした。実際に軽くなった部分はあります。
ただ、日々の感触を変えたのはそこではありませんでした。日付がどの時点で確定するかが動いたことのほうです。
受託の側では、日付は仕事が始まる前に確定していました。社内の側では、仕事が半分進んでからも動き続けます。
この差は、忙しさの総量には出ません。出るのは、予定を立てられる範囲のほうでした。
ですからこの記事では、どちらが楽かという比較はしません。負荷の種類が入れ替わるという一点だけを、書類の側から追いかけます。
受託の側で、日付はどこで決まっていたか
まず、移る前の世界を書き出します。あなたがいま座っている側の話なので、思い当たる箇所は読み飛ばして構いません。
比べる相手を先に固めておかないと、移った後の差が実感として残らないからです。
提案の段階で、日付は金額と一緒に確定していた
見積書には、金額と期間が同じ紙に載ります。片方だけを後で決めることはできません。
ですから日付は、要件が固まる前に置かれます。置いた日付から逆算して、工程表が引かれていきます。
この順番だと、後から要件が増えても日付は動きません。動かせるのは人数と品質のほうになります。
徹夜が発生する構造は、能力の話ではありませんでした。先に日付を置いた紙が、契約として残っていることのほうが効いていました。
提案を書いた人と、その日付で作る人が別なことも普通にあります。置いた側は、置いた時点の情報しか持っていません。
情報が増えるのは作り始めてからで、そのころには紙が確定しています。
決まった後の変更は、書面の手続きに変わる
要件が増えたとき、まず出てくるのは技術の話ではありません。この増分が当初の範囲に入るか、という話です。
入らないと判断されれば、変更依頼票が起票されます。金額と日付を引き直して、双方の承認を取り直す流れになります。
手続きが重いので、現場は「範囲に入る」ことにして飲み込みがちでした。飲み込んだ分は工数として記録に残りません。
結果として、遅れの理由が後から説明できなくなります。書面に出ていない負荷は、社内でも根拠にならないからです。
起票の判断は現場に降りてきますが、判断の材料は契約の側にあります。手元だけでは決められない場面が続きます。
守ったかどうかの判定は、契約書の側にあった
検収という区切りがあります。ここを通過すれば、期日は守られたことになります。
通過したシステムがその後どう使われたかは、判定に入りません。使われずに眠っても、期日は守られています。
この線の引き方には、良い面もありました。終わりが定義されているので、区切りごとに手が離れます。
終わりが来る仕事だった、というのが移った後に一番強く感じた差でした。
社内側には検収がありません。稼働した日から、同じ担当のまま面倒を見る期間が始まります。
区切りが無いぶん、いつ手を離せるかを自分で設計することになりました。ここは移った後で覚え直した部分です。
社内側では、同じ日付が逆の順番で決まっていた
移った先で最初に戸惑ったのは、いつまでに、が出てこないことでした。
依頼を受けても、期日が添えられていません。聞き返すと「早いほうがいい」という答えが返ってきます。
受託の側にいたころ、これは決められない発注者だと見えていました。実際に座ってみると、事情は逆でした。
先に決まっていたのは日付ではなく、いつなら業務を止められるかという枠のほうでした。個人の経験に基づく記述であり、同じ結果を保証するものではありません。
先に押さえられていたのは、たとえば次のような枠でした。どれも情報システム部門の都合では動きません。
- 月次の締めと支払いの日。ここを跨ぐ切り替えは、経理の合意が取れませんでした
- 棚卸しと決算の期間。数字を確定させる作業と並行して動かす判断は通りません
- 事業側の繁忙期。売上が立つ時期に業務を止める提案は、そもそも議題に載りませんでした
- 監査と法定の対応。日付が外から決まっているので、こちらが後ろへ回ります
ですから日付は、開発の進み具合ではなく、事業の暦のほうから決まります。決まるのは、開発が半分終わった後でした。
受託の側では、日付が先で中身が後。社内の側では、業務の枠が先で日付が後。同じ「納期」という語が、逆の順番から生まれていました。
この違いは、求人票にも面談にも書かれません。どちらの世界でも、使われている言葉は同じだからです。
厚生労働省が公開している job tag という職業情報のサイトには、システムエンジニア（受託開発）の項があります。
そこには仕事の中身として「要件定義から基本設計、詳細設計、開発、テスト、導入、保守まで一連のプロセスを担当する」と載っています（2026年8月13日 取得）。
一連のプロセス、という書き方が示すとおり、受託の側は工程が順に連なる形で定義されています。社内の側には、この連なりを外から受け取る立場が加わります。
受け取る立場に回ると、手を動かす量そのものも変わります。書く量が減った代わりに増える読み書きの中身は別の1本にしました。実装から離れることが不安なら、そちらを先に読むと順番が整います。
順番が入れ替わると、実務のどこが変わるか
順番の入れ替わりは、抽象的な話に聞こえます。実務では、書類に触る3つの場面として出てきました。どれも移った初日から当たります。
見積の読み方が、金額から日付の根拠へ移る
受け取る側に回ると、見積書の見る場所が変わります。合計欄より先に、期間の欄を見るようになりました。
知りたいのは高いか安いかではありません。この日付が、何を前提に置かれているかのほうです。
前提が書かれていない見積は、こちらの都合で日付が動いたときに全部崩れます。ですから、前提の記述量で相手を選ぶようになりました。
出す側にいたころ、前提の欄は保険だと思って書いていました。受け取る側では、そこが最初に読まれる欄でした。
読み方が変わると、書き方も変わります。自分が出す依頼文にも、前提を先に並べる癖が付きました。
遅れの報告先が、営業ではなく使う部署になる
遅れが見えたとき、受託の側では社内の営業へ先に上げていました。対外的な調整は、そこから先の仕事です。
社内側では、報告先が使う部署に変わります。間に挟まる人がいないので、説明はこちらが直接します。
ここで求められるのは、遅れの理由ではなく、代わりの手順でした。動かない期間をどう回すかまで添えて、初めて話が終わります。
紙とエクセルで凌ぐ段取りまで持っていくと、日付の話は落ち着きます。技術の説明は、そのあとで足りました。
間に合わせるの中身が、足すことから減らすことへ変わる
受託の側で締切に迫られたとき、打てる手は人を足すことでした。増員の稟議が通れば、数字の上では帳尻が合います。
社内側では、この手がまず使えません。予算は年度の初めに枠が決まっていて、期中に増やすには別の説明が要ります。
ですから間に合わせる手段は、範囲を削る方向になります。今回入れる機能と、次回へ回す機能を線引きする作業です。
削る判断には、使う部署の合意が要ります。技術の判断より、交渉の段取りのほうが時間を食いました。
削った機能は、翌年度の要望として戻ってきます。ですから削り方には、戻ってきたときの並べ方まで含まれます。
移る前に、いまの案件で確かめられること
順番の入れ替わりに耐えられるかは、移る前でも見当が付きます。あなたがいま担当している案件の書類で足ります。
- 直近の見積書を開き、期間の欄に前提が何行書かれているかを数える。ゼロなら、受け取る側では読みにくい紙になっている
- 今期に起票された変更依頼票の本数を数える。少ないほど、現場が飲み込んでいた量が多い
- 遅れを報告したとき、最初に話した相手が誰だったかを思い出す。社内の営業なら、緩衝材がある側にいる
- 締切に迫られたときに打った手を書き出し、足す手と減らす手に分ける。減らす手が一つも無いなら、移った後に手札を作り直すことになる
持ち越すものも分けておきます。あなたが場所を変えても消えない負荷が、3つ残りました。
- 日付を守れなかったときの説明は、どちらの側でも自分がします。相手が社外か社内かが変わるだけです
- 止まったシステムの前で最初に立つのも、どちらの側でも変わりません。契約の線が消えるぶん、社内側のほうが範囲は広くなります
- 覚え直しは毎回あります。受託では業種が変わるたび、社内では部署が変わるたびに、業務の言葉を学び直します
後悔として語られる中身がどこに寄るかは、評価される単位が入れ替わる話のほうで細かく割ってあります。締切より評価のほうが気になるなら、そちらを先に見ておくと順番が整います。
窓口を選ぶ前に、公表されている対象を読む
手札の棚卸しが済んだら、相手側の公表内容に目を落とす番です。ここを先に読むと、面談の持ち時間が前提の説明で消えません。
見るのは対象の欄です。ここは面談では動かせないので、合っていなければ申し込む前に判断できます。
あなたが社内側へ寄せたいのか、受託の枝も残したいのかで、読む順番も変わってきます。
社内SE転職ナビが対象に掲げるのは、自社の中で働きたいITエンジニア（社内SE・情報システム職）です（同社公式サイト。2026年8月17日 取得）。
対象として挙がっているのは、ITエンジニアとデザイナーです。レバテックキャリアはIT・Web業界への特化を掲げています（同社公式サイト。2026年8月17日 取得）。
申し込みと面談の間に、希望条件の入力が挟まります。
ここに引いたのは各社の公表内容そのままで、当サイトが裏を取った結果ではありません。書かれていない条件は、存在しない条件とは別です。
当サイトの評価軸に基づく整理であり、客観的な優劣を示すものではありません。評価軸は広告掲載方針に記載しています。
2つの窓口は、日付の話をどこまで持ち込めるかで分かれる
筆者は本サービスの利用者ではありません。以下は各社の公表情報と、SE・社内SE としての実務経験からの整理です。
面談で最初に埋まるのは、いまの働き方をひととおり説明する時間でした。順番の話まで持ち込めると、条件の絞り込みが一段速くなります。
「納期がきつい」ではなく「日付が契約で先に決まる側にいます」と言えると、あなたが探している環境の輪郭が相手にも伝わります。
社内側へ軸足を移すと決めた後なら、社内SE転職ナビが公表する対象の内側に入ります。
窓口が受けるのは社内SE、または情報システム職の枠です。開発側に残る道を探している間は、条件の側が先に絞り込みを始めます。
受託の枝も並べて比べたい段階なら、レバテックキャリアのほうが幅が出ます。見られるのは、ITエンジニアまたはデザイナーとしての職歴です。直近で担当した工程の記録が薄いと材料が足りません。
3つの質問は、開発側の枝でもそのまま使えます。違うのは、返ってきた答えを日付の根拠として読むかどうかです。受託の枝なら、契約の期間がそのまま答えになります。
まとめ — 入れ替わったのは、暦の持ち主だった
受託の側で、暦を持っていたのは契約書でした。日付が先に置かれ、中身が後から埋まります。
社内の側で、暦を持っているのは事業のほうです。業務を止められる枠が先にあり、日付は最後に決まります。
移って半年、慣れるまでに時間がかかったのは締切の重さではありませんでした。決まっていないまま進める時間の長さのほうです。
受託の側では、決まっていない期間は営業と契約が引き受けてくれていました。社内側では、その期間ごと手元に置くことになります。
ここに耐えられるかどうかは、いまの案件で減らす手を打てているかから見当が付きます。あなたの手札を先に数えておくと、移った後の半年が短くなります。