SAPコンサルタントとはどんな仕事か｜役割と求められる経験

求人票に「SAPコンサルタント（会計領域）」と書かれていても、業務内容の欄を読んだだけでは、その人が毎日何をしているのかが浮かびません。職種名に製品名が入っているせいで、製品にとても詳しい人か、製品そのものを作っている人だと受け取られがちですが、どちらも実態とはずれます。

ERPの導入プロジェクトで大半の時間が使われているのは、設定画面に向かう作業ではありません。「いまの業務のやり方のうち、どこを製品の標準的な処理に寄せ、どこを作り込み、どこをやめるか」を決める作業です。SAPコンサルタントは、この判断を業務領域ごとに引き受ける役割を指します。製品知識は判断のための材料であって、仕事の本体ではありません。

この記事では、導入プロジェクトの工程に沿って、どの場面で何を決める人なのかを整理します。製品のバージョンごとの機能や価格には触れません。役割名や領域の区切り方は会社によって差があるため、最終的には応募先の説明で確認する前提で読んでください。

この職種が繰り返し求められる判断は3種類

案件が変わっても、コンサルタント側に持ち込まれる判断はおおむね次の3つに集約されます。

• 現行業務のどこまでを製品の標準的な処理の流れに寄せるか。寄せれば構築も保守も軽くなりますが、現場の手順は変わり、説明と合意が必要になります
• 標準に寄せられない業務を、追加開発で作るのか、運用の手作業でしのぐのか、業務そのものをやめるのか
• 既存システムから持ってくるデータをどこまで移すか。過去分を全部持っていくと、移行の期間もテストの量も膨らみます

どれも、正解が製品側にあるわけではありません。決めるのは顧客ですが、選択肢と、それぞれを選んだ場合に後工程で何が起きるかを示すのがコンサルタント側の役割です。「詳しい人」との違いはここに出ます。標準機能の仕様を答えられることと、その業務でそれを採用してよいかを判断できることは、別の能力です。

工程が進むと、担当範囲は「決める」から「合わせる」へ移る

導入プロジェクトは、おおむね次の順で進みます。構想・企画、要件定義、設計、構築と設定、テスト、データ移行と稼働、稼働後の安定化です。コンサルタントと呼ばれる人がどこに入るかは、案件と会社によって変わります。

前半の要件定義では、現行業務と標準機能の差分を洗い出す作業が中心になります。差分ごとに「寄せる」「作る」「やめる」を判断し、それを一覧として決着させるところまでが山場です。ここで残した差分は、そのまま後工程の作業量になります。

設計から構築に入ると、判断の種類が変わります。決めたことを製品上でどう表現するかという作業が主になり、業務側との会話は「これでよいか確認する」形に寄っていきます。テスト工程では、想定した業務が端から端まで通るかを、実際の担当者に触ってもらいながら確認します。ここで初めて「聞いていた業務と違う」が出てくるのが典型的な進み方です。

稼働直後は、問い合わせ対応と不具合の切り分けに時間が取られます。この時期の負荷が読みにくいことは、働き方を検討するうえで見落とせない点です。

工程のどこを担当するかは、そのまま身につくものを決めます。要件定義から入る案件が多ければ業務側の判断力が積み上がり、構築とテストが中心なら製品の構造に強くなります。求人票を読むときは、募集されている役割がこの並びのどこに置かれているかを確認してください。

業務領域ごとに担当が分かれるため、業務経験がそのまま入口になる

ERPは会社の基幹業務を横断して扱いますが、担当者は領域ごとに分かれます。会計、購買と在庫、生産、販売、人事といった単位です。領域の区切り方と名称は製品の世代や会社の呼び方で変わるので、求人票に書かれている領域名で判断するのが確実です。

分かれる理由は単純で、領域ごとに前提となる業務の言語が違うからです。会計領域では仕訳と決算の締めが会話の土台になり、生産領域では品目の構成と工程の順序が土台になります。どちらも製品の設定項目としては隣り合っていても、話を成立させるために必要な知識が別物です。

この構造があるため、業務側の経験者が入りやすい職種になっています。月次決算を締めてきた人は会計領域の要件定義で何が論点になるかを知っていますし、購買の実務を担ってきた人は発注から検収までのどこで例外が起きるかを知っています。製品の操作は後から覚えられますが、業務のどこが崩れると現場が止まるかという感覚は、外から短期間では手に入りません。

特に接続しやすいのは、数字を「作る」だけでなく「使われ方まで設計してきた」経験です。原価の配賦基準を決めた、事業別の採算をどの単位で見るかを整理した、といった経験は、そのまま導入時の設計論点になります。この種の経験の棚卸しについては、管理会計の経験を生かせる仕事で職種ごとの要求の違いを扱っています。

業務寄りか技術寄りかで、求められるものと次の移り先が変わる

同じプロジェクトの中にも、業務プロセスを決める役割、決まったことを製品上に設定する役割、標準で足りない部分を作る役割があります。募集の名称はどれも「コンサルタント」や「エンジニア」になりがちなので、中身で見分ける必要があります。

	業務プロセス寄り	設定・構築寄り	開発・基盤寄り
主に決めること	業務をどこまで標準に寄せるか、例外を残すか	決まった要件を製品上のパラメータとしてどう表現するか	足りない機能をどう作るか、性能と連携をどう保つか
前提として要る知識	会計・購買・生産などの業務そのもの	業務と製品構造の対応関係	開発言語、他システムとの連携、実行基盤
詰まったときに効くもの	現場の運用を知っていること	過去案件での設定パターンの蓄積	障害の切り分け手順
未経験からの入りやすさ	業務経験があれば接続しやすい	業務側・IT側の両方から入るが、案件経験が求められやすい	IT経験者の移動先になりやすい
経験の持ち出し先	事業会社の業務部門、社内SE、他のERP導入	同種製品の導入プロジェクト	製品を問わない開発・基盤の仕事

この表で見ておきたいのは最後の行です。業務寄りの役割で積んだ経験は、製品が変わっても、事業会社側に戻っても説明できます。一方で設定・構築寄りに寄りすぎると、経験の説明が特定製品の中だけで完結しやすくなります。どちらが良いという話ではなく、5年後にどこへ移れる状態でいたいかで選ぶ材料になります。

なお、製品ベンダーによる認定資格の制度もありますが、取得条件や研修の受け方は改定されることがあるため、実際の要件は募集元や公式情報で確認してください。資格の有無より、どの領域でどの工程を担当したかのほうが先に見られます。

未経験から入る経路は大きく3つ

ここでの「未経験」は、その製品を扱った経験がないという意味です。業務経験もIT経験もない状態からの参入は、どの経路でも簡単ではありません。

	事業会社の業務担当から移る	IT部門・開発から移る	導入を担う会社に育成前提で入る
入口で見られるもの	担当業務の深さと、例外処理まで含めて回した経験	システム間の構造理解、改修や障害対応の切り分け経験	学習の速さと、稼働の変動に耐えられるか
最初に任されやすい範囲	特定領域の要件整理、テストケースの作成と実施	設定作業、他システムとの連携部分	資料作成、テスト実行、議事と課題管理
立ち上がりで苦しむ点	覚える製品構造の量と、隣の領域との連携	業務の目的が分からず、設定の妥当性を判断できない	何が分からないかを言葉にする段階
前段で効いてくる経験	自社の導入・更改プロジェクトに当事者として参加した経験	業務部門との要件のやり取りに入った経験	年齢が上がるほど枠は狭くなる傾向がある

現実的にいちばん通りやすいのは、自社のシステム更改や導入に業務側メンバーとして参加した経験を持っている場合です。ユーザー側として要件を出し、テストをして、稼働後の混乱を経験している人は、プロジェクトで何が起きるかを説明できます。この経験がない場合は、まず現職でその機会を取りに行くほうが、転職活動を先に始めるより順番として無理がありません。

社内SEとして基幹システムの運用に関わる立場から近づく経路もあります。ITコンサルと社内SEでは扱う課題の性質が違うため、どちらの立場から入るかで見える範囲が変わります。この2職種の違いはITコンサルと社内SEの違いで、SIerを含めた3つの働き方の比較は社内SE・ITコンサル・SIerの比較で扱っています。

入ってから最初に詰まるのは、製品の難しさではない

製品の学習は、案件に入って半年も経てば形になります。詰まりやすいのは別のところです。

標準に寄せる提案が通らない

現場は現行の手順で回っており、変える理由を説明されなければ抵抗します。ここで製品の制約を理由にすると話が止まります。業務側の言葉で、変えた後に何が楽になり、何が面倒になるかを両方示せるかどうかで結果が変わります。業務経験者の強みが最も出る場面です。

期間の後半に負荷が集中する

テストと移行の時期は、確認すべき件数が一気に増えます。前半に判断を先送りしていると、この時期に判断と作業が同時に来ます。稼働日が動かせない案件では、ここが働き方として最もきつい時期になります。

担当領域の外で起きた問題が自分に返ってくる

領域は分かれていますが、業務はつながっています。購買側の決めごとが会計側の処理を変えることは日常的に起きます。自分の領域だけを見ていると、テストで初めて衝突が見つかります。隣の領域の担当者と、どの情報が渡るかを早い段階ですり合わせておく必要があります。

稼働後の運用に長く残る場合がある

導入して終わりではなく、稼働後の保守に据え置かれる案件もあります。次のプロジェクトに移れるかは会社の方針と要員配置によるため、面談では直近の担当案件だけでなく、稼働後に人がどう動いているかを聞いておくと実態が見えます。

次にやること

まず、自分の業務経験のうち、どの領域のどの工程に接続するかを一枚に書き出してください。「経理を5年」ではなく、「月次の締めで例外処理をどう判断してきたか」「システムの改修要望をどの粒度で出してきたか」まで分解すると、要件定義側で使える経験かどうかが見えます。分解の手順はキャリアの棚卸しの進め方にまとめてあります。

次に、求人票を3〜5件並べて、領域名（会計、購買、生産など）と、募集されている役割が工程のどこに置かれているかを確認します。同じ職種名でも、要件定義から入る募集と、設定・テスト中心の募集では、求められる経験も入社後に積み上がるものも変わります。この2点が分かれば、自分に足りないのが業務側の深さなのか、プロジェクト経験そのものなのかを切り分けられます。

そのうえで応募に進む段階になったら、支援サービスは領域と工程まで理解している相手かどうかで選びます。判断の基準を先に決めてから登録する手順は、コンサル転職サービスの選び方で整理しています。