はじめに
2022年11月の｢SAP TechEd 2022のKeynote｣で｢SAP Build｣が発表されました。｢SAP Build｣自体は難しい概念の製品ではありませんが、SAP社が何度もリブランドをしているため、誤解がある場合があります。この記事では、過去の経緯を含め、｢SAP Build｣についての概要をまとめました。「SAP Business Technology Platform (BTP)の基本的なことのまとめ」や｢SAP Side by Side開発の基本的なことまとめ｣に続く基本的な説明記事です。今回は1記事のショートバージョンです。
また、本記事は概要把握や個人でのトライアル利用の参考としてまとめたものなので、プロジェクトでの利用の際は、SAP社への問い合わせや正式情報であるHelp Portalを活用してください。
一言でいうと
｢SAP Build｣はSAP社がBTP上にリリースした、｢ローコード・ノーコード製品群｣です。今回、2022年末のリリースにて新規に開発したものではなく、もともと存在していた製品に改良をして、リブランドした製品群になります。（既存製品がリブランドしているというところがポイントで、それを正しく理解していないと過去の製品との混同などが生じてしまいます。）
画面アプリケーション開発の｢SAP Build Apps（旧SAP AppGyver）、WF・RPA系の｢SAP Build Process Automation（旧 SAP Process Automation）、画面ポータル系の｢SAP Build Work Zone（旧SAP Launchpad service, SAP Work Zone）｣により構成されます。
細かい話は後続で説明するのですが、概要の対象領域と製品の変遷を下記に整理します。
2023年の「SAP TechEd」にて、生成AIを組み込んだ統合開発環境である「SAP Build Code」が発表されました。
2024年8月情報更新
2023年の「SAP TechEd」にて、生成AIを組み込んだ統合開発環境である「SAP Build Code」が発表されました。
SAP Build Apps
ローコード・ノーコードにて、WEB アプリケーションやiOS / Android等のアプリケーションを作成することができる製品です。GUIベースでデータ項目・ボタン・アイコンなどのをドラッグ&ドロップで配置し、直感的にアプリケーションを作成することができます。誰でも簡単にアプリケーションを作成することが可能です。
バックエンドのデータ処理（データの取得・変換・格納）なども実装することはできますが、基本的はその部分は対象となるバックエンドシステム（S/4HANA等）のAPIを介して、バックエンドシステム側で実行されることとなります。
また今回の発表で、フロントエンドを実装すると、そこからバックエンド機能がある程度自動で作成される｢Visual Cloud Functions｣も発表されており、トータルでローコード開発を担う製品にしたいという意図がわかります。
この製品はSAP社が2021年2月に買収した｢AppGyver｣が元になっています。買収後は｢SAP AppGyver｣として、インフラ諸々独立するかたちでサービスが提供されていたのですが、｢SAP AppGyver Enterprise Edition｣というかたちでBTPに統合され、その後｢SAP Build Apps｣となっています。
ちなみにこの分野の他のメジャーな製品としては｢OutSystems｣があげられます。また、｢AppGyver｣の買収前に、SAPといろいろな取組をしていた｢Mendix｣なども有名です。
SAP Build Process Automation
こちらは、｢ワークフロー機能｣と｢RPA｣機能を担う製品です。こちらは機能の詳しい説明はしなくてもある程度イメージはつくと思いますので、複数存在するこのエリアのSAP社の製品の変遷を整理します。現状も複数の製品が存在していますが、最終的には｢SAP Build Process Automation｣に統合されることとなると思います。
｢ワークフロー機能｣をもつ製品として最初に登場したのは｢SAP Workflow Management｣というワークフロー単体の機能としてリリースされています。こちらもGUIベースのわりとユーザフレンドリな製品ではあったのですが、ところどころIT屋さんっぽい要素があり、エンドユーザが親しみにくい点があったため、コアのエンジンは買えず、画面や操作性をリニューアルするかたちで｢SAP Process Automation｣という製品になり（この時点でRPA機能が統合されました）、今回｢SAP Build Process Automation｣とリブランドされています。
話は少しそれますがS/4HANA側の｢Business Workflow｣や｢Flexible Workflow｣と何が違うんですか？という質問を受けることがあります。
これらは、ビジネスケースが決定された標準機能の延長線上の機能です。ゆえに、｢購買依頼の承認ワークフロー｣の実装のように、想定される実装のポイントやその中で実装しうる要件もある程度の前提がおかれています。それに対して｢SAP Build Process Automation｣は０からつくりワークフローの開発・実行基盤です。ゆえにシナリオ限定せず、様々な部品を組み合わせワークフロー要件を実現化します。（極端な話としてはSAP社の製品と全く関係のないワークフローも実装可能です。）
｢RPA機能｣をもつ製品として最初に登場したのは｢SAP Intelligent RPA｣というRPA単体の機能としてリリースされています。その後、上記の理由にて｢SAP Process Automation｣、｢SAP Build Process Automation｣という変遷をたどっています。
SAP Build Work Zone
最後は、サービスポータルとなる｢SAP Build Work Zone｣です。ユーザが各種のアプリケーションにアクセスする際に最初にアクセスするポイントです。S/4HANAだと｢Launchpad｣にあたる機能なります。
この製品は｢SAP Build Work Zone, standard edition｣と｢SAP Build Work Zone, advanced edition｣となり、元となる製品が違います。
｢SAP Build Work Zone, standard edition｣の元となる製品は｢SAP Launchpad service｣でSAP社の製品にアクセスする際の｢セントラルアクセスポイント｣となる機能です。
そこにコラボレーション機能や、コンテンツ管理機能、Teamsなどのサードパーティー連係機能を盛り込んだ機能が｢SAP Build Work Zone, advanced edition｣です。皆様の会社には社内ポータルのようなサイトがあると思うのですが、あのようなコンテンツ管理機能に｢Launchpad｣が組み込まれたようなイメージで、知るべきことややるべきことが｢SAP Build Work Zone｣にアクセスすればすべてわかることを目指した製品だといえます。
SAP社のクラウド型ポータルソリューションには簡易版の｢SAP Start｣といものもあり、｢SAP Start｣→｢SAP Build Work Zone, standard edition｣→｢SAP Build Work Zone, advanced edition｣という順序で機能の充足度が上がっていきます。
S/4HANAの｢Launchpad｣と何が違う。
この様な疑問をもった方も多いと思います。細かの機能差はあるせよ、最初のアクセスポイントを何処に置くかという考え方が違います。S/4HANA側の場合は、S/4HANAがあるプライベートの環境に最初にアクセスし、そこから外部の環境を含め、他のサイトにアクセスすることとなります。｢SAP Build Work Zone｣の場合はクラウド上にアクセスポイントがあることになります。SAP社の方向性としては、エンドユーザは多くのクラウドシステムにアクセスすることとなるため、｢SAP Build Work Zone｣を起点とすることを推奨し、そちらを開発のメインストリームに据えている様です。こちらを使うと、｢SAP Mobile Start｣というNativeアプリ機能と連係できるなどのわかり易い利点も存在します。
ただし、デリバリする立場からすると、BTPに限らず、クラウドサービスはシステムダウンの可能性はゼロではなく（各社のクラウドサービスが大規模にダウンする話は年に1度くらいは耳にするわけで）エンドポイントが落ちて、基幹システムにユーザがアクセスできなくなるという事態は頭において置く必要があるなと感じております。
SAP Build Code（2024年8月追記）
「SAP Build Code」はBTP上で生成AIを組み込んだ稼働する統合開発環境です。BTPをよく知らない方は、BTP版の「生成AIエージェント付きVisual Studio Code」と捉えるとわかりやすいと思います。また、BTP経験者の方には「生成AIエージェント付きBusiness Application Studio」と捉えるとわかりやすいと思います。
主な対象言語は「Java」および「JavaScript」であり、BTP上の開発に最適化された各種機能を有しています。2024年の段階ではまだ機能は発展途上ですが、プロンプトベースでの開発サポートが可能です。（実機で試した感じでは、日本語のプロンプトにも対応しています。）
今後の「Business Application Studio」との関係は明言されていませんが、SAP社としては「SAP Build Code」に置き換えを進めていきたいと推測しています。
｢SAP Build｣のメリット
こちらに関しては｢Side by Side開発｣をBTPにて実施するメリット｣と基本的には同じになります。基本的な｢SAP社製品との接続性｣に優れており、｢SAP社製品を前提とした事前定義｣が準備されており、BTP上にあるがゆえに｢インフラ的な接続性｣にも優れています。
これらに加え｢SAP Build｣では｢開発する際のガバナンス強化｣がメリットとして挙げられています。開発者やユーザからの目線では使いやすさに目がいきますが、管理者の視点からは｢管理機能｣に目がいきます。
そのような背景としては｢日本人の改善文化｣があるのではないかと個人的に考えています。日本人は改善することが得意であり、この手の現場ツールを上手く使いこなすことが得意です。その一方で、個別最適のツールが大量に生み出され、古くは｢Lotus Notes｣や｢Excelマクロ｣、最近ではRPAの｢野良BOT｣の乱立や管理不全が各所で問題となっています。そのような経験から、管理者はガバナンスを意識し、それを理解しているSAP社としては、｢開発する際のガバナンス強化｣を意識し、ユーザが勝手にアプリの開発ができない仕組みや、作ったものを一元化できる仕組みを強化しています。
まとめ
SAP社は企業のアプリケーションの民主化（ローコード・ノーコード）を意識し各種のアプリケーションの開発を強化しています。そのような状況のなかで、対象となる製品が増えたため新しく｢SAP Build｣というブランドを設定しました。今後も開発が強化され発展する領域だと思いますので、継続して学習していくことが求められると思います。