SESインフラエンジニアでも上流工程へ行ける？設計・要件定義に進む方法を解説

「このままずっと運用監視だけなのかな…」

SESのインフラエンジニアとして働いていると、こんな不安を感じる瞬間がありますよね。

実際、SES業界では監視・運用案件が多く「上流工程は一部の人しか行けない」という空気もあります。

私自身もSES3年目までは、夜勤ありの監視業務や定型オペレーションが中心でした。

ただ、結論から言うと、SESでも上流工程へ進むことは十分可能です。

実際に私は、運用監視→構築→AWS案件→設計レビュー参加という流れで、徐々に要件定義や基本設計に関わるようになりました。

この記事では、

SESインフラエンジニアが上流工程へ行けないと言われる理由
実際に上流工程へ進める人の特徴
現場で評価されるスキル
私が実際にキャリアアップした流れ
上流へ進みやすい案件の選び方

を、実体験ベースでリアルに解説します。

「自分も設計や要件定義に進みたい」と考えている人は、ぜひ参考にしてください。

SESインフラエンジニアは上流工程へ行けないと言われる理由

運用監視案件が多い

SES業界では、未経験〜経験浅め向けとして運用監視案件が多い傾向があります。

特に多いのが以下です。

アラート監視
障害一次対応
手順書ベースのオペレーション
定型バックアップ
ログ確認

もちろん、運用監視そのものが簡単というわけではありません。

金融系や大規模システムの運用では、高度な障害解析や運用設計スキルが求められる現場もあります。

ただ、SESでは「定型運用のみ」を担当する案件も一定数あり、その場合は設計経験を積みにくいのが現実です。

私も最初の現場では、毎日Zabbixのアラート確認と定型作業が中心でした。

半年ほど経った頃、「このままだと市場価値が上がらないかもしれない」とかなり焦ったのを覚えています。

客先常駐で役割が固定されやすい

SESは客先常駐が基本のため、一度役割が固定されると変わりにくいです。

例えば、

状況	よくあるケース
運用担当として参画	ずっと運用だけ任される
手順対応が得意	自動的にオペレーション担当になる
コミュ力低め	顧客会議に呼ばれない

現場によっては「設計担当」と「運用担当」が完全に分かれています。

そのため、自分から動かないと上流経験はなかなか積めません。

設計経験を積みにくい

上流工程では、以下のような経験が求められます。

要件整理
構成検討
設計書作成
顧客説明
レビュー対応

しかし運用監視だけでは、これらに触れる機会がほぼありません。

実際、案件面談でも「設計経験ありますか？」はかなり聞かれます。

逆に言うと、少しでも設計に触れた経験があると評価されやすいです。

そもそもインフラエンジニアの上流工程とは？

要件定義

要件定義は、「何を作るか」を決める工程です。

例えばAWS案件なら、

可用性はどれくらい必要か
同時接続数は？
セキュリティ要件は？
監視はどうするか
バックアップは必要か

などを顧客と整理します。

ここでは技術力だけでなく、会話力や整理力も重要です。

基本設計

基本設計では、ネットワーク全体の構成を決めます。

具体例：

VPC構成
サブネット分割
冗長化構成
LB配置
監視設計
IAM設計

ここで設計ミスをすると、後工程に大きな影響が出ます。

詳細設計

詳細設計は、構築担当が実装できるレベルまで落とし込む工程です。

例えば、

パラメータシート
Security Groupルール
OS設定値
バックアップ設定
監視項目

などを具体化します。

構築・運用との違い

違いを簡単にまとめると以下です。

工程	主な内容
要件定義	何を作るか決める
基本設計	全体構成を決める
詳細設計	実装レベルまで具体化
構築	実際に環境を作る
運用	維持・監視する

上流工程へ行くには、まず「構築経験」がかなり重要になります。

SESでも上流工程へ進める人の特徴

構築経験を持っている

運用だけより、構築経験がある人は圧倒的に強いです。

なぜなら設計担当は「実際に構築できる現実的な設計」を求められるからです。

例えば、

Linuxサーバ構築
AWS環境構築
NW設定
ミドルウェア導入

を経験している人は、設計時の解像度が高いです。

顧客折衝を避けない

意外と重要なのがこれです。

現場では、

会議参加
課題整理
顧客説明
レビュー対応

を嫌がらない人が上流へ上がりやすいです。

私も最初は会議が苦手でした。

ただ、議事録作成やQA対応を積極的にやったことで、徐々に設計レビューへ呼ばれるようになりました。

設計書を読める

設計書を読める人は強いです。

おすすめは、現場で以下を読むこと。

基本設計書
パラメータシート
NW構成図
IAM設計
運用設計書

最初は意味不明でも大丈夫です。

私も最初はCIDR設計を理解できず、初めて参加した設計レビューではほとんど発言できませんでした。

会議後にVPC設計図を見返しながら、サブネット分割やルーティングを1つずつ調べたのを覚えています。

ただ、毎日少しずつ読むだけで理解は変わります。

クラウド知識がある

最近はAWSやAzure案件がかなり増えています。

実際、転職サイトやSES案件でもクラウド移行案件が増えており、オンプレのみよりクラウド経験者の需要が高くなっています。

特に以下は評価されやすいです。

AWS
Azure
Terraform
Docker
Kubernetes

オンプレだけより、市場価値がかなり高くなります。

上流工程へ行くために必要なスキル

Linux

最低限必要です。

特に重要なのは、

systemd
ログ調査
権限管理
ネットワーク確認
シェル

など。

「障害時に自走できる人」はかなり評価されます。

ネットワーク

インフラ上流ではNW理解が必須です。

特に重要：

TCP/IP
ルーティング
DNS
FW
LB

運用経験だけだと弱い部分なので、CCNAレベルは勉強しておくと強いです。

CCNAレベルの学習をすると、TCP/IPやルーティング、FWなどインフラ設計で必要になる基礎知識を体系的に理解しやすくなります。

クラウド（AWS/Azure）

今はクラウド経験があるだけで案件の幅が広がります。

おすすめはAWSです。

理由：

SES案件数が多い
設計案件も豊富
学習教材が多い

まずは以下からでOK。

EC2
VPC
IAM
RDS
CloudWatch

設計書作成スキル

設計書を読める人は強いです。

おすすめは、現場で以下を読むこと。

基本設計書
パラメータシート
NW構成図
IAM設計
運用設計書

最初は意味不明でも大丈夫です。

私も最初は「CIDR設計って何？」というレベルでした。

ただ、毎日少しずつ読むだけで理解が変わります。

コミュニケーション能力

ここで言うコミュ力は、雑談力ではありません。

重要なのは、

相手に分かりやすく説明できる
課題を整理できる
認識合わせができる

です。

上流ほど、この能力が重要になります。

実際に私が上流工程へ進んだ方法

私はSES3年目までは、典型的な運用監視エンジニアでした。

最初の現場は24/365監視。
夜勤もあり、毎日ほぼ同じ作業。

正直、「5年後もこれをやるのか…」とかなり不安でした。

転機になったのは、運用改善を自主的にやったことです。

具体的には、

手順書改善
Shell自動化
アラート整理
AWS監視改善提案

を少しずつ実施しました。

すると、構築チームのリーダーから声がかかり、検証環境構築を手伝うことになりました。

そこから、

Linux構築
AWS構築
Terraform導入補助
設計書レビュー参加

という流れで徐々に上流へ近づきました。

AWS移行案件では、EC2・RDS・ALBを使った30台規模の環境構築に参加しました。

最初はSecurity Group設計レビューで指摘ばかり受けました。

「このポート開放、本当に必要？」と聞かれて答えられず、かなり悔しかったです。

ただ、その経験から、

通信要件
最小権限
運用導線
障害対応

を意識するようになりました。

案件面談で特に評価されたのは、

「運用を理解している」
「改善提案経験がある」
「設計レビュー経験あり」
「顧客説明経験あり」

の4つでした。

特に運用経験は、設計時にかなり活きます。

例えば監視設計では、「どのログを残すべきか」「障害時にどこを確認するか」を運用経験ベースで考えられるようになります。

「運用しやすい構成」を考えられるのは、現場経験者の強みです。

SESで上流工程を目指すなら案件選びが重要

避けるべき案件

以下は注意です。

完全監視専任
手順実行のみ
技術者が成長しない現場
AWSに触れられない
ドキュメント文化がない

3年以上いると、キャリアが固定化しやすいです。

成長しやすい案件

おすすめは以下。

案件	理由
構築含む運用	上流へ繋がりやすい
AWS移行案件	設計経験を積みやすい
小規模SI案件	幅広く経験できる
IaC案件	市場価値が高い

特に「構築もやらせてもらえる運用案件」は狙い目です。

面談で確認すべきこと

案件面談では、必ず以下を聞きましょう。

構築作業はあるか
設計書を見る機会はあるか
AWS利用有無
レビュー参加可能か
会議参加可能か

ここを聞かないと、また監視専任になる可能性があります。

上流工程へ行きやすい転職先

SIer

上流案件が多いです。

特に、

基本設計
顧客折衝
提案

を経験しやすいです。

ただし、調整業務も増えます。

事業会社

自社サービス運営のため、改善提案しやすいです。

運用→設計まで一気通貫で関われる会社もあります。

クラウドインテグレーター

最近かなりおすすめです。

AWS/Azure案件が多く、

クラウド設計
IaC
モダン構成

を経験しやすいです。

市場価値もかなり上がります。

SESインフラエンジニアでも上流工程へ行ける？まとめ

SESインフラエンジニアでも、上流工程へ進むことは十分可能です。

ただし、待っているだけでは厳しいのも事実です。

重要なのは、

構築経験を積む
設計書を読む
AWSを学ぶ
顧客折衝を避けない
案件選びを意識する

この積み重ねです。

私自身、監視業務しかしていなかった頃は「上流なんて無理だ」と思っていました。

ただ、運用改善や構築補助を少しずつ積み重ねた結果、徐々に設計レビューや顧客打ち合わせにも参加できるようになりました。

最初から要件定義ができたわけではありません。

CIDR設計を理解できずに会議で黙ってしまったこともありますし、Security Group設計で何度もレビュー指摘を受けました。

それでも、現場で経験した失敗は、後から確実に自分の武器になります。

特に運用経験がある人は強いです。

障害時に困るポイント
運用しづらい設計
監視漏れ
ログ不足
バックアップ運用

など、「実際に困る現場」を知っているからです。

一般的には要件定義や設計が“上流工程”と呼ばれますが、運用監視にも高度な知識が必要な現場はあります。

そのうえで、設計や要件定義へ進みたいなら、構築・レビュー・顧客対応へ少しずつ関わることが重要です。

SESだから無理、ではありません。

今の現場でできることを1つずつ増やしていけば、上流工程への道は確実に近づきます。

「運用監視しか経験がないから…」と諦める必要はありません。

小さな改善提案や構築補助の積み重ねが、将来のキャリアを大きく変えていきます。