結論

RISE with SAP の後に SAP BTP を導入しても、それだけで開発組織が速くなるわけではありません。BTP は拡張、連携、データ活用、AI 活用のための重要な土台ですが、土台を買っただけでは「社内で使われるプラットフォーム」にはなりません。

この記事では、BTP チームがよく陥る失敗を、Platform Engineering と Product Thinking の観点で整理します。

「BTP を入れたのに速くならない」の正体

現場でよく起きるのは、BTP を導入した後に次のような状態で止まることです。

| 症状 | 実際に足りないもの |

|---|---|

| サブアカウントはある | 標準構成、命名規則、責任分界 |

| Integration Suite はある | API 管理方針、監視、変更ルール |

| CAP の PoC はある | 本番化パターン、CI/CD、運用設計 |

| Enablement 資料はある | 現場が迷わず使える Golden Path |

BTP の機能不足ではなく、プラットフォームを製品として設計していないことが問題です。

プラットフォームは「場所」ではなく「体験」

BTP チームが提供すべきものは、単なる環境ではありません。社内開発者が、安全に、迷わず、繰り返し使える開発体験です。

たとえば、S/4HANA の Side-by-Side 拡張を作るなら、次のようなものが必要になります。

  • CAP または ABAP Cloud を選ぶ判断基準
  • Destination と Connectivity の標準設計
  • XSUAA / IAS を含む認証・認可の雛形
  • Transport と CI/CD の手順
  • Application Logging、Alert Notification、監視の標準
  • Integration Suite や Event Mesh を使う場合の命名・管理ルール

これらが揃っていないと、各プロジェクトが毎回同じ設計判断をやり直します。結果として、BTP を導入したのに組織全体の速度は上がりません。

BTP チームに必要なのは Product Thinking

BTP チームは、社内向けの製品チームとして振る舞うべきです。利用者は業務アプリ開発チーム、連携チーム、S/4HANA 拡張チーム、データ活用チームです。

製品チームとして見るなら、考えるべき問いは変わります。

| インフラ管理の問い | 製品チームの問い |

|---|---|

| どのサービスを有効化するか | 利用者は何を最短で作れるようになるか |

| 権限をどう払い出すか | どこまでセルフサービス化するか |

| 問い合わせにどう答えるか | どの失敗を仕組みで潰すか |

| ドキュメントをどこに置くか | 利用者が迷わない導線になっているか |

この切り替えがないと、BTP チームはチケット処理係になります。プラットフォームチームとしては、まあ弱いです。

RISE with SAP 後に特に危ないこと

RISE with SAP 後は、Clean Core を意識しながら S/4HANA を拡張する場面が増えます。そこで BTP が期待されるのは自然です。

ただし、BTP 側で何でも自由に作ると、S/4HANA の中にあった密結合が外側に移動するだけです。

例えば次の境界を決めないまま進めると危険です。

  • In-App Extensibility と Side-by-Side Extensibility の境界
  • CAP と ABAP Cloud の使い分け
  • Integration Suite と直接 API 呼び出しの使い分け
  • Event Mesh を使うイベント駆動の対象範囲
  • S/4HANA、BTP、Hyperscaler の責任分界
  • 監査ログ、権限、データ保持の管理責任

BTP 活用は「自由に作れる場所」を増やすことではありません。安全に変化を吸収する境界を作ることです。

最初のロードマップ

最初から巨大なプラットフォーム構想を作る必要はありません。まずは 1 つの代表ユースケースに絞って、Golden Path を作る方が現実的です。

例として、S/4HANA の周辺拡張を作るなら、最初の成果物は次で十分です。

| 成果物 | 目的 |

|---|---|

| Reference Architecture | 標準構成を揃える |

| Starter Template | 認証、ログ、CI/CD を最初から含める |

| Review Checklist | 例外設計を早めに見つける |

| Runbook | 障害時の一次対応を明確にする |

| Enablement Session | 利用チームが自走できる状態を作る |

ポイントは、資料を増やすことではなく、次のチームが同じ迷い方をしない状態を作ることです。

まとめ

RISE with SAP 後の BTP 活用で失敗しやすいのは、BTP を導入しただけでプラットフォーム能力が手に入ったと考えることです。

  • BTP は環境ではなく、社内向け開発体験として設計する
  • Platform Engineering では Golden Path とガードレールが重要
  • Product Thinking では利用者、価値、改善サイクルを見る
  • Clean Core を守るには、BTP 側の責任分界も明確にする
  • 成果はサービス利用数ではなく、再利用性と自走率で見る

BTP を買うことはスタートです。そこから社内で使われるプラットフォーム製品に育てるところが、本当の仕事です。