「SEって、1日中コードを書いているの？」とよく聞かれます。SIer（システムインテグレーター）でSEとして10年働いてきた実感でいうと、答えは「いいえ」です。コードを書く時期もありますが、時間の多くは、何を作るかを決め、決めたことを文書にし、関係者と合意し、確かめることに使っています。

この記事では、SIerの仕事の全体像、工程によって大きく変わる1日の過ごし方、10年で役割がどう変わったか、そして失敗から学んだことを、できるだけ具体的に書きます。

書いている人：SE歴10年。テスト・製造（プログラミング）から始まり、設計、要件定義・顧客との調整、チームリーダー（PL）を経験。インフラ・AWS、移行切替・構成管理・リリース、新規の提案活動、最近はAI駆動開発にも関わっています。

※ 働き方は会社・プロジェクトによって大きく違います。ここに書くのは私の経験と、その中で見てきた一般的な進め方です。案件が特定されないよう、細部はぼかしています。

SIerの仕事の全体像：工程で考える

SIerの仕事は、多くの場合「工程」で区切られて進みます。代表的なのが、作る工程とテストする工程を左右に対応させた V字モデルです。

工程 主な成果物 対応するテスト
要件定義 要件定義書 受入テスト
基本設計 画面・データなどの設計書 システムテスト
詳細設計 処理の流れ・部品の設計書 結合テスト
製造 ソースコード 単体テスト

左の工程で作ったものを、右のテストで確かめる、という対応になっています。たとえば受入テストでは「顧客が求めたものになっているか」を、単体テストでは「部品が設計どおりに動くか」を確かめます。表の上のほう（要件定義・基本設計）を上流工程、下のほう（製造・テスト）を下流工程と呼ぶこともあります。

そのあとに、移行・リリース（本番環境への切り替え）と運用・保守が続きます。

ここで大事なのは、要件定義で「非機能要件」を決めることです。機能要件が「何ができるか」なのに対し、非機能要件は「どれくらい速く、止まらず、安全に動くか」です。性能（応答時間、同時に使う人数）、可用性（止めてよい時間）、セキュリティ、運用（バックアップ、監視）などが含まれます。未経験の方が見落としがちですが、クラウド（AWSなど）の構成は、この非機能要件でほぼ決まります。

工程によって、1日はこんなに変わる

「SEの1日」は、どの工程にいるかでまったく別物になります。私の場合の典型的な3パターンです。在宅と出社はおよそ半々です。

設計の時期

時刻 やること
10:00 始業。メールとチャットを確認し、今日の優先順位を決める
10:30 チームの朝会。進み具合と、止まっていること（課題）を共有
11:00 設計書を書く。打ち合わせが入りにくい午前中に集中して進める
13:30 顧客や他チームとの仕様確認。決まったことと未決のことを整理する
15:30 技術調査・検証。AWSのサービスの制約や、実際の動きを手を動かして確かめる
17:30 打ち合わせの結果を設計書と課題管理表に反映し、翌日の準備
19:00 終業

テストの時期

設計の時期と比べて、「見つかった不具合をさばく」仕事が中心になります。朝に前日のテスト結果と不具合の件数を確認し、原因の切り分け、修正の優先順位づけ、修正後の再テストの依頼を繰り返します。不具合の数が予定より多いと、スケジュールの見直しや顧客への説明も必要になります。

移行・リリースの時期

本番環境への切り替えは、業務への影響が少ない夜間や休日に行うことが多く、生活リズムが一番崩れる時期です。前日までに手順書のレビューとリハーサルを終え、当日は手順書どおりに作業を進めます。詳しくは後半で書きます。

所属によっても働き方は違う

同じ「SE」でも、どんな会社に所属するかで働き方は変わります。一般的な違いは次のとおりです。

所属 特徴 働き方のイメージ
SIer 顧客のシステムを受託して作る 工程に沿って進め、文書と調整が多い
自社開発 自社のサービスを作り続ける 改善を小さく速く繰り返す
SES 客先に常駐して技術を提供する 常駐先のやり方に合わせて働く

この記事は、私が経験してきたSIerの働き方をもとに書いています。

残業や忙しさは「時期」で決まる

SEは「残業が多い」と言われがちですが、私の実感では、忙しさは時期でほぼ決まります。設計の時期や、プロジェクトが落ち着いている時期は、定時前後で終わる日も多いです。一方で、テストの後半で不具合が多いとき、リリースや移行の前後、障害が起きたときは、どうしても作業が集中します。

「ずっと忙しい」わけではなく「忙しさに波がある」と理解しておくと、入ってからのギャップは小さくなると思います。

10年で役割はこう変わった

振り返ると、年次とともに「見ている範囲」が広がってきました。

段階 主な役割 見ていたもの
最初の数年 テスト、製造 自分に割り当てられた作業を、正しく終わらせること
中堅 基本設計・詳細設計 自分の担当範囲の品質。後工程の人が困らない設計書
リーダー（PL） チームのまとめ、進捗・品質管理 チーム全体の進み具合と品質。遅れやリスクを早めに見つけること
上流・横断 要件定義、顧客との調整、インフラ・AWS、移行・リリース、提案 顧客の業務と目的。そもそも何を作るべきか、どう安全に届けるか

大きく変わったのは、「言われたことを正しくやる」から「やるべきことを決める」側に移ったことです。若手のうちは、設計書に書いてあることを正確に作り、正確に試すことが一番の価値です。上流に行くほど、設計書そのものを作る立場になり、「書いていないこと」の責任も負います。

きつい場面を分解する：失敗から学んだこと

「SEはきつい」とよく言われます。私が経験した苦労を3つに分けて、何が起き、なぜ起き、今どう防いでいるかを書きます。

1. 仕様の認識ちがい

何が起きるか：いわゆる「手戻り」です。こちらは「Aのつもり」で作り、顧客は「Bのつもり」だった、ということが、テストや受入の段階になって発覚します。後工程で見つかるほど、作り直しの量は大きくなります。

なぜ起きるか：言葉だけで合意していることが多いからです。「一覧で表示する」「すぐ反映する」といった表現は、人によって思い浮かべるものが違います。

今やっていること

  • 文章だけでなく、画面イメージや具体的なデータの例で確認する
  • 打ち合わせの最後に「決まったこと」「決まっていないこと」「誰がいつまでに決めるか」を読み上げ、議事録に残す
  • 「すぐ」「たくさん」のような言葉は、数字（何秒以内、何件まで）に置き換えて合意する

2. 見積もりの甘さ

何が起きるか：作業量を小さく見積もってしまい、後半で残業や休日作業が増え、納期が厳しくなります。

なぜ起きるか：「作る作業」だけを数えて、打ち合わせ、レビュー、手戻り、テストデータの準備、環境の準備といった周辺の作業を見落としがちだからです。

今やっていること

  • 作業を細かく分解（WBS）し、1つあたり数日以内の単位になるまで分ける
  • 見積もりには、前提条件（「〇〇は顧客側で用意する」など）を必ず書く。前提が崩れたら見積もりを見直す根拠になる
  • 過去の実績と比べて、ずれが大きい部分を疑う

3. 本番作業・障害対応

何が起きるか：本番環境の作業で想定外のことが起きたり、稼働中のシステムで障害が発生したりします。予定はすべて崩れ、夜間や休日の対応になることもあります。

なぜ起きるか：本番環境は、テスト環境とデータ量、設定、周辺システムとのつながりが微妙に違います。どれだけ準備しても、ゼロにはなりません。

今やっていること

  • 手順書は「誰が読んでも同じ操作になる」粒度で書き、第三者にレビューしてもらう
  • 本番と近い環境でリハーサルをする
  • 切り戻し手順（元に戻す手順）と、「どの時点で何が起きたら戻すか」という判断基準を事前に決めておく
  • 障害が起きたら、原因究明より先に影響範囲の確認と暫定対応（まず止血）。そのうえで関係者へ報告し、落ち着いてから恒久対策と再発防止策を決める

移行・リリースの裏側

本番への切り替えは、SEの仕事の中でも特に緊張する場面です。一般的には、次のような流れで進みます。

  1. 事前準備：移行手順書と切り戻し手順書の作成・レビュー、リハーサル、関係者との役割分担・連絡体制の確認
  2. 当日の作業：業務の停止 → データの移行 → 設定の切り替え → 動作確認
  3. 判定：あらかじめ決めた基準で、切り替えてよいか（Go / No-Go）を判断する。No-Go なら切り戻す
  4. 業務開始後の監視：切り替え後しばらくは、エラーや性能を重点的に監視する

「うまくいった切り替えは、何も起きないので誰にも気づかれない」のが、この仕事の面白いところでもあります。

AI駆動開発で、仕事はどう変わりつつあるか

最近は、生成AIを使った開発にも関わっています。実感として、次のような作業はAIでかなり速くなりました。

  • 設計書や手順書のたたき台の作成
  • コードの作成・レビューの補助、テストケースの洗い出し
  • 調査の初動（知らない技術の概要をつかむ）

一方で、何を作るべきかを顧客と合意すること、出てきたものが正しいかを判断すること、本番で問題が起きたときに責任を持つことは、今のところ人の仕事のままです。これから学ぶ方にとっては、「AIに作らせたものを判断できる基礎力」の価値がむしろ上がっていると感じます。

それでも続けている理由：やりがい

  • リリースが無事に終わったとき：何か月も準備したシステムが本番で問題なく動き始めたときの達成感は、ほかではなかなか味わえません。
  • 頼られたとき：「この件はあの人に聞けば分かる」と声をかけてもらえることが増えました。積み上げてきたものが、誰かの役に立っていると実感できます。

SEに向いている人

10年働いてきて、この仕事で長く活躍している人に共通していると感じる特徴です。

  • 分からないことを調べるのが苦にならない
  • 人の話を聞き、意見の違いを整理できる
  • 地道な確認（テスト、レビュー、手順のチェック）を面倒がらない
  • 技術や仕事のやり方が変わることを、楽しめる

最初からすべてそろっている必要はありません。私自身、調整や段取りの力は、現場で失敗しながら身につけてきました。

未経験からSEを目指す方へ

この記事の内容から、未経験の方が意識しておくとよいことを3つ挙げます。

  1. 調べる力：10年やっていても、知らないことは毎日出てきます。大事なのは、分からないことを自分で調べ、試して、確かめられることです。
  2. 文章で伝える力：設計書、議事録、手順書、チャット。SEの成果物の多くは文章です。「誰が読んでも同じ意味になる」文章を書く練習は、プログラミングと同じくらい役に立ちます。
  3. 段取りする力：作業を分解し、前提と期限を明らかにする力は、見積もりにも本番作業にも直結します。

まとめ

  • SIerのSEの仕事は、工程（要件定義〜運用）で大きく変わる。コードを書く時間は一部
  • 1日の過ごし方も、設計・テスト・移行の時期でまったく違う
  • 年次とともに「言われたことを正しくやる」から「やるべきことを決める」側に移る
  • きつさの多くは、仕様の認識ちがい・見積もり・本番作業から来る。それぞれに防ぎ方がある
  • AIで速くなる作業は増えたが、判断と合意と責任は人に残る