SAP上流設計なぜ差が出る？3つの癖で任される人を見抜ける

2026年3月23日2026年4月13日

結論｜上流設計ができる人は知識が多い人ではなく、業務・目的・課題・影響を構造的に再構築できる人である。

この記事でわかること

なぜ同じSAP経験でも上流を任される人と任されない人に分かれるのか
上流設計ができる人に共通する3つの癖とは何か
できない人が「作業者」で止まる理由
自分の行動を変えるために何を変えればいいか

SAP上流設計ができる人と、そうでない人の差は何か。

5年のSAP経験を持っていても、要件定義フェーズを任される人と、詳細設計以降しか担当できない人がいます。
この違いは、FIやCOの知識量ではありません。S/4HANAの構成に詳しいかどうかでもありません。

現場で見聞きした範囲では、差は「思考の癖」にあります。

この記事では、上流設計を繰り返し任される人に共通する癖を、3つのレイヤーに分けて解説します。
スキル論ではなく、「どう考え、どう整理し、どう動かすか」という具体的な行動パターンです。

SAP上流設計ができる人は「要件を再構築している」

上流設計の仕事を一言で表すとすれば、「要件をそのまま受け取って、そのまま作ること」ではありません。

ユーザー部門から上がってくる要件は、そのままでは歪んでいます。
表面に見えているのは「欲しい機能」「直したい画面」です。

背景には、業務課題、組織の制約、将来の運用負担が混在しています。

上流設計ができる人は、最初に「要件を再構築する」という作業をしています。
具体的には、ユーザーが伝えた内容を一度解体し、目的・課題・業務フロー・影響範囲の4軸で組み直します。

この再構築ができるかどうかが、上流に入れるかどうかの分岐点です。

「要件を整理する」と「要件を再構築する」は似ているようで、異なります。

整理は受け取った情報を分類することです。
再構築は、情報の背景にある構造を取り出して、設計に必要な形に組み直すことです。

上流設計に求められるのは後者の再構築です。

上流ができる人の癖は3つのレイヤーに分かれる

上流設計ができる人の行動パターンは、バラバラに見えて構造を持っています。
観察すると、次の3つのレイヤーに整理できます。

思考の癖：何を、どう見るか
整理の癖：どう構造化するか
進め方の癖：どうプロジェクトを動かすか

この3層はそれぞれ独立していますが、上流設計を担える人は3層すべてに一定のパターンを持っています。
1層だけ優れていても、上流全体を回すことは難しい。

逆に言えば、3層のパターンが身についていれば、繰り返し上流を任される人材になれます。

1. 思考の癖｜何をどう見るか

目的から逆算して考える

上流設計ができる人は、ユーザーから要件を聞いたあと、最初に「なぜやるのか」を確認します。

「請求書の承認画面を変えてほしい」という要望が来たとき、即座に画面設計に入ることはしません。
「なぜその変更が必要なのか」「何が承認の妨げになっているのか」を先に問います。

目的が明確でなければ、どんなに精緻な設計をしても方向がズレます。
できない人は「要望＝仕様」として受け取り、言われたものを作ることに集中します。

目的を確認する癖がないと、後工程で「作ってみたが業務に合わなかった」という結果になりやすくなります。

課題を「欲しい」から「困っている」に変換する

「欲しい機能」を「困っている原因」に変換する癖があります。

たとえばユーザーが「FI-MM連携の画面がわかりにくい」と言った場合、できる人は「どんな業務場面でどの判断に迷っているのか」を聞きます。

表面の不満ではなく、その下にある業務課題を扱います。

この変換ができないと、要望を聞けば聞くほど設計が複雑になります。
原因を扱うことで、「その機能を追加しなくても業務課題は解決できる」という判断が生まれることもあります。

個別要件を抽象化してパターン化する

できる人は個別の要件から「共通ルール」を見つけます。

「A社ではこう、B社ではこう」という個別対応をそのまま積み上げるのではなく、「このタイプの業務では、このルールが成立する」という抽象化を行います。

これがカスタマイズを減らし、標準設計の精度を上げる土台になります。

抽象化の癖がない人は、要件をそのまま設計に変換するため、例外ケースが増えるたびに設計が膨らみます。
結果として、保守が難しいシステムができあがります。

部分最適ではなく全体最適で判断する

できる人はFIの設計がMMやSDに与える影響を先に考えます。

「この仕訳設定は、下流の支払処理にどう影響するか」「このマスタ設計は、将来のS/4移行で問題にならないか」を設計段階で確認します。

部分的に正しい設計が、全体を複雑にすることがあります。
運用・保守まで視野に入れる癖が、上流設計の判断精度を支えています。

2. 整理の癖｜どう構造化するか

業務フローから整理してトランザクションに落とす

画面や項目から入るのではなく、業務フローから入ります。

「この購買依頼が来たとき、誰が何を判断するのか」「どのタイミングで承認フローが発生するのか」を先に整理してから、SAPのトランザクションに落とします。

画面ベースで考えると、業務の流れが見えなくなります。
トランザクションの前後に何が起きているかを業務視点で押さえることが、上流設計の基点です。

論点を目的・制約・意思決定に分解する

ひとつの議論に複数の論点が混在していても、それを整理して扱います。

たとえばFit/Gap分析の場では、以下のような論点は別々に整理する必要があります。

目的：そもそもこの業務プロセスを変えるか
実現可能性：このSAPの設定で対応できるか
意思決定：このカスタマイズの承認は誰が取るか

混ぜたまま議論すると、時間が増えるだけで結論が出ません。
論点を分ける癖が、会議の生産性を変えます。

他業務・他システムへの影響範囲を先に洗い出す

設計を固める前に、影響が及ぶ範囲を一覧にします。

「この変更がどのFI転記に影響するか」「どのレポートが変わるか」「連携している外部システムはあるか」を先に出しておくことで、後工程での手戻りが減ります。

できない人は個別要件を1件ずつ処理しながら、後から「あの要件がここに影響していた」と気づきます。
影響範囲を先に洗う癖がないと、設計完了後に前工程に戻る頻度が高くなります。

標準前提で設計してから例外を扱う

最初に「標準で対応できるか」を確認します。
カスタマイズを前提に設計を始めると、後工程での修正コストが増えます。

できる人はFit to Standardの思考が染みついており、「標準でどこまで対応できるか」を先に詰めてから、本当に必要な拡張だけを設計します。

この順序が逆になると、カスタマイズが積み重なり、将来の移行やバージョンアップで負担になります。

3. 進め方の癖｜どうプロジェクトを動かすか

決める順番を方向性→範囲→詳細で設計する

上流設計では「何を、いつ、どの順番で決めるか」が結果を左右します。

できる人は、まず方向性を合意してから範囲を決め、範囲が固まってから詳細設計に入ります。

「細かい話は後でいい。まず大枠を決める」という判断ができるかどうかで、プロジェクト全体のテンポが変わります。

順番が設計されていない場合、細かい議論と方向性の議論が混在し、会議のたびに前の結論が覆ります。

文書化と図解で「合意したつもり」を排除する

「合意したつもり」で進めて後から大きくズレが発覚する、というパターンがあります。

できる人は、口頭で合意した内容を文書・図・箇条書きで明文化し、全員が同じ理解を持っているかを確認してから次のステップに進みます。

認識ズレは後工程に行くほど修正コストが高くなります。
設計段階での文書化が、炎上を防ぐ最初の手です。

不明点を曖昧なままにせず問いとして言語化する

「よくわからないが、おそらくこうだろう」という曖昧な状態をそのまま進めません。

曖昧さはリスクであるため、その場で「確認が必要な問い」として言語化し、誰がいつまでに答えを出すかを明確にします。

できない人は曖昧を曖昧のまま放置し、後工程でそれが炎上の原因になります。
問いに変える癖は、プロジェクトのリスクを可視化する癖と同じです。

共有ではなく合意を取りにいく

情報を「共有する」と「合意を取る」は異なります。

できる人は、意思決定が必要な場面で「これでよいですか」と明示的に確認します。
ユーザー部門、PMO、上位マネージャーそれぞれから必要な合意を取り、前提を固定します。

この癖がないと、設計完了後に「そんな話は聞いていない」という状況が発生します。
合意を取りにいくことは、後工程を守ることでもあります。

できない人はなぜ上流に上がれないのか

上流設計に上がれない人には、共通したパターンがあります。

できない人の行動パターン	結果
要件をそのまま受け取り、再構築しない	設計が要望の積み上げになる
業務フローより先に画面や項目を確認する	業務の流れが見えないまま設計が進む
個別要件を抽象化せず、そのまま積み上げる	カスタマイズが増え、設計が複雑化する
曖昧な状態を放置して進める	後工程で手戻りや炎上が発生する
合意ではなく共有で終わらせる	「聞いていない」が頻発する

これらは意識が低いからではありません。
「作業者」としての仕事の進め方が身についているためです。

詳細設計以降では、要件が決まった状態でいかに正確に実装するかが求められます。
この仕事ではこれらのパターンで問題は出ません。

しかし上流設計では、要件が決まる前の段階から関わるため、受け取る姿勢ではなく再構築する姿勢が必要になります。

上流に行けないのはスキルが足りないからではなく、「上流の仕事の性質が違う」ことに気づいていない場合がほとんどです。