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

ABAPのシステム開発は、ABAPのプログラムを書くことから始めず、SAP標準機能と業務要件を整理し、将来の移行や保守まで見据えて6段階で進めることが成功の近道です。

「既存のZプログラムを残せるのか」「S/4HANAやクラウドでもABAPは必要なのか」「どこまでを開発会社へ依頼すればよいのか」と悩む担当者は少なくありません。本記事では、ABAPのシステムの全体像から、要件整理、選定、設計開発、テスト、稼働、定着までの進め方を、判断基準・確認事項・費用相場・見積もりの見方とあわせて解説します。

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

ABAPのシステムとは何ですか？全体像を理解します

ABAPのシステムとは、ABAPという言語単体の製品ではなく、SAP ERP、SAP ECC、SAP S/4HANAなどの業務基盤をABAPで拡張・連携・運用する仕組みを指します。財務会計、販売、購買・在庫、生産、人事などの業務データを中心に、標準機能では足りない画面、帳票、承認、連携、バッチ処理を追加します。

代表的な機能は、ALVなどを使った一覧・集計レポート、SAP GUIやSAP Fioriへ追加する入力画面、請求書・納品書・注文書などの帳票、倉庫・銀行・EDI・CRM・BIとの連携、定期ジョブや大量データ処理です。承認ルート、変更履歴、監査用ログ、権限に応じた表示制御もABAP開発の対象になります。

ただし、ABAP担当者だけで業務要件を決められるとは限りません。販売条件ならSD、購買ならMM、会計ならFI・COなどのSAP機能知識、Basisやインフラの設計、データ移行、権限設計、ユーザー受入を組み合わせて初めて業務システムとして成立します。見積もりや体制を見るときは、ABAP開発者の人数だけでなく、これらの役割が含まれているかを確認します。

全体像は、SAPアプリケーションサーバー上のABAPランタイム、HANAデータベース、SAP GUIまたはFioriの画面、外部システムとの接続、認証・認可、開発・検証・本番環境、移送管理、テスト、監視に分けて捉えると整理しやすくなります。たとえば販売管理と倉庫をつなぐ場合は、ABAPの処理だけでなく、IDoc、RFC、BAPI、API、ファイルなどの接続方式と、エラー時の再送・通知まで設計します。

財務・取引先・従業員データを扱う場合は、機能要件と同時に最小権限、職務分掌、特権ID、開発・本番の分離、変更履歴、監査ログ、バックアップ、復旧、通信の暗号化を決めます。個人情報保護委員会のガイドラインでも、アクセス制御や認証、ログの定期分析、不正アクセス防止、通信経路の暗号化などが安全管理措置の例として示されています。

既存ECCの資産を活用する改修ではClassic ABAPが現実的な場合があります。一方、新規のS/4HANA拡張では、公開APIや拡張ポイント、CDS、RAP、Fioriを優先し、SAP標準コードと顧客拡張を分離するClean Coreの考え方が重要です。SAP公式のABAP Cloud Development Modelでは、クラウド最適化されたABAP言語、CDS、RAP、ABAP Development Tools、公開APIを組み合わせ、アップグレードに強い拡張を目指す開発モデルとして整理されています。

2026年時点のSAP Platform資料では、ABAP for Cloud Developmentは利用できる構文や参照可能な開発オブジェクトを制限し、Released APIのリリース契約によって安定した拡張を支えます。したがって「ABAPが古いか新しいか」で判断するのではなく、現行バージョン、移行計画、求める自由度、アップグレード頻度、外部連携の責任範囲を並べて方式を選びます。

ABAPのシステム開発の進め方を6フェーズで解説します

ABAPの開発は、要件を聞いてすぐコーディングする流れではありません。業務と標準機能の差分を把握し、方式を選び、設計・開発・テスト・移行・定着を一続きの計画にすることが重要です。以下では、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けて、成果物と判断基準を示します。

最初に現行SAPのバージョン、利用モジュール、ユーザー数、主要業務フロー、帳票、バッチ、インターフェース、Zプログラム一覧、障害履歴、データ量を棚卸しします。要望は「入力画面を変えたい」ではなく、「どの担当者が、どのデータを、どの条件で処理し、何を成果物として出すのか」に分解します。現行画面の項目名だけを受け取ると、実際の承認や例外処理が抜けやすいためです。

この段階の判断基準は、標準機能や設定で解決できるか、キー・ユーザー拡張や公開APIで対応できるか、サイドバイサイド拡張が適切か、ABAP開発が必要かです。法定帳票、締め処理、在庫評価、監査証跡など後戻りが難しい要件は、業務部門と経理・法務・情報システムが承認します。成果物は業務フロー、要件一覧、非機能要件、対象データ、対象インターフェース、対象外の明示です。

チェックポイントは、要望ごとに優先度、発生頻度、代替手段、法的必須性、将来の移行影響が記録されていることです。「現場が便利になるから」という理由だけで個別アドオンを増やさず、業務を標準へ寄せる選択肢も同じ表で比較します。

要件がまとまったら、パッケージ標準、設定変更、キー・ユーザー拡張、ABAP Cloud、BTP上のサイドバイサイド拡張、Classic ABAPの順に比較します。S/4HANA Cloud Public Editionでは、クラウド対応とアップグレード安定性を満たす開発者拡張が前提になりやすく、既存ECCの自由なテーブル参照をそのまま移すとは限りません。データを密に扱う処理はオンスタック、外部サービスや複数システムをまたぐ処理は疎結合の拡張というように、責任範囲で分けます。

開発会社を選ぶときは、SAP認定や要員数だけでなく、自社の業界とモジュールの実績、Zプログラム棚卸しの方法、ATCなどの移行診断、CDS・RAP・Fiori・APIの経験、データ移行と権限設計の責任分担、稼働後の日本語サポートを確認します。ABAP開発者の派遣なのか、機能コンサルタント・Basis・テスト担当を含む成果物型のチームなのかも、見積もり前に区別します。

チェックポイントは、採用しなかった方式と理由まで残っていることです。特に「クラウドだから安い」「スクラッチなら業務に合う」と決めつけず、初期費用、移行費、ライセンス、運用、アップグレード、テストの総保有コストで比較します。

設計では、業務フロー、画面、帳票、データ項目、エラー処理、権限、ログ、連携、ジョブ、性能目標を具体化します。S/4HANA向けの新規開発なら、公開APIや拡張ポイントを先に確認し、CDSで意味のあるデータモデルを設計し、RAPでトランザクションサービスを構築する流れを検討します。画面だけを先に作るのではなく、どの業務オブジェクトを誰が変更できるかを定義します。

Classic ABAPで既存資産を改修する場合も、未公開テーブルへの直接依存、標準オブジェクトの変更、ハードコーディングされた会社コードや税区分、処理量に対する性能不足を確認します。コードの品質を保つため、命名規約、レビュー基準、静的解析、移送単位、ソースコードの保管先、設計書とコードの対応関係を合意します。

チェックポイントは、設計書に正常系だけでなく、入力不備、重複、タイムアウト、連携先停止、再送、ロールバック、権限不足、月末や大量データの扱いまで書かれていることです。納品物にはソースコード、基本・詳細設計書、API一覧、権限設計、ジョブ一覧、テスト仕様、移行手順、運用手順、既知の制約を含めます。

テストは、ABAPプログラムがエラーなく動くかだけでなく、業務の開始から完了まで正しい結果になるかを確かめます。単体テストではロジックと例外、結合テストではSAPモジュールや外部連携、総合テストでは締め処理や権限、性能テストではピーク時の応答とジョブ時間、受入テストでは現場の判断基準を検証します。

データ移行を伴う場合は、本番直前に一度だけ移す計画にしません。移行対象の抽出、変換、名寄せ、エラー修正、件数照合、残高照合、移行時間、切り戻しをリハーサルします。テストデータには権限を持つ人だけがアクセスし、個人情報や取引情報を必要以上に複製しない運用も決めます。

チェックポイントは、テストケースに担当者、入力条件、期待結果、実績、証跡、判定、未解決課題、再テスト日が記録されていることです。重大な障害を残したまま稼働日を迎えないため、重大度ごとの未解決件数と、誰がリリース可否を決裁するかをあらかじめ決めます。

稼働フェーズでは、移行停止時間、最終バックアップ、移行実行、件数・残高確認、ジョブ設定、外部連携の接続、権限付与、ユーザー通知、障害時の切り戻しを時系列で管理します。カットオーバー計画は作業名だけでなく、開始条件、完了条件、担当者、所要時間、依存関係、判断者、連絡先まで記載します。

稼働直後のハイパーケアでは、問い合わせ窓口を一本化し、画面の使い方と障害を分けて受付します。売上計上、入出庫、請求、支払、月次締めなど業務影響の大きい指標を監視し、エラー件数、ジョブ遅延、連携滞留、応答時間を日次で確認します。開発会社だけに任せず、自社の業務責任者が優先順位を決めます。

チェックポイントは、切り戻しの判断基準が「問題があれば戻す」のような曖昧な表現になっていないことです。たとえば残高不一致、法定帳票の出力不能、受注連携の停止、復旧見込みが設定時間を超える場合など、業務影響で判断できる条件に置き換えます。

定着フェーズでは、操作研修だけでなく、業務手順、問い合わせ、権限申請、マスタ変更、移送、障害対応、バックアップ、リリース、監査対応を運用に落とし込みます。担当者が異動しても保守できるよう、設計書とソースコードの対応、ジョブの目的、連携エラーの再送方法、既知の制約を運用台帳へ残します。

保守契約では、問い合わせ対応だけか、障害の一次切り分け、夜間監視、セキュリティパッチ、SAPノート適用、性能改善、軽微な改修まで含むかを分けます。月次で障害件数、処理時間、未使用アドオン、権限棚卸し、未解決課題をレビューすると、稼働後に個別改修が膨張することを防ぎやすくなります。

チェックポイントは、引き継ぎ後に自社担当者が三つの代表業務を実際に再現できることです。具体的には、通常処理、例外処理、障害時の復旧を手順書だけで実施し、できない箇所を追加教育や契約範囲の見直しにつなげます。

ABAPのシステム開発費用の相場と内訳を確認します

ABAP単体には公開された一律の定価がほとんどなく、対象モジュール、既存コードの品質、インターフェース数、データ移行、テスト、ライセンス、Basis・インフラ、保守範囲で費用が変わります。以下の金額はABAP専用の公定価格ではなく、リサーチノートに基づく業務システム・ERP相場と公開調査をもとにした発注前の概算レンジです。実際の予算は、現行資産の診断後に見直します。

既存帳票1本から数本、単純なレポート、軽微な画面・項目追加、単一インターフェースであれば、100万〜500万円、期間は1〜3か月が一つの概算レンジです。複数モジュールをまたぐ帳票・承認、APIやIDoc連携、Fiori画面、データ加工、総合テストを含む中規模案件では、500万〜2,000万円、3〜9か月程度が目安になります。いずれも要件と既存資産の状態によって変わります。

販売・購買・生産などの大規模アドオンに、複数システム連携、権限・監査、移行を含める場合は、2,000万〜1億円、6〜18か月程度のレンジで検討します。ECCからS/4HANAへABAP資産を移行し、Zプログラムの棚卸し、ATC検査、非互換修正、公開APIへの置換、性能・回帰テストまで行う案件は、5,000万〜3億円程度、9〜24か月程度の規模になる場合があります。

ここで注意したいのは、移行費用のレンジがABAP改修だけを意味しないことです。電通総研の「SAPユーザー意識調査結果2025年度版」では、SAP S/4HANAへの移行費用について、10億円以上が26％、5億〜10億円未満が24.7％でした（出典: 電通総研、2025年度）。この調査は国内295社を対象にしたSAP全体の移行費用であり、ABAP開発費だけの統計ではありません。

初期費用は、構想・現状調査、要件定義、機能コンサルティング、ABAP設計・実装、Fioriや帳票、API・IDocなどの連携、データ移行、権限、テスト、教育、カットオーバー、ハイパーケアに分けて見ます。Basis・インフラ、SAPや周辺サービスのライセンス、環境構築が別請求かどうかも確認します。ABAP開発費だけを安く見せ、テストや移行を後から追加する見積もりは比較しにくいためです。

ランニングコストには、問い合わせと障害対応、監視、ジョブ運用、バックアップ・復旧、セキュリティパッチ、SAPノート適用、軽微な改修、性能改善、定期的な権限棚卸しが含まれます。業務システム全般の相場では、年間保守を初期開発費の10〜20％程度とする目安があります（出典: リサーチノート内のNotebookLM Q&A）。ABAP案件にもそのまま適用できる定価ではないため、対応時間、対象範囲、月間工数、緊急対応の有無を分けて確認します。

コストを抑えやすいのは、使われていないZプログラムを廃止し、標準機能や公開APIへ寄せ、テストデータと受入基準を早く決める進め方です。反対に、業務部門ごとに個別画面・帳票を追加し、マスタ整備や権限を後回しにすると、仕様変更、移行、回帰テスト、教育が連鎖して費用が膨らみやすくなります。

ABAP開発の見積もりを取る際のポイントを解説します

見積もりの精度を上げるには、開発会社へ「ABAPで作りたい」とだけ伝えず、現行環境、対象業務、データ、連携、非機能、希望時期、保守方針を渡します。発注先の提案力を比べるためにも、同じ情報と同じ前提で複数社から見積もりを取ります。

最低限、SAPの製品名とバージョン、利用モジュール、対象会社・拠点、ユーザー数、業務フロー、現行画面・帳票、Zプログラム一覧、インターフェース一覧、ジョブ一覧、データ件数、権限ロール、障害履歴、希望稼働日を準備します。移行案件なら、現行データの保持期間、名寄せの課題、残高・在庫の照合方法、移行できないデータの扱いも渡します。

要件書には、必須、できれば実現したい、将来検討の三段階を付けます。さらに、応答時間、同時利用者、月間処理件数、ジョブの完了時刻、障害時の復旧目標、ログの保存期間、法定保存、暗号化、監査証跡、バックアップの復旧目標などを非機能要件にします。これらがないと、同じ「帳票開発」でも開発会社ごとの前提が異なります。

比較表では、要件定義、方式設計、ABAP実装、UI・帳票、連携、移行、権限、テスト、教育、稼働支援、保守を分け、各項目の工数、単価、期間、成果物、前提、除外事項を並べます。特に「ABAP開発一式」「テスト一式」のような大きな項目は、対象本数やケース数を質問します。価格差が大きい場合は、安い会社が悪いのではなく、含まれる範囲が違う可能性を確認します。

発注先には、担当予定者の役割と経験、再委託の有無、担当者変更時の引き継ぎ、ソースコードと成果物の帰属、検収条件、仕様変更の単価、障害時の責任分界、稼働後の体制を尋ねます。既存のSAP機能と業務理解が必要な案件では、提案時に実際の業務シナリオを使った設計レビューを依頼すると、コードだけを作る会社か、業務成果まで考える会社かを見分けやすくなります。

ABAP案件で費用が膨らみやすいのは、古いZプログラムの仕様が分からない、標準機能とアドオンの境界が曖昧、マスタが整備されていない、インターフェースの責任者が不明、テストデータが用意できない、業務部門の要望が途中で変わるといった場合です。これらは開発者を増やすだけでは解消しません。最初に棚卸しと意思決定者を置き、対象外の範囲まで合意します。

見積もりには、前提が崩れた場合の変更管理を入れます。たとえば対象帳票が追加された場合、公開APIが使えず別方式になった場合、データ品質の修正が必要になった場合、テスト環境の準備が遅れた場合を、誰がどの手続きで再見積もりするか決めます。固定価格でも未知の要件まで無制限に含まれるわけではないため、前提と変更条件を契約書に残します。

また、ECCを使っている企業は移行時期も判断材料にします。SAP公式情報では、SAP Business Suite 7の主要アプリケーションは2027年末までメインストリーム保守、2028年から2030年末までは追加料金を伴う延長保守の選択肢があり、S/4HANAは少なくとも2040年までいずれかのリリースが保守対象です（出典: SAP Support、Maintenance 2040）。期限だけで移行を急ぐのではなく、Z資産の品質、業務リスク、予算、移行に必要な期間を見積もりへ反映します。

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

最後に、ABAPのシステム開発を検討する担当者から寄せられやすい疑問へ回答します。技術の選択だけでなく、既存資産、移行、費用、発注体制の判断に役立つ内容です。

ABAPが一律になくなるわけではありません。ECCやS/4HANAの業務ロジック、帳票、連携、拡張を維持するにはABAPの知識が必要で、新規開発ではABAP Cloud、CDS、RAP、公開APIを使う場面が増えています。重要なのはClassic ABAPの技術だけに依存せず、標準機能、Clean Core、Fiori、API、移行の知識まで含めて体制を整えることです。

すべてをそのまま移行できるとは限りません。まず利用状況、業務上の重要度、標準機能との重複、未公開テーブルや古いAPIへの依存、性能、法定帳票との関係を棚卸しし、廃止、標準化、修正、再設計に分けます。残す場合も、公開APIや拡張ポイントへ置き換えられるかを確認し、移行後の回帰テストまで含めて判断します。

外注できますが、ABAPのコーディングだけを切り出せるかは案件によります。要件と設計を自社で確定し、テストデータ、SAP環境、レビュー担当、受入基準を用意できる場合は、実装部分を委託しやすくなります。業務要件が未整理で、移行や権限、連携も必要なら、SAP機能コンサルタントやBasis、テスト担当を含むチームへ依頼した方が責任分界が明確になります。

現行バージョン、対象モジュール、業務フロー、画面・帳票、Zプログラム、連携本数、データ量、権限、テスト範囲、希望時期、保守範囲が必要です。特に既存コードの仕様が不明な場合は、最初から本開発の固定価格を求めず、棚卸し・アセスメントを先に依頼します。概算レンジとその前提を分けて提示してもらうと、予算と不確実性を同時に管理できます。

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

ABAPのシステム開発は、ABAPの技術選定だけで成否が決まりません。要件整理で業務と標準機能の差分を明らかにし、選定で拡張方式と体制を決め、設計開発で公開API・CDS・RAPや既存資産の扱いを定め、テスト・移行・稼働・定着まで一貫して管理することが重要です。

特に重視したいのは、標準機能・設定・公開API・ABAP Cloud・サイドバイサイド拡張・Classic ABAPの順で比較し、個別開発を最後の選択肢として検討することです。既存のZプログラムは、利用状況と移行影響を調べてから、残す、直す、置き換える、廃止するに分けます。これにより、目先の要望を満たしながら、次のアップデートで改修が連鎖するリスクを抑えられます。

発注前には、現行バージョン、対象モジュール、業務フロー、Zプログラム一覧、連携一覧、データ量、権限、非機能要件、希望稼働日をまとめます。見積もりはABAP実装だけでなく、要件定義、機能設計、移行、テスト、教育、稼働後支援、保守を分け、金額の根拠と除外事項を確認します。自社だけで整理しきれない場合は、アセスメントから依頼すると、予算と開発範囲を現実的に定めやすくなります。

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

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