ABAPのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ABAPのシステム開発の流れは、要件整理から始まり、方式選定と設計・開発を経て、テスト、稼働、定着へ進む6フェーズです。

この流れに沿って進めると、移行後も保守できる仕組みにつながります。全体像をさらに詳しく知りたい方は、ABAPのシステム開発の完全ガイドもご覧ください。

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

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

ABAPのシステムの全体像

ABAPのシステムは、SAP ERP、SAP ECC、SAP S/4HANAなどの業務基盤を、ABAPで拡張・連携・運用する仕組みです。言語単体で完結する製品ではなく、業務基盤と組み合わせて成り立ちます。

扱う業務データは、財務会計や販売、購買・在庫のほか、生産や人事にも及びます。標準機能で足りない部分は、ABAPで画面や帳票を追加して補います。承認や連携、バッチ処理も、ABAPで組み込みます。

ABAPが担当する主な機能

ABAPが担う開発は、画面や帳票から連携処理まで多岐にわたります。

• 画面・レポート：ALVで一覧や集計を作り、SAP GUIやSAP Fioriに入力画面を追加。
• 帳票・連携：請求書・納品書・注文書などの帳票、倉庫・銀行・EDI・CRM・BIとの連携、定期ジョブ、大量データ処理。
• 業務統制：承認ルート、変更履歴、監査用ログ、権限に応じた表示制御の実装。

業務システムを成立させるには、ABAP担当者に加えて、SAPの機能知識も欠かせません。たとえば、販売条件はSD、購買はMM、会計はFI・COの知識が関わります。

Basis・インフラ、データ移行、権限設計、ユーザー受入なども組み合わせて進める必要があります。そのため、見積もりでは、ABAP開発者の人数だけでなく、これらの役割が含まれるかを確認します。

システムを構成する要素

システムは、実行基盤から運用までの要素に分けて見ると、全体像がつかみやすくなります。

• 基盤：ABAPランタイムとHANAデータベース。
• 画面・接続：SAP GUIまたはFiori、外部接続、認証・認可。
• 開発・運用：開発・検証・本番環境、移送管理、テスト、監視。
• システム連携：IDoc、RFC、BAPI、API、ファイルなどを使い、再送・通知も設計。

財務・取引先・従業員データを扱う場合は、機能要件と同時に安全管理も決めます。安全管理の対象には、最小権限や職務分掌、特権IDなどが含まれます。

加えて、開発・本番の分離と変更履歴、監査ログも対象です。バックアップや復旧、通信暗号化も含みます。

また、個人情報保護委員会のガイドラインは、安全管理措置の例として、アクセス制御や認証、ログの定期分析、不正アクセス防止などを挙げています。通信経路の暗号化も例に含まれます。

Classic ABAPとABAP Cloudの選び分け

方式を選ぶ際は、既存ECCの改修か、新規のS/4HANA拡張かを起点に比べます。

• 既存ECC：資産を活用する改修では、Classic ABAPが現実的な場合があります。
• 新規S/4HANA拡張：公開API、拡張ポイント、CDS、RAP、Fioriを優先し、Clean Coreで標準コードと顧客拡張を分離。
• 方式の判断：現行バージョン、移行計画、自由度、アップグレード頻度、外部連携の責任範囲で比べる。

ABAP Cloud Development Modelは、クラウド最適化ABAP、CDS、RAPを組み合わせた開発モデルです。ABAP Development Toolsと公開APIも用います。このモデルは、アップグレードに強い拡張を目指し、使える構文と参照できる開発オブジェクトを制限します。

2026年時点のSAP Platform資料は、ABAP for Cloud Developmentについて説明しています。さらに、Released APIのリリース契約が、安定した拡張を支えます。

ABAPのシステム開発の進め方（6フェーズ）

ABAP開発では、要件を聞いてすぐにコーディングに入るのではなく、まず業務と標準機能の差分を把握します。そのうえで、方式選定から定着までを一続きの計画として立てます。

6フェーズは要件整理から定着まで順に進み、各フェーズで成果物と判断基準を確認します。

1. 要件整理：業務課題と標準機能の差分の確定

現場の要望は整理しつつ、便利さだけで個別アドオンを増やさないよう注意します。

• 現行環境：SAPのバージョン、モジュール、ユーザー数、業務資産の棚卸し。
• 要望の具体化：担当者・データ・処理条件・成果物への分解。
• 方式選定：標準・設定・キー拡張・公開API・サイドバイサイドと、ABAPの要否の比較。
• 重要要件：後戻りしにくい要件を関係部門で承認。
• 成果物・評価：要件の文書化と、優先度や移行影響の記録。

棚卸しでは、主要な業務フロー、帳票、バッチを確認します。加えて、インターフェースとZプログラムの一覧、障害履歴、データ量も見ておきます。

画面の項目名だけでは、承認や例外処理が抜けやすいため、要望を業務条件まで分解します。法定帳票や締め処理、在庫評価、監査証跡は、業務部門と経理・法務・情報システムが承認します。

成果物には、業務フローや要件一覧、非機能要件を含め、対象データ・インターフェースと対象外を明記します。

要望ごとに、優先度と発生頻度、代替手段を記録します。法的な必須性や将来の移行影響も残しておきます。

2. 選定：拡張方式と開発体制の決定

拡張方式と開発体制は、要件と責任範囲に合わせて選びます。

1. パッケージ標準、設定変更、キー・ユーザー拡張、ABAP Cloud、BTP上のサイドバイサイド拡張、Classic ABAPの順に比べます。
2. S/4HANA Cloud Public Editionでは、クラウド対応とアップグレードの安定性に適した開発者拡張が前提になりやすいです。
3. 密なデータ処理はオンスタックに、外部サービスや複数システムをまたぐ処理は疎結合にするなど、責任範囲で分けます。

なお、既存ECCの自由なテーブル参照を、そのまま移せるとは限りません。

開発会社の評価では、SAP認定や要員数は一部の材料にとどまります。業界・モジュールの実績やZプログラムの棚卸し経験を確認します。さらに、ATCなどの移行診断や、CDS・RAP・Fiori・APIの経験も見ます。

データ移行と権限設計の責任分担、日本語サポートも確認します。そのうえで、ABAP開発者の派遣か、機能コンサルタントやBasis・テスト担当を含む成果物型チームかを区別します。

採用しなかった方式と理由も記録します。比較は総保有コストで行い、初期費用や移行費、ライセンスに加えて、運用、アップグレード、テストも含めて見ます。「クラウドだから安い」「スクラッチなら業務に合う」と決めつけず、費用と運用を比べます。

3. 設計・開発：将来の変更を前提とした実装

設計・開発では、業務要件と将来の変更に備える仕様を具体化します。

• 設計対象：業務フロー、画面、帳票、データ項目、エラー、権限、ログ、連携、ジョブ、性能目標。
• 実装方式：公開APIや拡張ポイントを確認し、CDSのデータモデルとRAPのトランザクションサービスを検討。
• 品質・納品：例外や大量データへの対応を定め、ソース、設計書、API・権限・ジョブ一覧、テスト・移行・運用手順、既知の制約までそろえる。

業務オブジェクトを誰が変更できるかは、画面を作る前に定義します。Classic ABAPでは、未公開テーブルや標準オブジェクトへの依存も確認します。

会社コードや税区分のハードコーディング、処理量に対する性能不足を点検します。命名規約とレビュー基準、静的解析について合意します。移送単位やソースの保管先も、あわせて決めます。

設計書には、入力不備や重複、タイムアウト、連携先の停止の扱いを記します。さらに、再送、ロールバック、権限不足、月末や大量データの扱いも盛り込みます。

4. テスト：業務シナリオと移行の検証

テストでは、業務の開始から完了まで正しい結果になるかを確かめます。

• 単体・結合・総合・性能・受入：ロジックと例外、SAP・外部連携、締め処理と権限、ピーク時の応答とジョブ時間、現場の判断基準を検証。
• 移行リハーサル：抽出、変換、名寄せ、エラー修正、件数と残高の照合、移行時間、切り戻しの確認。
• リリース判定：テスト結果と未解決課題を記録し、重大度別の件数と決裁者を決める。

リリース判定では、重大な障害を残したまま稼働日を迎えないことが前提になります。また、データ移行は、本番直前の一度きりにせず、リハーサルを重ねて手順を固めます。

データへのアクセスを制限し、個人情報や取引情報を必要以上に複製しない運用も決めておきます。

テストケースごとに、担当者と入力条件、期待結果を記録します。実績と証跡、判定、未解決課題、再テスト日も残します。

5. 稼働：カットオーバーと初期安定化の管理

稼働では、カットオーバーと初期安定化の条件を時系列で管理します。

• 切り替え作業：停止時間、最終バックアップ、移行、件数・残高確認、ジョブ・外部接続、権限、通知、切り戻し。
• 計画の条件：開始・完了条件、担当者、所要時間、依存関係、判断者、連絡先。
• 初期安定化：問い合わせ窓口を一本化し、使い方と障害を分け、業務指標やエラー・遅延・応答時間を確認。
• 切り戻し判断：残高不一致、法定帳票の出力不能、受注連携停止、復旧見込み超過など業務影響で判断。

日次の確認結果をもとに、優先順位は自社の業務責任者が決めます。開発会社に判断を任せきりにはしません。

売上計上や入出庫、請求、支払、月次締めなどを監視します。そのうえで、エラー件数やジョブ遅延、連携の滞留、応答時間を日次で確認します。

6. 定着：保守できる仕組みへの引き継ぎ

定着では研修だけでなく、担当者が継続して保守できる運用を整えます。

• 運用手順：業務手順、問い合わせ、権限申請、マスタ変更、移送、障害対応、バックアップ、リリース、監査対応。
• 保守契約：問い合わせだけか、一次切り分け、夜間監視、パッチ、SAPノート、性能改善、軽微な改修まで含むかを区分。
• 引き継ぎ確認：通常・例外・障害復旧の三つの代表業務を自社担当者が再現し、追加教育や契約見直しへつなぐ。

設計書とソースの対応、ジョブの目的、連携エラーの再送方法、既知の制約は、担当者の異動に備えて運用台帳に残します。

月次では、障害件数や処理時間、未使用アドオン、権限の棚卸し、未解決課題をレビューします。これにより、個別改修の膨張を防ぎやすくなります。

ABAPのシステム開発費用の相場と内訳

ABAP単体では、公開された一律の定価がほとんどありません。費用は、対象モジュールや既存コードの品質、連携数によって変わります。データ移行やテスト、ライセンスに加えて、Basis・インフラや保守範囲も費用を左右します。

ここで示す数字は、ABAP専用の公定価格ではなく、リサーチノートに基づく業務システム・ERP相場と公開調査による発注前の概算です。実予算は、現行資産の診断後に見直します。

案件規模ごとの費用・期間の目安

規模別の概算レンジは次のとおりです。いずれも、要件と既存資産の状態によって変わります。

• 小規模：帳票1本から数本などで100万〜500万円、1〜3か月。
• 中規模：複数モジュールや連携を含み500万〜2,000万円、3〜9か月。
• 大規模：複数連携、権限・監査、移行を含み2,000万〜1億円、6〜18か月。
• ECCからS/4HANAへのABAP資産移行：5,000万〜3億円程度、9〜24か月程度。

小規模に当たるのは、単純なレポートや軽微な画面・項目の追加、単一連携です。中規模は、帳票・承認とAPI・IDocの連携を含む案件です。Fiori、データ加工、総合テストも含まれます。

移行費用には、Zプログラムの棚卸しやATC検査、非互換修正、公開APIへの置換、性能・回帰テストが含まれる場合があります。

電通総研の「SAPユーザー意識調査結果2025年度版」によると、SAP S/4HANA移行費用は、10億円以上が26％、5億〜10億円未満が24.7％でした（出典: 電通総研、2025年度）。

この調査は、国内295社を対象とした、SAP全体の移行費用の調査です。ABAP開発費だけの統計ではないため、数字を読むときは注意してください。

初期費用に含める項目とランニングコスト

費用は、初期導入と稼働後の運用に分けて確認します。

• 初期導入：構想・調査、要件定義、機能コンサル、ABAP設計・実装、Fiori・帳票、API・IDoc連携、移行、権限、テスト、教育、稼働支援。
• 別請求の確認：Basis・インフラ、SAP・周辺サービスのライセンス、環境構築。
• 運用費：問い合わせ・障害対応、監視、ジョブ運用、バックアップ・復旧、パッチ、SAPノート、軽微な改修、性能改善、権限棚卸し。

ABAP費だけを低く示し、テストや移行を後から加える見積もりは比較しにくいため、範囲をそろえて見ます。

業務システム全般では、年間保守を初期開発費の10〜20％程度とする目安があります（出典: リサーチノート内のNotebookLM Q&A）。ただし、ABAPに定価はないため、対応時間、範囲、月間工数、緊急対応を確認します。

未使用のZプログラムを廃止し、標準機能や公開APIへ寄せ、テストデータと受入基準を早めに決めると、費用の抑制につながります。反対に、個別画面や帳票の追加、マスタ整備や権限の先送りは、仕様変更、移行、回帰テスト、教育へ波及します。その結果、費用が膨らみやすくなります。

ABAP開発の見積もりを取る際のポイント

見積もりを依頼する際は、「ABAPで作りたい」という要望に加えて、現行環境や業務、データ、連携の条件を渡します。非機能の条件、希望時期、保守方針も伝えます。

提案を比べるため、同じ情報と前提をもとに、複数社から見積もりを取ります。

見積もり前に準備する資料

見積もり前に、現行環境と対象業務の資料をそろえます。

• 現行環境：SAP製品・バージョン、モジュール、対象会社・拠点、ユーザー数。
• 開発対象：業務フロー、画面・帳票、Zプログラム、連携、ジョブ、データ件数、権限、障害履歴、希望稼働日。
• 移行情報：データ保持期間、名寄せの課題、残高・在庫の照合方法、移行できないデータの扱い。

要件書には、必須、できれば実現したい、将来検討の三段階を付けます。あわせて、応答時間や同時利用者、月間処理件数、ジョブ完了時刻も定めます。

障害時の復旧目標やログ保存期間、法定保存、暗号化、監査証跡、バックアップの復旧目標も、非機能要件に含めます。条件がないと、同じ帳票開発でも各社の前提が食い違います。

複数社の見積もりの同条件での比較

比較表では、作業範囲と費用の前提、発注後の体制を、同じ条件で照らし合わせます。

• 作業別費用：要件定義、方式設計、ABAP実装、UI・帳票、連携、移行、権限、テスト、教育、稼働支援、保守の工数・単価・期間。
• 範囲と成果物：前提、除外事項、成果物を確認し、「一式」は対象本数やケース数を質問。
• 契約・体制：担当者、再委託、引き継ぎ、成果物の帰属、検収、変更単価、障害責任、稼働後体制。
• 提案内容：業務シナリオを使った設計レビューで、業務成果まで考えているかを確認。

価格差が大きいときは、含まれる範囲が異なっていないかを調べます。発注先は、価格だけで評価せず、範囲や体制もあわせて見ます。

見積もりが膨らむリスクへの事前対応

見積もりでは、費用が増える要因と、変更が生じたときの扱いを先に整理します。

• 費用増の要因：古いZプログラムの仕様不明、標準機能とアドオンの境界、未整備マスタ、連携責任者不在、テストデータ不足、要望変更。
• 事前対応：開発者の増員で解消するとは限りません。棚卸しと意思決定者を置き、対象外も合意します。
• 変更管理：帳票追加、公開APIが使えない場合の方式変更、データ修正、テスト環境の遅れを想定し、再見積もりの担当者と手続きを決めます。

固定価格であっても、未知の要件まで無制限に含まれるわけではありません。そのため、前提と変更条件を契約書に残しておきます。

ECCを使う企業は、移行時期も判断材料になります。SAP公式情報では、SAP Business Suite 7の主要アプリケーションが2027年末までメインストリーム保守の対象です。2028年から2030年末までは、追加料金を伴う延長保守の選択肢があります。

S/4HANAは、少なくとも2040年までいずれかのリリースが保守対象です（出典: SAP Support、Maintenance 2040）。期限だけで移行を急ぐのではなく、Z資産の品質、業務リスク、予算、移行に必要な期間を見積もりに反映します。

ABAPのシステム開発でよくある質問（FAQ）

ABAPシステム開発では、技術の選び方のほか、既存資産や移行、費用、発注体制についても疑問が寄せられます。

ABAPは今後も必要ですか？

ABAPが一律になくなるとは限らず、ECCやS/4HANAの業務ロジック、帳票、連携、拡張の維持には知識が必要です。

新規開発ではABAP Cloud、CDS、RAP、公開APIを使う場面が増えています。そのため、Classic ABAPに偏らず、標準機能やClean Core、Fiori、API、移行の知識も整えます。

既存のZプログラムはすべてS/4HANAへ移行できますか？

すべてをそのまま移行できるとは限りません。まず、利用状況や業務上の重要度、標準機能との重複、未公開テーブルや古いAPIへの依存を棚卸しします。

性能や法定帳票との関係も確認したうえで、廃止、標準化、修正、再設計に分けます。残す場合も、公開APIや拡張ポイントへの置き換えと、移行後の回帰テストを検討します。

ABAP開発だけを外注できますか？

外注はできますが、コーディングだけを切り出せるかは案件によります。要件と設計を自社で確定し、テストデータやSAP環境、レビュー担当、受入基準を用意できれば、実装を委託しやすくなります。

業務要件が未整理で、移行や権限、連携も必要な場合は、SAP機能コンサルタントやBasis、テスト担当を含むチームへ依頼すると、どこまでを誰が受け持つかが明確になります。

ABAPシステムの開発費用を正確に出すには何が必要ですか？

必要なのは、現行バージョンや対象モジュール、業務フローのほか、画面・帳票、Zプログラム、連携本数に関する情報です。さらに、データ量、権限、テスト、希望時期、保守範囲も必要です。

既存コードの仕様が不明な場合は、本開発の固定価格を求める前に、棚卸しやアセスメントを依頼します。概算レンジと前提を分けて示してもらうと、予算と不確実性を管理できます。

ABAPのシステム開発の進め方のまとめ

開発の成否は、ABAP技術の選定だけで決まるとは限りません。要件整理で業務と標準機能の差分を把握し、方式と体制を決めることが出発点です。

設計・開発では、公開API、CDS、RAPや既存資産の扱いを定めます。そのうえで、テスト、移行、稼働、定着まで一貫して管理します。

進め方で外せない判断基準

方式は、標準機能や設定から始め、公開API、ABAP Cloud、サイドバイサイド拡張、Classic ABAPの順で比較します。個別開発は、最後の選択肢として検討します。

既存のZプログラムは、利用状況と移行の影響を調べたうえで、残す、直す、置き換える、廃止するに分けます。そうすると、次のアップデートで改修が連鎖するリスクを抑えやすくなります。

発注前にそろえる資料

発注前には、現行情報と見積もりの範囲をあわせて整理します。

• 現行情報：バージョン、対象モジュール、業務フロー、Zプログラム・連携一覧、データ量、権限、非機能要件、希望稼働日。
• 費用範囲：要件定義、機能設計、移行、テスト、教育、稼働後支援、保守を分け、根拠と除外事項を確認。
• 整理支援：自社だけで整理しきれない場合は、アセスメントから依頼して予算と開発範囲を定める。

ABAPシステムは、コードを納品しただけでは終わりません。業務部門が使い続け、担当者が保守し、SAPの変化に対応できる状態までを成果と考えます。そのうえで、6フェーズの完了条件と責任分担を決めます。

▼全体ガイドの記事
・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を創業。