職種区分の統計では設計や管理に近い区分の水準が高いものの、工程の名前だけで年収が上がるわけではありません。要件定義や基本設計を担当しても、判断を自分が持っていない、商流が深い、実装の裏づけがないといった場合は、期待したほど動きません。
工程による水準の違いはSEの年収の中でも触れています。この記事は、下流の担当者や上流への異動を打診された人が、「上流に移ると自分の年収はどう変わるのか、何を確かめて移るべきか」を判断するためのものです。
統計で読める差と、読めない差
工程別の年収を集計した公的統計は見当たりません。最も近い手がかりは、賃金構造基本統計調査の職種区分です。プログラマーなどが入る区分と、システムコンサルタントや設計者が入る区分を比べられます。
| 項目 | システムコンサルタント・設計者 | ソフトウェア作成者 |
|---|---|---|
| 年収換算額(当サイト算出) | 889万円 | 578万円 |
| 年間賞与その他特別給与額 | 239万円 | 110万円 |
| 平均年齢 | 38.3歳 | 37.1歳 |
| 平均勤続年数 | 11.9年 | 9.9年 |
平均年齢が近いのに年収換算額に開きがあるので、年齢だけでは説明できない差があることは読み取れます。ただし、この表は「上流へ移るとこの差が手に入る」という意味ではありません。左の区分には情報処理プロジェクトマネージャやシステムコンサルタントが含まれ、右の区分には社内システムエンジニアやテクニカルスペシャリストも含まれます。所属する会社の規模や業種の違いも混ざっています。
また、年収換算額は6月分の月額を12倍して賞与を足した当サイトの概算で、調査が公表した年収ではありません。したがって、表から言えるのは「設計や管理を担う人が多い区分の水準は高い」までです。個人が工程を変えたときの変化は、次の3条件で判断してください。
工程の名前より、失敗したときの影響で値段がつく
上流の仕事に高い評価がつきやすいのは、判断を誤ったときの影響が大きいからです。要件を取り違えると、その後の設計、実装、テストの全部がやり直しになります。会社はその損失を防げる人に対して払います。
| 工程 | 主な判断 | 誤ったときの影響 |
|---|---|---|
| 要件定義 | 何を作り、何を作らないか | 案件全体の費用、期間、契約 |
| 基本設計 | 画面、データ、連携の分け方 | 後工程の手戻り、他システムへの影響 |
| 詳細設計 | 処理の方式、例外の扱い | 担当範囲の品質、性能 |
| 実装・テスト | コードの書き方、確認の範囲 | 不具合、リリースの遅れ |
この表は仕事の優劣を示すものではありません。性能問題やデータ移行のように、実装の判断ひとつで大きな損失を防ぐ場面もあります。そうした仕事を担う人は、工程が下流でも高く評価されます。評価を決めているのは工程の位置ではなく、判断の影響の大きさだと捉えてください。
条件1:判断を自分が持っているか
上流の案件に入っても、担当が議事録、資料の整形、進捗の集計なら、年収を動かす根拠になりにくいです。工程の名前は上流でも、決めている人が別にいるからです。
見分けるには、直近の打ち合わせを振り返ります。顧客の要望に対して「これはやらない」「この順番で進める」と案を出したのは誰か、その案で問題が起きたときに説明するのは誰かを確かめます。自分なら判断の仕事で、他の人なら補助の仕事です。
補助の段階が無駄というわけではありません。顧客の業務を学ぶ入口として価値があります。ただし、補助のまま何年も続くと「要件定義の経験あり」と書けても、選考で掘り下げられたときに説明が止まります。一つの機能や帳票など、小さな範囲で構いませんから、案を出して合意まで持っていく経験を取りに行ってください。
条件2:その工程に値段がつく位置にいるか
同じ要件定義でも、商流の位置で給与の原資が変わります。発注元と直接決める一次請けと、上位の会社が決めた範囲を受ける会社では、責任の大きさも受け取る金額も違うからです。多重下請けの中では、「上流」と呼ばれる仕事が、実は上位の会社が作った要件の整理であることもあります。
当サイトの診断モデルで、東京、実務6〜9年、スコア70の推定を企業タイプごとに見ると次のとおりです。
| 企業タイプ | 推定レンジ | レンジの図 |
|---|---|---|
| メガベンチャー・外資 | 780〜915万円 | |
| 上場・大手 | 686〜805万円 | |
| 中小の受託・SIer | 593〜696万円 | |
| スタートアップ | 624〜732万円 | |
| SES | 530〜622万円 |
これは統計ではなく、編集判断で係数を置いたモデルの推定で、工程の違いは計算に入っていません。読み取ってほしいのは、上流へ移ることと、水準の高い企業タイプへ移ることは別の打ち手だという点です。商流が深い会社の中で工程だけを上げても、給与テーブルの上限に当たれば止まります。商流の確かめ方は一次請けと二次請けの違いに譲ります。
条件3:実装の裏づけがあるか
実装を知らないまま上流へ進むと、見積もりと設計の判断に根拠が持てなくなります。「できる」と答えた仕様が後から高くつく、といった失敗が起きやすく、経験を積んでも評価が伸びないことがあるからです。
具体例を挙げます。顧客から「検索を速くしたい」と言われたときに、データ量と処理の方式を知っていれば、どこに費用がかかり、どこまでなら現実的かをその場で話せます。知らなければ持ち帰りが増え、後工程の担当者に判断を預けることになります。
例外として、業務知識や顧客との調整に強みがあり、実装は他の人に任せる役割もあります。コンサルタントや業務に特化したSEがこの型です。ただ、その場合は業務の専門性が評価の中心になるので、技術で評価される求人と同じ基準では比べられません。転向を考えるならITコンサルタントとエンジニアの比較を読んでください。
上流に移っても年収が増えない3つの場合
3条件を満たしても、総額が動かない場面があります。移る前に確かめておくと、後から驚かずに済みます。
一つ目は、残業代が減る場合です。昇格と同時に管理職として扱われ、時間外の手当が止まると、基本給の増額を打ち消すことがあります。ただし、労働基準法の「管理監督者」に当たるかは、役職名ではなく職務の内容、責任と権限、勤務の実態、待遇で判断されるとされています。社内で管理職と呼ばれていても、該当しなければ時間外の割増賃金の支払いが必要です。個別の判断は労働基準監督署などに確認してください。残業代を含めた比べ方は管理職と残業代で扱っています。
二つ目は、役割だけが変わって等級が変わらない場合です。「次の案件からは要件定義も」と言われても、給与の条件が同じなら、責任だけが増えます。引き受ける前に、どの等級の仕事として扱われるのかを聞いてください。
三つ目は、外部の担当を調整するだけの役割になる場合です。発注の管理が中心になり、技術の判断が減ると、数年後に転職するときに説明できる実績が細ります。事業会社の情報システム部門などでは、役割の中身によって評価が分かれます。
工程で分けない会社では、問い方が変わる
自社のサービスを開発する会社では、工程ごとに担当を分けないチームもあります。その場合、「上流へ移る」という考え方自体が当てはまりません。評価されるのは、課題の定義から設計、実装、運用までのどこまでを自分で持てるかです。
たとえば、顧客の問い合わせを分析して改善案を作り、実装してから効果を測った人は、工程の呼び名がなくても上流の判断をしています。SIerから自社開発へ移る人は、「要件定義の経験があります」だけでなく、「何を捨てる判断をしたか」を話せると伝わります。
逆に、自社開発の人がSIerの求人を見るときは、工程の言葉に翻訳する必要があります。担当した範囲を要件定義、基本設計といった言葉に置き換えて、職務経歴書に書くと、読み手の判断が早くなります。
インフラの上流は「非機能」を決める仕事
インフラエンジニアの上流は、業務の要件より、止まってよい時間、データ量の見込み、費用、権限といった非機能の条件を決める仕事です。これが曖昧なまま進むと、作った基盤が要求に合わず、後から大きな作り直しが必要になります。
求人票に「上流工程」とあっても、インフラの場合は決まった構成の詳細を詰める仕事を指すことがあります。面談では、可用性の目標や費用の上限を誰が顧客と合意するのかを聞いてください。段階ごとの打ち手はインフラエンジニアが年収を上げる方法で整理しています。
下流から上流へ移る5つの手順
移る順番は、範囲を小さく始めて、説明できる実績を残すことが基本です。
- 今の設計書を読み、実装やテストで困った箇所を、仕様の問題として書き出す
- 詳細設計のうち、担当機能の例外や性能の方針を自分で提案する
- 顧客や企画側との仕様確認に、確認事項を自分で作って参加する
- 小さな機能で、基本設計の案を作り、上位の担当者のレビューを受ける
- 判断した内容、選ばなかった案、結果を記録し、等級の要件と照らして上司に伝える
1と2は、今の担当のままで始められます。テストで同じ種類の不具合が繰り返されるなら、仕様のどこが曖昧かを示すだけでも、上流の入口の仕事になります。3と4は上司の協力が必要なので、「次の案件で、この範囲を担当させてほしい」と具体的に頼みます。
半年ほど試しても機会が得られない場合は、配属の変更を相談するか、外の求人を比べます。客先常駐で、上位の会社が工程を固定している現場では、本人の努力だけでは範囲を広げられないことがあります。
フリーランス単価で上流の値段を見るときの注意
公的統計でも、上流の職種と実装の職種は別に集計されています。厚生労働省の賃金構造基本統計調査では、システムコンサルタント・設計者の平均年齢は 38.3歳、ソフトウェア作成者は 37.1歳 で、上流の職種のほうが年齢の構成が高めです。上流や管理の役割に高い報酬が付きやすい方向は、独立しても変わらないと考えられます。
ただし、これは会社員の統計で、フリーランスの単価ではありません。また、上流の案件は相応の実績を前提に募集されるので、「上流へ移れば単価が上がる」とは読めません。独立を考えるときは、フリーランスの単価と手取りの手順で、手元に残る額を計算してください。
この記事の見方が当てはまらない場合
ここでの条件は、請負や準委任の案件で工程が分かれた働き方を中心にしています。研究開発や組み込みの現場では、工程の分け方が異なり、深い実装の専門性が評価の中心になることがあります。そうした現場で無理に要件定義へ移ると、強みを手放す結果になりかねません。
モデルの推定レンジは工程を区別していないので、「上流なら表の上の行」とは読まないでください。統計の年収換算額も、個人の到達額を示すものではありません。実際の金額は、上流を含む求人の提示額と、現在の会社の等級表で確かめてください。
上流へ移る前の最終チェック
- 自分の担当が判断か補助かを、直近の案件で確かめた
- 発注元と自社の間に何社あるかを確認した
- 上流の役割がどの等級に当たるかを聞いた
- 残業代、手当、賞与の変化を内訳で確認した
- 実装の知識で弱い部分を書き出した
- 判断した内容と選ばなかった案の記録を始めた
上流へ移るかどうかは、工程の名前ではなく、自分の判断が増えて、それが給与に届く道があるかで決まります。その前に、今の条件での水準を確かめておくと、社内と転職のどちらを先に試すかを決めやすくなります。