アプリケーション開発：ユースケースと意思決定パターン

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 21 min read

本記事の位置づけ#

参考資料#

1) アプリケーション開発のランドスケープ#

本記事では新しいツールを紹介するのではなく、B01で説明した同じ4つのファミリーを別の角度から取り上げます。それは、それらの中からどのように選択するかです。本記事で使用する意思決定の視点を交えながら、各ファミリーを振り返ります。

これらは代替手段ではありません。§5の選択ルールこそが本シリーズが存在する理由そのものです。このルールがなければ、「SAP Buildを使おう」という判断がデフォルトでBuild Appsに流れ、後でプロジェクトがその代償を払うことになります。

2) S/4HANA への接続方法#

4つのファミリーは、異なるレイヤーで異なる結合強度でS/4HANAに接続します。接続ポイントによって、クリーンコア準拠、リリースサイクルの独立性、および作業が属する拡張性ティア（キーユーザー → デベロッパー → サイドバイサイド）が決まります。

                        SAP BTP — Application Development families
   ┌────────────────────────────────────────────────────────────────────────┐
   │  Pro Code  →  CAP, Build Code, BAS  ──── Cloud Foundry / Kyma          │
   │  ABAP      →  BTP ABAP Environment (Steampunk, side-by-side)           │
   │  Low Code  →  Build Apps, Build Process Automation                     │
   │  Portal    →  Build Work Zone (surfaces apps from above)               │
   └─────────────┬───────────────────────────────────────┬──────────────────┘
                 │ released APIs, OData,                 │
                 │ business events                       │ launchpad / site
                 ▼                                       │
   ┌────────────────────────────────────────────────┐    │
   │  S/4HANA Cloud (public or private edition)     │ ◄──┘
   │  ── Key User extensibility (in-app)            │
   │  ── Embedded Steampunk (in-stack ABAP Cloud)   │
   └────────────────────────────────────────────────┘

重要ポイント：結合はスキルやコストよりも先にファミリーを選択します。 拡張機能が標準のS/4HANAテーブルやBAdIへの直接アクセスを必要とする場合、選択肢はキーユーザー拡張性またはEmbedded Steampunkとなります。他のファミリーは構造上、誤った選択となります。結合が確定した後にのみ、チームのスキルと権限によって残りのオプションが絞り込まれます。

3) 成熟度マップ#

4つのファミリーはすべて2026年に本番利用可能となりますが、運用リスクのプロファイルは異なります。このマップはプロモーションではなく、正直な評価に基づいています。プロジェクトが実際に受け入れられる成熟度プロファイルを持つファミリーを選択してください。

4) 要件チェックリスト#

各機能には独自のチェックリストがあります。BTPの本格的な開発をスコープする際は、4つのチェックリストすべてを実行してください。§4.5の機能横断的なチェックでは、ツールの境界をまたぐ要件を捕捉します。

Pro Code（CAP、Build Code、BAS）の前提条件#

ABAP（Steampunk + Embedded Steampunk）の前提条件#

Low Code（Build Apps + Build Process Automation）の前提条件#

Portal（Build Work Zone）の前提条件#

クロスファミリーのクリーンコアおよび運用チェック#

5) 意思決定基準#

3つの質問で、BTPアプリケーション開発がそもそも正しい答えかどうかを判断します。ドメイン選択テーブルでファミリーを選び、ライセンステーブルで商取引上の驚きを防ぎます。

最初に問うべき3つの質問#

Q1. 測定可能なビジネス上の課題は何ですか？

もし答えが「BTPで何かを作りたい」というものなら、その要件は準備ができていません。課題は具体的でなければなりません（承認サイクルに14日かかる、手動データ入力に週20人時かかる、カスタマーセルフサービスポータルがないためにコールセンターがパンクするなど）。測定可能な課題がなければ、ツールの選択は正当化できません。「BTPのクレジットを使い切らなければならない」というのは課題ではありません。

Q2. データの所有者は誰で、どこに保管する必要がありますか？

S/4HANAテーブルへの密結合（カスタムフィールド、スタック内ロジック）は1つのレジデンシープロファイルであり、BTP上でのサイドバイサイド（リージョナルデータを含む）は別のプロファイル、SAPと非SAPの混在統合は3つ目のプロファイルです。データレジデンシー、データ所有権、およびGDPR/SOC2の境界によって、その作業がS/4HANA、BTP ABAP環境、CAP、またはまったく別の場所に属するかが決まります。

Q3. 予算権限を持つ内部スポンサーは誰ですか？

中央IT、LoBオーナー、プロセスオーナー — その答えによって、適切な商用モデル（サブスクリプション vs BTPEAクレジット vs PAYG）や、スポンサーにとって価格が理解しやすい製品ファミリーが変わります。スポンサーが資金調達できないツールは、技術的な適合性に関わらず、適切なツールではありません。

ユースケースの形状に基づくツール選択#

ライセンスとコスト#

6) よくある障害#

これらは要件段階の失敗であり、実装のバグではありません。それぞれの事例は十分な頻度で観察されており、パターンを認識する方が教訓を再導出するよりも迅速です。

障害 1：「すべてに SAP Build を使用する」

SAP Buildは4つのプロダクト（Code、Apps、BPA、Work Zone）から構成されており、単一のプラットフォームではありません。「Build」を一つの回答として扱うと、4つの異なる選択判断が、誤ったデフォルト（通常は最もマーケティングされている柱であるBuild Apps）に平準化されてしまいます。解決策は、まず§5のユースケース表を使用し、その後、どのBuildの柱（またはBuild以外の柱）が該当するかを特定することです。

障害 2: エンタープライズ・クリティカルなワークロードに対するローコード

Build Appsは、シンプルなUI、OData/REST統合、およびシチズンデベロッパーによる運用を前提とした部門内アプリケーションを対象としています。これを顧客向けトランザクションシステムや高スループットのサービスに採用すると、パフォーマンス、ガバナンス、UIの柔軟性の限界がユーザー受入テストの段階で顕在化し、その時点では低コストでの方向転換が不可能になります。対策としては、要件定義の段階でスコープを正直に評価し、「エンタープライズクリティカル」が実際の制約条件である場合には、Build Code上でCAPを採用することです。

障害 3: S/4HANA テーブルに密接に結合されたカスタマイゼーションのための CAP

CAP と S/4HANA は公開 API を介して接続できますが、スタック内のデータアクセス（標準テーブルのカスタムフィールド、スタック上の BAdI）を必要とするカスタマイズは、CAP ではなく Embedded Steampunk またはキーユーザー拡張性に属します。CAP で構築すると、脆弱な統合レイヤーが強制され、文書上はクリーンコアに違反していなくとも、実質的にはその精神に反することになります。

障害 4: 非SAP統合におけるABAP Cloudの混在言語使用

チームがABAPスキルを持っている場合、すべての要件がABAP要件のように見えてしまいます。SAPと非SAPのAPIをNode.jsやJavaでオーケストレーションするサイドバイサイドサービスは、BTP ABAP環境ではなく、CAPに属します。選択基準は、チームの経歴ではなく、作業内容です。

障害 5: ワークゾーンが「アプリケーション」としてスコープされている

“Work Zone でポータルを構築する"という表現は、場合によっては「既存のアプリを表示するランチパッドが必要」（Work Zone の正しいスコープ）を意味し、また別の場合には「カスタムロジックを持つカスタムサイトが必要」（Work Zone は不適切な場所）を意味します。要件の中でこれを明確に区別してください。Work Zone はアプリを表示する場所であり、アプリを構築する場所ではありません。

障害 6: クリーンコアレビューの省略

拡張配置が結合度、リズム、データレジデンシー、エンタイトルメントではなくチームの好みで決定されると、次回のS/4HANAアップグレード時にクリーンコア違反として顕在化します。その対策は、ツール決定の前にクリーンコア拡張性階層分類を実行することであり、後ではありません。

障害 7: ビルドスプリントまで商用権限を無視する

顧客が調達できない「正しい」ツールは、間違ったツールです。BTPEAのスコープ、CPEAの残高、サブスクリプション明細項目は、開発者が構築途中でサービスにサブスクライブしようとした際に調達部門がブロックする時ではなく、要件定義時に確認されなければなりません。

FAQ#

Q: これは要約記事です — まずB01～B07を読むべきですか、それともここから始めても大丈夫ですか？

能力マップはB01から始め、候補ツールに該当するB02～B07のいずれかに進んでください。選択内容のクロスチェックにはB08を使用します。このシリーズは初めて読む方向けに順序立てられていますが、経験者はB08を単独の意思決定ツールとして活用できます。

Q: このオンプレミスとクラウドはどのように適用すればよいですか？

意思決定パターンはデフォルトでクラウドファーストです。BTPはSAPのクラウド開発プラットフォームです。オンプレミスのS/4HANAでは、キーユーザー拡張性とオンスタックABAPは依然として有効ですが、サイドバイサイドのオプションはBTPに移行します。クリーンコアの側面（結合、リズム、データ）は同様に適用されます。ランタイムカタログのみが狭まります。

Q: BTPEAクレジットがあり、お客様が「それらを活用したい」と考えています。これは有効な動機となりますか？

いいえ。クレジットの使用は財務的な結果であり、要件ではありません。正しいアプローチは、最も影響の大きい課題（Q1）を特定し、ユースケースの形状に合ったツールを選び、そのツールがBTPEAの対象範囲内にあるかを確認することです。クレジットが適切なツールをカバーしていれば問題ありません。カバーしていない場合は、調達に関する話し合いであり、間違ったものを作る理由にはなりません。

Q: プロジェクトからBTPアプリケーション開発を完全にスコープ外とするのはどのような場合ですか？

3つのシグナル：(1) 測定可能なビジネス上の課題がない（Q1が不合格）、(2) その作業はS/4HANA自体に属する（キーユーザー拡張性またはスタック内RAP — BTPは不要）、(3) 顧客にBTPサービスの権限がなく、引き渡し後に運用するスキルもない。これらのうちいずれか1つでも該当すれば、今回のスコープからBTPを除外する十分な理由となる。

Q: この決定を監査に耐えうる形で適切に文書化するにはどうすればよいですか？

3つの成果物：(1) クリーンコア拡張性階層の分類とその根拠、(2) ユースケースとツールのマッピング（本記事の§5の表は防御可能なテンプレート）、(3) 調達部門からの商用権限確認。SAP Discovery Centerのリファレンスアーキテクチャが一致する場合、外部検証を提供します。

Q: Joule for Developersは独立したツールですか、それとも他のツールの機能ですか？

BAS、ADT、VS Code全体にわたるJoule Studioを介した水平機能です。§5のファミリー選択は変更しません。作業に適したファミリーを選択し、そのファミリー内でJouleを有効にします。SAPが公表する生産性向上（記述約20%、テスト約25%）は、ファミリーに依存しません。

Q: 複数のファミリーを組み合わせる方が、1つだけを選ぶよりも適切なのはどのような場合ですか？

頻繁に。典型的なパターンは、Build Code上のCAP（サービス）＋内部管理者UI用のBuild Apps＋承認ワークフロー用のBPA＋それらすべてを統合するWork Zoneです。§5の表は、プロジェクト全体ではなく、ユースケースの形状に応じてツールを選択するものです。実際のプロジェクトのほとんどは、複数の形状にまたがります。

概要#

BTPアプリケーション開発は、コーディング時ではなく要件定義時に解決されます。4つのファミリー（Pro Code、ABAP、Low Code、Portal）は、異なるランタイムと商用モデルを通じて重複する成果をカバーしており、誤ったデフォルト（通常は「すべてにBuild Appsを使用」）が適切な選択よりもはるかに多く見られます。結合度、スキル、開発サイクル、権利の順に4つの選択軸を適用してください。§5のユースケース表を防御可能な出発点として、§6の失敗リストを承認前の健全性チェックとして使用します。L2-Bシリーズは、この判断が場当たり的にならないために存在します。

次に読むべきもの#