エンジニアの1日の流れ|入社前に知っておくこと【2026年版】
未経験からエンジニアを目指すとき、想像しにくいのが「実際、1日何をしているのか」です。
「コードを書く仕事」というイメージがありますが、実務でコードを書いている時間は、思っているより短いのが普通です。
そして、この認識のずれが入社後のつまずきにつながります。「コードを書きたくて入ったのに、会議と確認ばかり」と感じて、早期に辞める人が実際にいます。
この記事では、1日の実際の流れ、開発以外にやっていること、職種による違い、そして面接で確認すべきことを整理します。
1. 結論:知っておくことは3つ
①コードを書く時間は、1日の半分以下のことが多い。残りは、仕様の確認、レビュー、会議、動作確認、調査に使われます。
②中断が多い。質問への対応、障害の確認、割り込みの依頼。まとまった時間が取れない日があります。
③職種と会社の規模で大きく変わる。自社開発、受託、SES、そしてWeb系かインフラかで、1日の形が違います。
「コードを書く仕事」ではなく「動くものを届ける仕事」だと考えると、実態に近くなります。
2. 1日の流れの例
自社開発の企業で、実装を担当している場合の一例です。
| 時間 | やっていること |
|---|---|
| 始業〜30分 | 連絡の確認、その日の作業の整理 |
| 30分〜15分間 | 朝会(進捗と困っていることの共有) |
| 午前中 | 実装。途中で仕様の確認や質問への対応 |
| 昼休み | — |
| 午後の前半 | 実装の続き、動作確認 |
| 午後の中盤 | レビュー(他人のコードを読む、自分のを見てもらう) |
| 午後の後半 | 仕様の相談、次の作業の準備 |
| 終業前 | 作業内容の記録、翌日の整理 |
まとまって実装できるのは、午前中と午後の前半の3〜4時間というのが典型的な形です。
開発以外にやっていること
| 作業 | 内容 |
|---|---|
| 仕様の確認 | 「この場合はどう動くべきか」を関係者に聞く |
| レビュー | 他人のコードを読み、指摘する/指摘を受ける |
| 動作確認 | 書いたものが想定通りに動くかを確かめる |
| 調査 | エラーの原因、使えるライブラリ、過去の実装 |
| 記録 | 何をしたか、なぜそうしたかを残す |
| 会議 | 朝会、設計の相談、振り返り |
このうち「調査」の時間が最も見落とされます。エラーの原因を追うのに半日かかることは珍しくありません。
3. 編集長の実体験:想像と違ったと言われた話
私の知人に、未経験からエンジニアに転職した人がいます。仮にQさんとします。
入社から2か月後に会ったとき、Qさんはこう言いました。
Qさん「思っていたのと違いました」
私「どこがですか」
Qさん「コードを書いている時間が、1日2時間くらいなんです」
Qさんが1日にやっていたことを聞くと、次のような内訳でした。
- 朝会と進捗の共有:30分
- 仕様の確認と質問:1時間半
- 実装:2時間
- 動作確認とエラーの調査:2時間
- レビュー:1時間
- 記録と整理:30分
Qさん「学習していたときは、ずっとコードを書いていたので」
私「実務だと、書く前に決めることが多いんですね」
Qさん「そうなんです。何を作るかを確認する時間のほうが長くて」
その後、Qさんの受け止め方は変わりました。
Qさん「半年経って分かったんですが、確認をしないで書き始めると、作り直しになるんです。確認の時間は無駄じゃなかった」
1年後、Qさんは同じ職場で続けています。
辞めた人と続けた人の差は、この認識を入社前に持っていたかどうかだと、Qさんは言っていました。
Qさん「面接で『1日の時間の使い方を教えてください』と聞いておけばよかったです。聞いていれば、驚かなかったので」
会議の中身
エンジニアの会議は、報告よりも相談が中心です。「この仕様で問題ないか」「この作り方でよいか」を確認する場で、決めるために集まります。
未経験のうちは発言しにくく感じますが、分からない点を質問するだけで参加している扱いになります。黙って聞いているだけだと、理解しているものとして進んでしまいます。
4. 職種・形態による違い
| 形態 | 1日の特徴 |
|---|---|
| 自社開発 | 仕様を自分たちで決めるため、相談の時間が長い |
| 受託開発 | 顧客とのやり取りと、仕様の確認が多い |
| SES(常駐) | 常駐先の進め方に従う。工程によって内容が固定される |
| インフラ・運用 | 監視、対応、構築。障害時は割り込みが最優先 |
| 社内SE | 社内の問い合わせ対応が一定量ある |
最も差が出るのは「割り込みの多さ」です。運用や社内SEは、予定していた作業が中断されることが日常的にあります。
まとまった時間で集中したい人は、割り込みの少ない形態を選んでください。これは向き不向きの問題で、優劣ではありません。
インフラ側の1日
インフラエンジニアの場合、次のような形になります。
| 時間 | やっていること |
|---|---|
| 始業 | 監視の状況確認、夜間のアラートの確認 |
| 午前 | 構築作業、設定変更の準備 |
| 午後 | 変更の実施、動作確認 |
| 随時 | 障害対応(発生時は最優先) |
変更作業は、影響が出にくい時間帯に行うことがあります。夜間や早朝の作業が発生する職場もあるので、面接で確認してください。
なお、これらの違いは求人票からはほとんど読み取れません。「開発業務全般」としか書かれていない求人が大半なので、面接で聞くしかありません。
5. 面接で聞くべき5問
| 質問 | 分かること |
|---|---|
| 「1日の時間の使い方を教えてください」 | 実装と会議の配分 |
| 「入社1年目の方は何を担当していますか」 | 最初に任される範囲 |
| 「仕様は誰がどう決めていますか」 | 相談の相手と流れ |
| 「レビューはどういう形で行われますか」 | 指導の受け方 |
| 「割り込みの依頼はどのくらいありますか」 | 集中できる時間の量 |
1問目が最も情報量があります。具体的な時間配分が返ってくれば実態があり、「人によります」で終われば、決まった形がない職場です。
5問目は聞きにくく感じますが、聞いて構いません。「集中して取り組む時間を作りたいので」と添えれば、自然な質問になります。
答えを複数社で比べる
同じ質問を3社に投げると、違いがはっきり出ます。「実装が5割」と答える会社と「会議が3割」と答える会社では、入社後の日常が違います。
どちらが良いかではなく、自分がどちらで働きたいかで選んでください。比べる材料がないと、この判断ができません。
6. 入社前にずれやすい認識5つ
| 想像 | 実際 |
|---|---|
| 1日中コードを書く | 書く時間は半分以下のことが多い |
| 一人で黙々と作業する | 確認と相談が業務の中心にある |
| 技術力があれば評価される | 進捗の共有と説明も評価される |
| 学習したことをそのまま使う | 既存のコードに合わせる場面が多い |
| 完成したら終わり | 動作確認、レビュー、修正が続く |
3番目のずれが、最も評価に影響します。実装が進んでいても、詰まっていることを共有しないと「進捗が見えない人」になります。
「困っています」と早く言えることが、実務では技術力と同じくらい評価されます。
1日の終わりにやること
多くの職場で、その日の作業内容を記録する習慣があります。これは報告のためだけでなく、翌日の自分のためでもあります。
書くのは3行で足ります。「何をやったか」「どこで詰まったか」「明日の最初にやること」。この3行があると、翌朝の立ち上がりが速くなります。
未経験のうちは、詰まった内容を書き残しておくと、同じエラーに再会したときに助かります。
7. 1年目の過ごし方
| 時期 | 状態 |
|---|---|
| 1〜3か月 | 環境の構築、既存コードを読む、小さい修正 |
| 3〜6か月 | 小さい機能の実装。レビューで多く指摘される |
| 6か月〜1年 | 機能単位で担当。仕様の確認も自分で行う |
| 1年以降 | 設計から関わる機会が出る |
最初の3か月は、コードを書くより読む時間のほうが長くなります。これは正常です。
この時期に「何もできていない」と感じる人が多いのですが、既存のコードを理解することが最初の仕事です。焦って書き始めると、後で作り直しになります。
会社の規模による違い
小規模な会社では、1人が担当する範囲が広くなります。実装だけでなく、仕様の決定、動作確認、場合によっては顧客とのやり取りまで入ります。
大きな会社では、工程ごとに担当が分かれていることが多く、1日のうちで担当する作業の種類が少なくなります。
広く経験したいなら小規模、深く担当したいなら中〜大規模という選び方ができます。どちらが良いかではなく、何を最初に経験したいかで決めてください。
8. 進め方と時間配分
面接前にやることは3つです。
| 段階 | 時間 | やること |
|---|---|---|
| 求人票の確認 | 20分 | 仕事内容の欄に、開発以外の記載があるか |
| 社員インタビュー | 15分 | 1日のスケジュールが載っていれば読む |
| 質問の準備 | 15分 | 5問から3問を選ぶ |
| 面接での確認 | 面接内 | 逆質問の時間に聞く |
| 記録 | 10分 | 答えを管理シートに残す |
合計1時間ほどです。複数社の答えを並べると、企業ごとの違いが見えてきます。
9. よくある質問
コードを書く時間が短いと、技術力は伸びませんか
伸びます。読む、確認する、レビューを受けるという作業が、書く力を作ります。書く量だけで技術力が決まるわけではありません。
会議が多い職場は避けるべきですか
会議の中身によります。仕様の相談や設計の議論であれば、業務に必要な時間です。報告のためだけの会議が多い場合は、面接で頻度を確認してください。
未経験だと最初は何をしますか
環境の構築、既存コードを読む、小さい修正が一般的です。いきなり機能を任されることはほとんどありません。
残業はどのくらいありますか
企業と時期によります。リリース前と障害対応時に集中するのが一般的な形です。面接で「繁忙期はいつで、そのときの働き方はどうなりますか」と聞いてください。
質問ばかりして迷惑になりませんか
なりません。むしろ、聞かずに間違った方向で進めるほうが手戻りが大きくなります。ただし、調べれば分かることは先に調べてから聞いてください。
一人で作業する時間はありますか
あります。ただし、まとまった時間が取れるかは職場によります。集中して取り組みたい場合は、割り込みの量を面接で確認してください。
リモートワークだと1日の流れは変わりますか
会議がオンラインになり、質問がチャットになります。質問の心理的なハードルが上がるため、意識して聞く必要があります。頻度や運用は職場によって差が大きいので、面接で確認してください。
入社前に何を準備しておけばいいですか
使う技術の基本を触っておくことと、業務で使うツールに慣れておくことです。ただし、既存のコードの読み方は入社後にしか学べません。
10. まとめ:今週やる3つのこと
エンジニアの仕事は、コードを書く時間よりも、書く前と書いた後の作業が多いのが実態です。
1. 面接で「1日の時間の使い方」を聞く。具体的な配分が返ってくれば実態があります。「人によります」なら、決まった形がない職場です。
2. 「入社1年目の方は何を担当していますか」を聞く。最初に任される範囲が分かれば、入社後のギャップが減ります。
3. 求人票の仕事内容に、開発以外の記載があるか確認する。仕様の確認、レビュー、運用。書かれていれば、実態を伝えようとしている求人です。
ずれをなくす作業は、入社前にしかできません。面接の逆質問を使ってください。
この先、読むべき記事
- 未経験エンジニア1年目にやること|3か月・6か月・1年の目標(1年目の動き方)
- SES・受託・自社開発の違い|未経験エンジニアが最初に選ぶ基準(形態による違い)
- IT企業を選ぶ4つの軸|規模とフェーズで働き方が変わる(会社の選び方)
- チーム開発の経験がないとき|一人で作った実績の伝え方(チーム開発の見せ方)
- インフラエンジニアの未経験転職|第二新卒に入口が広い理由と学習の順番(インフラ側の入口)
- エンジニアの職種の違い|入口を選ぶための地図(職種による違い)
- エンジニアの夜勤と当番|実態と面接で確認する項目(夜間対応の確認)
- アジャイル開発の現場|第二新卒が求人票から実態を読む(進め方による違い)
この記事を書いた人
木戸 悠介(きど ゆうすけ)/なぜキャリア?運営者。1996年生まれ、神戸市出身。
23歳で上場企業子会社に新卒入社し、メディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた。2ヶ月で10社に応募し2社から内定。その後スタートアップに3人目の社員として参画し、現在は自分の会社を経営している。