見出し画像

Side-by-Side拡張 vs In-App拡張——正しい拡張戦略の選び方



「この要件、コアの中で作るべきか、外に出すべきか」

S/4HANAプロジェクトの設計フェーズで、筆者が最も頻繁に直面する問いがこれです。

Clean Core戦略のもと、SAPは「拡張はコアの外へ」というメッセージを強く打ち出しています。しかし現場では、 すべての拡張をコアの外に出せばよいわけではありません。 要件の性質を見極めず、一律にSide-by-Side拡張を選択すれば、不要なネットワーク遅延やアーキテクチャの複雑化を招きます。逆に、何でもコア内に作り込めば、従来のZ開発の二の舞です。

筆者はワークスアプリケーションズでERPの製品開発を経験し、その後SAPコンサルタントとして多数の移行プロジェクトを支援してきました。 ERP開発者として「コア内で作る」経験と、SAPコンサルタントとして「コアの外に出す」経験の両方を持つ からこそ、この問いに対する実務的な判断基準をお伝えできると考えています。


2つの拡張パターンを正確に理解する

まず用語を整理します。SAPの拡張戦略には 2つの基本パターン があります。

In-App拡張(On-Stack拡張) は、S/4HANAシステム内部で行う拡張です。BADIやEnhancement Spotを使った拡張ポイントへの実装、カスタムフィールドやカスタムロジックの追加、ABAP Cloud(Released APIのみを使用する制約付きABAP)での開発がこれに当たります。ポイントは、 Clean Coreに準拠した方法であれば、コア内の拡張も「正しい拡張」である という点です。

Side-by-Side拡張 は、S/4HANAの外部、つまりSAP BTP上で独立したアプリケーションやサービスを構築する拡張です。Cloud Foundry、Kyma、ABAP EnvironmentなどのBTPランタイム上で開発し、S/4HANAとはAPIやイベントを通じて連携します。Java、Node.js、Pythonなど多様な言語で開発でき、S/4HANAのアップグレードから完全に独立しています。

ここで重要な認識があります。 「In-App拡張=旧来のZ開発」ではありません。 In-App拡張はClean Coreのルールに従い、Released APIのみを使用し、標準コードの修正(Modification)は行いません。旧来のZ開発との根本的な違いは、 将来のアップグレード互換性が保証されているかどうか です。


判断基準1:リアルタイム性の要求度

拡張パターンの選択で 最も決定的な判断基準 がリアルタイム性です。

In-App拡張を選ぶべきケース:

伝票登録時のバリデーション、価格計算、与信チェックなど、 ミリ秒単位の応答が求められるトランザクション処理 はIn-App拡張の領域です。ユーザーが「登録」ボタンを押した瞬間に実行されるチェックロジックを、ネットワーク越しのBTPに置けば、数百ミリ秒から数秒のレイテンシーが加わります。ユーザー体験の劣化は避けられません。

筆者が支援した食品メーカーのプロジェクトでは、受注登録時に出荷可能日を即座に計算するロジックがありました。在庫データ、生産計画、輸送リードタイムを参照する複雑な計算ですが、 結果を1秒以内に返す必要があった ため、BADIによるIn-App拡張を選択しました。

Side-by-Side拡張を選ぶべきケース:

一方、レポート生成、データ分析、承認ワークフロー、外部システム連携など、 数秒から数分の応答時間が許容される処理 はSide-by-Side拡張の候補です。ユーザーが非同期で結果を受け取る業務フローであれば、ネットワーク遅延は問題になりません。


判断基準2:データ量と処理特性

処理するデータの量と特性も、重要な判断材料です。

数百万件のトランザクションデータをバッチ処理する場合 、データの所在地が重要になります。データがS/4HANA内にあるなら、そのデータをネットワーク越しにBTPに転送して処理するよりも、 データの近くで処理する 方が効率的です。ABAP Cloudの強力なデータ処理能力を活かしたIn-App拡張が適しています。

一方、 複数のシステムにまたがるデータを集約・分析する場合 は、Side-by-Side拡張が有利です。S/4HANA、SuccessFactors、外部SaaSのデータをBTP上のSAP DatasphereやAnalytics Cloudに集約すれば、ERPコアに負荷をかけずに横断的な分析が可能です。


判断基準3:技術スタックと開発チームの構成

現実のプロジェクトでは、 「誰が作るか」 も重要な判断要素です。

チームにABAP開発者が多い場合 、In-App拡張やABAP Environmentでの開発が立ち上がりの速い選択肢です。ABAPの知識はABAP Cloudの世界でもそのまま活きます。CDSビュー、RAP(RESTful ABAP Programming Model)、BADIなど、ABAP開発者にとって馴染みのある概念で拡張を実装できます。

JavaScript/Java開発者が中心のチーム なら、BTP上のCloud Foundry環境でCAP(Cloud Application Programming Model)を使ったSide-by-Side拡張が自然な選択です。モダンな開発プラクティス(CI/CDパイプライン、コンテナ、マイクロサービス)を適用でき、市場で利用可能な幅広い人材プールとツールを活用できます。

筆者の経験則として、 「チームが最も生産性高く開発できる技術スタック」 を選ぶことが、品質と速度の両面でプロジェクト成功の確率を上げます。技術的に最適な選択肢が、組織的に実行不可能では意味がありません。


判断基準4:アップグレード独立性とデプロイ頻度

ビジネス要件の変化が激しく、頻繁にリリースしたい機能 はSide-by-Side拡張が圧倒的に有利です。

S/4HANAコア内の変更は、本番システムへの影響を常に考慮しなければなりません。トランスポート管理、リグレッションテスト、Change Managementのプロセスを経る必要があります。一方、BTP上のアプリケーションは ERPコアから物理的に分離されている ため、独立したCI/CDパイプラインで週次や日次のリリースも可能です。

具体的に、以下のような機能はSide-by-Side拡張の好適例です。

  • 顧客向けポータル :UI/UXの改善を頻繁にリリースしたい

  • 承認ワークフロー :業務プロセスの変更に柔軟に対応したい

  • 外部システム連携 :SAP Integration Suiteによる標準化されたモニタリング・リトライ機構を活用したい

  • AI/ML機能 :請求書の自動読み取り、需要予測など、SAP AI CoreやJouleとの統合


実務で使える判断フローチャート

ここまでの4つの基準を、 実務で即使える判断フロー として整理します。

ステップ1:リアルタイム性の確認

ミリ秒単位の応答が必要か? --> Yes: In-App拡張 を検討

ステップ2:データの所在と量の確認

S/4HANA内の大量データをバッチ処理するか? --> Yes: In-App拡張 を検討

ステップ3:アップグレード独立性の確認

S/4HANAのアップグレードから完全に独立させたいか? --> Yes: Side-by-Side拡張 を検討

ステップ4:デプロイ頻度の確認

週次・日次でリリースしたいか? --> Yes: Side-by-Side拡張 を検討

ステップ5:チーム構成の確認

開発チームの主要スキルは? --> ABAP中心なら In-App拡張 、Java/JS中心なら Side-by-Side拡張

もちろん、これは出発点であり、最終判断では非機能要件(セキュリティ、可用性、コスト)や組織的な制約も考慮する必要があります。 大切なのは、「どちらか一方だけが正解」ではないと認識すること です。多くの企業では、In-App拡張とSide-by-Side拡張を要件に応じて使い分ける ハイブリッドアプローチ が現実的な最適解です。


まとめ:拡張戦略は「二者択一」ではない

改めて要点を整理します。

  • In-App拡張 :リアルタイムトランザクション処理、大量データバッチ処理、S/4HANAとの緊密連携が必要な場合に選択。ABAP Cloud+Released APIで将来互換性を確保

  • Side-by-Side拡張 :UI拡張、ワークフロー、外部連携、分析・AI機能、高頻度デプロイが必要な場合に選択。BTP上で多様な技術スタックを活用

  • 判断の基軸 :リアルタイム性、データ量、アップグレード独立性、デプロイ頻度、チーム構成の5つ

  • 現実解 :両方を要件に応じて使い分けるハイブリッドアプローチ

「拡張はコアの外へ」というClean Coreのメッセージは、 「コア内の拡張を全面禁止する」という意味ではありません。 正しくは、「コアを汚さない方法で拡張する。コアの外に出すべきものは出す」です。どちらの拡張パターンを選んでも、Released APIの使用とClean Core準拠を守ることが大前提です。

この判断を正しく行えるエンジニア・コンサルタントは、今後のSAPプロジェクトで極めて重要な存在になるでしょう。


📚 関連書籍のご紹介

拡張戦略の設計判断を深く学びたい方には、拙著をおすすめします。

『SAP S/4HANA 2025 & Clean Core 完全ガイド』

👉 Amazon Kindleで読む

拡張性モデル(Level A~D)、ABAP Cloudの制約と活用法、BTP上での具体的な開発パターンまで、800ページ超で網羅しています。

また、S/4HANA移行の全体像を掴みたい方にはこちらもおすすめです。

『ERP / S/4HANA 入門ガイド』

👉 Amazon Kindleで読む


🎥 関連動画

SAP・ERP・アジャイル開発に関する動画を配信しています。

👉 チャンネルはこちら


著者プロフィール

大垣伸悟

ERP開発者 × SAPコンサルタント × アジャイルコーチ

ワークスアプリケーションズにてCOMPANY(国内シェアNo.1 ERP)の製品開発に従事した後、SAP S/4HANAコンサルタントとして大手自動車メーカー・食品メーカーの基幹システム移行を支援。現在はアジャイルコーチとして多数の大企業のDXを推進。

📕 著書:『大企業向けITソリューション百科事典』全17巻(Amazon Kindle)

🎥 YouTube:大垣伸悟

📝 note:gigathlete_inc

フォローして最新記事をチェック!

いいなと思ったら応援しよう!