ABAPのシステム開発の発注/外注/依頼/委託方法について

ABAPのシステムを発注・外注するときは、ABAPのプログラム単体ではなく、SAPの業務要件、既存資産、連携、テスト、運用までを含む成果範囲を先に定めることが成功のポイントです。

この記事では、ABAPのシステム開発を依頼する前の発注形態の選択から、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積もり比較、稼働後の保守までを、2026年時点のSAPの動向を踏まえて解説します。ECCの既存Zプログラム改修とS/4HANAへの移行では、必要な専門性も見積もりの作り方も異なりますので、自社の案件に合う発注方法を判断できるように整理します。

▼全体ガイドの記事
・ABAPのシステム開発の完全ガイド

ABAPのシステムを発注・外注するときの全体像

「ABAPのシステム」は、ABAPという言語だけで完結する製品ではなく、SAP ERP、SAP ECC、SAP S/4HANAなどの業務基盤を拡張・連携・運用する仕組みを指すことが多いです。そのため、発注先を探すときはABAPを書ける人数だけでなく、財務会計、販売管理、購買・在庫、生産などの業務理解と、SAP標準に合わせて拡張を抑える設計力を確認する必要があります。

依頼対象には、既存帳票やALVレポートの追加、SAP GUIやFioriの画面改修、請求・受注・在庫データの外部連携、IDoc・RFC・BAPI・APIを使った接続、定期ジョブや大量データ処理、権限・承認・監査ログの実装があります。ECCからS/4HANAへ移行する場合は、Zプログラムの棚卸し、ATCなどによる影響確認、非互換修正、公開APIへの置き換え、データ移行、回帰テストまでが対象になることがあります。

既存ECCの細かな個別要件を維持するならClassic ABAPが候補になりますが、標準オブジェクトの直接変更や未公開テーブルへの依存が多いと、将来のアップグレードで改修とテストが増えます。S/4HANAやクラウドを前提にする新規拡張では、公開API、CDS、RAP、ABAP Development Toolsなどを使い、SAP標準コードと顧客コードを分離するABAP Cloudの考え方が重要になります。

SAP Help Portalの2025 FPS01（2026年2月版）は、ABAP for Cloud Developmentではクラウド対応の言語バージョンとリリース済みオブジェクトへのアクセスを重視すると説明しています。発注時には「ABAPで作る」とだけ書かず、標準機能、設定、公開API、BTP上のサイドバイサイド拡張、オンスタック拡張、Classic ABAPのどれを選ぶのか、その理由まで方式設計書に記載してもらいます。

ABAPのシステムに合う発注形態の選び方

発注形態は、完成させたい成果物が明確か、業務要件がまだ変わるか、自社にSAPのプロジェクト責任者がいるかで選びます。単価の安さだけで決めると、要件の曖昧さをめぐって追加費用や納期遅延が起きやすいため、案件の不確実性をどちらが負担する契約なのかを先に確認することが大切です。

要件定義から設計、ABAP実装、テスト、移行、稼働後支援までを一つのSI会社やプライムベンダーにまとめて依頼する形です。自社にSAPの専門家が少なく、複数モジュールや周辺システムをまたぐ場合は、責任窓口を一本化しやすいメリットがあります。一方、ABAP開発だけを頼みたいのにERP全体の管理費まで含まれることがありますので、機能コンサル、Basis、インフラ、データ移行、教育の費用を分けて提示してもらいます。

仕様書や設計書を自社または別のSAPコンサルタントが用意し、ABAPの設計・実装・単体テストを専門会社へ依頼する方法です。既存の業務知識を自社で持っている場合や、帳票・レポート・インターフェースの追加を短期間で進めたい場合に向いています。ただし、業務要件の解釈、性能、権限、結合テスト、障害時の切り分けを誰が担うかが曖昧だと、コードは完成しても業務で使えない状態になります。

要件が段階的に固まる、月ごとに改修優先順位が変わる、運用保守と追加開発を継続したい場合は、準委任やラボ型でABAP担当者を含むチームを確保する選択肢があります。作業量の変動に対応しやすく、担当者が業務知識を蓄積しやすい反面、完成機能の範囲を毎月確認する運営が必要です。月次の作業報告、残課題、次月の予定、消化工数、品質指標を定例会議で確認し、実質的な丸投げにならないようにします。

RFPと要件整理で発注前に決めること

RFPは「ABAPで何かを作ってほしい」という依頼文ではなく、業務上の目的、対象範囲、現行環境、制約、期待する成果物、選定基準をベンダーが同じ条件で見積もるための資料です。RFPを先に整えるほど、会社ごとに異なる前提で出された見積もりを比較しやすくなります。

現行SAPの製品名とバージョン、利用モジュール、データベース、開発・検証・本番環境、移送経路、接続先、ユーザー数、バッチ件数、帳票数、障害履歴を整理します。さらに、Zプログラム、ユーザー exit、拡張ポイント、CDS、API、IDoc、RFC、BAPI、ジョブを一覧化し、使用中・未使用・所有部門・重要度・改修履歴を記録します。

棚卸しが難しい場合は、発注前に診断フェーズだけを外注してもかまいません。ソースコードの本数だけで規模を判断せず、呼び出し関係、参照テーブル、外部連携、権限、性能、業務上の停止許容時間まで調べることで、あとから見つかる追加作業を減らせます。

「月末の請求処理を短縮する」「受注から出荷までの状況を担当者が確認できる」といった業務目的と、「どの項目をどの条件で取得し、どの帳票へ出力するか」という機能要件を分けます。画面、帳票、インターフェース、ジョブ、承認、エラー処理、権限を業務シナリオ単位で記載し、正常系だけでなく取消、再実行、重複、タイムアウト、マスタ不備の扱いも決めます。

会計・取引先・従業員データを扱うABAPのシステムでは、処理時間、同時利用者数、障害時の復旧時間、バックアップ、ログ保存期間、権限分離、開発・検証・本番の分離、通信の暗号化を非機能要件にします。個人情報保護委員会のガイドラインが示すアクセス制御、識別・認証、不正アクセス防止、ログ分析、通信の暗号化なども、発注時に確認する項目です。

納品物には、要件定義書、方式設計書、基本・詳細設計書、ソースコード、API・連携仕様、権限設計、テスト計画と結果、移行手順、運用手順、障害時の連絡方法、既知の制約を含めます。電子取引の注文書や請求書を扱う場合は、国税庁が案内する真実性・可視性・検索性などの保存要件に関係するため、経理や法務もRFPレビューに参加してもらいます。

ABAPのシステム開発で選ぶ契約形態

ABAPのシステムでは、要件定義は変動しやすい一方、移行や本番リリースには明確な成果が求められます。そのため、プロジェクト全体を一つの契約形態に固定するより、要件整理・診断は準委任、仕様確定後の開発は請負、稼働後の改善は準委任というように、工程の性質に合わせて分ける方法が現実的です。

請負契約は、合意した成果物を完成させ、検収を受けることを重視する契約です。帳票、インターフェース、Fiori画面などの仕様と受入テストが固まっている工程では使いやすい形です。検収条件には、対象プログラム、対応ブラウザやSAPリリース、性能基準、エラー処理、テスト合格基準、瑕疵対応の期間、納品ソースコードの範囲を記載します。

「仕様変更は追加費用」「法改正やSAPアップデートは別途協議」「発注者のデータや承認が遅れた場合の扱い」も決めておきます。成果物の定義が曖昧なまま請負にすると、ベンダーはリスク分を見積もりに上乗せし、発注者は納品後に期待と違うと感じる可能性があります。

準委任契約は、一定の業務を専門家として遂行することを依頼する形で、要件定義、現行調査、アーキテクチャ検討、運用支援、継続的な改善に向いています。完成機能の一括納品ではなく、期間、役割、稼働時間、会議体、報告内容、成果の確認方法を決めます。発注者側にも意思決定者と業務担当者を置き、優先順位を毎月確定させる必要があります。

派遣やSESに近い形で人材を受け入れる場合は、契約上の業務範囲だけでなく、誰が指揮命令を出すのか、勤怠・セキュリティ教育・アクセス権を誰が管理するのかを確認します。再委託がある場合は、再委託先の会社名、担当者の経験、機密情報へのアクセス、障害時の責任、ソースコードとドキュメントの帰属をRFPと契約書の両方に記載します。

ABAPのシステムの費用相場と見積もりの内訳

ABAP単体の開発費に公開された一律の定価はなく、対象モジュール、既存コードの品質、画面・帳票数、インターフェース数、データ量、テスト範囲、Basisやインフラ、保守期間によって変わります。以下はリサーチノートに基づく業務システム・ERP相場からの編集上の概算であり、発注前の予算レンジとして使い、最終金額は現行調査と要件定義後に確定させます。

既存帳票1本から数本、単純なレポート、軽微な項目追加、単一インターフェースであれば、目安は100万〜500万円、期間は1〜3か月です。複数モジュールをまたぐ帳票・承認、APIやIDoc連携、Fiori画面、データ加工、総合テストを含む中規模案件は、500万〜2,000万円、3〜9か月程度が一つの目安になります。いずれも公開されたABAP専用価格ではなく、要件の複雑さで上下する推定レンジです。

販売・購買・生産などの業務拡張に複数システム連携、権限、監査、移行を加える大規模アドオンでは、2,000万〜1億円、6〜18か月程度のレンジで検討します。ECCからS/4HANAへABAP資産を移行する場合は、Zプログラムの数と品質、非互換対応、公開APIへの置換、回帰テストによって、ABAP関連だけでも5,000万〜3億円程度、9〜24か月程度の計画になることがあります。これはERP全体の導入費ではなく、ABAP資産移行を中心に見た概算です。

電通総研の「SAPユーザー意識調査結果2025年度版」では、SAP S/4HANAを新規導入した企業を除く移行費用について、5億円以上と回答した企業が半数を超え、10億円以上が26％、5億〜10億円未満が24.7％でした（出典: 電通総研、2025年度調査）。この数字はABAP開発だけではなく、業務設計、ライセンス、データ移行、インフラ、教育、運用移行などを含むERP全体の移行費です。

相見積もりでは、ABAP改修、機能コンサルタント、Basis・インフラ、データ移行、テスト、教育、稼働後のハイパーケアを分けてもらいます。初期開発費だけでなく、年間保守、監視、ジョブ管理、SAPアップデート対応、問い合わせ対応を確認します。業務システム全般の目安では年間保守を初期開発費の10〜20％程度とする考え方がありますが、契約範囲によって変わりますので、比率だけで判断せず対応時間と作業内容を比較します。

委託先の選定と見積比較のポイント

委託先は、会社の知名度やABAPエンジニアの人数だけで選ぶのではなく、自社の案件を最後まで運用できるかで見極めます。既存ECCの改修、S/4HANA移行、ABAP Cloud開発、FioriやBTP連携では必要なスキルが異なるため、提案書に担当者の経験と担当範囲を書いてもらいます。

確認する実績は「SAP導入実績あり」だけでは不十分です。自社と近い業界、対象モジュール、利用中のSAPバージョン、連携方式、帳票、データ量、海外拠点の有無を聞きます。さらに、Classic ABAPの保守だけでなく、CDS、RAP、Fiori、OData、BTP、公開API、ATCによる移行診断、テスト自動化まで対応できるかを確認します。

実績紹介では、課題、担当範囲、体制、期間、移行前後の変更、稼働後の保守方法を質問します。可能であれば、提案時に実際のプロジェクト責任者、SAP機能コンサルタント、ABAPリーダー、Basis担当の同席を依頼し、発注後も同じメンバーが対応するのか、交代時の引き継ぎ方法があるのかを確認します。

見積書の総額だけを並べず、作業項目、担当ロール、工数、単価、期間、前提条件、成果物、検収、保守、再委託、除外項目を同じフォーマットに写します。「要件定義は別途」「データクレンジングは対象外」「SAP標準設定は発注者」「本番移送は別契約」といった記載を見落とすと、安く見えた会社のほうが後から高くなることがあります。

特に比較したいのは、未確定要件をどのように扱うかです。概算見積もりの段階で固定価格を約束し、リスクを隠す提案よりも、現状調査、要件定義、開発、テスト、移行の各段階で見積もりを更新する提案のほうが、ABAP案件では現実的な場合があります。変更管理票の発行条件、承認者、影響評価、予算上限、納期への影響を確認します。

財務、取引先、従業員の情報を扱う場合は、開発者が本番データへアクセスできる条件、個人情報のマスキング、特権ID、ログ、脆弱性対応、バックアップ、障害連絡、復旧目標を確認します。開発環境へ本番データをコピーする場合の承認と削除方法も、見積もりと契約の対象にします。

稼働後は、問い合わせの受付時間、一次切り分け、SAP標準障害とABAP障害の境界、緊急時の連絡先、月次の改善枠、リリース手順、ナレッジ移管の方法を確認します。安定稼働を委託先に任せる場合でも、ソースコードと設計書を受け取り、自社または第三者が将来保守できる状態を契約上の成果に含めることが大切です。

発注から開発・稼働後までの進め方

発注後に重要なのは、ベンダーへ任せることと、発注者が意思決定を手放すことを混同しないことです。業務部門、情報システム部門、経理・法務、セキュリティ担当が判断すべき事項を整理し、委託先には専門的な調査、設計、開発、検証、助言を依頼します。

最初にRFPを配布し、質問受付、回答、提案、プレゼンテーション、技術面談、見積もりの再提出という流れで比較します。提案を評価するときは、価格だけでなく、要件理解、方式の妥当性、担当者の経験、リスクの指摘、成果物、テスト方針、保守体制、発注者側に必要な作業を点数化します。

要件定義の後は、標準機能で対応する部分と拡張する部分を確定し、基本設計、詳細設計、ABAP実装、単体テスト、結合テスト、総合テスト、性能・権限テストへ進みます。各工程でレビューを行い、未決事項を残したまま次工程へ進まないようにします。特に外部連携では、相手先のエラー、再送、重複、通信停止、日付や通貨の変換をテストケースに入れます。

S/4HANA移行や大規模改修では、データ移行リハーサルを複数回行い、残高、件数、キー項目、業務シナリオの結果を照合します。カットオーバー当日は、移送、バックアップ、連携停止、最終データ抽出、移行、照合、業務確認、連携再開、監視開始の順番と判断者を決めます。

稼働直後は問い合わせが増えるため、一定期間のハイパーケアを設け、障害の優先度、暫定対応、恒久対応、再発防止、ユーザー教育を記録します。納品後に担当者が離れる場合に備え、引き継ぎ会、操作説明、ソースコードの読み方、ジョブと監視の一覧を残してもらいます。

ABAPのシステム発注・外注でよくある質問

ABAPの発注では、技術用語よりも、現行資産の範囲、業務上のゴール、委託先の責任、納品後の運用を明確にすることが重要です。ここでは、初めて外注を検討する担当者が確認しやすい質問に直接回答します。

まずは現行SAPのバージョン、対象モジュール、Zプログラム、帳票、連携、ジョブ、権限、障害履歴の棚卸しを依頼する方法がおすすめです。目的と対象範囲が固まっていないまま実装を依頼するより、診断と要件整理を先行させたほうが、後続の開発見積もりと契約範囲を正確にできます。

既存帳票や軽微な改修なら100万〜500万円、中規模の連携・Fiori・承認・テストなら500万〜2,000万円、大規模アドオンなら2,000万〜1億円が概算レンジです。ECCからS/4HANAへのABAP資産移行は5,000万〜3億円程度の計画になる場合がありますが、いずれも公開定価ではなく、作業範囲と現行資産の状態に基づく推定です。RFPでABAP、移行、テスト、保守を分けて見積もることが必要です。

すべての案件で必須ではありません。既存ECCの安定運用や限定的なClassic ABAP改修では、現行環境と互換性を優先する判断もありますが、新規のS/4HANA拡張では公開API、CDS、RAP、Fiori、BTPなどを比較し、将来のアップグレードに耐えやすい方式を選びます。SAP Business Suite 7の主要アプリケーションは2027年末までがメインストリーム保守で、2028年から2030年には有償の延長保守の選択肢があり、S/4HANAは少なくとも2040年までいずれかのリリースが保守対象です（出典: SAP Support「Maintenance 2040」、2026年確認）。

帳票や単純な画面改修であればABAP担当者中心でも進められますが、複数モジュール、外部連携、S/4HANA移行、権限、監査、データ移行を含む場合は、SAP機能コンサルタント、Basis、テスト・移行担当を含めた体制が必要です。提案段階で役割分担表を作り、自社、プライムベンダー、ABAP開発会社、再委託先の責任境界を確認します。

まとめ

ABAPのシステムを発注・外注するときは、ABAPの実装量だけでなく、SAP標準への適合、既存資産の品質、業務要件、連携、権限、テスト、移行、稼働後保守までを一つの計画として整理します。発注形態は、成果が固まった開発には請負、調査や継続改善には準委任、全体を任せたい場合には一括発注というように、工程の不確実性に合わせて選びます。

RFPには、現行バージョン、対象モジュール、Zプログラムと連携の一覧、業務フロー、ユーザー数、データ量、法定帳票、希望時期、受入条件、非機能要件、納品物、保守範囲を記載します。見積もりは、ABAP改修、機能設計、Basis・インフラ、移行、テスト、教育、ハイパーケアを分け、前提条件と除外項目をそろえて比較します。

委託先選びに迷ったら、まず利用中のSAP環境とABAP資産の棚卸しを行い、業務部門と「残す機能」「標準へ寄せる機能」「廃止する機能」を合意します。そのうえで複数社へ同じRFPを渡し、価格だけでなく、業務理解、Clean Coreや公開APIの方針、テストと移行の責任、担当者の固定性、保守体制を比較すれば、将来の改修費まで含めて納得できる発注先を選びやすくなります。

▼全体ガイドの記事
・ABAPのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。