SESで上流工程にどこまで関われる？｜要件定義には届かず、基本設計からテストまで担当した現場

SESエンジニアとして5年あまり、4社を経験しました。そのうち2社目と3社目では、新規の要件定義を自分で決める席に座ったことがありません。

一方で、2社目では設計から単体テストまで、3社目の保守改善では基本設計から結合テストまでを担当しました。要件定義には届かず、その後ろの工程には触れられた、というのが私の実感です。

今回は、SESで上流工程にどこまで関われるのかを、実体験を交えてお伝えします。

この記事で分かること

要件定義に届きにくいのが、能力や年数ではなく、要件を決める責任と契約の形で決まる理由
三次請け（2社目）・データ移行（3社目前半）・保守改善（3社目後半）で、触れた工程がどう違ったか
関われた工程と、関われなかった工程
上流に近づく3つのルートに対する、私の経験ベースの評価
上流求人へ応募・転職する前に、面談で確かめる4つのこと

SESの上流工程で要件定義に届きにくいのは、決める席が契約の外にあるからです
要件定義の責任は、もともと発注するユーザー企業にあります
上流の線引きと、私の席からの見え方
三次請けの2社目｜設計からテストまで、仕様は上から降りてきました
二次請けの3社目｜移行では設計の外側にいて、保守で上流寄りの工程を担当しました
前半の約1年｜データ移行は、手順書に沿って実行する役でした
後半の約1年半｜保守改善で、基本設計から結合テストまで担当しました
それでも届かなかったもの
触れる工程は、契約の中身と担当の割り振られ方で決まります
人を出す契約と、成果物を納める契約の違い
人を出す契約で、要件を決める席が空きにくい3つの理由
保守で基本設計まで届いたのは、枠が小さかったからだと思います
上流に近づく3つのルートを、経験した範囲で評価する
現場の中で広げられたのは、割り振りの運用のおかげでした
PMOや小規模案件は、語れる材料がありません
上流求人へ応募する前に、工程の書き方と確かめ方を決めておく
保守改善の経験は、3つの区分で書き分ける
面談や営業との確認で聞くこと
上流工程への関わり方についての、よくある疑問
上流の経験がなくても、上流の求人に応募できますか
商流が上の会社へ移れば、上流に行けますか
準委任なのに上流を任される現場はありますか
保守案件に入ると、上流から遠ざかりますか
まとめ

SESの上流工程で要件定義に届きにくいのは、決める席が契約の外にあるからです

結論要件定義に届きにくい一番の原因は、年数や能力より、要件を決める責任が発注側にあり、人を出す契約には決める席が含まれにくいことです。

2社目と3社目では、要件定義の会議で決める側に座る機会がありませんでした。当時は経験が足りないからだと考えていましたが、今は違う見方をしています。席が用意されなかったのは、そもそも契約がその席を含んでいなかったからだと思います。

要件定義の責任は、もともと発注するユーザー企業にあります

最初に、上流工程が何を指すのかを確認しておきます。IPAのDX SQUAREは、企画から要件定義、基本設計までをまとめて「上流工程」と呼んでいます。

同じページには、要件定義でつくった成果物の責任はユーザー企業にあり、ITベンダーに支援してもらう場合でも変わらない、とも書かれています（出典: 要件定義とは｜IPA DX SQUARE）。

ここから先は私の読みです。要件を決める責任が発注側にあり、ベンダーの役割が「支援」だとすれば、人を出す立場のSESは、決める席に座る前提で呼ばれていないことになります。

もちろん、支援として要件定義に入るSES案件もあるはずです。ただ、私の2社目・3社目には、そういう席に座る機会はありませんでした。

上流の線引きと、私の席からの見え方

上流の範囲は会社や求人によって揺れます。この記事ではIPAの説明に合わせて、基本設計までを上流と呼びます。

そう数えると、基本設計は上流に入り、詳細設計以降は入りません。工程ごとに、私がどう関わったかを並べました。

工程	2社目（三次請け）	3社目前半（データ移行）	3社目後半（保守改善）
要件定義	担当範囲に含まれていなかった	関わらなかった	関わらなかった。要件の不備に気づいたときに連携する程度
基本設計	担当範囲に含まれていた（細部は覚えていない）	関わらなかった	担当した
設計の続き〜テスト	設計から実装・単体テストまで担当	なし（手順書に沿った移行作業の実行）	結合テストまで担当

一番はっきりしているのは、要件定義にはどの時期も関わらなかったことです。一方で、保守改善では基本設計から結合テストまで通して担当できました。

2社目の基本設計については、担当範囲に入っていたものの、どこまで自分で書いたのかを今は細かく覚えていません。覚えていないことを、それらしく書くのは控えます。

三次請けの2社目｜設計からテストまで、仕様は上から降りてきました

2社目は三次請けで、業務システムの案件でした。進め方はウォーターフォール型です。

担当範囲は基本設計からテストまでとされていましたが、細かい分担は正直なところ覚えていません。はっきり言えるのは、設計から実装、単体テストまでを担当したことと、要件を決める側には入っていなかったことです。

三次請けは、発注側のユーザー企業から見ると、間に会社が何社も挟まる位置です。要件を決める場から遠いのは自然だったと思います。上流工程の中身が「決める」ことだとすれば、決める場に席がない状態が、要件定義に届かない実態でした。

二次請けの3社目｜移行では設計の外側にいて、保守で上流寄りの工程を担当しました

3社目は商流が一段浅い二次請けで、金融系のWebサイトの案件でした。前半と後半で、触れる工程がまるで違いました。

商流の位置をどう見分けたかは、別の記事にまとめています。

前半の約1年｜データ移行は、手順書に沿って実行する役でした

前半は、旧システムのデータを新システムへ移すデータ移行でした。私の担当は、リハーサルと本番切り替えの実施です。

対象データ数百テーブル数百万件以上

リハーサル3〜4回

本番の切り替え24時間以上連休・複数日、夜間・休日対応

3社目のデータ移行の規模です。

作業量は多く、トラブルも一通り起きました。ただ、上流という観点で見ると、この1年は設計の外側にいた時期でした。手順書は与えられるもので、私がその内容を決める立場ではありません。

この時期に身につかなかったものは、スキルが身につかない理由の記事に、保守改善の時期との対比として書いています。

後半の約1年半｜保守改善で、基本設計から結合テストまで担当しました

移行が終わると、同じ現場の保守改善に担当が変わりました。

保守改善の中身は、ユーザーからの改修依頼への対応と、障害調査・不具合修正です。フロントとサーバー側のどちらも対応しました。

担当は依頼ごとに割り振られ、特定の画面や領域に固定されませんでした。1件ごとに基本設計から結合テストまでを通して実施し、成果物は毎回レビューを受けています。

改修依頼連絡窓口のリーダー経由
要件の確認不備は連携して伝える
基本設計改修の設計
詳細設計・実装毎回レビュー
単体・結合テスト証跡の作成

保守改善で私が関われた流れです。強調の段が、上流に含まれる工程です。

要件定義そのものは担当しませんでした。ただ、依頼の内容に不備や抜けがあれば、連絡窓口のリーダーを通じて伝え、連携して詰めていきました。

保守改善では、基本設計を自分の手で書いてレビューを受ける経験ができました。

それでも届かなかったもの

関われたのは、既にあるシステムを直すという枠の中の話です。新規の大きな要件定義は、保守改善の中で担当したことがありません。

もう一つの限界は、依頼元との距離です。やりとりは連絡窓口のリーダーが挟まる形で、依頼元と直接やりとりする形ではありませんでした。

つまり、保守改善で得たのは、要件定義そのものではなく、決まった要件を受けて基本設計から検証まで通して担当する経験です。

触れる工程は、契約の中身と担当の割り振られ方で決まります

結論商流の段数よりも、自社がどんな形の契約で受けているかと、担当が依頼ごとに割り振られるかどうかで、触れる工程が変わると私は見ています。

2社目の三次請けから3社目の二次請けに移っても、触れる工程が自動的に広がったわけではありません。3社目の前半は手順書を実行する役で、2社目より設計から遠ざかっていました。位置が上がっても、担当の中身が変わらなければ、触れる工程は広がりません。

契約書は見られない立場なので、ここから先は一般的な契約の形と自分の現場を突き合わせた、私の見立てです。

人を出す契約と、成果物を納める契約の違い

民法上、準委任は仕事の完成を約束する契約ではなく、善良な管理者の注意をもって事務を処理する契約です。請負は、仕事の完成を約束する契約です。

SESで多いのは準委任だと言われますが、私は2社目・3社目の契約書を見ておらず、契約の形は確認できていません。ここでは、常駐して担当の作業を進める形だったことから、人を出す形に近いと見ています。

準委任と請負の違いは、別の記事で詳しく整理しています。

人を出す契約で、要件を決める席が空きにくい3つの理由

上流に行きにくい3つの理由

責任の所在要件定義の成果物の責任はユーザー企業にあり、ベンダーは支援する立場とされています（IPA DX SQUARE）。
契約の範囲人を出す契約は、決められた内容を誠実に作業する義務で成り立つので、決める工程は契約の外に置かれやすいと私は見ています。
入場前の確定面談とスキルシートの時点で、担当する工程の範囲が先に見られやすいと私は見ています。

3つ目は、私の見立てです。入場してから担当が決まるのではなく、面談の時点で、どの工程の枠で入るかが先に決まりやすいという順番だと考えています。面談でどこまで案件を選べるのかは、別の記事にまとめています。

保守で基本設計まで届いたのは、枠が小さかったからだと思います

では、なぜ保守改善では基本設計まで任されたのか。私の見立ては、既存システムの改修という枠が小さく、決める責任が重すぎなかったからです。

新規の大きな要件は、事業の方針に関わるので、発注側が握るのだろうと思います。改修依頼のレベルであれば、設計からテストまでの作業は現場に任せやすいのではないでしょうか。

これが、保守改善でも要件定義までは届かなかった理由だと考えています。ここは裏づけのある統計ではなく、私の現場での体感です。

上流に近づく3つのルートを、経験した範囲で評価する

上流に近づく方法として、よく挙がるルートは3つあります。商流の浅い会社へ移る、今の現場の中で担当する工程を広げる、PMOや小規模案件に入る、の3つです。

私が実際に経験したものと、していないものを分けて、率直に評価します。

ルート	私の経験	私の評価
商流の浅い会社へ移る	三次請けから二次請けへ（2社目から3社目）	移ったこと自体で工程は広がらなかった。契約の形と担当の中身次第
今の現場で担当する工程を広げる	3社目の保守改善で、基本設計から結合テストまで	一番手応えがあった。ただし依頼ごとの割り振りという現場の運用が前提で、再現性は現場次第
PMO・小規模案件に入る	2社目・3社目ではなし	見たことがないので、評価は書けない

現場の中で広げられたのは、割り振りの運用のおかげでした

3つの中で効いたのは、2つ目です。ただ、これは私が工夫して広げたというより、依頼ごとに担当が割り振られる運用だったから、結果として基本設計から回ってきたというのが実態です。

担当が特定の画面や領域に固定される現場では、同じことをしても広がらなかったと思います。自分の努力より、担当の割り振り方に左右されるというのが、正直な感想です。

PMOや小規模案件は、語れる材料がありません

PMOと小規模案件は、私の2社目・3社目では経験していません。上流に近いと言われるルートですが、どんな契約で、どこまで決める席があるのかを、私は自分の経験として語れません。

検討するなら、次の章の確認項目をそのまま使って、契約と承認者を聞くのが現実的だと思います。

上流求人へ応募する前に、工程の書き方と確かめ方を決めておく

上流を扱う求人に移ることを考えるなら、工程をどう書くか、移る先の何を確かめるかを先に決めておく必要があります。

保守改善の経験は、3つの区分で書き分ける

「何年で上流に行けるのか」を示す確かな統計を、私は示せません。だから、年数の目安は書きません。

私にできたのは、工程の書き方を3つの区分に分けることでした。保守改善の経験は、この区分で書くと誤解を生みにくいと感じています。

区分	意味	私の例
担当した	成果物を自分が作り、レビューを受けた	保守改善での基本設計、詳細設計、実装、単体・結合テスト
範囲を限って関わった	決める側ではなく、気づいた点を連携した	要件の不備に気づいたときの連携
関わっていない	経験がない	要件定義、新規システムの基本設計

たとえば保守改善の経験なら、「既存システムの保守改善で、依頼ごとの基本設計を担当した。要件定義は担当していない」と区分どおりに書きます。どのシステムで、どこまでを担当したかを分けて書くことが、後で崩れない書き方です。

職務経歴書への落とし込みは、別の記事に書いています。