はじめに
本記事は「SAP Side by Side開発の基本的なことまとめ」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。
なぜ「Side by Side開発」を実施するのか？
こちらに関しては、明確な定義のようなものはなく、いくつもの利点があります。個人によって捉え方は変わると思うのですが、私個人としての見解として、大きな利点は下記の2点になります。
- 疎結合アーキテクチュアによる、パッケージアップグレード負荷の軽減
- 自由度の高い基盤による、新しいテクノロジーの早期取り込みによる付加価値創造
ここからは製品としてS/4HANAを想定して、もう少し掘り下げていきます。
パッケージアップグレード負荷の軽減
パッケージアップグレード負荷
S/4HANAとABAPの組み合わせによる開発は、良くも悪くも結合度が高い仕組みでした。設計書を丁寧に作成しても、システム全体を簡単に可視化することはできません。そのため、アプリケーションの基盤をアップグレードする際、関連する変更点の特定が困難となり、すべての機能に対して再テストを実施することが一般的な対応方法となっていました。例えば、ECC時代には数十億円で構築したシステムのアップグレードにおいて、その半分程度のコストをかけてアップグレードとリグレッションテストを実施する事例が見られました。
それに対して「Side by Side開発」にすると、S/4HANAの標準機能（プラットフォーム機能）との接点が、APIの仕様というかたちで明確化されるため、影響の把握および改修・テストがしやすくなります。S/4HANA側のAPIをアドオンしてしまうとそこに対する影響調査は残ってしまうのですが、標準のAPIを利用していれば、そこはSAP社として動作を保証してくれるので、アップグレード対応のアドオン影響確認に必要な工数が格段に下がることになります。そのため、SAP社は「Side by Side開発」を推奨しています。
SAP社の標準APIについてについて、こちらの記事でもう少し詳しく書いています。
S/4HANAのアップグレードサイクルの高速化
アップグレード負荷に着目しなければいけない背景には、S/4HANAのアップグレードサイクルの高速化があります。
S/4HANA以前のSAP社のERP製品はかなり長い期間の製品保証がされておりました。これらの保証が切れるのが2025年末、2027年末のため、昨今、S/4HANA化のプロジェクトが多数立ち上がり、SAPビジネスマーケットの活況を招いています。
それに対して、S/4HANAの製品保証期間は原則7年となります。（正確にはそれ以降は「Customer Specific Maintenance」期間に入り、いろいろと製品を利用する上での制約が発生します。このあたりの正確な情報をSAP社にお問い合わせ下さい。）そのため、S/4HANAは基本的には7年周期でのアップグレード作業が必要になり、S/4HANA以前の時代に比べ、アップグレード対応に容易に対応できるシステムを構築する必要があるわけです。
ABAPのアップグレード負荷は高いのか？
アップグレードに関して必ず議論になるテーマです。理論的には、ABAPプログラムでも、標準機能との接点を明確かつシンプルに設計し、適切な仕様書を作成すれば、アップグレード時の影響範囲をある程度正確に把握できます。しかし、これを保守も含めて実現することは実務上難しく、結局アップグレード時には全体テストが必要になるのが現状です。そのため、システムの疎結合化が推奨されています。
新しいテクノロジーの早期取り込み・付加価値創造
この点については詳しい説明は不要でしょう。S/4HANAとABAPの組み合わせでは、追加機能の開発にABAPだけを使用せざるを得ませんでした。
一方、「Side by Side」開発では、新規開発の際にJavaやJavaScriptなど、様々な言語を選択できます。SAPの世界では気付きにくいことですが、これらの言語にはOSS（Open Source Software）として豊富なライブラリやフレームワークが用意されており、実現可能な機能の幅が大きく広がります（もっとも、OSSには定期的なアップデートや脆弱性対応という課題もありますが）。
DevOpsの実現と開発サイクルの高速化
新技術やOSSの活用により、機能面だけでなく開発者の生産性も向上します。
OSSとして公開されているIT技術の多くは、WEBアプリ、モバイルアプリ、WEBサイトなどの開発に特化しており、DevOpsを実現する開発アーキテクチャの構築が可能です。自動化された単体テストやデプロイ作業により、純粋な開発以外の工数と期間を削減し、開発サイクルを加速できます。
ただし、BTP単体ではこれらの機能が十分ではなく、外部サービスの利用や運用スキルの習得が必要になります。そのため、現状では完全なDevOpsの実現は容易ではありませんが、S/4HANAでもDevOpsの実装は不可能ではありません。
ローコード・ノーコードツールの活用
BTPでは、アプリケーションの作成にプログラミングをあまり必要としない、「ローコード・ノーコードツール」の開発にも力をいれています。
具体的にはカスタム開発の実施に際しては、その実施ツール（IDE）である、「Business Application Studio」に「ローコード機能」が実装され、コーディングの難易度や負荷を軽減できます。また、「ローコード・ノーコードツール」である「SAP Build Apps」やRPAやワークフローを従来のBTPサービスよりさらに容易に開発できるようになった「SAP Build 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における追加要件の実現手段について説明します。