SESで設計経験ができない人へ|上流工程に近づくための現状整理と転職戦略
SESで設計経験ができないと悩むエンジニア向けに、原因、放置リスク、今の現場でできる経験の棚卸し、設計経験を積める案件・転職先の見極め方、職務経歴書や面接での伝え方を整理します。
「SESに入って数年経つのに、テストや運用保守ばかりで設計経験ができない」「基本設計や要件定義に関わったことがなく、このまま市場価値が上がるのか不安」と感じていませんか。
SESで設計経験ができない悩みは、本人の努力不足だけで起きるものではありません。常駐先の体制、商流、任される役割、案件の切り出され方によって、下流工程に固定されやすい構造があります。
ただし、「設計経験がないから転職できない」と決めつける必要もありません。大切なのは、今の経験の中にある設計に近い要素を整理し、足りない経験をどう補うかを決めることです。
この記事では、SESで設計経験ができない原因、今のまま放置するリスク、上流工程に近づくための判断基準、職務経歴書や面接での伝え方を整理します。読み終えるころには、「今の現場で粘るべきか」「案件変更を相談すべきか」「転職を考えるべきか」を判断しやすくなるはずです。
SESで設計経験ができないと感じるのは、どんな状態か
まず整理したいのは、「設計経験ができない」という悩みの中身です。設計経験がないと感じていても、実際にはいくつかの段階に分かれます。
状態 | よくある業務 | キャリア上の課題 |
|---|---|---|
設計書を読むだけ | 詳細設計書を見て実装、テスト仕様書に沿って確認 | 設計の意図や判断理由を説明しにくい |
設計書の一部修正だけ | 既存設計書の項目追加、軽微な修正 | ゼロから設計した経験としては伝えにくい |
詳細設計はできる | 基本設計をもとに処理分岐、画面項目、DB更新内容を整理 | 基本設計や要件整理への接続が弱い |
設計レビューに関われる | 設計書の不備指摘、実装観点からの改善提案 | 実績として言語化できれば評価されやすい |
要件から設計に落とせる | 仕様確認、影響調査、設計方針の提案 | 上流工程経験として伝えやすい |
「設計経験がない」と一括りにせず、自分がどの段階にいるのかを切り分けることが最初の一歩です。
たとえば、設計書をゼロから作った経験はなくても、既存機能の影響調査、仕様の不明点確認、テスト観点からの設計不備の指摘をしているなら、設計に近い経験はあります。転職活動では、その経験を「作業」ではなく「判断」や「改善」として伝えられるかが重要です。
SESで設計経験を積みにくい主な原因
SESで設計経験ができない原因は、本人のスキルだけではありません。むしろ、現場構造によって設計に関われる範囲が決まってしまうことが多くあります。
商流が深く、任される範囲が限定されている
商流が深い案件では、顧客に近い会社や元請けが要件定義・基本設計を担当し、下位のSES企業には実装、テスト、運用保守だけが切り出されることがあります。
この場合、どれだけ真面目に働いても、そもそも設計工程が自分の担当範囲に含まれていません。努力の方向を間違えると、「頑張っているのに上流に行けない」という状態が続きます。
常駐先が教育よりも即戦力を求めている
常駐先は、自社社員ではなく外部人材としてSESエンジニアを受け入れています。そのため、長期的な育成よりも、今不足している作業を埋める役割を期待されることがあります。
受託開発やシステム開発の現場でも、設計を任せる相手には「仕様変更時に影響範囲を考えられるか」「関係者と認識を合わせられるか」が見られます。単に手が空いているから設計を任せる、というケースは多くありません。
つまり、設計に関わるには、技術力だけでなく、確認力、説明力、影響調査力も必要です。
会社側が案件希望を具体的に聞いていない
自社の営業や上司が、あなたのキャリア希望を具体的に把握していないケースもあります。
「上流をやりたい」とだけ伝えても、営業側には曖昧に聞こえることがあります。次のように、希望を工程や業務で具体化する必要があります。
- 詳細設計から担当できる案件に入りたい
- 基本設計書を読んで実装に落とす経験を積みたい
- 設計レビューに参加できる案件を希望したい
- 顧客との仕様確認に同席できる現場を希望したい
- 運用保守でも改善提案や影響調査に関われる案件がよい
設計経験を積みたいなら、「上流に行きたい」ではなく「どの設計作業に関わりたいか」まで言語化することが大切です。
もし今の悩みが「設計以前にスキルがつかない」という不安に近い場合は、SESでスキルがつかないと感じたときの選択肢もあわせて整理しておくと、自分に足りない経験を切り分けやすくなります。
設計経験ができないまま働き続けるリスク
設計経験がないままでも、すぐにキャリアが詰むわけではありません。テスト、保守、運用、実装にも重要な価値があります。ただし、将来的に開発エンジニアとして年収や役割を広げたいなら、放置にはリスクがあります。
指示待ちの実装者として見られやすくなる
転職市場では、経験年数が増えるほど「どのような判断をしてきたか」が見られます。
20代前半なら、指示通りに実装できることも評価されます。しかし経験年数が増えると、次のような点を問われやすくなります。
- 仕様の不明点をどう確認したか
- 設計書の矛盾にどう気づいたか
- 既存機能への影響をどう調べたか
- 保守しやすい実装にするために何を考えたか
- 障害や不具合を再発させないために何を改善したか
これらを説明できないと、実装経験があっても「指示された作業をこなしていただけ」と受け取られる可能性があります。
転職先の選択肢が狭くなりやすい
自社開発、社内SE、受託開発、SIerなど、次のキャリアを考えるとき、多くの職場では何らかの設計理解が求められます。
もちろん、すべての企業が要件定義経験を必須にしているわけではありません。しかし、画面設計、API設計、DB設計、バッチ処理設計、運用設計など、どこかの領域で「考えて作った経験」があると選択肢は広がります。
逆に、テスト実行や定型運用だけが長く続いている場合は、開発職へ戻るハードルが上がることがあります。
年収や評価が上がりにくくなる
SESで給料が上がりにくい背景には、単価、商流、評価制度など複数の要因があります。その中でも、設計や顧客折衝に関われない状態が続くと、単価交渉や昇給の材料を作りにくくなります。
「作業量が多い」「現場で頑張っている」だけでは、会社や顧客に対して評価材料として伝わりにくいからです。
市場価値を上げるには、作業時間ではなく、任された範囲・判断した内容・改善した結果を残す必要があります。
給料や評価への不満も強い場合は、設計経験だけでなく、SESで給料が上がらない原因と年収アップの考え方も確認しておくと、転職すべき理由が整理しやすくなります。
今の現場で設計に近づけるかを見極める判断基準
設計経験ができないと感じたとき、すぐに転職する前に、今の現場で経験を広げられる余地があるかを確認しましょう。
判断基準は、「設計書を書けるか」だけではありません。設計に必要な情報へアクセスできるか、設計者と会話できるか、改善提案が受け入れられるかを見ます。
確認ポイント | 残る価値がある状態 | 環境変更を考える状態 |
|---|---|---|
設計書へのアクセス | 基本設計書や詳細設計書を読める | テスト手順書や運用手順書しか見られない |
質問できる相手 | 設計者やリーダーに仕様確認できる | 質問しても背景を教えてもらえない |
担当範囲 | 影響調査や小規模改修を任される | 定型作業だけで変更の余地がない |
レビュー機会 | 設計書やコードのレビューに参加できる | 成果物を提出して終わりになっている |
案件変更の可能性 | 営業や上司が希望を聞いてくれる | 希望を伝えても案件都合だけで決まる |
現場で見ていると、設計経験を積める人は、最初から設計担当として入った人だけではありません。実装やテストの中で不明点を整理し、「この仕様だとこの画面にも影響します」「この項目はDB側の制約と矛盾しています」と言える人が、少しずつ設計レビューや影響調査に呼ばれることがあります。
一方で、どれだけ主体的に動いても、権限や情報が渡されない現場もあります。その場合は、本人の努力ではなく環境の問題として切り分ける必要があります。
今の現場で設計に近づけるかは、「頑張れば任されるか」ではなく「情報・会話・レビューの機会があるか」で判断しましょう。
設計経験がないSESエンジニアが今からできる整理方法
設計経験がない状態から市場価値を高めるには、まず今の業務を棚卸しする必要があります。何も整理しないまま転職活動を始めると、「テストをしていました」「運用保守をしていました」で終わってしまい、評価される経験が伝わりません。
担当業務を工程ではなく役割で書き出す
まず、これまでの業務を「テスト」「保守」「実装」といった工程名だけで整理しないようにしましょう。工程名だけでは、あなたが何を考え、どこまで担当したのかが伝わりません。
次の観点で書き出すと、設計に近い経験を見つけやすくなります。
- 仕様の不明点を確認した経験
- 既存機能への影響を調べた経験
- 設計書や手順書の誤りを見つけた経験
- テスト観点を追加した経験
- 障害原因を調査し、再発防止を提案した経験
- 運用手順を改善した経験
- 処理フローやデータの流れを整理した経験
これらは、基本設計そのものではなくても、設計者に必要な視点に近い経験です。
「なぜそうしたか」を言語化する
設計経験として評価されるかどうかは、作業名ではなく判断理由で変わります。
弱い伝え方 | 評価されやすい伝え方 |
|---|---|
テストを担当しました | 仕様変更に伴う影響範囲を確認し、既存機能の回帰テスト観点を追加しました |
バグ修正をしました | 不具合原因を調査し、入力チェックとDB制約の不整合を修正しました |
運用保守をしました | 問い合わせ内容を分類し、頻発する手順ミスを減らすために運用手順を見直しました |
設計書を修正しました | 実装内容と設計書の差分を確認し、後続メンバーが参照できるよう処理条件を追記しました |
設計未経験でも、「仕様を理解し、影響を考え、改善した経験」は職務経歴書で評価材料になります。
足りない経験を3つに分ける
次に、足りない経験を漠然と「上流経験がない」で終わらせず、次の3つに分けます。
- 設計書を読む経験が足りない
- 設計書を書く経験が足りない
- 要件や仕様を決める経験が足りない
設計書を読む経験が足りないなら、まずは基本設計書や詳細設計書を読める案件が必要です。設計書を書く経験が足りないなら、小規模改修の詳細設計や設計書修正から入るのが現実的です。要件や仕様を決める経験が足りないなら、顧客折衝や仕様調整に近いポジションを目指す必要があります。
この切り分けをせずに「自社開発に行けば解決する」と考えると、入社後にギャップが生まれることがあります。
設計経験を積むために今のSES会社で相談すべきこと
今の会社に残る可能性があるなら、まず案件変更や担当範囲の拡大を相談しましょう。ただし、相談の仕方が曖昧だと「タイミングが来たらね」で終わってしまいます。
営業や上司には希望条件を具体的に伝える
相談するときは、次のように具体的に伝えるのが効果的です。
現在の現場ではテストと運用保守が中心で、設計書を読んだり修正したりする機会が限られています。次の案件では、詳細設計、影響調査、小規模改修の設計書作成に関われる案件を希望しています。いきなり要件定義でなくてもよいので、設計レビューや仕様確認に参加できる環境を優先したいです。
このように伝えると、営業側も探す案件の条件を理解しやすくなります。
案件面談で確認すべきポイント
案件面談では、仕事内容を聞くだけでなく、設計に関われる余地があるかを確認しましょう。
- 担当工程はどこからどこまでか
- 詳細設計書の作成や修正は担当範囲に含まれるか
- 基本設計書をもとに実装する機会はあるか
- 仕様確認やレビューに参加できるか
- 既存システムの影響調査を担当することはあるか
- チーム内で設計内容を相談できる相手はいるか
注意したいのは、「上流案件」という言葉だけで判断しないことです。上流と書かれていても、実態は議事録作成、資料修正、進捗管理だけというケースもあります。それ自体に価値がないわけではありませんが、設計力を伸ばしたい人にとっては目的とずれる可能性があります。
「上流」という言葉ではなく、設計書・仕様確認・影響調査・レビューに関われるかを確認しましょう。
案件の運に振り回されている感覚が強い場合は、案件ガチャに振り回されない働き方を整理しておくと、会社に残るべきかどうかも考えやすくなります。
転職で設計経験を積みたい場合の転職先の選び方
今の会社で相談しても変わらない場合は、転職を選択肢に入れて構いません。ただし、「設計をやりたい」という理由だけで転職先を選ぶと、また同じような環境に入ってしまうことがあります。
自社開発は設計経験を積めるが、開発力も見られる
自社開発では、プロダクトを継続的に改善していくため、仕様検討や設計判断に関われる可能性があります。
一方で、設計だけをやりたい人よりも、実装、改善、運用まで含めてプロダクトに向き合える人が求められやすいです。SESで実装経験が浅い場合は、いきなり自社開発だけに絞ると選択肢が狭くなることがあります。
受託開発は設計に近づきやすいが、商流と担当範囲を見る
受託開発は、顧客から依頼を受けてシステムを作る働き方です。要件定義、基本設計、詳細設計、開発、テストまで一貫して関われる会社であれば、設計経験を積みやすい環境になります。
ただし、受託開発でも下請け中心の場合は、SESと同じように一部工程だけを担当することがあります。求人票では、直請け比率、担当工程、チーム体制、レビュー文化を確認しましょう。
SIerは上流に関われる可能性があるが、開発から離れすぎる場合もある
SIerでは、大規模システムの要件定義、基本設計、ベンダー調整などに関われる可能性があります。顧客折衝やプロジェクト管理に進みたい人には向いています。
一方で、会社や配属によっては、開発よりも調整、資料作成、進行管理が中心になることもあります。手を動かしながら設計力を伸ばしたい人は、開発工程にも関われるか確認が必要です。
社内SEは業務理解を深められるが、開発経験が積めるとは限らない
社内SEは、自社の業務システムやIT環境を支える仕事です。ユーザー部門との調整や業務改善に関われるため、要件整理の力は伸ばしやすいです。
ただし、開発は外部ベンダーに任せる会社もあります。設計書を書く経験や開発力を伸ばしたい場合は、内製開発の有無を確認しましょう。
転職先 | 向いている人 | 注意点 |
|---|---|---|
自社開発 | プロダクト改善、実装、運用まで関わりたい人 | 設計だけでなく開発力も求められやすい |
受託開発 | 顧客要望を設計に落とす経験を積みたい人 | 直請けか下請けかで経験範囲が変わる |
SIer | 大規模案件や顧客折衝に関わりたい人 | 調整中心になり、開発から離れる場合がある |
社内SE | 業務改善や社内ユーザーとの調整に関わりたい人 | 内製開発がないと設計・実装経験は積みにくい |
設計経験を積みたい転職では、会社の種類よりも「どの工程を、どの立場で担当できるか」を確認することが重要です。
転職先の違いをもう少し広く比較したい場合は、自社開発・社内SE・受託・SIer・フリーランスの違いを見ながら、自分に合う方向性を整理してみてください。
設計経験がない人が職務経歴書で意識すべき書き方
設計経験がないSESエンジニアほど、職務経歴書で「担当工程」だけを書いてしまいがちです。しかし、それでは自分の強みが伝わりません。
職務経歴書では、設計経験の有無をごまかすのではなく、設計に近い経験を具体的に書くことが大切です。
担当工程だけでなく、考えたことを書く
たとえば、次のように書き換えます。
避けたい書き方 | 改善した書き方 |
|---|---|
詳細設計書をもとに実装を担当 | 詳細設計書をもとに実装を担当。処理条件に不明点があったため、既存機能の挙動とDB項目を確認し、仕様確認後に実装方針を調整 |
テストを担当 | 結合テストを担当。仕様変更による影響範囲を洗い出し、既存機能の回帰テスト観点を追加 |
運用保守を担当 | 運用保守を担当。問い合わせ内容を分類し、頻発する障害の原因調査と手順改善を実施 |
このように、何を考えて動いたのかを書くことで、設計未経験でも「設計工程に進む素地がある」と伝えやすくなります。
守秘義務に配慮しながら成果を伝える
SESでは、顧客名やシステム詳細を職務経歴書に書けないことがあります。その場合でも、業界、システム種別、担当範囲、改善内容は抽象化して書けます。
- 金融系業務システムの保守開発
- 社内向け申請システムの機能改修
- 販売管理システムの結合テスト
- 既存バッチ処理の改修と影響調査
- 問い合わせ削減を目的とした運用手順の見直し
実務で評価されやすいのは、「大きな案件にいたこと」そのものではなく、その中で自分が何を理解し、どこに貢献したかです。
職務経歴書では、設計経験がないことを隠すより、設計に必要な思考をどこで使ったかを示しましょう。
面接で「設計経験がありません」と聞かれたときの伝え方
面接では、設計経験がないことを過度にネガティブに話す必要はありません。ただし、「現場が悪くて経験できませんでした」だけで終わると、受け身に見られます。
伝えるべき流れは、次の3つです。
- 現在の担当範囲を正直に説明する
- その中で設計に近い視点を持って取り組んだ経験を話す
- 今後どの設計経験を積みたいかを具体的に伝える
現職では、主に詳細設計書をもとにした実装と結合テストを担当しており、基本設計をゼロから作成した経験はまだありません。ただ、改修時には既存機能への影響調査や、設計書と実装内容の差分確認を行ってきました。今後は、詳細設計の作成や設計レビューに関わりながら、要件を実装に落とし込む力を伸ばしていきたいと考えています。
この伝え方なら、経験不足を認めつつ、現場で何を学び、次にどう伸ばしたいのかが伝わります。
面接官が見ているのは、完璧な設計経験だけではありません。設計工程に入ったときに、仕様を確認し、影響範囲を考え、周囲と認識を合わせながら進められるかです。
「設計経験がない」ことよりも、「設計に必要な視点を持って仕事をしてきたか」が面接では重要です。
設計経験ができないSESエンジニアが避けたい失敗パターン
設計経験を積みたいと考えるとき、焦りから間違った行動を選んでしまうことがあります。ここでは、特に避けたいパターンを整理します。
資格を取れば設計経験の代わりになると思い込む
資格は知識の整理には役立ちます。基本情報技術者、応用情報技術者、クラウド系資格などを学ぶことで、設計に必要な基礎知識を補うことはできます。
ただし、資格だけで「設計できます」とは言えません。転職で見られるのは、知識を使ってどのように仕様を整理し、判断し、改善したかです。
資格学習をするなら、職務経歴書に書ける業務改善や個人開発とセットで考えましょう。
ポートフォリオだけで上流経験を補おうとする
個人開発やポートフォリオは、設計の考え方を見せる材料になります。ER図、画面遷移図、API仕様、技術選定理由を添えると、設計への理解を伝えやすくなります。
しかし、ポートフォリオだけで実務の設計経験を完全に代替できるわけではありません。特に業務システムや受託開発では、関係者との調整、既存制約、保守性、運用負荷まで考える力が見られます。
ポートフォリオは、「実務経験がない代わり」ではなく、「設計に向き合う姿勢を補足する材料」と考えましょう。
上流工程という言葉だけで転職先を選ぶ
「上流工程に関われます」と書かれた求人でも、実際には資料作成や進捗管理が中心の場合があります。
設計力を伸ばしたいなら、面接で次の点を確認しましょう。
- 入社後に担当する最初の工程
- 設計書を作成する機会の有無
- 実装やテストとの距離感
- レビュー体制
- 顧客との仕様確認に参加できるか
- 若手や中途入社者が設計に進むまでの流れ
「上流に行きたい」だけで転職すると、開発力も設計力も中途半端になる可能性があります。
SESで設計経験ができない人の今後の判断基準
最後に、今の会社に残るべきか、案件変更を相談すべきか、転職を考えるべきかの判断基準を整理します。
状況 | おすすめの判断 | 理由 |
|---|---|---|
設計書を読める、質問もできる | 今の現場で経験を広げる | 影響調査や設計レビューに近づける余地がある |
設計書は読めるが、作成機会がない | 担当範囲の拡大を相談する | 小規模改修や設計書修正から経験を作れる可能性がある |
テストや運用だけで情報が渡されない | 案件変更を相談する | 現場内で努力しても設計に近づきにくい |
希望を伝えても会社が動かない | 転職を検討する | 会社の案件構造がキャリア希望と合っていない可能性が高い |
開発経験自体が浅い | まず実装経験を増やす | 設計に進むには、実装・テスト・保守の理解が土台になる |
システム開発の現場では、良い設計者ほど実装や運用の現実を理解しています。最初から要件定義だけを目指すより、実装、テスト、保守で見えている課題を設計視点に変換できる人のほうが、現場では信頼されやすいです。
そのため、今の経験を無駄だと決めつける必要はありません。ただし、今後も設計に近づく機会がないなら、環境を変える判断も現実的です。
残るか転職するかは、「今の現場で設計に必要な経験が増えているか」で判断しましょう。
まとめ:SESで設計経験ができないなら、経験の棚卸しと環境の見極めが必要
SESで設計経験ができない悩みは、本人の能力不足だけで起きるものではありません。商流、常駐先の体制、担当範囲、会社の案件選定によって、設計に関われない状態が続くことがあります。
ただし、設計書をゼロから作った経験がなくても、影響調査、仕様確認、設計書の不備指摘、テスト観点の追加、運用改善など、設計に近い経験は見つけられます。まずは自分の業務を棚卸しし、「作業」ではなく「判断」として言語化しましょう。
そのうえで、今の現場に設計書・仕様確認・レビュー・影響調査へ関われる余地があるなら、担当範囲を広げる相談をする価値があります。逆に、情報も権限も渡されず、会社に希望を伝えても変わらないなら、案件変更や転職を考えるタイミングです。
設計経験を積むために大切なのは、「上流に行きたい」と焦ることではありません。自分に足りない経験を切り分け、今の環境で補えるものと、環境を変えなければ得られないものを見極めることです。
設計経験がない状態からでも、今の経験を整理し、次に積むべき経験を選べば、キャリアの方向性は変えられます。