はじめに

本記事は「SAP Side by Side開発の基本的なことまとめ」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。

なぜ「Side by Side開発」を実施するのか？

こちらに関しては、明確な定義のようなものはなく、いくつもの利点があります。個人によって捉え方は変わると思うのですが、私個人としての見解として、大きな利点は下記の2点になります。

疎結合アーキテクチュアによる、パッケージアップグレード負荷の軽減
自由度の高い基盤による、新しいテクノロジーの早期取り込みによる付加価値創造

パッケージアップグレード負荷

良くも悪くもS/4HANAとABAPの組合せの開発は結合度が高い仕組みでした。ある程度丁寧に設計書を書いたとしても、すべてを簡単に可視化することができません。そのため、一度作ったアプリケーションの基盤がアップグレードされた際に関連する変更点の特定が難しく、一通りのテストの再実施を実施するというのが一般的な対応方法となっていました。ゆえに、10億かけて構築した仕組みを、2億かけてアップグレード＆リグレッションテストをするといった話がECC時代にはあったと思います。

それに対して「Side by Side開発」にすると、S/4HANAの標準機能（プラットフォーム機能）との接点が、APIの仕様というかたちで明確化されるため、影響の把握および改修・テストがしやすくなります。S/4HANA側のAPIをアドオンしてしまうとそこに対する影響調査は残ってしまうのですが、標準のAPIを利用していれば、そこはSAP社として動作を保証してくれるので、アップグレード対応のアドオン影響確認に必要な工数が格段に下がることになります。

SAP社の標準APIについてについて、こちらの記事でもう少し詳しく書いています。

S/4HANAのアップグレードサイクルの高速化

アップグレード負荷に着目しなければいけない背景には、S/4HANAのアップグレードサイクルの高速化があります。

S/4HANA以前のSAP社のERP製品はかなり長い期間の製品保証がされておりました。これらの保証が切れるのが2025年末、2027年末のため、昨今、S/4HANA化のプロジェクトが多数立ち上がり、SAPビジネスマーケットの活況を招いています。

それに対して、S/4HANAの製品保証期間は原則5年となります。（正確にはそれ以降は「Customer Specific Maintenance」期間に入り、いろいろと製品を利用する上での制約が発生します。このあたりの正確な情報をSAP社にお問い合わせ下さい。）そのため、S/4HANAは基本的には5年周期でのアップグレード作業が必要になり、S/4HANA以前の時代に比べ、アップグレード対応に容易に対応できるシステムを構築する必要があるわけです。

ABAPのアップグレード負荷は高いのか？

アップグレードに関して必ず話題に上がるテーマです。理論的には、ABAPプログラムであっても、標準との接点を明確かつシンプルになるようプログラムを作成し、必要に応じて仕様書を作成すれば、アップグレードの際の影響範囲の見極めはそれなりの精度で可能になります。ただし、それを保守も含め実現するのは難易度が高く、アップグレードの際に全体的なテストをするという現実があるため、疎結合にすることが推奨されています。

新しいテクノロジーの早期取り込み・付加価値創造

こちらに関してはあまり深い説明はいらないでしょう。S/4HANAとABAPの組合せでは、ABAPを用いてゼロから追加開発機能を組み上げることが必要でした。

それに対して「Side by Side」では、ゼロからの構築の場合でも様々な言語（主にはJavaとJavaScript）を選択することができます。SAPの世界にいると感じにくいのですが、これらの言語に対してはOSS(Open Source Software)として、様々なライブラリやフレームワークが展開されているのでできることの幅は広がります。（OSSはOSSで、アップデートや脆弱性対応などやることがあるという事実もあるのですが。。）

DevOpsの実現と開発サイクルの高速化

OSS活用の新技術の取り込みにより、向上するのは機能要件的な側面だけでなく、開発者側の利便性も向上します。

OSSは一般に公開されるようなIT技術は、WEBアプリ、モバイルアプリ、WEBサイトなどの開発向けに作られているものも多く、いわゆるDevOps的な、短期間に開発・デプロイを実現する開発アーキテクチャの構築が可能になります。具体的には、自動で単体テストを実行したり、各種のデプロイ作業を自動実行したりすることで、純粋な開発以外の工数・期間を短縮し、開発サイクルを高速化を実現します。

BTP単体でのこのあたりの機能群は不足があり、外部サービスの利用が必要になることやこれらを運用するための各種のスキルの習得が必要になることから、完璧なかたちでの実現のハードルは高い現状ではありますが、S/4HANAでのDevOpsも不可能ではない状況です。

ローコード・ノーコードツールの活用

BTPでは、アプリケーションの作成にプログラミングをあまり必要としない、「ローコード・ノーコードツール」の開発にも力をいれています。

具体的にはカスタム開発の実施に際しては、その実施ツール（IDE）である、「Business Application Studio」に「ローコード機能」が実装され、コーディングの難易度や負荷を軽減できます。また、「ローコード・ノーコードツール」である「SAP AppGyver」やRPAやワークフローを従来のBTPサービスよりさらに容易に開発できるようになった「SAP Process Automation」なども準備されています。これにより開発スキルやコーディングスキルがなくても、アプリケーションの開発が可能になります。

「Side by Side開発」なら何をやっても良いのか

「Side by Side開発」の話をしていると、「Side by Sideなら追加開発をし放題だ！これで、業務を変えずにシステム導入できる！」とか「ECCで400本あるアドオンが、S/4HANA移管の際にSide by Sideで開発したい！」といった、思考を持つ方がいます。（多少誇張していますが。。。）

勘違いしてはいけないのは、「Side by Side開発」は上記のようなメリットはあれど、追加開発です。当然、構築工数がかかりますし、バグを含むリスクもあります。また、アップグレード対応や保守系の工数かかることに変わりはありません。基本的にS/4HANAにおける概念は「Fit to Standard」です。

まとめ

ここまでの内容で「パッケージアップグレード負荷の軽減」と「新しいテクノロジーの早期取り込み」を主要な要因として「Side by Side開発」が推奨されることを説明してきました。

ただし、すべての追加要件の実現をBTP上で実現すれば良いわけでなく、適材適所として、実現先を見極める必要があります。次の記事では、S/4HANAにおける追加要件の実現手段について説明します。