SESの上流工程とは？必要スキル・下流から進む7ステップ

上流工程を、要求・設計・計画・検証の四つへ分ける

上流工程という言葉には、要求整理、要件定義、基本設計、技術選定、プロジェクト計画、顧客折衝、PM・PMOなど複数の仕事が混ざります。求人に「上流から担当」と書かれていても、顧客の課題を定義するのか、決まった要求を設計書へ落とすのか、進捗やリスクを管理するのかで必要な経験は違います。希望欄には「上流」だけでなく、次に持ちたい判断と成果物を書きます。

要求では、利用者、目的、現行業務、困りごと、制約、優先順位を整理します。依頼をそのまま議事録へ写すのではなく、対象範囲と対象外、正常系と例外、受入条件を確認し、未決事項を判断者へ戻します。要件定義書という文書名を担当していなくても、要求の矛盾や不足を見つけて確認した事実は、前工程へ関与した証拠になります。

設計では、要求を機能、データ、画面・API、権限、性能、可用性、セキュリティ、運用へ分け、複数案の影響を比べます。基本設計を一人で作った経験がなくても、既存仕様の影響調査、設計レビュー、例外条件の追加、移行・切り戻しの検討にどこまで関わったかを出せます。自分の提案と、最終決定者の判断は分けて説明します。

計画では、工程、要員、期限、依存関係、品質、変更、リスクを扱います。厚生労働省のjob tagが示すITプロジェクトマネージャの仕事を、そのまま自分の経験として借りてはいけません。担当したのが進捗更新だけならそう書き、差分の原因を整理して優先順位や計画変更の判断材料まで作ったなら、その入力・出力・承認者を具体化します。

検証は下流ではなく、上流の判断が正しかったかを確かめる工程です。受入条件からテスト観点を作り、不具合傾向を要求や設計へ戻し、リリース後の問い合わせ・性能・運用負荷を確認できれば、要求から結果までの循環を説明できます。「上流だけをやりたい」ではなく、実行結果を見て次の判断を直せる範囲を増やす方が、求人の役割を比較しやすくなります。

• 要求: 利用者・目的・範囲・制約・受入条件
• 設計: 機能・データ・非機能・運用の選択肢
• 計画: 工程・要員・依存関係・品質・変更・リスク
• 検証: テスト・移行・運用結果を要求と設計へ戻す
• 確認: 自分の成果物・レビュー担当・最終決定者

テスト・保守・実装経験を、前後工程との接点へ変換する

現在の担当がテスト実施、監視、問い合わせ、詳細設計、実装のどれであっても、工程名だけで上流経験の有無を決めません。一案件を「入口となった情報」「自分が調べたこと」「判断または提案したこと」「次工程へ渡したもの」「結果を確認した方法」の五列へ分けます。担当していない列は空欄にし、経験を作らずに次に増やす責任として残します。

テスト中心なら、渡された項目数ではなく、どの要求・設計・リスクから観点を作ったかを出します。仕様差分から境界値、権限、並行処理、外部連携、障害復旧を追加し、不具合の原因を要求漏れ・設計・実装・環境へ分類して前工程へ戻した経験は、品質を通じた設計判断への関与です。テスト設計者やレビュー担当との分担も明記します。

運用・保守なら、問い合わせを転送した回数ではなく、ログ、SQL、監視、既存仕様、操作履歴から原因範囲を絞った順序を整理します。暫定回避、恒久対応、対応しない案を比較し、影響、期限、利用部門の優先順位を示して改修判断を支えたなら、要求整理と変更設計の証拠になります。顧客名や障害の内部情報は持ち出しません。

実装中心なら、受け取った設計どおりに書いた事実と、曖昧さを発見して設計へ戻した事実を分けます。既存コードと仕様から影響範囲を調べ、API、DB、権限、エラー処理の選択肢をレビューで合意し、結合・本番後まで確認した経験は、設計の入口になります。「Javaを三年」より、どこまで独力で判断し、どこから承認を得たかを伝えます。

インフラ運用なら、手順実行だけでなく、変更前後の性能、費用、可用性、監視、バックアップ、復旧、切り戻しを比べた経験を探します。PMO・調整なら、会議数ではなく、決定事項、未決事項、依存関係、変更、リスク、担当、期限を更新し、誰の判断が何によって変わったかを出します。職種名を盛らず、実際の成果物を証拠にします。

• テスト: 要求とリスクから観点を追加し、原因を前工程へ戻す
• 保守: 原因範囲・暫定回避・恒久対応・優先順位を整理する
• 実装: 仕様差分・影響範囲・設計案をレビューで合意する
• インフラ: 性能・費用・可用性・復旧条件を比較する
• PMO: 決定・未決・依存・変更・リスクの状態を更新する

現職で増やせる責任と、転職が必要な制約を90日で分ける

上流工程へ進むために、すぐ退職する必要があるとは限りません。現在の案件は業務知識、既存システム、関係者を既に理解しているため、隣の責任を小さく増やせる場合があります。一方で、契約・配属・体制上、設計レビューへ参加できない、上位会社だけが顧客と話す、案件変更の期限がない場合もあります。希望ではなく、担当者と期限がある約束で判断します。

最初の30日で、直近三案件を五列へ棚卸しし、空欄のうち一つだけ選びます。たとえば、テスト実施からテスト設計、実装から影響調査、運用から改善提案、進捗更新からリスク整理へ広げます。上司や営業には「上流案件をください」ではなく、担当したい成果物、現状の根拠、必要なレビュー、開始できる時期を具体的に伝えます。

31〜60日で、現職の回答と求人十件を同じ表へ置きます。現職には、次回更新で担当できる成果物、案件変更の候補時期、評価・給与への反映を確認します。求人には、入社90日の案件、担当工程、成果物、レビュー担当、配属決定者、変更可能性を確認します。求人の「上流比率」だけでは、自分の担当が上流になるか分かりません。

61〜90日で、現職に残る、案件を変える、会社を変えるの三案を判定します。現職で責任を増やせる担当者・案件・開始日が書面または具体的な計画になったなら、実績を作ってから再評価できます。「検討する」だけで期限がない、求人でも配属と工程が未定なら、どちらも上流経験の保証として扱いません。

退職は求人比較、応募、内定条件の確認とは別の判断です。心身や安全の問題がある場合は90日計画より休息・医療・公的相談を優先します。それ以外でも、生活費、在職中の選考時間、引き継ぎ、雇用保険・社会保険などを確認し、転職先が決まる前に勢いだけで退職しないようにします。

• 0〜30日: 三案件を五列で棚卸しし、隣の責任を一つ選ぶ
• 0〜30日: 成果物・レビュー担当・開始時期を現職へ聞く
• 31〜60日: 現職と求人十件を同じ7項目で比較する
• 61〜90日: 担当者と期限のある案だけを残す
• 90日後: 残る・案件変更・転職・退職を別々に判断する

不足経験は、補佐・レビュー・影響調査から一段ずつ作る

担当していない要件定義や基本設計を、職務経歴書で経験済みに変えることはできません。不足がある場合は、いきなり一人で要件定義を持とうとせず、要求ヒアリングの同席、議事メモから未決事項の整理、既存仕様の影響調査、設計レビュー、受入条件の作成など、現在の工程と接する補佐から始めます。誰のレビューを受けるかも決めます。

要求整理を増やすなら、依頼を機能一覧へする前に、利用者、目的、現行手順、例外、期限、対象外を確認します。会議へ出ただけでは経験になりません。確認事項一覧、業務フロー、要求差分、受入条件など、自分が作成・更新し、関係者の確認を受けた成果物を残します。会社と顧客の情報管理ルールに従い、転職用に資料を持ち出さないでください。

基本設計を増やすなら、画面やAPIを一から任されることだけを待ちません。既存設計と実装の差、外部連携、権限、データ移行、非機能、運用監視など一領域の影響調査を担当し、選択肢とトレードオフをレビューへ出します。承認された案と不採用案、判断理由を自分の言葉で説明できる状態にします。

計画・PMOを増やすなら、WBS更新だけで終えず、遅延の原因、依存関係、変更要求、品質リスク、対応案、判断期限を整理します。最終決定はPMが行っても、判断材料を作り、決定後の状態を追跡した経験は書けます。役職名ではなく、どの意思決定をどの情報で支えたかを記録します。

資格や個人開発は基礎知識と学習の証拠にはなりますが、顧客・利用者との要求合意や業務システムの設計責任を自動的に証明しません。個人開発を使うなら、利用者仮説、要求、設計案、テスト、運用、改善までを自分で検証し、実務未経験の範囲を明記します。求人の必須実務条件は、作品だけで満たしたと自己判断しません。

• 要求補佐: 目的・現行・例外・対象外・受入条件を整理
• 設計補佐: 影響範囲と複数案をレビューへ提出
• 品質: 要求から受入・テスト方針を作り前工程へ戻す
• PMO: 依存・変更・リスク・期限を判断材料へ変える
• 未経験: 資格・個人開発と実務責任を分けて記載する

職務経歴書は工程名でなく、入口・判断・出口を書く

職務経歴書の担当工程へ「要件定義」「基本設計」と丸を付けるだけでは、採用側は任せられる範囲を判断できません。一案件ごとに、案件の目的、体制、自分の役割、入口となった依頼・資料、調査した事実、比較した案、合意した相手、作った成果物、次工程への引き渡し、結果を整理します。上位者の成果と自分の担当を混ぜません。

「顧客折衝を経験」も分解します。誰と、何を決めるために、どの資料や選択肢を示し、どこまで自分が回答し、何を持ち帰ったのかを書きます。日程調整や議事録作成だけなら、その仕事を過小評価する必要はありませんが、要件の決定経験としては書きません。未決事項と判断期限を管理して合意を進めたなら、その変化を出します。

数字は、測定方法を説明できるものだけを使います。工数削減、障害減少、手戻り削減を測っていなければ作りません。「影響調査の確認順を統一した」「受入前の未決事項を一覧化した」「リリース判定に必要な証跡をそろえた」など、観察できる変化でも再現性は伝えられます。顧客名、画面名、構成、障害詳細は一般化します。

求人へ合わせるときは、経験を盛るのではなく、求人の成果物と案件事実を対応させます。要件定義求人なら要求差分・受入条件、基本設計求人なら機能・データ・非機能、PM求人なら計画・変更・リスクの証拠を前に出します。足りない必須条件は隠さず、近い経験、レビューを受けた範囲、入社後に必要な支援を説明します。

同じ経歴書を全求人へ送らず、職務要約と詳しく書く三案件の順序を応募職種に合わせます。ただし、日付、人数、役割、工程、技術、成果の事実は版ごとに変えません。送付日、求人、版、推薦文、応募同意を記録し、面接で職務経歴書と違う範囲を話さないようにします。

• 目的・体制・自分の役割を最初に書く
• 入口となった依頼・資料と調査した事実を書く
• 比較した案・判断理由・承認者を分ける
• 成果物・次工程への出口・結果をつなぐ
• 未経験と支援を受けた範囲を隠さない
• 顧客情報を一般化し、根拠のない数字を作らない

求人では「上流比率」より、入社90日の工程と成果物を聞く

求人の「要件定義から参画」「プライム案件多数」「上流工程比率」「キャリアアップ可能」という表示だけでは、入社後の担当を確定できません。会社全体の案件構成と、一人の配属予定は別です。応募前と面接で、想定案件、顧客との距離、商流、工程、成果物、レビュー体制、配属決定者、案件変更の条件を確認します。

第一に、同じ経歴で入社した人が最初の90日で担当した工程と成果物を聞きます。要求一覧、基本設計、詳細設計、テスト計画、移行計画、WBS、課題・リスク表のどれか。単独担当か補佐か、誰がレビューし、顧客へ直接説明するかまで確認します。「本人の希望と適性で決定」という回答なら、適性を誰が何で判断し、いつ配属が決まるかを聞きます。

第二に、上流だけでなく実装・テスト・運用とのつながりを確認します。要求を作った後に結果を見られるのか、分業で資料だけを渡すのかによって、学べる責任が変わります。自社開発なら利用者データと改善、社内SEなら利用部門・ベンダー・運用、SIerなら顧客・設計・品質、ITコンサルなら課題・選択肢・導入の範囲を聞きます。

第三に、配属が希望と違う場合の扱いを確認します。案件変更を申し出る時期、次案件の選び方、待機時の給与、評価日、上流工程を担当できなかった場合の育成・レビュー、転勤や顧客先勤務の範囲を聞きます。案件選択や研修を口約束の保証として受け取らず、求人票、面接メモ、労働条件通知書の差分を残します。

厚生労働省は募集時等に明示する労働条件として、業務内容と就業場所の変更範囲などを案内しています。想定年収だけでなく、基本給、固定残業、賞与、試用期間、勤務時間、雇入れ直後の業務・就業場所、変更範囲を照合します。「上流へ行ける」期待と、雇用条件・配属の事実を別々に確認してください。

• 同じ経歴の入社者が90日で担当した工程・成果物
• 単独・補佐の範囲とレビュー担当・最終承認者
• 顧客へ直接説明する範囲と商流・配属決定者
• 要求から実装・テスト・運用結果まで追えるか
• 希望外配属・案件変更・待機給与・評価日の条件
• 基本給・固定残業・賞与・試用期間
• 業務内容・就業場所の雇入れ直後と変更範囲

対象条件に合う二社までへ、同じ経歴と7問を渡す

転職支援を使う場合は、「上流求人が多い」という宣伝だけで決めません。現在の経歴で紹介可能な求人、その求人を選んだ理由、入社90日の工程と成果物、不足する経験、配属条件を具体的に説明できるかを比較します。サービスごとに希望を変えると提案差の理由が分からないため、同じ職務要約、必須条件、除外条件、7問を渡します。

TechGoは、確認した主な利用条件では主に実務経験2年以上のITエンジニア、20代後半〜30代の支援を中心に案内しています。年収と技術環境を同時に見直し、次に任される工程を求人ごとに比較したい人の候補です。公開求人や支援実績を自分の結果へ置き換えず、現在の紹介可能件数、企業が評価した案件事実、配属工程、選考対策を確認します。

STRATEGY CAREERは、確認した主な利用条件ではエンジニア経験者、主に20〜30代、東京・大阪エリアでの就職希望が対象の目安です。SIer、事業会社、ITコンサルなど進路をまだ一つに決めず、どの職種で現在の経験が評価されるか比べたい人の候補です。各求人の選定理由と、上流という言葉を具体的な成果物へ直した回答を求めます。

社内SE転職ナビは、客先側で要望を受ける働き方から、利用部門の要求整理、ベンダー協働、受入、運用改善を社内で持つ道を比べたい人の候補です。社内SEでも問い合わせ中心、一人情シス、ベンダー管理中心など役割は異なります。内製と外注、入社90日の担当、障害当番、評価、企業スカウトとエージェントの応募経路を確認します。

TechClipsエージェントは、自社サービスを持つ事業会社を中心に、設計・開発だけでなく公開後の利用と改善へ関わる求人を比べたい人の候補です。自社開発という会社分類を、上流工程や裁量の保証にしません。企画・PdM・デザイナーとの分担、要求の決定者、技術選定、レビュー、運用・改善の担当範囲を求人ごとに確認します。

比較中の全社へ申し込む必要はありません。年齢、実務経験、勤務地、転職時期が対象に合い、面談と求人提案を実際に利用する候補を二社まで選びます。求人紹介、応募、面接、内定承諾、退職は別の判断です。面談後に紹介件数、選定理由、評価された事実、不足条件、次の連絡日を記録し、現職で責任を増やす案と同じ表で比べます。

• 今の経歴で紹介可能な求人と、選んだ理由は何か
• 入社90日の工程・成果物・レビュー担当は誰か
• 要求・設計・計画・検証のどこを任されるか
• 不足する実務経験と、補佐から入れる求人はあるか
• 配属決定・希望外配属・案件変更の条件は何か
• 企業ごとの応募前に本人確認を取るか
• 給与内訳・評価・業務と勤務地の変更範囲は何か

職務経歴書の変換例

「上流希望」という抽象語を、入口、調査、比較した案、合意、自分の成果物、検証、未経験、次に持つ責任へ変えます。経験していない工程を足さず、隣の責任へ進める証拠を示します。

行動前チェックリスト

• 上流工程を要求・設計・計画・検証へ分けた
• 直近三案件を入口・調査・判断・出口・結果で棚卸しした
• テスト・保守・実装・インフラの前後工程との接点を探した
• 自分の担当・レビュー担当・最終決定者を分けた
• 未経験の要件定義・基本設計を経験済みにしていない
• 現職で増やす成果物・担当者・開始期限を確認した
• 求人で入社90日の工程・成果物・レビュー担当を聞く
• 上流比率・プライム・自社開発を配属保証にしていない
• 顧客名・内部資料・測っていない数字を持ち出していない
• 給与内訳・評価・待機・案件変更条件を確認する
• 業務内容・就業場所の変更範囲を書面で照合する
• 対象条件に合う候補二社までへ同じ経歴と7問を渡す
• 求人紹介・応募・内定・退職を別々に判断する