この記事の要点
- 01SAPコンサル会社は大手のコンサルファーム、SIer、専門会社の3つの型に分かれ、違いは得意な工程と体制に出る
- 02会社の規模やパートナーのレベルは会社単位の情報で、自社の案件に入る人の経験までは教えてくれない
- 03先に自社に足りない役割を決め、その役割を担う本人に会って、5つの問いで確かめる
目次6項目
SAPの依頼先を探して検索すると、社名を並べた一覧や順位表がいくつも見つかります。大手のコンサルファーム、SIer、SAPを専門にする会社。候補の名前は挙がるのに、自社がどこに声をかければよいのかは、一覧を読んでも決まりません。
決まらないのは、比べる物差しが会社の側にしかないからだと筆者は考えています。規模、実績の件数、パートナーのレベルは、どれも会社単位の情報です。発注側が先に決めるのは、自社のプロジェクトでどの役割が足りないかです。足りない役割が決まれば、声をかける相手の型と、面談で確かめる人が決まります。
以下、社名は挙げません。書くのは、会社の型と、任せる役割と、提案の場で確かめる問いです。
SAPコンサル会社（SAPコンサルティング会社）は3つの型に分かれる
「SAPコンサル会社」という呼び名に、決まった定義はありません。SAP Japanの「SAPパートナーを探す」ページは、パートナーを販売、構築、コンサルティングおよび導入、マネージドサービス、イネーブルメントに分けて紹介しています。これは役割による分け方です。導入の相談先になるのは、主にコンサルティングと導入を担う企業です。
発注側が候補を挙げるときは、会社の成り立ちで分けるほうが使いやすいと筆者は考えています。大手のコンサルファーム、SIer、SAPの専門会社の3つです。これは筆者の整理で、SAPの公式の区分とは別のものです。1社が2つの型にまたがることもあります。
大手のコンサルファーム：構想と全体の管理に人の厚みがある
「SAPコンサルの大手」と聞いて多くの人が思い浮かべる、総合系のコンサルティングファームです。SAPコンサルファームと呼ばれることもあります。筆者の見るところ、持ち味は経営課題の整理、業務改革、国や会社をまたぐプロジェクトの全体管理です。体制は大きくなりやすく、提案の場に出てきた人と、日々の作業を担当するコンサルタントが別になることがあると筆者は見ています。
SIer：設計から開発、移行、運用までを通して請ける
SIer（システムインテグレーター）は、システムを作って動かすことを本業にする会社です。SAPの設定と追加開発（アドオン）、周辺システムとの連携、データ移行、基盤、稼働後の運用保守までを、ひと続きで請けられます。作る工程を広く請ける型なので、標準機能に合わない要件が出たときに、作る以外の選択肢をどこまで示すかを確かめておきます。
SAPの専門会社：領域を絞り、同じ人が設計と設定を担いやすい
SAPを専門にする中小規模の会社です。会計、販売・物流、生産、基盤といった特定の領域（モジュール）や、プロジェクトの管理に絞って支援します。ひとつの領域について、要件定義から設定までを同じコンサルタントが担当しやすい反面、全領域を1社でまかなうことは難しいと筆者は見ています。
SAPのパートナー制度とは関係なく、会社の成り立ちで分けたこの見方でいえば、筆者の会社は3つめの型にあたります。その立場から書いている点は、割り引いて読んでください。
| 型 | 得意な工程 | 体制 | 向く場面 | 確かめておくこと |
|---|---|---|---|---|
| 大手のコンサルファーム | 構想、業務改革、全体の管理。構想から稼働までを請けられる | 大人数。海外拠点にも対応しやすい | 複数の会社や国にまたがる導入。業務の見直しから始める導入 | 提案した人が、実際に案件に入るか |
| SIer | 設定と追加開発、連携、データ移行、基盤、運用保守 | 開発の要員が多い。協力会社と組むことが多い | 追加開発や連携が多い導入。稼働後の運用保守まで同じ相手に頼みたい場合 | 作る以外の選択肢を示すか。協力会社の人の役割 |
| SAPの専門会社 | 特定の領域の要件定義と設定、発注側のPMO | 少人数。領域ごとの担当者が見えやすい | 領域を絞った支援。発注側に立つ管理役がほしい場合 | 人数の上限。ほかの会社との組み方。選定を手伝う場合、導入の候補にならないか |
表 3つの型の比較。筆者の整理で、個々の会社には当てはまらないことがある。
3つの型は、6つの工程のうち人の厚みを置く場所が違う
工程ごとに、各型が中心になりやすい度合い（筆者の整理）
経営課題の整理と業務改革の計画
システムの現状調査が中心
担当する領域の論点整理
選定の事務局。導入の候補にもなる場合は、事務局と分ける
選ばれる側に立つことが多い
発注側に立つ選定の事務局。導入も請ける場合は分ける
業務の型を決める議論の取りまとめ
機能と追加開発の要件
担当する領域を深く
全領域を請けられる体制
設定、追加開発、連携
設計した人がそのまま設定しやすい
切替の計画と判定の取りまとめ
移行の道具と要員、基盤
担当する領域のデータに限る
稼働後は体制を縮めることが多い
運用保守として続けて請ける
担当する領域の改善と問い合わせ
丸の数は、その工程で各型が中心になりやすい度合いを筆者が整理したもの。調査や統計にもとづく数値ではなく、個々の会社には当てはまらないことがある。
型の違いは、優劣よりも人の厚みを置く工程の違いとして読む。先に決めるのは、自社がどの工程で誰を必要としているかになる。
ポイント
3つの型は、どれが上かを決めるための分類ではありません。違うのは人の厚みを置く工程です。自社に足りない役割がどの工程にあるかを決めると、当てはまる型が絞れます。
SAPコンサル企業を選ぶ前に、任せる役割を決める
型が分かっても、それだけでは選べません。SAPコンサル企業に声をかける前に、自社がどの役割を外に頼むのかを決めます。
SAPの導入プロジェクトは、構想、ベンダー選定、要件定義、設定とテスト、データ移行と本番切替、定着の順に進みます。この6つの工程は筆者の切り方です。SAPの導入方法論であるSAP Activateは、DiscoverからRunまでの6つのフェーズで手順を示していますが、区切りは同じではありません。工程ごとに発注側が決めることは、SAP導入の進め方の記事に整理しています。どの工程にも、発注側が決める仕事と、手を動かす仕事があります。
外に頼めるのは、手を動かす仕事と助言です。決める仕事は社内に残ります。情報処理推進機構（IPA）の「超上流から攻めるIT化の原理原則17ヶ条」は、原理原則の一つに「要件定義は発注者の責任である」を挙げています。そのうえで発注者の行動規範として、要件定義の段階で受注者をうまく活用することを示しています。この考え方に沿って、役割を4つに分けます。
手順は単純です。4つの役割を紙に並べ、社内で担える役割に、担当者の名前と割ける時間を書きます。名前を書けなかった役割が、外に頼む役割です。
構想とベンダー選定：決めるのは社内、材料づくりは頼める
導入の目的、対象範囲、移行の方式、予算と期間の置き方は、経営が決めることです。外に頼めるのは、判断の材料をそろえる作業です。構想で決めることはSAP導入の構想策定の記事、RFPの書き方はSAP導入のRFPの記事で扱っています。RFP（提案依頼書）の作成、評価基準づくり、各社との質疑の管理といった選定の事務局も頼めます。
気をつけたいのは、選定を手伝う会社が、その後の導入を請ける候補でもある場合です。政府の情報システムのルールである「デジタル・ガバメント推進標準ガイドライン」は、調達仕様書の作成に直接関与した事業者を、その調達の入札に参加させないと定めています（競争上有利にならないと認められる場合を除く）。民間の取引に適用されるルールではありません。それでも、選ぶ手伝いをする会社と選ばれる会社を分けておく考え方は、民間の選定でも参考になると筆者は考えます。
設計と設定：領域ごとに、誰が設計し誰が設定するかを聞く
要件定義から設定とテストまでは、会計、販売、購買、生産、在庫といった領域ごとに進みます。データ移行と本番切替も、この役割に含めて考えます。ERPは業務をまたいでデータがつながる仕組みなので、領域の境目の仕様を誰が詰めるのかも役割のうちです。
ここで聞いておくのは、業務の設計をする人と、SAPに設定する人が同じかどうかです。別の人が担当する体制なら、設計の意図をどう引き継ぐのかを確かめます。筆者は、設計書に書き切れなかった意図は、担当が替わるところで落ちやすいと見ています。
PMO：発注側に立つ管理役を、作る会社と分けるかを決める
PMOは、計画、課題、リスク、進み具合を管理する役割です。SAPジャパンの年次イベントのパネルディスカッションでは、登壇した導入会社のコンサルタントが、体制の準備不足を失敗の要因に挙げました。処方箋として示されたのは、ステアリングコミッティで課題を経営陣と共有し、その判断を受けてPMOが要員を調整する進め方です。
PMOを誰に頼むかには、2つの考え方があります。導入を請ける会社の中に置くか、発注側に立つ別の会社に頼むかです。先のガイドラインは、プロジェクトの管理を支援する事業者を、管理の対象になる設計・開発の入札に参加させないと定めています。理由は相互けん制です。作る会社を管理する役は、作る会社と分けておくという考え方です。
PM（プロジェクトマネージャー）の役割そのものは、外に出し切れません。同じガイドラインは、発注者には主体性を持って事業者を管理する責任があると書いています。
定着：稼働後に誰が残るかを、契約の前に決める
稼働したあとには、問い合わせへの対応、改修要望の整理、利用者への教育が続きます。SAP Activateも、最後のRunフェーズを、定着を続けて導入した仕組みの価値を引き出す段階としています。導入のチームが解散したあと、設定の中身を知る人が社内か委託先に残るかどうかは、契約の前に決めておきます。稼働後の運用保守の委託については、SAPの運用保守の記事で扱っています。
役割を先に決めると、声をかける型と、面談で会う人が決まる
4つの役割と、社内に残すこと・外に頼めること
決める仕事は社内に残り、外に頼めるのは手を動かす仕事と助言。足りない役割が決まってから、型と人を選ぶ。
規模で選ぶと、案件に入る人を確かめないまま契約しやすい
大きい会社なら安心だろう、という選び方には落とし穴があると筆者は見ています。会社の規模を物差しにすると、自社の案件に誰が入るのかを確かめる手順が抜けやすいからです。会社の規模からは分からないことを、公表資料で確かめられる範囲で3つ挙げます。
ひとつめ。パートナーのレベルや資格者数は、会社単位の情報です。 SAPのパートナープログラムには、Basic、Silver、Gold、Platinumのレベルがあります。SAPのサポートポータルの説明では、パートナーはポイントを積み上げて次のレベルを目指します。ポイントの項目に並ぶのは、契約済みで今後12か月に計上されるクラウド売上、直近12か月に導入を終えた案件の年間契約額、認定された専門領域（コンピテンシー）などです。SAP Japanは、パートナー別の認定コンサルタントの資格取得数と資格者数も公開し、月次で更新しています。どちらも会社の厚みは教えてくれますが、自社の案件に入る人までは分かりません。レベルの読み方はSAPベンダーの選び方の記事で詳しく扱いました。
ふたつめ。提案した会社の社員だけが作業するとは限りません。 公正取引委員会は2022年、ソフトウェア業の下請取引の実態調査を公表しました。報告書は、この業界に多重下請構造型のサプライチェーンがあるとし、エンドユーザーと元請けに対して、契約内容の明確化を図るよう求めています。発注側は、このエンドユーザーにあたります。先の政府のガイドラインも、調達仕様書に、再委託の制限、認める場合の条件、承認の手続きを書くよう定めています。協力会社と組むこと自体は、珍しいことでも悪いことでもありません。確かめておきたいのは、体制図のどの役割を、どの会社の人が担うのかです。
みっつめ。品質が予定どおりにならなかった要因の1位は、ベンダーのスキル不足です。 日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」（2025年度調査）で、この要因を挙げた回答は59.9%でした。SAPに限った調査ではなく、ベンダーの規模別に集計したものでもありません。大手に頼めば避けられるとも、小さい会社なら避けられるとも読めない数字です。同じ調査では、500人月以上のプロジェクトで、工期が予定より遅れた割合が47.8%、品質に不満が残った割合が29.6%でした。10人月未満では、どちらも10%を下回ります。大きいプロジェクトほど、その割合が高く出ています。スキルは会社でなく人に付くものなので、筆者は、担当する人の単位で確かめる必要があると考えています。
注意
パートナーのレベル、資格者数、会社の規模は、案件に入る人を保証しません。契約の前に、体制図の役割ごとに、担当する人の名前と所属の会社を書いてもらいます。
提案の場で確かめる5つの問いは、役割を担う本人に聞く
役割が決まったら、その役割を担う人に、提案の場で直接聞きます。政府のガイドラインも、提案の審査の手法として、プロジェクト遂行の責任者になる予定の人によるプレゼンテーションと質疑応答を挙げています。会社の代表としての説明より、その案件を担当する本人の答えを聞くという考え方です。
筆者は発注側の選定の事務局を務めてきました。その立場から勧めるのは、次の5つの問いです。
| 問い | 答えから分かること | この問いを置く理由 |
|---|---|---|
| 1. この案件で、御社はどの役割を引き受け、どこを引き受けませんか | 提案の範囲と、発注側に残る仕事 | 引き受けない範囲が書かれていないと、境目の仕事が宙に浮く |
| 2. 提案書に名前のある責任者と主要メンバーは、実際に入りますか。どれだけの時間を割きますか | 提案した人と作業する人が同じかどうか | 会社の実績は、その人の実績とは限らない |
| 3. その方は、同じ領域・同じ移行の方式の導入を、どの立場で経験しましたか | 担当する役割での経験の深さ | 同じ案件でも、設計した人と管理した人では経験が違う |
| 4. 再委託する範囲はどこですか。相手の会社と、承認の手続きを教えてください | 体制図の中の、他社の人の役割 | 多重の委託では、指示と責任の経路が長くなる |
| 5. 標準機能に合わない要件が出たとき、追加開発のほかに、どんな選択肢を示してきましたか | 作る以外の提案ができるか | 追加開発は、稼働後の更新のたびに検証の対象になる |
表 提案の場で確かめる5つの問い。筆者が勧めるもので、2は出典2の審査手法、4は出典2と出典5の考え方を参考にした。
1では、引き受けない範囲を先に言える相手かどうかを見ます。範囲の外を書かない提案は、境目の仕事があとから追加の費用として出てきやすいと筆者は見ています。
2と3は、同じ人に続けて聞きます。「その案件で、あなた自身は何を決め、何を設定しましたか」と聞くと、会社の実績と本人の経験が分かれます。4で知りたいのは、再委託の有無よりも、体制図の名前の横に入る所属の会社です。
5つのうち、差が出やすいのは5です。SAPは、新規に導入するときの設定について、SAP Activateと、業務ごとの標準設定のひな形であるSAP Best Practicesに沿うよう強く勧めています。初回の導入と、その後の更新の両方が簡単になるからです。IPAの原理原則も、業務パッケージを採用する場合はカスタマイズを前提としない、と発注者に求めています。追加開発を減らす提案は、請ける会社にとって仕事を減らす提案でもあります。それでも標準機能での代わりの案を出せる相手かどうかを、過去の案件の話で確かめます。
見積もりの金額の比べ方は、SAP導入の費用の記事にまとめています。
ポイント
- 問いは、会社の代表でなく、その役割を担う本人に聞く
- 答えは、会社の実績でなく、その人が担当した案件の話で受け取る
1社に任せるか、役割で分けるか：選ぶ役と管理する役は、作る会社と分ける
役割ごとに型を当てると、次に、全部を1社に頼むか、役割で分けるかを決めることになります。どちらにも利点と注意があります。
| 任せ方 | 利点 | 注意 |
|---|---|---|
| 構想から定着まで1社に任せる | 窓口と責任が一本になる。工程の間の引き継ぎが社内で済む | 選ぶ役と作る役、管理する役と作る役が同じ会社になる。発注側のPMが、主体性を持って確かめる必要がある |
| 役割で分ける | 選ぶ手伝いと作る仕事、管理する役と作る役を分けられる。領域ごとに経験のある人を当てやすい | 境目で引き継ぎが生じる。どの文書をどの水準で渡すかを、契約の前に決めておく |
IPAと経済産業省が整備した「情報システム・モデル取引・契約書」は、工程ごとに契約を分ける多段階契約の考え方を採っています。IPAの講演資料は、多段階とは受注先をその都度変えることではなく、要件の固まり具合に応じて見積もりの精度を上げていくことだと説明しています。契約を工程で区切ることと、会社を分けることは別の話です。1社に任せる場合でも、契約は工程ごとに区切れます。
筆者は、次の分け方が現実的だと考えています。構想とベンダー選定の事務局、発注側のPMOは、作る会社と別に置く。設計と設定は、領域ごとに同じ会社の同じ人に通して頼む。分けた場合は、境目の文書と、問題が出たときにどちらが直すのかを契約に書いておきます。
Never Redは、会計領域の導入を担う立場で入る場合と、お客様側の選定の事務局・PMOとして導入ベンダーと向き合う場合があります。導入を担う場合は、設計から設定、テストまでを当社のメンバーが担います。支援の範囲と進め方はSAP導入支援をご覧ください。当社が入った工程と担った役割は、SAP導入事例に事例ごとに並べています。
まとめ
- SAPコンサル会社は、大手のコンサルファーム、SIer、SAPの専門会社の3つの型に分けて見ると、候補を挙げやすい
- 型の違いは、人の厚みを置く工程の違い。優劣の順位にはならない
- 先に、構想とベンダー選定、設計と設定、PMO、定着のうち、自社に足りない役割を決める
- パートナーのレベル、資格者数、会社の規模は会社単位の情報。体制図の役割ごとに、担当する人と所属を確かめる
- 提案の場では、その役割を担う本人に、5つの問いを聞く
よくある質問
- SAPコンサル会社とSAPベンダーは、何が違いますか。
- はっきりした境目はありません。どちらもSAPの導入を支援する会社を指して使われます。この記事では、構想や業務の設計、プロジェクトの管理を担う会社まで含めて、SAPコンサル会社と呼んでいます。見積もりを取る前に社内で決めておくことは、SAPベンダーの選び方の記事に書きました。
- 大手のSAPコンサルファームに頼めば安心ですか。
- 大手のコンサルファームは体制が厚く、構想から稼働までを請けられます。ただし、自社の案件に入る人の経験は、会社の規模からは分かりません。提案書に名前のある責任者と主要メンバーが実際に入るのかを、面談で確かめてください。
- SAPコンサル企業の一覧やランキングは、参考になりますか。
- 候補の名前を知る入口にはなります。ただ、順位は誰かが決めた物差しで並べたものです。自社に足りない役割に合うかどうかは、役割を決めて提案を受けるまで分からないと筆者は考えています。
- 構想だけ、PMOだけといった頼み方はできますか。
- できます。工程ごとに契約を分ける考え方は、IPAのモデル契約にも示されています。分けて頼む場合は、次の工程を担う会社へどの文書を渡すのかを、契約の前に決めておきます。
- 何社に声をかければよいですか。
- 社数の前に、足りない役割と、見積もりの前提を全社に同じ形で渡せるかを確かめてください。前提がそろっていなければ、何社から提案を受けても比べられません。
SAPの依頼先の選び方や、選定の進め方についてのご相談は、お問い合わせからお寄せください。
出典
- SAPパートナーの区分（販売、構築、コンサルティングおよび導入、マネージドサービス、イネーブルメント）：SAP Japan「SAPパートナーを探す」
- 調達仕様書の作成に直接関与した事業者とプロジェクト管理支援事業者の入札制限（相互けん制）、発注者として主体性を持って事業者を管理する責任、調達仕様書に書く再委託に関する事項、提案の審査手法（責任者となる予定の者によるプレゼンテーションと質疑応答）：デジタル庁「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日 デジタル社会推進会議幹事会決定）第3編第6章
- 原理原則［9］「要件定義は発注者の責任である」と行動規範「要件定義段階で受注者をうまく活用する」、原理原則［7］の行動規範「業務パッケージを採用する場合は、カスタマイズを前提としない」：独立行政法人情報処理推進機構（IPA）「超上流から攻めるIT化の原理原則17ヶ条」
- SAP Activateの6つのフェーズ（Discover、Prepare、Explore、Realize、Deploy、Run）と、Runフェーズの説明：SAP Japan「SAP Activate」
- ソフトウェア業の多重下請構造型のサプライチェーンと、エンドユーザー・元請けに対する契約内容の明確化の提言：公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書（概要）」（2022年6月29日）
- SAP PartnerEdgeのレベル（Basic、Silver、Gold、Platinum）とポイントの項目：SAP Support「Level Tab」
- パートナー別の認定コンサルタント資格取得数・資格者数（月次更新）：SAP Japan「パートナー別SAP認定コンサルタント資格取得数・資格者数」
- プロジェクト規模別の工期と品質の遵守状況（2025年度、図表7-1-4）：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026」（2026年4月）。品質が予定どおりにならなかった要因（2025年度）：同「企業IT動向調査2026（2025年度調査）」速報版（2026年4月）
- 体制の準備不足を失敗の要因とし、ステアリングコミッティとPMOを処方箋に挙げた発言：SAPジャパン「エキスパートコンサルが明かす SAP ERP 導入の失敗と成功の法則」（SAP NOWレポート、2024年10月7日）
- 新規導入の設定でSAP ActivateとSAP Best Practicesに沿うことの推奨（初回の導入とその後の更新を簡単にする）：SAP Help Portal「Getting Started With SAP S/4HANA 2025」（PDF）
- 多段階契約の考え方と、「多段階とは受注先をその都度変えることではない」という説明：独立行政法人情報処理推進機構「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）
CONSULTATION
SAP導入・S/4HANA移行のご相談
延長保守か移行か、移行ならどの方式か。会計の設計まで含めて、方針を決める段階からご一緒します。SAP FI（財務会計）の導入と経営管理の設計を、同じ担当者が受け持ちます。
あわせて読みたい
