結論｜市場価値の差は「PMOか上流設計か」というラベルの差ではなく、何をどこまで担えるかで決まります。
- SAP PMOとSAP上流設計の実務上の違い
- 市場価値差が生まれる6つの構造要因
- PMOと上流設計それぞれが強い場面・強くなりにくい場面
- PMOのままでよいか、上流に寄せるべきかの判断軸
「PMOは単価が低い」
「上流に行けば市場価値が上がる」
そのように語られることがあります。
しかし、その理解は正確ではありません。
PMOでも高単価の案件はありますし、上流設計でも伸びにくい条件があります。
市場価値差が生まれる本当の要因は、役割名ではありません。
顧客接点・意思決定関与・スコープ責任・業務影響度・専門性・フェーズの重なり方で決まります。
この記事では、SAP PMOとSAP上流設計を同じ比較軸で整理します。
「どちらが上か」ではなく「どの条件で価値が出るか」を整理することが目的です。
SAP PMOと上流設計は、何が違うのか
PMOと上流設計は、現場でよく対立的に語られます。
しかし実際には、単純な上下関係でも、完全に別物でもありません。
まず両者の役割を整理します。
SAP PMOとは何をする役割か
SAP PMOは、プロジェクト全体の成功確率を上げるために存在する役割です。
進捗管理、課題管理、会議体運営、標準化、横断調整、チェンジ管理などが主な業務になります。
ただし、「PMO＝議事録係」「PMO＝報告書作成」という理解は正確ではありません。
支援型PMOはその性質が強くなりがちですが、領域PMOや全体PMOでは意思決定への関与も深くなります。
PMOの市場価値は一律ではなく、担う範囲と関与の深さで変わります。
支援型に留まると市場価値が伸びにくい構造については、PMOキャリアが停滞するパターンを整理するで整理しています。
SAP PMOのキャリア構造全体については、SAP PMOのキャリア構造を確認するも参照してください。
SAP上流設計とは何をする役割か
SAP上流設計は、要件定義・FIT&GAP・基本設計・業務プロセス設計を担う役割です。
業務部門と直接対話し、業務要件を仕様へ落とし込む過程で価値を出します。
顧客接点が近く、意思決定に関与しやすい場面が多いため、「上流は強い」と語られやすい面があります。
しかし、単一モジュールの浅い作業に留まる場合は、単価の上限が見えにくくなることもあります。
要件定義とFIT&GAPの実務については、SAP上流設計の要件定義とFIT&GAP構造を確認するで整理しています。
両者は対立ではなく、一部重なる
PMOと上流設計は「別の仕事」ですが、実務では重なる部分があります。
PMOでも設計議論に踏み込むことがあります。
上流設計でも全体調整が求められることがあります。
大規模なS/4HANA移行案件では、PMOが業務要件整理に関与するケースも現場では見られます。
違いは「何をやるか」より「どこで価値を出すか」の重心にあります。
PMOは全体最適・横断統制で価値を出し、上流設計は業務変革・要件決定で価値を出します。
この重心の違いが、市場価値の差を生み出す起点になります。
市場価値は「PMOか上流か」ではなく、何をどこまで担えるかで決まる
単価差や市場価値差は、役割ラベルではなく構造要因で生まれます。
この構造を理解しないまま「PMOだから低い」「上流だから高い」と判断すると、現実と異なる場合があります。
市場価値は「任せられる範囲×再現性」で決まる
市場が評価するのは肩書きではありません。
「何を任せられるか」と「それを再現できるか」の掛け合わせで評価が決まります。
PMOでも上流設計でも、この構造は変わりません。
範囲が広くても再現性がなければ評価は安定しません。
逆に再現性があっても、担える範囲が狭すぎると単価の上限が早く見えます。
市場価値の構造については、任せられる範囲で市場価値を整理するで詳しく整理しています。
単価差はラベル差ではなく構造差で生まれる
案件サイトやエージェント記事ベースで整理すると、単価に影響する要因として次のものがあります。
- 顧客接点の近さ：エンド直か、元請けに近い商流かで差が出やすい
- 意思決定への関与：支援側か、決める側に近いかで評価が変わる
- スコープ責任の広さと重さ：横断的な責任ほど評価されやすい傾向がある
- 業務への影響度：間接的か直接的かで単価への影響が異なる
- 専門性の深さ：モジュール知識と業務知識の組み合わせが評価される
- フェーズの位置：要件定義〜基本設計のフェーズが単価への影響が最も大きくなりやすい
単価が上がらない構造については、SAPコンサルの単価が上がらない構造を確認するで整理しています。
面談での評価と単価提示の関係については、単価提示の評価フレームワークを確認するも参考になります。
比較表：SAP PMOと上流設計を6軸で並べる
市場価値に影響する6軸で、PMOと上流設計を並べます。
この表の目的は優劣の判定ではなく、「どの条件で差が出るか」を整理することです。
| 比較軸 | SAP PMO | SAP上流設計 |
|---|---|---|
| 主な目的 | プロジェクト成功確率の向上、遅延防止、標準化 | 業務要件整理、業務変革、設計責任 |
| 顧客接点 | 間接〜中程度。指揮型で高まる | 高め。業務部門と直接対話しやすい |
| 意思決定関与 | 支援型では薄い。指揮型で深まる | 決める側に近い立場になりやすい |
| スコープ責任 | 横断的・全体最適が得意領域 | 深さはあるが、モジュール・業務軸に限定されやすい |
| 専門性 | 横断調整、標準化、チェンジ管理 | モジュール知識、業務知識、設計力 |
| 業務影響度 | 間接的に高い | 直接的に高い |
| 関わるフェーズ | 全フェーズ横断 | 要件定義〜基本設計が中心 |
| 単価傾向 | 補佐〜領域〜全体で段階差が大きい | 上流参画と専門性が組み合わさると上限が上がりやすい |
| 伸びる条件 | 指揮型、全体統括、S/4HANA移行、再建案件 | エンド直、業務変革、S/4HANA、モジュール深度 |
| 伸びにくい条件 | 進捗管理・議事録止まり | 単一モジュールの浅い作業、小規模、間接商流 |
この表から見えるのは、PMOと上流設計の優劣ではありません。
どの条件を満たしているかで、市場価値の出方が変わるということです。
同じPMOでも、担う範囲と役割の深さで評価は大きく変わります。
SAP PMOの方が強い場面、上流設計の方が強い場面
「どちらが強いか」ではなく「どこで強いか」を整理します。
場面と条件によって、評価の比重は変わります。
PMOの方が強い場面
次の場面では、PMOの横断性が直接評価につながります。
- 大規模移行案件での全体統制：複数モジュール・複数チームを横断する統括責任
- リスク管理と課題収束：複雑な案件での問題収束と関係者調整の主導
- 標準化とチェンジ管理：組織横断でプロセスを変える役割
- 再建案件での指揮：停滞した案件を立て直すPMOは、高い評価を受けやすい
案件サイトやエージェント記事ベースでは、領域統括で100〜140万円程度、全体PMOで130万円超が目安になりやすい傾向があります。
ただし支援型に留まると、この水準には届きにくい構造があります。
上流設計の方が強い場面
次の場面では、上流設計の専門深度が評価されやすくなります。
- 業務変革フェーズ：業務プロセスを設計し直す責任を担う場面
- 要件決定の場面：業務部門と直接折衝し、要件を仕様へ落とす役割
- モジュール専門性が問われる場面：特定領域の深い知識が差別化になる
- S/4HANA移行での業務設計：業務要件の整理と新プロセスの設計
上流設計は、要件定義フェーズやモジュール専門性と組み合わさると、120〜180万円程度のレンジに入りやすい傾向があります。
ただし、単一モジュールの浅い作業だけでは、同じ上流でも伸びにくい面があります。
単価差が広がる条件、縮まる条件
上流が優位になりやすい条件：
- エンド直で業務変革の主担当を担う
- 要件定義フェーズで顧客折衝に入る
- S/4HANA移行での業務設計責任
PMOが逆転しやすい条件：
- 指揮型PMOとして全体統括を担う
- 再建案件でリスク収束を主導する
- チェンジ管理と標準化を横断責任で担う
上流でも伸びにくい条件：
- 単一モジュールの浅い設計作業に留まる
- 間接商流で顧客接点が薄い
- 小規模案件で意思決定関与が限定的
PMOキャリアの停滞パターンは、PMOキャリアが停滞するパターンを整理するで整理しています。
上流設計案件でのリスクについては、SAP上流案件の炎上リスクを確認するも参照できます。
責任と裁量のミスマッチについては、責任と裁量のミスマッチ構造を整理するで整理しています。
PMOのままでいいのか？ 上流へ行くべきか？
「PMOを続けるべきか」「上流へ移るべきか」は、SAPコンサル3〜7年目が直面しやすい問いです。
答えは一律ではありません。
自分がどこで価値を出しやすいかによって変わります。
PMOを続けたほうがいい人
次の特徴がある人は、PMOとして市場価値を伸ばしやすい傾向があります。
- 全体最適で考えることが自然にできる
- 利害調整や関係者管理が苦でない
- 横断責任を担うことへの抵抗が少ない
- 支援型から指揮型へのステップを意識できている
PMOは支援型で止まると評価が伸びにくいですが、指揮型・全体PMO・領域統括へと責任を広げていけると、市場価値は上がりやすくなります。
次の案件で担える範囲を広げることを意識できているかが、分岐点になります。
上流設計へ寄せたほうがいい人
次の特徴がある人は、上流設計へ軸を移すことで市場価値が伸びやすい傾向があります。
- 業務理解を深めることに充実感を感じる
- 要件を自分で決める立場に近づきたい
- 特定モジュールの専門性をさらに磨きたい
- 顧客と直接業務議論をしたい
ただし「上流に行けば単価が上がる」と単純に考えるのは早計です。
担う役割の深さと顧客接点の近さが揃って初めて、単価への影響が出てきます。
上流への移行を検討するなら、どの案件で・どの責任を担うかを先に設計する必要があります。
PMOから実務へ戻れる人・戻れない人
PMOから上流実務へ戻ることを検討する場合、戻りやすい条件があります。
PMOに入る前の実務経験が深いほど、実務に戻りやすくなります。
一方、PMO専業が長期化すると、モジュール知識の鮮度が落ちる場合があります。
戻れる条件と戻りにくい条件については、PMOから実務に戻れる条件を整理するで整理しています。
PMOから抜けるべきタイミング
PMOを続けるべきか、抜けるべきかの判断には、タイミングの基準があります。
「支援型PMOに留まっている期間が長くなっている」「専門性が蓄積されていないと感じる」といったサインが出てきた場合は、見直しを検討する時期かもしれません。
判断のタイミングについては、PMOから抜けるべきタイミングを整理するで整理しています。
上流に向いている人の特徴
上流設計で価値を出しやすい人には、業務知識への関心・要件を言語化する力・顧客折衝への耐性など、複数の要素が重なっています。
向き不向きを感覚で判断するより、これらの要素を一つずつ確認するほうが判断しやすくなります。
業務知識の必要水準については、業務知識の必要水準を整理するが参考になります。
上流コンサルタントに共通する習慣については、上流設計者に共通する習慣を確認するも参考になります。
S/4HANA移行では、PMOと上流設計の価値はどう変わるか
S/4HANA移行案件では、PMOと上流設計の両方の需要が高まっています。
全体統制とチェンジ管理の複雑さ、業務プロセスの再設計の必要性が同時に発生するため、どちらの役割も評価されやすい構造があります。
PMOは全体統制とチェンジ推進で価値を発揮しやすくなります。
複数モジュール・複数チームを横断する統括責任は、S/4HANA移行規模のプロジェクトでは特に評価されます。
上流設計は業務設計と要件整理で価値を出しやすくなります。
ECC→S/4HANAへの移行に伴う業務プロセスの見直しは、要件定義力と業務知識の組み合わせが問われる場面です。
現場で見聞きした範囲では、S/4HANA移行案件ではPMOと上流設計の協業価値も上がっており、両方の経験がある人が評価されやすいケースが増えています。
どちらか一方に特化するよりも、両面の視点をもつことが案件の中でも差別化につながりやすい傾向があります。
S/4HANA移行でのスキル価値については、S/4HANA移行でのスキル価値を整理するで整理しています。
まとめ｜評価されるのは、上流の深さとPMOの横断性をつなげられる人
PMOか上流か、という二択で考える必要はありません。
支援型PMOで止まると伸びにくくなります。
浅い上流設計でも同様です。
この2点は共通しています。
評価されるのは、上流の専門深度とPMOの横断責任を接続できる人です。
両方の視点を持つことで、案件全体を設計力と統制力の両面から動かせるようになります。
キャリアを設計するうえで問うべきなのは、「PMOか上流か」ではありません。
「自分は今どの要因を担えていて、どの要因が足りないか」です。
ラベルではなく要因で見ると、次の判断が変わります。
- PMOを続けるなら、横断責任と指揮型への移行を設計できているか
- 上流へ寄せるなら、業務知識と顧客接点の深さを積めているか
- 両方の経験があるなら、それをどう接続して市場に提示できるか
面談での評価と市場価値の提示については、面談での評価を獲得する構造を確認するで整理しています。
任せられる範囲と再現性の整理は、任せられる範囲で市場価値を整理するも参照してください。
次にやること｜構造理解を「自分の現在地」に落とす
ここまでで、「PMOか上流設計か」ではなく、
どの要因をどこまで担えているかで市場価値が決まるという整理はできたはずです。
ただし、この理解だけでは不十分です。
実際のキャリアは、「構造を理解しているか」ではなく、自分がどの位置にいるかを説明できるかで結果が変わります。
例えば、次のような状態に陥りやすくなります。
- 市場価値の構造は理解しているが、自分の強みとして提示できない
- 任せられる範囲を言語化できず、面談で評価が伸びない
- 上流に行くべきか、PMOで伸ばすべきかの判断が曖昧なままになる
本記事で整理した6軸（顧客接点・意思決定関与・責任範囲など）も、自分の経験に紐づけて言語化できて初めて意味を持ちます。
その整理を体系的に行いたい場合は、こちらのnoteを参考にしてください。
