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

ABAPのシステム開発は、現行資産の棚卸し、要件と責任範囲の明確化、契約と委託先の選定の順に進めます。この順に進めると、追加作業や納期遅延を抑えやすくなります。

ここでは、発注形態と契約、費用相場、委託先の選び方、発注後の進め方を順に取り上げます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

「ABAPのシステム」は、SAP ERP、SAP ECC、SAP S/4HANAなどの業務基盤を拡張・連携・運用する仕組みを指すことが多いです。そのため、ABAPという言語だけで完結する製品とは限らない点を、まず押さえておきます。

発注先にはABAPの開発力に加えて業務理解も求めます。財務会計や販売管理、購買・在庫、生産などの業務を理解し、ABAPの設計に反映できることが必要です。さらに、SAP標準に合わせて拡張を抑える設計力も確認します。

帳票改修から全社移行までの外注対象

発注対象になりやすい作業は、既存機能の改修、外部連携、運用処理、移行対応の四つに分けられます。

• 画面・帳票：既存の帳票、ALVレポート、SAP GUI、Fioriの画面の改修。
• データ連携：請求・受注・在庫の各連携と、IDoc・RFC・BAPI・APIによる接続。
• 処理・統制：定期ジョブ、大量データ処理、権限・承認・監査ログの実装。
• S/4HANA移行：Zプログラムの棚卸し、ATC影響確認、非互換修正、公開API置換、データ移行、回帰テストが対象になる場合があります。

Classic ABAPとABAP Cloudの案件ごとの比較

既存ECCでは、標準オブジェクトを変更したり未公開テーブルに依存したりすると、将来の改修やテストが増える場合があります。

• Classic ABAP：既存ECCの個別要件を維持したい場合に候補になります。
• ABAP Cloud：S/4HANAやクラウドで新たに拡張する場合に検討します。
• 発注方式：標準機能、設定、公開API、BTP上のサイドバイサイド拡張、オンスタック拡張、Classic ABAPの中から選びます。

ABAP Cloudでは、公開API、CDS、RAPといった仕組みを使い、SAP標準と顧客のコードを分けます。開発にはABAP Development Toolsも使います。

ABAP for Cloud Developmentの説明は、SAP Help Portal 2025 FPS01（2026年2月版）にあります。

この方針は、クラウド対応の言語版とリリース済みオブジェクトへのアクセスを重視しています。そのため、発注時は「ABAPで作る」と決めるだけでなく、方式設計書に選択理由も書いてもらいます。

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

発注形態は、完成させる成果物が明確か、業務要件が変わるか、自社にSAPのプロジェクト責任者がいるかで選びます。

単価だけで決めてしまうと、要件が曖昧なまま進んだときに追加費用や納期遅延が起きやすくなります。そのため、不確実性をどちらが負担する契約なのかを先に確かめます。

成果物まで任せる一括発注

要件定義から稼働後の支援までの全工程を、SI会社やプライムベンダーにまとめて依頼する形です。

SAPの専門家が社内に少ない場合や、複数モジュールや周辺システムにまたがる場合は、責任の窓口を一本にまとめられます。

ABAP開発だけを頼む場合でも、ERP全体の管理費が含まれることがあります。そのため、機能コンサルやBasis、インフラのほか、データ移行や教育の費用も分けて提示してもらいます。

ABAP開発や保守だけを切り出す分業型

仕様書や設計書は自社か別のSAPコンサルタントが用意し、ABAPの設計、実装、単体テストを専門会社に依頼します。

自社に業務知識がある場合や、帳票・レポート・インターフェースを短期間で追加したい場合に向いています。

曖昧なまま進むと、コードが完成しても業務で使えない状態になり得ます。そのため、業務要件の解釈や性能、権限、結合テスト、障害時の切り分けの担当を、先に決めておきます。

準委任やラボ型でチームを確保する形

要件が段階的に固まる場合や、月ごとに改修の優先順位が変わる場合、運用保守と追加開発を続けたい場合には、準委任やラボ型でABAP担当者を含むチームを確保できます。

作業量の変動に合わせやすく、担当者が業務知識を積み上げやすい点が利点です。一方で、完成機能の範囲は毎月確かめる必要があります。

定例会議では、月次報告と残課題、次月予定を確認します。消化工数と品質指標も見て、丸投げを防ぎます。

発注前のRFPと要件整理

RFPは、各社が同じ条件で見積もれるように、業務目的や現行環境、成果物などを記した資料です。「ABAPで何か作ってほしい」といった依頼文とは性格が違います。

RFPを先に整えておくと、会社ごとに異なる前提で出された見積もりを比べやすくなります。

現行環境とABAP資産の棚卸し

現行のSAP環境、ABAP資産、診断の要否を洗い出します。

• システム環境：製品名・バージョン、利用モジュール、データベース、開発・検証・本番環境、移送経路、接続先の記録。
• 利用規模：ユーザー数、バッチ件数、帳票数、障害履歴の整理。
• ABAP資産：Zプログラム、ユーザー exit、拡張ポイントに加え、CDS、API、連携（IDoc、RFC、BAPI）、ジョブの一覧。
• 資産情報：各資産の使用状況、所有部門、重要度、改修履歴を残します。
• 診断委託：棚卸しが難しい場合は、発注前に診断フェーズを外注できます。

診断では、ソースコードの数だけでなく、呼び出し関係や参照テーブルを調べます。さらに、外部連携と権限、性能、業務上の停止許容時間まで確かめると、追加作業を抑えられます。

業務要件と機能要件の書き分け

業務目的と機能要件は、分けて書きます。たとえば、業務目的は「月末の請求処理を短縮する」や「受注から出荷までを担当者が確認できる」のように書きます。

機能要件では、取得する項目と条件、出力する帳票を決めます。画面や帳票、インターフェースに加えて、ジョブ、承認、エラー処理、権限も業務シナリオ単位で記載します。

正常系に加えて、取消や再実行、重複、タイムアウト、マスタ不備の扱いも決めておきます。

非機能要件と納品物の事前合意

会計、取引先、従業員のデータを扱う場合は、発注前に要件と成果物をそろえておきます。

• 性能・復旧：処理時間、同時利用者数、障害時の復旧時間を定めます。
• 運用・環境：バックアップ、ログ保存期間、権限分離、環境分離、通信暗号化の方針。
• 個人情報保護：個人情報保護委員会のガイドラインが示すアクセス制御や識別・認証、不正アクセス防止、ログ分析を確認項目にします。
• 納品物：要件定義・方式・基本・詳細設計書、ソース、API・連携仕様、権限設計を含めます。
• 検証・運用資料：テスト計画と結果、移行・運用手順、障害連絡方法、既知の制約。

電子取引の注文書や請求書を扱う場合は、国税庁が案内する保存要件が関わります。真実性・可視性・検索性などがそれにあたるため、経理や法務の担当にもRFPを確認してもらいます。

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

要件定義は変わりやすい一方で、移行や本番リリースには明確な成果が求められます。そのため、工程の性質に応じて契約を分ける方法が現実的です。たとえば、要件整理と診断は準委任、仕様確定後の開発は請負、稼働後の改善は準委任とします。

請負契約の成果物と検収条件

請負契約では、成果物の範囲と検収条件、変更時の扱いを事前に合意しておきます。

• 適用工程：成果物の完成と検収を重視するため、帳票やインターフェース、Fiori画面などの仕様と受入テストが固まった工程に向いています。
• 検収基準：対象プログラム、対応ブラウザやSAPリリース、性能、エラー処理、テスト合格基準の定義。
• 納品・瑕疵対応：瑕疵対応の期間と、納品するソースコードの範囲。
• 変更・遅延：仕様変更の追加費用、法改正やSAP更新時の協議、発注者のデータや承認が遅れた場合の扱い。

成果物が曖昧なままだと、ベンダーがリスク分を上乗せする形になり、納品後に期待と違う可能性があります。

準委任契約の作業と専門知識の活用

準委任契約は、専門家として一定の業務を遂行してもらう形です。要件定義や現行調査、アーキテクチャ検討、運用支援、継続改善などの場面に合います。

準委任は一括で納品する形ではないため、期間や役割、稼働時間、会議体、報告内容、成果の確認方法を定めておきます。

発注者側にも意思決定者と業務担当者を置き、毎月、優先順位を確定させます。

派遣と再委託の指揮命令と責任範囲

派遣やSESに近い形で人材を受け入れる場合は、契約上の業務範囲に加えて、指揮命令者や勤怠、セキュリティ教育、アクセス権の管理者を確認します。

再委託がある場合は、RFPと契約書に、会社名や担当者の経験、機密情報へのアクセス、障害時の責任を記載します。ソースコードと文書の帰属も、契約書で明らかにしておきます。

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

ABAP単体の開発費は、対象モジュール、既存コードの品質、画面・帳票数、連携数で変わります。データ量やテスト範囲、Basis・インフラ、保守期間もかかわるため、一律の公開定価はありません。

これから示す金額は、リサーチノートに基づく業務システム・ERP相場を編集した概算です。予算の目安として使い、最終金額は現行調査と要件定義の後に確定します。

規模別の費用レンジ

規模や作業内容ごとの費用と期間を、概算のレンジで示します。

• 小規模：既存帳票1本から数本、単純レポート、軽微な項目追加、単一連携。100万〜500万円、1〜3か月が目安です。
• 中規模：複数モジュールの帳票や承認、API・IDoc連携、Fiori画面、データ加工、総合テスト。500万〜2,000万円、3〜9か月程度です。
• 大規模アドオン：複数システム連携、権限、監査、移行を含む業務拡張。2,000万〜1億円、6〜18か月程度です。
• ECCからS/4HANAへの移行：ABAP関連だけで5,000万〜3億円程度、9〜24か月程度になる場合があります。

これらはABAP専用の公開価格ではありません。要件の複雑さによって上下する、推定のレンジです。

ECCからS/4HANAへの移行費は、Zプログラムの数と品質、非互換対応、公開APIへの置換、回帰テストによって変わります。この概算は、ERP全体の費用ではなく、ABAP資産の移行を中心に見たものです。

ERP全体の移行費との切り分け

ERP全体の移行費とABAP関連費は分けて、見積もりの範囲を確認します。

• 調査結果：新規導入を除くS/4HANA移行費は、5億円以上が半数超を占めます。
• 費用範囲：調査額には、ABAPのほか、業務設計、ライセンス、データ移行、インフラ、教育、運用移行が含まれ、ERP全体の費用です。
• 見積もり：ABAP改修、機能コンサル、Basis・インフラ、移行、テスト、教育、ハイパーケアの費用を分けて示します。
• 保守：業務システム全般では、年間保守を初期開発費の10〜20％程度とする考え方があります。

新規導入を除くS/4HANA移行費の内訳は、10億円以上が26％、5億〜10億円未満が24.7％です（出典：電通総研、2025年度調査）。

保守費は契約範囲によって中身が変わるため、比率はあくまで目安として扱います。初期開発費に加えて、監視やジョブ管理、SAPアップデート、問い合わせ対応の範囲を確認します。さらに、契約上の対応時間と作業内容を比べます。

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

委託先は、会社の知名度やABAPエンジニアの人数よりも、自社の案件を稼働後まで運用できるかで見極めます。

ECC改修、S/4HANA移行、ABAP Cloud、Fiori・BTP連携では、必要なスキルがそれぞれ異なります。

業界・モジュール・移行方式の実績

実績を確認するときは、自社との近さと、新旧技術への対応力を比べます。

• 案件との近さ：業界、対象モジュール、SAPバージョン、連携方式、帳票、データ量、海外拠点の有無。
• 技術範囲：Classic ABAPに加えて、CDSやRAP、Fiori、OData、BTP、公開API、ATC診断、テスト自動化の経験を確認します。
• 実施体制：課題や担当範囲、担当者の配置、期間、移行前後の変更、稼働後保守について質問します。

可能であれば、提案の場にプロジェクト責任者やSAP機能コンサルタント、ABAPリーダー、Basis担当者の同席を求めます。発注後に担当者が交代する場合の引き継ぎ方法も、確かめておきます。

見積もりの前提・工数・除外項目の比較

見積もり金額は、前提や除外範囲によって変わります。そのため、項目ごとに比べます。

• 金額と体制：作業項目、担当ロール、工数、単価、期間をそろえて比べます。
• 契約条件：前提、成果物、検収、保守、再委託の範囲。
• 除外項目：「要件定義は別途」「データクレンジングは対象外」「SAP標準設定は発注者」「本番移送は別契約」といった記載。

除外範囲を見落とすと、当初は安く見えた会社でも、後から費用が高くなることがあります。

未確定の要件をどう扱うかも比べます。固定価格でリスクを隠す提案よりも、段階ごとに見積もりを更新する提案のほうが現実的な場合があります。

見積もりを更新する段階は、現状調査、要件定義、開発、テスト、移行の各段階です。そのうえで、変更管理票の発行条件や承認者、影響評価、予算上限、納期への影響も確認します。

セキュリティと稼働後の体制

情報管理と稼働後の支援について、委託先と確認する項目を整理します。

• データ管理：本番アクセス条件、個人情報のマスキング、特権ID、ログ、脆弱性対応の取り決め。
• 障害対応：バックアップや障害連絡、復旧目標、受付時間、一次切り分けの内容を確認します。
• 開発環境：本番データをコピーするときの承認と削除方法を、契約に含めます。
• 保守引き継ぎ：SAP標準障害との境界、緊急連絡先、月次改善枠、リリース手順、ナレッジ移管を決めておきます。

委託先に安定稼働を任せる場合でも、ソースコードと設計書は受け取ります。そのうえで、自社や第三者が将来保守できる状態を、契約の成果に含めます。

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

委託先には専門的な調査や設計、開発、検証、助言を任せられます。一方で、任せることと意思決定を手放すことは別で、意思決定は発注者が担います。そのため、業務、情報システム、経理・法務、セキュリティ担当の判断事項を、あらかじめ整理しておきます。

現状調査と提案評価による発注先の絞り込み

RFPを配布したあとは、質問と回答、提案、プレゼン、技術面談、再見積もりの順に進めて比べます。

価格や要件理解、方式の妥当性、担当者の経験を点数にします。さらに、リスク指摘や成果物、テスト方針、保守体制、発注者側の作業も点数化します。

設計・開発・テストの段階的な検収

要件定義の後は、標準機能と拡張範囲を確定させます。そのうえで、基本設計、詳細設計、ABAP実装と進み、単体・結合・総合テストや性能・権限テストへ移ります。

各工程でレビューを行い、未決事項を残したまま次の工程へ進まないようにします。

外部連携では、相手先のエラーや再送、重複、通信停止をテストケースに含めます。日付や通貨の変換も、テストケースに入れます。

移行・受入・ハイパーケアの計画

移行・受入から稼働後までは、手順と確認内容を順に計画します。

1. 移行リハーサル：S/4HANA移行や大規模改修では複数回行い、残高や件数、キー項目、業務シナリオの結果を照合します。
2. カットオーバー：移送とバックアップ、連携停止、最終データ抽出、移行、照合の順に進めます。
3. ハイパーケア：稼働直後の問い合わせに備えて、一定期間を設けます。

カットオーバーでは、業務確認や連携再開、監視開始も含めて判断者を決めておきます。ハイパーケアでは、障害の優先度や暫定・恒久対応、再発防止、ユーザー教育を記録します。

納品後に担当者が離れる場合に備えて、引き継ぎ会や操作説明、ソースコードの読み方、ジョブと監視の一覧を残してもらいます。

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

発注では、技術用語より先に、現行資産の範囲や業務上のゴール、委託先の責任、納品後の運用を明確にします。初めて外注する担当者から寄せられることの多い質問に答えます。

ABAPのシステム開発は何から外注すればよいですか？

まず、現行資産の棚卸しを依頼します。SAP版や対象モジュール、Zプログラムに加えて、次の範囲も洗い出してもらいます。

• 帳票と連携：既存の帳票や、外部との接続の一覧。
• ジョブと権限：定期ジョブと、権限や承認の仕組み。
• 障害履歴：過去に起きた障害の記録。

目的や範囲が固まっていない段階で実装を始めるより、診断と要件整理を先に行えば、見積もりと契約範囲を正確にできます。

ABAPのシステムを外注するといくらかかりますか？

既存帳票や軽微な改修は100万〜500万円、中規模の連携・Fiori・承認・テストは500万〜2,000万円が概算です。大規模アドオンは2,000万〜1億円です。

ECCからS/4HANAへのABAP資産移行は、5,000万〜3億円程度になる場合もあります。これは公開価格ではなく、範囲と現行資産によって推定した金額です。RFPでは、ABAP、移行、テスト、保守を分けて書きます。

2026年にABAP開発を外注するならABAP Cloudが必須ですか？

ABAP Cloudが必要かどうかは、既存環境の運用か新規拡張かで判断します。

• 既存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担当者だけを依頼すればよいですか？

帳票や単純な画面改修であれば、ABAP担当者中心でも進められます。

複数モジュールや外部連携、S/4HANA移行、権限、監査、データ移行を含む場合は、SAP機能コンサルタントやBasis、テスト・移行の担当も必要になります。

提案時に役割分担表を作り、自社、プライムベンダー、ABAP開発会社、再委託先のそれぞれが、どこまでを受け持つかを確認します。

まとめ

ABAPシステムの発注では、実装量だけでなく、SAP標準への適合や既存資産の品質まで見て計画します。業務要件や連携、権限、テスト、移行、稼働後保守も、あわせて計画に入れます。

発注形態は、工程の不確実性に合わせて選びます。成果が固まった開発には請負、調査や継続改善には準委任、全体を任せる場合には一括発注が合います。

発注前にそろえる資料

発注前にそろえる資料は、RFPと見積もりの出し方です。RFPには、現行バージョンや対象モジュール、Zプログラムに加えて、次の内容を書きます。

• システム構成：連携一覧と業務フロー。
• 利用規模：ユーザー数とデータ量。
• 業務条件：法定帳票、希望時期、受入条件。
• 非機能と納品：非機能要件、納品物、保守範囲。

見積もりは、ABAP改修や機能設計、Basis・インフラ、移行の費用を分けて出してもらいます。テストや教育、ハイパーケアの費用も、分けて示してもらいます。前提条件と除外項目をそろえ、比べられる形にします。

最初の一歩は現行資産の棚卸し

発注前の確認は、現行資産の棚卸しから委託先の比較へと、順に進めます。

• 現行資産：SAP環境とABAP資産を棚卸しし、残す機能、標準へ寄せる機能、廃止する機能を業務部門と合意します。
• 委託先比較：同じRFPを複数社に渡し、価格や業務理解、Clean Core・公開APIの方針、テスト・移行の責任、担当者の固定性、保守体制を比べます。
• 最終判断：将来の改修費も踏まえ、委託先を決めます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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