SAPコンサルが全員ABAPでアドオンを開発できる必要はありません。ただし、標準機能とアドオンの境界を判断し、障害の原因を切り分ける場面では、ABAPを読めることが大きな助けになります。求められる深さは担当範囲によって違います。
担当別に必要な深さ
| 担当 | あると役立つABAP知識 |
|---|---|
| 業務・要件定義 | データ構造、拡張ポイント、標準とアドオンの区別 |
| 保守・障害調査 | エラー時の処理経路、デバッガ、権限チェック、更新処理 |
| アドオン設計 | 内部テーブル、Open SQL、BAPI/API、例外・性能・テスト設計 |
| 開発担当 | 実装・単体テスト・コードレビューまで |
ABAPを読めると何が変わるか
たとえば画面でエラーが出たとき、メッセージの発生箇所、権限不足、マスタ不足、アドオンの判定条件を分けて調べられます。仕様書だけでは分からない「現在のシステムの動き」を確認でき、開発担当への依頼も具体的になります。ただし本番システムでのデバッグや変更は権限と運用ルールに従います。
学ぶ順番
- 担当モジュールの業務フローと主要テーブルを理解する。
- 簡単なレポートで変数、内部テーブル、
SELECT、イベントを読む。 - テスト環境でブレークポイントを使い、画面操作から処理まで追う。
- アドオン設計や性能調査が必要になったら、BAPI、CDS、RAPなどへ広げる。
Fioriの案件でもABAPが消えるわけではありません。画面側のSAPUI5と、バックエンドのABAP・CDS等の役割を知ると、担当者同士の会話がスムーズになります。
