SEの仕事内容とは？具体的な1日のスケジュールから激務になる理由を解説

「SEって何をする人か知りたい」
「SEって一口に言うけど具体的にどんな役割があるんだろう」
「SEってどういう1日を送っていたんだろう」
「SEってよく激務って言われるけどなんでだろう」

SEに興味を持っている人はSEってどんな仕事なんだろと気になる人が多いと思います。個人的には、SEと一括りにしても、SEの役割って多様だなと思うことがあるかと思います。多くの人がSEという言葉で職種を一括りにしてしまいがちですが、実際にはその中には様々な職種があります。

システム導入のプロジェクト一つをとってもSEの役割は多岐に渡っていてそれらの役割の違いを知ることは大切だと思います。

SEの仕事は激務であると言われることが多いですが、私なりの観点でその理由を考えてみました。私のSE時代の１日のスケジュールを紹介するとともに、元SEで今はITコンサルして働く立場から、SEが直面している激務の背景について深掘りし、実際にどんな要因がそれを引き起こしているのかを紹介します。

この記事では、SEの仕事内容と私がSE時代にあるチームのチームリーダとしてPJに参画していた際の1日のタイムスケジュールをお伝えし、SEがなぜ激務になるのか、その具体的な理由と、プロジェクトの進行における難しさについて解説していきます。これからSEを目指す方や転職を考えている方にとって、SEの役割や業務の特徴を理解する一助になれば幸いです。

ちなみに、私がSEを辞めた理由は以下記事にまとめていますので、もし興味があれば覗いてみてください。

SEの仕事内容

まず最初にSEの仕事内容について紹介します。

SEと言っても様々な役割がある

「SE」と一言で言っても、その中には実に多くの職種が存在します。例えば、プロジェクトをリードする「プロジェクトマネージャー」や、ソフトウェアを設計する「ソフトウェアエンジニア」、オフショア開発で重要な役割を担う「ブリッジSE」、実際にプログラムを書く「プログラマー」、インフラの設計や管理を担当する「インフラエンジニア」など、職種ごとに求められるスキルや役割が異なります。

これらの職種ごとに専門的な知識や経験が必要であり、システム導入のプロジェクトにおいては、それぞれの職種が密接に連携して仕事を進めていきます。そのため、自分がSEとして働く中でそれぞれの役割でどんなスキルが必要なのかを理解することは、将来のキャリアを決める上で非常に重要です。

---

システム導入は複雑

システム導入プロジェクトは、単なるプログラミングや設計だけでなく、多くのステークホルダーとの調整や、複雑な問題解決が伴います。また、導入するシステムはパッケージなのか、クラウドなのか、業務領域はどこなのか・・・様々な種類がある中でそれらすべてを一人で賄うのは不可能です。

そのプロジェクトに応じた、プロフェッショナルのスキルを持つ役割が求められます。それにより、必要な能力が大きく異なります。プロジェクトがどれだけ複雑かによって、その中でどのような役割を担うかが決まるため、職種ごとの理解が欠かせません。

---

具体的な職種5選

それでは、SEにおける主な職種について具体的に紹介し、それぞれの職種がどのような役割を担っているのか、必要なスキルについて詳しく解説します。以下体制図の赤字部分を紹介します。

プロジェクトマネージャー（PM）

プロジェクトマネージャーは、プロジェクトの責任者として全体の進行を管理します。主な仕事は、顧客との進捗報告や問題解決、スケジュールの調整、リスクヘッジなどです。その責任はプロジェクトの中で最も大きいと言っても過言ではなく、特に顧客との折衝やチームのマネジメントを担うため、高いコミュニケーション能力と判断力が求められます。

• 必要なスキル：プロジェクト管理の知識、リーダーシップ、コミュニケーション能力、問題解決能力
• 大変な点：顧客からの期待が高く、常にプレッシャーがかかる。スケジュールやリソースの調整は難易度が高く、責任が重い。

ソフトウェアエンジニア

ソフトウェアエンジニアは、顧客と仕様を詰めた後、その要件を基にソフトウェアを設計します。具体的には、システムの設計や実装に関わり、要件定義や設計書の作成を行います。ソフトウェアに関する深い知識と、システム全体の理解が求められる重要な役割です。ITコンサルが要件定義から一気通貫で設計まで実施する場合もありますし、SEが設計を実施する場合もあります。

• 必要なスキル：各ソフトウェアの知識、システム設計の知識、顧客業務に関する知識
• 大変な点：顧客の業務理解が必要で、それを仕様に落とし込むのが難しい

ブリッジSE

ブリッジSEは、オフショア開発において重要な役割を果たします。日本で決めた設計を現地のプログラマーに伝える役割です。クライアントの要件や仕様を正確に現地の言語に翻訳し、現地チームに伝える必要があります。このため、現地の言語の理解と、IT知識を併せ持つことが求められます。

• 必要なスキル：言語スキル、ITに関する知識、コミュニケーション能力
• 大変な点：言葉の壁がある中で、正確に情報を伝えることが求められる

プログラマー

プログラマーは、ソフトウェアエンジニアが設計した通りに、実際にコードを作成する役割です。要件を元にした実装がメインであり、プログラミングスキルが求められます。プログラムを書くことが主な仕事であり、設計やテストの業務にも関わることがあります。

• 必要なスキル：プログラミングスキル、アルゴリズムの理解
• 大変な点：納期に追われることが多く、うまくいかないとプレッシャーを感じることがある

インフラエンジニア

インフラエンジニアは、システムを支えるインフラの構築と運用を担当します。顧客が求める仕様に基づいて、サーバーやネットワークの構築を行い、システムが安定して稼働するための環境を整えます。また特に昨今であればセキュリティ面が非常に重要になってきており、需要が高まっています。

• 必要なスキル：ネットワークやサーバーの知識、セキュリティ関連の知識
• 大変な点：システム全体の安定性を守るため、予期しない障害対応やトラブルシューティングが頻繁に発生する。

1日のスケジュール

次に１日のスケジュールを紹介します。前述のPMに近い役割を担っていた際の私のとある日のスケジュールとなります。

SEの時はチームリーダとしての活動が多かった

細かい1日のスケジュールの紹介に入る前に、私がSEの時に担っていた主な役割について紹介します。私がSEの時、主な役割はチームリーダーでした。PMとチーム(下請けベンダー)との橋渡し役として、チーム側のリーダとしてプロジェクトに参画していました。

具体的には、下請けベンダーの進捗管理、作成物のレビュー、顧客への進捗報告など、プロジェクトを進めるために必要な管理業務を行いました。また、各チームの平仄を合わせる横並びでの管理業務もありました。

具体的な私の1日のスケジュール

次に、私がSE時代に実際に過ごしていた1日のスケジュールを具体的に紹介します。打ち合わせや資料作成、進捗管理といったチームリーダーの一般的な役割をこなしている1日かと思います。

SEが激務な理由

SEの激務は、システム導入プロジェクトの難しさに起因していると考えています。要件定義工程では顧客がまだプロジェクトは何ぞやの段階でうまく顧客を巻き込んで要件を決めた行かなければならなかったり、ステークホルダーが多いためその間の調整が必要だったりプロジェクトを進めるうえで複雑なタスクが多いです。

また、SEは下請けベンダーに要件定義から開発までを実施してもらうので、そういった体制づくりやコミュニケーションも必要になってきます。基幹システムのような大規模プロジェクトになればなるほど難易度が上がります。

顧客側の意識改革が必要

システム導入プロジェクトでは、顧客側がシステムに対して十分な理解や経験がない場合が多いです。特に、ITシステムを導入するためには、業務運用の変更に対する覚悟が必要で、それを顧客側でトップダウンでの意識改革をしてもらう必要があります。

しかし、実際には多くの顧客側業務部門が、単なるシステム変更として捉えており、システム導入にともなって業務変更が必要になることの重大さを理解していません。結果として、要件定義の工程からいきなり炎上するのです。システムが変わることで顧客の業務に手間がかかるようになる可能性も理解しておかないとプロジェクトがうまく進みません。

難しい点

次に、SEが抱える難しいポイントについて見ていきましょう。

要件定義で要件を出し切れない

システム導入の最初の工程である要件定義は、プロジェクトの成否を決める重要な部分です。先ほども少しお伝えしましたが、顧客業務部門がシステム導入のプロジェクトに慣れておらず、顧客の現場メンバーはシステム変更の内容に対してイメージが湧いていないことが多いため、顧客と対話する中で、要件が十分に出し切れないことがよくあります。

また、予算や時間の制約があるため、スケジュール通りに要件定義を進めることが求められますが、早急に決めなければならない項目も多く、結果として要件が不完全なまま進んでしまうケースが増えます。これはSEの負担を増やし、さらにプロジェクト後半で大きな問題を引き起こす原因となります。

顧客の現場側が業務変更の覚悟ができていない

新システムを導入することにより、現行業務からの変更が避けられません。しかし、顧客側の現場では、業務変更の覚悟ができていない場合が多いです。要件定義を進めていても、「今まで通りにできればよい」というコメントが多く、システム導入のプロジェクトを理解していないことが多いです。

またその現行業務を具体的に示す必要がありますが、それもできないことが多いです。特にシステムの導入目的が業務改善や経営改善である場合、業務フローの変更が不可避であるにもかかわらず、現場がその変更を受け入れられず、要件定義において問題が生じることが多いのです。

ステークホルダーが多く、利害が複雑

システム導入プロジェクトでは、多くのステークホルダーが関与します。顧客内でもIT部門や業務部門、経営層といった立場の人が関与し、ベンダー側でもSEや営業、経営層、下請けベンダーといった多くの関係者が協力してプロジェクトを進める必要があります。

他にも、コンサルが顧客側でプロジェクト管理をしていたり、他のシステム導入ベンダーがいたりと、とにかくステークホルダーが多いです。そのため、これらのステークホルダー間で意見が一致しない場合が多く、プロジェクトの進行が遅れやすいのがシステム導入プロジェクトの特徴です。

ベンダー側が多重下請け構造

SIerのビジネスモデルは、SEが案件を受注した後（一次請けした後）、実際のシステム構築作業を下請けベンダーに発注することになります。（二次請け）その二次請けのベンダーが基本的にはシステム構築の作業をしますが、それをさらに子会社やフリーランスに発注している場合があり、三次請けになることもあります。こうして多重下請けが発生していきます。

この場合、SEから見ると、スキルセットや品質の管理が難しくなり、リスクが増加します。これにより、SEは人員の管理やコミュニケーションの管理等でもタスクが増えてしまいます。SEの負荷が高くなり、プロジェクトが遅れるリスクも高まります。

見積もりが甘くなりがち

システム導入プロジェクトでは、要件定義後のような初期段階で見積もりを行いますが、これが甘くなってしまうことがあります。顧客に予算を確保してもらう目的なのですが、まだ要件定義後だと決まっていないこともあり、見積もりが難しいことが多いです。

特に顧客からのコスト削減のプレッシャーが強いと、SEはプロジェクト予算を切り詰めた見積もりを提示してしまいがちです。実際には難しいスケジュールやリソースで進めることになってしまい、後から追加のコストやスケジュール遅れいった問題が起こり、SEの顧客との交渉の負荷になります。

SEあるある

最後にSEあるあるを紹介したいと思います。

ITコンサルに転職してSE時代の働き方を振り返ると、SEとして働く中でもSE特有の「あるある」がたくさんありました。ITコンサルともまた違った働き方になるので、SEがどういう仕事の仕方をしていたのか、SEとはどういう仕事なのかを面白おかしく見ていただければと思います。

---

SEの仕事は特徴的

SEは、システム導入を行う中で様々なタスクをこなすことが求められます。その役割には、もちろんITの技術的な設計開発といった面もありますが、大手SIerの場合はそれよりも、プロジェクトの進捗管理やクライアントとの調整などの非技術的な面が多かったです。

特に大規模なシステム開発プロジェクトに関わると、進捗管理やリソース調整といった仕事が増え、また社内向けの報告や契約ごとの作業が増え、もはやプロジェクトにほとんど携わっていないのではないかとも感じる時があります。もちろんSEの仕事は多岐に渡りますが、その中でも特に目立つ「あるある」なシチュエーションをいくつか挙げてみます。

---

SEあるある５選

若手から見積もりがうまくなりがち

SEとして働く中で、最初は手を動かすような技術的なタスクを進めることが多いですが、少し年次が上がるに連れて、下請けベンダーの作業見積もりを任されることが増えます。見積もりをするときは、必要なリソースや作業量を予測し、期間を算出する必要があります。

そのため、年次が進むごとに、見積もり作業が得意になり、精度も上がっていきます。しかし、この見積もり業務は、重要ですが、本質的なSE業務とは言えません。そういった小手先のような見積もりや予算の管理をしている時間が長くなり、技術的な作業に専念する時間が少なくなっていくのです。

社内フェーズゲート対応だけしがち

特に大規模プロジェクトのようなリスクの高いプロジェクトを担当していると、プロジェクトの進捗をチェックするフェーズゲートのような社内のプロセスに関わることがあります。このプロセスは、内部報告向けとして進捗やリスクを管理するために重要なのはわかるのですが、プロジェクトを進めるうえでの負担にしかなりません。

本来、SEとしてはシステム開発や導入、テストといったプロジェクト作業に専念すべきなのですが、社内の進捗管理やドキュメント作成に多くの時間を割くことになり、実際のシステムに関する作業から遠ざかることが多くなるのです。この状況を長く続けることが、SEにとっては大きなストレスとなり、やりがいを感じにくくなる原因の一つです。

下請けベンダーと仲良くなりがち

SEは多くのプロジェクトで下請けベンダーとともにチームを組むことになります。この時、チームリーダーとしてベンダーとの関係を築いていくことが重要です。ベンダーとの連携は、プロジェクトの進行を円滑にするためには欠かせない要素です。

密にコミュニケーションを取ってプロジェクトを進めていくため、自然と仲良くなることが多いです。共に仕事をしながら喜怒哀楽を共有し、たまに飲み会で愚痴などを言い合うことで良好な関係性が築かれていきます。

定時で帰ることに遠慮しがち

SEは、コミュニケーションがとても重要な仕事になるので、昼間は打ち合わせが多いため、定時後に自分の作業をすることが習慣となります。仕事の中で自分の担当作業に集中できる時間が取れない場合、定時後に集中して作業することに慣れ、むしろその時間を有効に使おうとするようになります。

そのため、定時で帰れることが珍しく、帰れそうになったら何か作業を忘れていないかそわそわしてしまいます。

30歳前後で転職を悩みがち

SEとしてキャリアを積む中で、特に30歳前後になると、自分の将来について悩むことが多くなります。ある程度のスキルや経験を積み重ねてきた後、「このままこの仕事を続けるキャリアで本当に良いのか？」という疑問が湧いてきます。

特に、マネジメント業務や進捗管理など、より事務的な仕事が増えてくると、「このままで良いのだろうか？」という疑問が大きくなります。このタイミングで転職を考える人が多いのは、キャリアパスが見えてきたからこそ、将

---

まとめ

SEが激務になる理由は、システム導入プロジェクトの複雑さに起因しているということを私の考えから紹介しました。SEへの転職やSEでのキャリアを続けることを検討している方への参考になれば幸いです。