まず結論
RISE with SAP の後に SAP BTP を導入しても、それだけで企業にプラットフォーム能力が生まれるわけではありません。BTP は便利なサービス群ですが、買った瞬間に「社内開発を速くする製品」へ変わるほど親切ではありません。
この記事では、BTP チームが陥りやすい失敗を Platform Engineering と Product Thinking の観点で整理します。対象は、SAP BTP を導入済み、または RISE with SAP 後に拡張・連携・データ活用の基盤を作ろうとしているチームです。
BTP を導入しても速くならない典型パターン
よくある失敗は、BTP を「環境」として扱い、社内向けの「製品」として扱わないことです。
| 状態 | 起きること |
|---|---|
| サブアカウントだけ増える | 命名、権限、接続方式がチームごとにバラバラになる |
| Integration Suite を入れただけ | API 管理、監視、変更ルールが決まらず属人化する |
| CAP や ABAP Cloud を試すだけ | 再利用できるテンプレートや標準部品が残らない |
| Enablement が資料配布だけ | 現場が何を使えばよいか判断できない |
つまり、BTP が悪いのではありません。BTP を運用するチームが「社内開発者に何を提供するのか」を定義していないのが問題です。
BTP チームは製品チームとして振る舞うべき
プラットフォームチームの顧客は、社内の開発者、業務部門、S/4HANA 周辺の拡張を作るチームです。であれば、BTP チームはインフラ管理係ではなく、社内向け製品チームとして動く必要があります。
たとえば次のような提供物を持つべきです。
| 提供物 | 例 |
|---|---|
| Golden Path | S/4HANA 拡張を CAP で作る標準手順 |
| テンプレート | 認証、Destination、CI/CD、ログ出力を含む雛形 |
| 再利用部品 | 共通 API、イベント定義、監査ログ部品 |
| ガードレール | 権限設計、接続方式、命名規則、Transport 方針 |
| サポートモデル | 相談窓口、レビュー観点、障害時の責任分界 |
ここまで作って初めて、BTP は「使ってください」ではなく「この道を通れば安全に速く作れます」と言える状態になります。
RISE with SAP 後に見落とされる論点
RISE with SAP によって S/4HANA の運用責任や標準化の考え方は変わります。Clean Core を守りながら拡張するなら、BTP は重要な選択肢になります。
ただし、ここで雑に進めると、BTP 側に新しい密結合を作るだけです。
たとえば次のような問いを先に決める必要があります。
- S/4HANA への拡張は In-App / Side-by-Side のどちらを標準にするのか
- CAP、ABAP Cloud、Integration Suite をどう使い分けるのか
- Destination、Connectivity、Principal Propagation の設計責任は誰が持つのか
- Event Mesh や Integration Suite のイベント/API 命名は誰が管理するのか
- 本番運用、監視、監査証跡、変更管理はどのチームが見るのか
これを決めずに PoC を量産すると、「動くもの」は増えます。しかし運用できる製品は増えません。ここ、地味に最悪です。
プラットフォームの成果は利用数ではなく再利用性で見る
BTP チームの KPI を、単純な利用サービス数やサブアカウント数だけで見るのは危険です。数字は増えても、現場が毎回同じ設計で迷っているなら意味がありません。
見るべき指標は、もう少し現場寄りです。
| 観点 | 見るべき指標 |
|---|---|
| 開発速度 | 新規拡張の立ち上げにかかる日数 |
| 標準化 | テンプレート利用率、例外設計の件数 |
| 再利用性 | 共通 API / 共通イベント / 共通部品の利用数 |
| 運用品質 | 監視、ログ、障害対応手順の整備率 |
| Enablement | 開発チームが自走できた割合 |
BTP を買ったことではなく、現場が迷わず安全に作れるようになったことを成果にするべきです。
最初に作るべき最小セット
いきなり全社プラットフォームを作ろうとすると、だいたい重くなります。最初は小さくてよいので、利用者が迷わない最小セットを作ります。
- 標準アーキテクチャ図
- CAP / ABAP Cloud / Integration Suite の使い分けガイド
- 1 つの Golden Path
- 権限、Destination、Transport の設計ルール
- サンプルリポジトリ
- レビュー観点チェックリスト
- 問い合わせと改善要望を受ける窓口
このセットがないまま「BTP を使ってください」と言うのは、地図なしで山に放り込むのと同じです。登れた人を称賛する前に、道を作りましょう。
まとめ
RISE with SAP 後の BTP 活用で重要なのは、サービスを購入することではありません。BTP チームが、社内開発者向けのプラットフォーム製品を育てることです。
- BTP は導入しただけでは開発速度を上げない
- Golden Path、テンプレート、ガードレールが必要
- CAP、ABAP Cloud、Integration Suite の使い分けを明確にする
- 成果は利用サービス数ではなく、再利用性と自走率で見る
- BTP チームは運用係ではなく、社内向け製品チームとして動く
プラットフォームは買うものではなく、育てるものです。RISE with SAP の後に BTP を使うなら、まずこの前提から始めた方がいいです。