「SAP ERPのDXとABAPモダナイズ」では、ABAPを中心に下記について触れてきた。

• レガシーシステムとは何か
• レガシーコードとは何か

　Fit to Standard（標準導入）の観点からは「ない方が好ましいABAP」だが、実際には活用が必要になる場面も生じる。

　そこで本記事では「アリかナシか」ではなく、「ABAP」の技術的要素に踏み込み、システム構築をする中でABAPを活用する際、DXに向けて必要となる検討事項と、その際に役立つナレッジをご提供していきたい。

　特にSAP ERP刷新、新規導入といった場面におけるABAP検討の際にお役に立てばと思う。

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

▼ 目次
・SAP ERPで、ABAPが必要とされる場面
・SAP ABAPモダナイズの概要
・DXの文脈で語られる「ソースコードのモダナイズ」

1. SAP ERPで、ABAPが必要とされる場面

　「組み合わせて作る基幹システム」本連載で共通したテーマである。

　「組み合わせる」とはなにか？

　というと、APIで繋げることを指す。

　「それならABAPで作らず、外部でオープンな言語・仕組みで作った方が良いのでは？」という疑問が湧くが、外部からのAPI呼出しのみでシステムを構成すると、どのような課題・リスクが必要となるだろうか？

　解を見る前に、ぜひ考えてみて欲しい。

　答えは、以下のようなことが発生することになる。

• API呼出頻度が高くなると、都度、認証認可手続き及び通信のオーバーヘッドのため、期待するパフォーマンスが出ない
• 複数の更新系APIを呼び出した時に、API間でデータの整合性を担保することができない
• 複数の照会系APIを呼び出した時に、データの結合をロジック内で実現する必要が発生する

　詳細を見ていこう。

1-1. ABAPを使わない選択が、システムをより複雑化させる？

　課題・リスクへの対応策の一部として、一般的に良く使われるのは、メッセージキューイング（MQ）の仕組みを活用することだ。あるタイミングでは不整合が発生したとしても、MQで必ず処理されるはずなので、時間差で整合性は担保される、という考え方である。

　例えば受注と発注を同時に行うような処理で、受注と発注のタイミングが少しばかりズレたとしても、結果的にデータが発生していれば良い、というケースがある。その場合はMQで更新をかけておけばよい。ここまでは考えは単純だ。

　問題はここからで、一見従来の機能を再現したように見えるが、MQを使うということは、従来とは明らかに仕様が異なると考えるべきだ。従来は受注、発注双方のチェックロジックでOKが出てから両方の更新処理を実行していただろうが、今後は、受注は受注、発注は発注のチェックだけを行うことになる。結果として「本当だったら発注を考えるとNGだったはずのデータが、受注側ではOKになってしまった」という事態が発生しうる。タイミングがずれるだけでなく、仕様が異なることが業務上許容できるかということだ。

　ロールバックという概念は無くなるので、必要ならば更新系MQへデータを投入する前のチェックロジックだけのチェックMQを用意するとか、処理結果を受けてキー情報から当該データを削除して整合性を担保するような処理を用意するとか、意外と「APIを呼び出せばいい」というだけのはずが複雑化していくことがある。そこまでやるならば、いっそABAPでロジックを作成した方が良い。

1-2. 意外に、弱点がない「モダンなABAP」

　「ABAPを使おう！」となったとき、問われる疑問として、以下３点の懸念があがる。

• ABAPで作成すると、将来的なバージョンアップに対応できなくなるのではないか
• ABAPを使い続けることで、調達コストが増加するのではないか
• ABAPを使うことはシステムの柔軟性を損なうのではないか

　ひとつずつ、検討してみたい。

1-2-1. 将来的なバージョンアップへの対応懸念について

　この解は「作りに依存することになる」。

　SAPではVDMと呼ばれるデータ活用のためのデータモデルを公開している。多くの場合「CDS View」で公開されており、基本的にバージョンを越えて同じレイアウトで提供されることが保証されている、ということである。更新系の処理も、積極的にAPIを併用することで、バージョン差異の影響を最小限に（BTP上のJavaからAPIを呼び出すのと同程度に）とどめることができる。

1-2-2. 調達コスト問題への懸念について

　筆者が試してみた感想であるが、オブジェクト指向のABAPの作成や、単体テスト自動化の実装のうち、特に後者については、ABAPだけしか知らないというエンジニアよりも、オープン系の開発経験を持つエンジニアのキャッチアップが早いようだ。

　従来のABAPエンジニアは、多くの場合SAP標準のテーブル構造の理解であるとか、マスタ構造・フレームワークの知識といったものを持っているため一概には言えないが、ABAPはモダナイズすることで調達・育成の難易度が格段に下がると考えている。

1-2-3. 柔軟性に関する懸念について

　ポイントとなるのは、テストの自動化だ。

　柔軟性を損なっているのは、下記に挙げるソースコードの状態に依存していることが多いと思う。

• （ロジックを追いかけられないので）テストに時間がかかる
• （影響がわからないので）そもそも触るのが怖い

　少なくとも単体テストの自動化によって、どこかに破綻が発生したら自動的にその破綻を抽出できる状態が整っているのであれば、この二つは相当なレベルで軽減される。


　こうしてみてくると、「ABAPってなぜそんなに悪者扱いされているのか？」と思えるほどでもある。

　肌感覚となるが、単にオブジェクト指向のABAPを取り扱うベンダーが日本では非常に少なく、知っている人も少ないし、技術移行や育成の手法が確立されなかったということではないかと思う。

　なにせDX以前は大して要求されていなかったので、市場が育たなかったのだ。

2. SAP ABAPモダナイズの概要

　「モダナイズ」とは「モダナイゼーション」を指し、近代化・現代化といった意味を持つ言葉である。

　モダナイゼーションの概要については、以下をご覧ください。

　IT分野においては、古くなったシステムを現在のニーズに即した最新のシステムに生まれ変わらせることを指し使われる用語を指す。

　 ここでは下記について取り上げる。

• 今後、ABAPが満たすべき条件
• 新規ABAPの役割分担
• 既存ABAPのモダナイズをどうするか

2-1 今後、ABAPが満たすべき条件

　ABAPが存在すること自体は悪くないが、以下3つの条件を満たしていくことが必要だ。

• データモデルはSAPが標準で用意しているデータを参照する…バージョン差異対応
• 基本的には、オブジェクト指向のABAPを活用する…技術的制約対応
• 単体テストは自動化する…属人化排除・柔軟性確保対応

　ABAPをモダナイズするということは、こうした条件を満たすように新規プログラムを作っていくか、もしくは既存のプログラムを変更することを指している。

2-2. 新規ABAPの役割分担

　新規ABAPの場合は、比較的方針が明確である。

　UIは従来のGUIではなく、Web化しておいた方が、Web UI向けの多様なオープン技術の恩恵にあずかることができる。そうすると、画面操作や簡単な入力チェックといった作業は画面に任せておける。

　ABAPが担うべき役割はデータの整合性担保にある。

　画面とABAPの間にあるデータ加工に関しては、ケースに依るためABAP、あるいはJavaなどWeb上のバックエンド処理にするかは検討すれば問題がない。

　ABAPでは、「データを取り扱う」ための専用フレームワークが用意されている。Behavior Definitionという機能である。以前「BOPF（Business Object Processing Framework）」と呼ばれていたもののアップデート版だ。

　筆者は未検証ではあるが、基本的な制御をフレームワークがやってくれる点は、ローコード開発につながる。必要に応じ、ぜひ活用していただければと思う。

2-3. 既存ABAPのモダナイズはどうするか？

　既存のソースコードのモダナイズは、ハードルが高い。

　画面も従来通りGUIを使う方針を立てている場合もあるだろう。その場合もモダナイズは可能である。画面系の制御とビジネスロジックを分割して、ビジネスロジック部分をオブジェクト指向化することで、単体テスト自動化の恩恵にあずかることができる。

　通常の改修よりもコストはずっと必要になるが、やる価値はある。

　テクニカルにはインクルードの扱いとか、グローバル変数の扱いなど考慮すべき点は存在するが、ここでは実際に実行して成果を出した事例がある、という事実だけ共有しておきたいと思う。

　以下は、既存ABAPをモダナイズした場合の概念図。

3 DXの文脈で語られる「ソースコードのモダナイズ」

3-1. モダナイズされると何がいいのか

　モダナイズという言葉は、既存のソースコードがある場合に使われることが多いので、ここでは論点を明確化するため「新規構築」ではなく「既存が存在」する場合について触れていく。

　モダナイズは、それだけでコストがかかるものである。

　その割には、外部仕様（ユーザから見た、システムの挙動）は変化しない。

　そういう訳か、「エンジニアの満足のためだけに、そのコストが必要なのか？」といった疑問を耳にすることがある。


　「やる価値がある」ということを、まずは伝えておこう。

　システム全体をDX対応できるようにしようとするとき、「単体テスト自動化」というワードが非常によく出てくる。

　テスト（特に単体テスト）が自動化されていないソースコードは、多くの場合、属人化している。自動化されていないから、当然ながらテストにはかなりの時間がかかる。

　本来ならマイクロサービスアーキテクチャを目指し、次々に仕様変更していきたいのにそれができない。もちろん、DevOps（デブオプス）などの実現も不可である。

　こうした点から、テスト自動化は先進的なDXの取り組みとして、企業で触れられることがある。それが、SoRである。

　SoEとSoRについては、以下より「DX時代の基幹システムに求められる要素」をご覧いただきたい。

　SAPで必要なのかというのが次の疑問だろう。

• SAPそのものが高頻度で新機能を実装し続けており、これに対応するには、プログラムはできるだけ変更しやすい状態を保持する必要がある
• SoEの要件に応じて、SoRからデータ提供をする必要が多く存在しており、提供データの仕様は変化していることが想定される

　基本的には、SoRであってもモダナイズは必要。

　ただし、変更の可能性が極めて少ない領域においては、その限りではない。というのがSoR領域のモダナイズだ。

3-2. モダナイズの事例とROI

　投資対効果という文脈から「モダナイズは効果的だ！」と証明しにくいのが難点。

　しかし、中長期目線でみると、確実に効果は発揮されるだろう。

　そこで一例だが、あるプロジェクトの実測イメージを共有したい。

　モダナイズを終えたプログラムで、障害が発生したときの対応時間の図表である。

　1日半かかっていた対応が、3時間弱で完了したという結果となっている。

　単にテストが自動化されただけではなく、自動化へのプログラム改修が更なる効果を生み、大きな成果を伴っている事例である。

　さらに、中長期目線でみてみると、下記に挙げる様々な効果が期待できるが、事前に数値化で表現するのは難しい。

• 属人化排除ができる
• 調達／育成の容易性
• 技術的制約の排除

　取り組むかべきかどうかは、コストではなく、各社の戦略問題だと考えるのがいいと考える。

3-3. ABAPモダナイズの対象を選定するポイント

　先に触れたが、筆者は全てのABAPをモダナイズする必要があるとは考えていない。

　各社、システムの構成上、SAP ERPに必要とされる役割が異なるため、システム変更が要求される機能やプログラムもそれぞれの事情により異なるだろう。

　ごく一般的な考えとして「おすすめ」なのは帳票。

　比較的変更の頻度が多いだろうということと、外部連携で活用されがちなのが理由である。うまく構築すれば外部インターフェースと帳票プログラムのソースコード統合が可能だと思われるし、データレイクを構築する際にも格段に自由度が上がる。

3-4. 地味だが重要なソースコードのモダナイズ

　ソースコードのモダナイズは非常に地味な活動である。

　地味ではあるが、積み上げれば積み上げるほどに、じわじわと確実に成果が上がる。

3-4. ABAPモダナイズの効果

　エンジニアの観点から、ABAPモダナイズの効果を付け加えたいと思う。

　ABAPは、SAP独自の独特な言語として歴史を重ねてきており「ABAPエンジニアであることは、今後、市場価値を持ちづらいのでは？」と懸念する、非常に多くの優秀なエンジニアの声が聞かれる。

　ABAPエンジニアはABAPモダナイズによって、いつでもオープン系の開発に従事することができるようになる。

　BTP上でのJava開発やFioriといったフロントエンド系の開発もハードルがずっと低くなる。

　反対に、オープン系技術者も、ABAPエンジニアを抱えるベンダーも、モダナイズされたABAPの現場であれば今後もますます活躍することができる。

　ABAPモダナイズは、エンジニアの流動性を高め、モチベーションをアップさせる取り組みだとも、とらえている。そして、エンジニアの枯渇状況が叫ばれる中、モダナイズとともにエンジニア調達の選択肢を広げられることは、再度お伝えしておきたい。

　人材のアップデート、技術のアップデートは、ベンダーだけの課題ではなくなってきている。DX対応の基幹システムを検討するときには、ぜひこのような論点もご一考いただければと思う。

次回予告

　次回はFit to Standardの基本的な進め方や、進めるうえでのポイント、実施することで得られる効果などを、改めて考察する。