この前、親戚に「エンジニアって何してるの？」と聞かれて、うまく答えられなかったことがあって。「パソコンでシステムを作ってる」と言ったら「ホームページの？」と返ってきて、そこから先の説明を諦めてお茶を濁しました。8年やっていてもこれ慣れないっす。
そこで今回は、エンジニアを8年やってきた僕なりの答えを書いてみました。先に言ってしまうと、僕の実感は「システムエンジニアは、地道でめんどくさい作業がやたら多い仕事」です。夢のない答えでほんとごめんなさい。でも、これがリアルの感覚に近いと思っています。
この記事の対象者です。
- システムエンジニア（SE）に興味がある・目指している人
- IT業界に入ったばかりで「思っていた仕事と違うかも」と感じている人
- 家族や友人に自分の仕事をうまく説明できない現役の人（僕です）
※あくまで僕個人の経験ベースの話です。会社や案件によって全然違う、という前提で読んでもらえたらと思います。
求人サイトの説明はあながち間違ってはいないけどちょい違う
求人サイトや転職メディアで「システムエンジニア」を調べると、だいたいこう書いてあります。
クライアントの要望をヒアリングし、要件定義・設計などの上流工程を担当。設計書をもとにプログラマーへ実装依頼、自分でも開発・テストを担当することも。運用保守に回ることも。
ヒアリング → 要件定義 → 基本設計 → 詳細設計 → 開発 → テスト → 運用保守、という工程の図もセットでよく見ます。
これ、間違ってはいないです。僕も新人研修で同じ図を見ましたし。ただ、この説明を読んで仕事の中身がイメージできた人はたぶんいないんじゃないかと思います。「上流工程を担当します」と言われても、自分がSEなって実際に何していくのかっていうのは全くイメージできないと思います。
なので、僕とそのまわりのエンジニアが実際に何をしているかを中心に書いていきます。
僕はふだん何しているか
僕は今フリーランス8年目で、8人のWeb開発チームをPMとして見ながら、自分でも設計や実装をしています。新卒で入ったのはSES企業で、インフラ企業の業務システム改修や、検索大手の広告入稿アプリの開発などをやってきました。
で、今の僕の一日ですが、コードを書いている時間は体感で3割くらいです。残りの7割は、ざっくりこんな感じです。
- チャットで出社
- 朝会でチームの進捗確認
- 設計書や仕様メモを確認・見直す
- メンバーが書いたコードのレビュー
- 仕様確認とかのミーティングする
- 質問対応・関係者との調整
- マージ対象の確認
なので一般的な「エンジニア＝一日中コードを書いている人」のイメージでエンジニア入ると、ここで「あれ？」となります。僕もこれ最初なりました。
まわりのエンジニアは何をしているか
「それはお前がPMだからだろ」と思われそうなので（半分そうっちゃそうですが）、立場の違うエンジニアの例も書いておきます。働く場所によって、毎日やることはまぁ違います。
※特定を避けるため、細部は少しぼかしています。
SESで客先常駐している後輩の場合。 金融系システムの改修案件。Excelの設計書を直して、テストを流して、エビデンス（ちゃんと動いた証拠の画面キャプチャ）をExcelに貼っていく、の繰り返しが中心。「今日、Excelしか開いてないです」という日も普通にあるらしいです。コードを書く時間より、コードの周りの作業のほうが長い。
うちのチームにいる、自社開発出身のメンバーの場合。 前職では自社サービスの開発をしていて、コードを書く時間は長めだったそう。そのかわり、仕様を自分たちで決めるための打ち合わせや、リリース後の問い合わせ対応・障害対応がセットでついてきます。「作って終わり」ではなく「動かし続ける」仕事だった、と言っていました。
立場が違っても共通しているのは、「コードを書く」は仕事の一部でしかなくて、その手前と後ろに地道な作業が大量にあることです。
なんで「めんどくさい作業が多い」なのか
これが一番話したかったポイント。SEのめんどくさい作業を具体的に挙げると、たとえばこのあたりでしょう。
- Excel設計書が細かい。1画面のボタン1個の挙動までびっしり書きます
- テストケースの洗い出し。正常系・異常系・境界値…と漏れなく潰すのがむずい
- エビデンス貼り。テストを1件流すたびに画面キャプチャを撮って、Excelに貼って、日付と結果を書くみたいな
で、これらの作業の正体を突き詰めると、「自分がやったことを、上司や客先にちゃんと証明するための作業」なんですよね。コードだけできて提出しても「それ大丈夫なん？」が確証できなきゃダメなんです(仕事なので)。
システムは当たり前ですが目に見えないので「ちゃんと考えました」「ちゃんと動きました」を形にして残さないと、作った本人以外は誰も確認できない。だからこの手の作業が必要なんです。僕も理解しているつもりです。
理解はしているんですが、やりながら「もっとこうすればいいじゃん」と思う場面がとにかく多いんですよね。このスクショ貼り、自動化できるよね、とか。この設計書、コードから生成すればズレないよね、とか。必要性はわかるけど、手段が割に合っていない。「昔からこうやってるから」とか「確認者の都合で」とか。そういう環境がかなり多いのがSEです。システムエンジニアの仕事のかなりの割合は、この「割に合わない作業」とどう付き合うかだと思ってます。
しんどいところと、面白いところ
ついでに、僕の本音も書いておきます。
しんどいのは、まず「動いて当たり前」と評価されることです。100点でやっとゼロ、バグるとマイナス。それから仕様変更。仕様が変わると、さっき書いたテストケースとかエビデンスが軒並み取り直しになります。めんどくさい作業がシンプル2倍です。クソです。あとは板挟みですね。これもクソ。
面白いのは、設計したとおりに動いた瞬間です。これは何年やっても「おっほ」ってなります。自分の作った機能で誰かの業務が楽になる手応えも、この仕事ならではだと思います。
それと、僕の場合は「めんどくさい作業を工夫で潰せたとき」が一番気持ちいいです。昔、エビデンス取りをちょっと工夫して体感時間1/3でこなせた時とか。開発で本体の機能を作ったときより達成感あったりします。
AI来て、この仕事はどう変わったか・変わりそうか
ここ2〜3年で一番変わったのは、まさにこの「めんどくさい作業」の部分です。
テストケースの叩き台はAIに洗い出させて、僕は漏れがないかを見る側に回る。設計書のたたき台や議事録の要約もそうです。僕のチームでもClaude Codeを導入できたので日常的に使っていて、僕もメンバーも自分の手でコードを書く時間はさらに減りました。「もっとこうすればいいじゃん」と思っていた部分が、本当にそうなり始めています。
一方で、変わらない部分もはっきりしてきました。それは何を作るかを決めること。AIの出力が正しいかを判断すること。「これでいきます」と責任を持っていえること。ここは仕事という本質上AIがどれだけ進んでも僕らの側に残っていて、むしろコードを書く部分が軽くなった分、比重が上がっている実感があります（僕の個人的感覚です）。
なので、これからSEになる人は「コードを書ける」だけだと足りなくて、コードと仕様を読めて、AIが出してきたものに対して「これは違う」が言える側に立てるかが効いてくるはずです。
おわりに
「地道でめんどくさい作業が多い仕事」と書きましたが、ネガキャンがしたいわけではないです。
あのめんどくささの中には「ぱっと見わかりにくいものを、ちゃんと作ったと証明する作業」で、そこに真面目に向き合った経験は、設計力や、AIに任せた結果を判断する力の土台になっています。少なくとも僕はそうでした。
これからSEを目指す人は、広告とかでみるキラキラした「コーヒー飲みながらまったりフルリモで高収入」のイメージじゃなく、「地道な作業を、工夫しながら楽にしていく仕事」くらいの期待値で入ると、現場とのギャップで折れにくいと思います。逆に、めんどくさい作業を前にして「もっとこうすればいいじゃん」と考え始められる人は、たぶんこの仕事に向いています。
自己紹介
現在、8年目になるエンジニア兼PMやってるやむぅ。です！普段はフリーランスエンジニアとして、8人の開発チームのPM（プロジェクトマネージャー）をしたり、AIゲームコーチングサービス『Repl-AI』などの「個人サービス運営」「個人的なエンジニアサポート」この三つを主軸に活動しています。
- エンジニア歴: 8年目（上流の設計から下流の実装・テストまで全部やってます）
- 得意な技術: Java, TypeScript, Next.js, Python, Go, Cursor, Claude code など
- 個人運営スクール: 個人開発や転職にコミットするプログラミングスクール「Programing Factory - ProFact」運営
- 個人開発したサービス運営: WebニュースのAI分析サービス／Twitchクリップの検索・シェアサイト／Meta社のThreads分析・投稿予約ツール／ゲームプレイのAIコーチングサービス
僕がやっているProFactでは、こういう現役経験から話せる「エンジニア業務のリアル」と、AIと一緒に開発する前提の実務スキルを、現役エンジニアと一緒に手を動かしながら学べます。気になった方はのぞいてみてください。
※副業、Web制作を目指している方はお力になれません…ご了承ください。