「SAPとは」で検索すると、たいていこう説明されます。ドイツ生まれのERPパッケージで、会計・購買・販売・在庫・生産・人事が一つのデータの上で動く統合基幹業務システムである、と。

間違っていません。ただ、この説明を10回読んでも、その現場で人が毎日何をしているのかは一行も分からない。私はそこで長いこと足踏みしました。

私は経理からこの領域に入り、アビームコンサルティング、アクセンチュアを経て、いまはSAPのFI（財務会計）を中心に導入プロジェクトを見ています。振り返ると、SAPが分かった瞬間というのは、製品の説明を理解したときではありませんでした。「この仕事は、会社の決めごとをシステムの設定に落とす仕事だ」と腹に落ちたときです。

この記事は、製品の説明をやり直す記事ではありません。案件の説明をします。何という単位で仕事が募集され、誰と誰がいて、自分はどこに立って、毎日何をしているのか。そこから逆にSAPを説明します。

製品としてのSAPは、ここまで分かれば足りる

先に、製品の側を最短で片づけます。ここは3分でいい。

  • SAPは、ドイツのSAP SE社が作っている業務システムのパッケージです
  • 会計、購買、在庫、販売、生産、人事といった業務が、同じデータの上で連動するのが最大の特徴です
  • 大企業を中心に、日本でも基幹システムとして広く使われています
  • 旧世代のSAP ECCから、現行世代のS/4HANAへの移行が、いま各社で進んでいます

現場で意味を持つのは、実はこの4つ目です。ECCの標準保守は2027年末に区切られており（有償の延長保守で2030年末までという選択肢はあるものの、限定的です）、そのため移行プロジェクトが各社で立ち上がっています。この事情が、いま案件が多い理由そのものです。詳しくはS/4HANAへの移行で案件は本当に増えるのかに書きました。

製品の説明は、本当にここまでで足ります。機能の一覧を覚えても、案件では一度も使いません。

案件の側から見ると、SAPは「決めごとを設定に落とす仕事」になる

ここからが本題です。

会社には、数え切れないほどの決めごとがあります。売上をいつ立てるか。締めは何日か。誰の承認が要るか。原価をどう配賦するか。どの単位で在庫を持つか。これらは普段、担当者の頭とExcelと、慣習の中に散らばっています。

SAPを入れるというのは、その決めごとを一度全部引きずり出して、明文化して、システムの設定として固定するということです。

SAPの導入プロジェクトで起きていることの正体は、システムの構築ではなく、会社の決めごとの棚卸しと再決定である。

だから難所は技術ではありません。難所は、決まっていなかったことを、決めさせることです。

「その承認、いまは誰がやっていますか」と聞いて、「部長です」「いや、忙しいときは課長が」「実質は担当が押しています」と三人から違う答えが返ってくる。この状態のまま設定はできません。誰かが交通整理をして、決めて、決めた結果を文書にする必要があります。SAPコンサルの仕事時間の大半は、この整理と合意形成に溶けています。

導入プロジェクトは、こういう順番で進む

案件の話をするには、工程を知っているほうが早い。標準的な導入は、おおむねこの順で進みます。

工程やることコンサルの主な役割
構想・企画何のために入れ替えるかを決める。範囲と予算の骨格経営層との議論。参画するのは上位層が中心
要件定義現行業務を洗い、あるべき姿を決めるいちばん人が要る。決めごとの引き出しと合意形成
設計決めたことを、設定と追加開発に振り分ける標準機能でどこまでやるかの線引き
開発・設定実際に設定を入れる。追加開発は開発者が作る設定は自分で手を動かす。仕様は自分が書く
テスト単体、結合、そして業務部門による受入テストシナリオを作り、出た不具合を切り分ける
データ移行旧システムの残高やマスタを移す会計の残高が合うかは会計側の担当が見る
本番稼働・稼働直後切替。初回の締めを乗り切るここが山。問い合わせが一気に来る
保守・運用障害対応、追加の改修、法改正対応導入とは別の仕事に変わる

案件の募集がいちばん多いのは、要件定義から本番稼働までの帯です。人が要るのはここだからです。

そして独立して受ける立場から見ると、導入案件と保守案件は、まったく別の仕事です。ここは後でもう一度書きます。

仕事は「モジュール」という単位で割られている

SAPの案件情報を見ると、必ずアルファベット2文字が付いています。これがモジュールで、業務領域の区切りです。募集はほぼこの単位で来ます。

略号領域ざっくり何をする人か
FI財務会計仕訳、債権債務、固定資産、決算。外に出す数字を作る
CO管理会計原価、配賦、収益性分析。中で使う数字を作る
MM購買・在庫発注、入庫、請求書照合
SD販売受注、出荷、請求
PP生産生産計画、製造指図
HR/HCM人事人事マスタ、給与
ABAP追加開発標準機能で足りない部分をプログラムで作る

私はFIを軸にしています。FIとCOは境目が曖昧に見えますが、実務では見ている相手が違います。FIは外（監査法人、税務、開示）を向いていて、COは中（事業部、経営）を向いている。この違いはSAPのFIとCOの違いに分けて書きました。

**モジュールをどれか一つ、縦に深く取ることが、この領域でのキャリアの基本形です。**広く浅く全部を触った人より、FIだけを5年やった人のほうが案件では選ばれます。どのモジュールから入るかの考え方はSAPのモジュール、どれを選ぶかに整理しました。

要件定義の現場で、実際にやっている作業

抽象的な説明が続いたので、具体を出します。FIの要件定義で、私が実際にやっていることです。

1. 現行のやり方を、聞いて書く

経理部に行って、月次の締めを何日にどうやって回しているかを、手順の粒度で聞きます。「25日に売上を締めて」ではなく、「誰が、どのファイルを、どこから取ってきて、何を突き合わせて、誰に渡すか」まで落とします。ここで初めて、システムに載っていない作業が大量に出てきます。

2. 標準機能でできるか、を判定する

聞いた要望を、そのままシステムに作るわけではありません。SAPには標準のやり方があり、そこに業務を寄せられるなら、そのほうが安く、後の保守も楽です。判定は3択になります。

  • 標準機能の設定で実現できる（いちばん良い）
  • 業務のやり方を少し変えれば、標準で実現できる（説得が要る）
  • どうしても追加開発が必要（費用と保守負担が増える）

この3択の2番目を通せるかどうかが、コンサルの腕です。「できません」でも「作ります」でもなく、「こう変えれば標準で回ります、その代わりここが楽になります」と言えるかどうか。

3. 決めた内容を文書にして、承認をもらう

口頭で合意しても、3か月後には全員が別のことを覚えています。決めたことは必ず書いて、業務部門の承認をもらいます。地味ですが、**この文書が後半の防波堤になります。**テストで揉めたとき、稼働後に「聞いていない」と言われたとき、根拠になるのはこの紙だけです。

4. 設定を入れて、動かして見せる

設定作業そのものは、慣れれば時間はかかりません。難しいのは、入れた設定が業務のどこに効くかを説明することです。会計期間を締める設定ひとつで、月末の現場の動き方が変わります。

この仕事の難しさは、製品知識の側にはない

未経験の方からよく聞かれるのが、「覚えることが膨大で無理ではないか」という不安です。正直に答えます。

**製品知識は、案件をやりながら覚えられます。**設定項目の意味も、トランザクションコードも、現場で使えば身につきます。ここは時間の問題です。

きついのは別のところです。

  • 決められない会社の、決めごとを決めさせる。権限のない立場で、部門間の利害を調整することになります
  • 誰も全体を知らない。現行業務の全体像を持っている人が、その会社にいないことがあります
  • 後半に効いてくる判断を、前半でしている。要件定義で置いた前提が、稼働直前に牙をむきます
  • 稼働直後の1か月。初回の決算を回しきるまでは、電話が鳴り止みません

現場のきつさの正体は、時間の長さだけでは説明しきれません。そちらはコンサルはきついのかに、盛らずに書きました。

逆に言えば、業務を分かっていて、人の話を整理できる人には、向いている仕事です。経理出身者がこの領域で強いのは、まさにここです。仕訳の意味が分かる人は、要件を聞いた瞬間に「それは資産計上か費用か」を確認できます。分からない人は、そこを飛ばして設計してしまう。

私自身が経理からこの領域に移った経緯は、経理からSAPコンサルへ転身した実話に書いています。

入口は一本ではない

「SAPコンサルになるには」を調べると、たいてい転職の話だけが出てきます。実際には入口が複数あり、入った後に見えるものも違います。

入口最初に任されること弱点になりやすいところ
新卒でコンサル会社に入るテストや資料作成から。教育の仕組みがある業務そのものを知らないまま設計に入る
IT側から中途で入る設計や開発の周辺。技術の会話ができる会計・業務の言葉が最初は入ってこない
経理・業務側から中途で入る業務要件の整理。現場との会話が強いシステムの制約が体感で分からない
事業会社のユーザー側で経験する自社の導入プロジェクトに参加する一社のやり方しか知らないまま出る

どれが有利かではありません。**足りない側を後から埋めた人が、最終的に強くなります。**IT側から入った人は会計を、業務側から入った人はシステムの制約を、それぞれ意識して取りに行く必要があります。

未経験からの現実的な道筋は未経験からSAPコンサルへのロードマップに、資格の効き方はSAPの資格は要るのかに分けて書きました。

独立して受ける側から見ると、導入と保守は別の商品になる

ここは、いずれ独立を考えている人向けです。

同じ「SAPの案件」でも、導入と保守では受け方がまるで違います。

見る軸導入案件保守・運用案件
期間数か月〜数年。終わりがある継続。切れにくい
稼働の波山と谷が激しい。稼働直前は重い平坦。読みやすい
求められるもの決めさせる力、設計の判断早い切り分け、業務の網羅的な理解
単価の作られ方役割の重さで決まる対応範囲と時間で決まりやすい
独立直後の相性実績が要る。いきなりは入りにくい入りやすいが、実績になりにくいこともある

独立して最初の1年は、この二つを混ぜて持つ人が多い。保守で稼働の土台を作り、導入で実績と単価を作るという組み方です。私も最初はその形でした。

単価がどう決まるかの構造はSAPコンサルの単価に、独立が現実的かどうかはSAPコンサルの独立は現実的かに書いています。

「SAPとは」に、私なりに一行で答える

最後に、最初の問いに戻ります。

SAPとは、会社の決めごとを一箇所に固定するための仕組みであり、SAPコンサルとは、その決めごとを引き出して、決めさせて、設定に落とす仕事である。

製品の説明としては不正確かもしれません。でも、案件の説明としてはこれがいちばん近い。私はこの理解に辿り着くまでに、数年かかりました。

そして、この定義が正しいとすれば、この仕事に一番効く経験は、業務そのものを回した経験だということになります。経理でも、購買でも、生産管理でもいい。自分が現場で「これ、なんでこうなってるんだろう」と思った回数が、そのまま資産になります。

まとめ

  • 製品としてのSAPは、業務が同じデータの上で連動するパッケージ。知っておくべきはECCからS/4HANAへの移行が進んでいることまでで足りる
  • 案件の側から見ると、SAPの仕事は会社の決めごとを引き出し、決めさせ、設定に落とす仕事
  • 工程は構想から保守まであり、人が最も要るのは要件定義から本番稼働まで
  • 仕事はFI・CO・MM・SDといったモジュール単位で募集される。一つを縦に深く取るのが基本形
  • 難しいのは製品知識ではなく、決まっていないことを決めさせること
  • 入口は新卒・IT側・業務側・ユーザー側の複数がある。足りない側を後から埋めた人が強くなる
  • 独立して受けるときは、導入案件と保守案件は別の商品として考える

いま自分が持っている業務経験のどこがこの領域で効いて、何が足りないのかを整理したい方は、30秒の無料診断から始めてみてください。製品を覚える前に、自分の現在地が言葉になるほうが先です。