SAPコンサルと社内SEの違い

SAPの導入プロジェクトでは、コンサルと、事業会社の情報システム部門（情シス）の担当者が一緒に仕事をします。どちらもSAPの知識を持ち、要件定義や設計の場に並んで座りますが、何に責任を持ち、どこまで先を見ているかが違います。

この記事では、導入プロジェクトで見てきた範囲で、2つの立場の違いを整理します。コンサルから社内SE（事業会社のSAP担当）への転職を考えている人や、逆に社内SEからコンサルを見ている人に向けた内容です。

一言でいうと

コンサルは課題解決の専門家で、情シスは自社のシステムを支え続ける当事者です。どちらにも専門性は必要ですが、責任を持つ期間と範囲が違うため、同じ課題を見ても判断の重心がずれます。

情シスは「その後の何年か」を見ている

コンサルはプロジェクト単位で参画するため、目の前の課題を、決められた期間の中で解決することが求められます。一方、情シスはプロジェクトが終わったあともシステムを運用していく立場です。そのため、同じ設計を見ても、次のような点を重く見ます。

• 運用の負荷：毎月の締めや年次の切替で、誰がどれだけ手を動かすことになるか
• 他システムへの影響：周辺システムとのインターフェースや、既存の帳票・データ連携が崩れないか
• 現場の使いやすさ：業務部門が日々の入力や照会を無理なくこなせるか。問い合わせが情シスに集中しないか

コンサルの提案は、SAPの標準や統制の観点では正しいことが多いのですが、情シスはそれを「この会社の、この人員で、何年も回せるか」というものさしで測り直します。

権限設計で意見が分かれた例

この違いがよく表れたのが、権限設計の場面でした。コンサル側は、内部統制とセキュリティの観点から、業務ごとに使える機能を細かく分ける方針を提案しました。支払の登録と承認を別の人に分けるなど、職務分掌（一人に不正や誤りの機会が集中しないよう、業務を分担させる考え方）を権限で担保する設計です。

これに対して情シスの担当者からは、「実際の現場では、一人の担当者が複数の業務を兼任している。権限を細かく分けすぎると、日常の業務が回らなくなる」という指摘がありました。情シスは業務フローだけでなく、誰が何を兼任しているかという人員配置まで把握していたため、設計どおりに運用できるかを具体的に判断できたのです。

結果として、内部統制上どうしても必要な制約は残しつつ、実際の担当に合わせてロール（権限をまとめた単位）の割り当て方を見直すことで決着しました。コンサルが統制の観点で最適な形を示し、情シスが現場で無理なく運用できる形に寄せる、という役割分担になった例です。

社内SE（SAP担当）に求められるスキル

事業会社のSAP担当の求人を見ると、求められる経験はおおむね次のようなものです。2026年10月時点で求人サイトを見た範囲では、年収は500万〜800万円台の帯が多く、管理職やグローバル案件ではそれより高い求人もありました。

• いずれかのモジュール（FI・CO・MM・SDなど）の導入または運用の経験。3年以上を条件にする求人が多い
• 業務部門へのヒアリングと課題整理、要件定義、基本設計書の作成
• テストの計画と実施の支援、稼働後の問い合わせ対応
• ベンダー（コンサル・保守会社）の管理
• 海外拠点がある会社では英語。拠点との調整に使う

コンサル出身者が強みにしやすいのは、要件定義とSAP標準の知識です。逆に、社内の稟議や予算の取り方、業務部門との長期的な関係づくりは、入ってから身につけることになります。

どちらが向いているか

転職先を探すなら

社内SEの求人は、一般の転職サイトでは「SE」「システムエンジニア」の大きな括りに埋もれがちです。社内SEに絞った転職サービスや、コンサル・DX領域に強いエージェントを使うと、SAP担当の求人を見つけやすくなります。

この記事に出てきた名前