SAPを中心としたシステムを構築する中で、「ABAP」という技術要素は避けて通れないが、この扱いは時に難しい。

　ABAP（読み方：アバップ）とはAdvanced Business Application Programmingの略で、SAPの動作基盤であるNetWeaver上で拡張機能を開発するための開発言語である。

　標準導入（＝Fit to Standard）の文脈からは、ない方が望ましい。Fit to Standardとは、ERPのパッケージに備わっている標準機能をフル活用する手法のことだ。

　一方、既存資産（システム＆人的）の利活用では魅力的であるだけでなく、むしろしっかり理解したうえで使った方が良い場面も存在する。

　そこで今回は「アリかナシか」ではなく下記をご提供したいと思う。

• DXに向けて必要となるABAPをめぐる検討事項
• その際、役立つ技術的ナレッジ

　経済産業省が提唱するDXレポートに対応した基幹システムを検討していくための材料をご提供していく。正確に理解をしてほしく論説が長くなってしまったためPart１、Part２と２回に分け掲載することとした。ぜひお付き合いいただければと思う。

＼ SAP ERPに関連したおすすめイベント・セミナー ／

▼ 目次
・レガシーシステムの原因は、レガシーコードにある
・SAPの開発言語「ABAP」イコール技術的制約という認識は誤り

1. レガシーシステムの原因は、レガシーコードにある

• レガシーシステムとは何か？
• レガシーコードとは何か？
• レガシーシステムとレガシーコードのDXには、何をすべき？

1-1. レガシーシステムとは何か？

　はじめに、レガシーシステムとはなにか、という基本から考えたい。

　レガシーシステムとは、DXレポートで語られた「DX化の足かせとなるシステム」を指す。

　ここで、DXレポートが示す以下の「レガシーシステムの特長」を見てみよう。

グラフ １. レガシーシステムが足かせを感じる理由

（出典）経済産業省　 DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～（簡易版）
一般社団法人日本情報システム・ユーザー協会「デジタル化の進展に対する意識調査」平成29年

　これらレガシーシステムの特長11項目のうちレガシーコードに関わる項目はといえば、以下の通りなんと6項目も存在する。

• 9.ドキュメントが整備されていないため調査に時間を要する
• 2.レガシーシステムとのデータ連携が困難
• 10.影響が多岐にわたるため試験に時間を要する
• 3.技術的な制約や性能の限界がある
• 4.有識者がいない、ブラックボックス化しているため触れたくない
• 8.維持・運用費が高く、改修コストを捻出しにくい

　レガシーシステムには「レガシーコード」が大きく影響していることが明確である。

　「そういうことなら、そもそもソースコードを持たなければいい（！）」

　その通りである。

　DXレポートでも、レガシーシステムが発生した背景には、不要な個別開発による機能拡張があったことが指摘されている。Fit to Standardというコンセプトは、そもそもこういった個別の機能拡張を発生させないアプローチであると言える。

　この連載で、繰り返し「ノーコード・ローコード」を提唱してきた。できるだけ組み合わせてシステムを構成する中で、不可避に発生する不利益点は「ノーコード・ローコード」でカバーする。「そもそも持たなければ、レガシー化の懸念はなくなる」というわけだ。

　一方で、そうはいっても、現実的に機能拡張が必要となる場面は存在するだろうし、既存の資産を活かしたい、という場面もあるだろう。

1-2. レガシーコードとは何か？

　キャッチコピー的にいうなら「テストがないコードはレガシーコードだ！」ということになる。

（「レガシーコード改善ガイド」、翔泳社、マイケル・C・フェザーズ（著）、平澤章・越智典子・稲葉伸之・田村友彦・小堀真義（翻訳））

　「テストがない」レガシーコードの特長は「システム変更が容易ではない」という1点に集約される。システム変更ができないシステムは「塩漬け」にならざるを得ない。

　つまり、レガシーコードで作られているのがレガシーシステムとなる。

1-3. レガシーシステムとレガシーコードのDXには、何をすべき？

　システムには、塩漬けで良いものと悪いものが存在する。長らく続いてきた業務の中で、見直すことがなさそうに思われる帳票やロジックは存在するだろう。一方、今後、見直しが発生しそうな処理や、外部のシステムと自由に連携したいというデータ・処理・機能も存在するものである。

　「レガシー＝悪」というのは、大きな流れで言えばその通りだが、もう少し中身を見て判断してほしい。

　SoR※を全面的に見直したり、常に改修がかかり続けることは考えにくい。とはいえ多くの場合、レガシーシステムに課題は存在する。

　モダナイズ※は、大まかにはこういったコードレベルの選別から開始することになると思われる。

※SoR（System of Record）とは、正確に記録することを重視して設計されたシステムを指し、業務システムの意味で使われる。SAP S/4HANAをはじめとするERPを含む基幹システムが該当し、品質、安定性や継続性がこのSoRの特長であり、価値となる。

※モダナイズとは、すでに稼働しているソフトウェアやハードウェアなどを、稼働中の資産を活かしながら最新の製品や設計で置き換えることを指す。

2 SAPの開発言語「ABAP」イコール技術的制約という認識は誤り

• ABAPは継続的な投資対象。モダナイズに重要な新機能も追加
• DX対応できない「古いABAP」「手続き型ABAP」課題

2-1. ABAPは継続的な投資対象。モダナイズに重要な新機能も追加

　さて、２章からは技術的な面を中心に解き明かしていきたい。

　企画・管理部門の方には馴染みにくい話になると思うが、今後、SAP ERPのシステム刷新などを考えている担当者の方々は、ぜひ、一度耳に慣らしておいていただけると、今後役立つ日がくるだろうと思う。当記事の読者はシステム関係者が多いため、技術要素中心に今回は話を進めていこうと思う。

　さて、RAP（RESTful ABAP Programming Model）という言葉を聞いたことがあるだろうか。SAP社が提唱している新しいABAPプログラミング手法である。SAP社はABAPについて継続的に投資の対象であることを明言し、ABAPへの機能追加や新しい環境への適応を発表している。2018年のSAP TechEdで方針が発表され、ラスベガス会場は盛大な拍手が沸き起こった。

　そういった文脈の中、2017年9月には重要な役割を果たす新しい機能として、テストにおいてデータを仮想化する待望の機能がABAPに追加されている。

　これまで多くのエンジニアが「SAP社のERPシステムはデータの断面によって挙動が変わるから、いつもテストが大掛かりにならざるを得ない」とボヤいていたのではないだろうか？

　しかし、この新機能により、単体テストにおけるデータ依存・環境依存を解消することができる。これはレガシーコードから脱却する非常に大きな要素となる。

　ただし、この機能が活用できるのも基本的には新しいオブジェクト指向のABAPのみ。実はこの機能に限らず、SAPが提供する「新しいABAP機能」は、オブジェクト指向のABAPでしか提供されていない。技術的観点からは、「ABAPかどうか」ではなく「古いABAPか、新しいABAPか」が、判断ポイントとなる。

• 新しいABAP
• オブジェクト指向
• 古いABAP
• 手続き型（次項参照）

2-2. DX対応できない「古いABAP」「手続き型ABAP」課題

　古いABAPには新しい機能は搭載されない。

　すなわち、以下ができない。

1. RAP方式による実装
2. インターフェースをODATAとして公開してクラウドとの通信
3. 単体テスト自動化を実装
4. その他画面のリアルタイム更新（IoT対応のための機能）等新機能の活用

　これら４つは、条件として「オブジェクト指向ABAP（新しいABAP）である」ことが課せられている。結果、既存のABAPはDX対応が難しく、「古いABAPはレガシーコード化しやすい」といわれる所以となっている。

表 1. ABAPは悪か

　次回、SAP ERPのDXとABAPモダナイズPart２「レガシーシステムはレガシーコードでできている」へ続く