はじめに
本記事は「SAP Side by Side開発の基本的なことまとめ」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。
また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報であるHelp Portalを活用して下さい。
S/4HANAにおける追加要件の実装手段の整理
Side by Side開発」の必要性について説明する一方で、他の選択肢を理解することも重要です。すべての要件を「Side by Side開発」で実現すればよいわけではありません。各要件に最適な実現手段を慎重に検討し、その全体像を把握する必要があります。本記事では、S/4HANAにおける要件実装の全体像を整理していきます。
まずは「Fit to Standard」
前の記事でも述べましたが、重要なため改めて強調させていただきます。S/4HANAはパッケージ製品であり、その活用において基本となるのは「Fit to Standard」です。つまり、S/4HANAの機能を最大限に活用し、ビジネスプロセスをシステムに適合させることが原則となります。
また、S/4HANAで実現できない要件については、他のパッケージ製品の活用を検討することが望ましいと考えます。近年はSaaSを含め多くの製品が提供されており、カスタム開発は工数や運用負荷の観点から適切でない場合が多いためです。
「S/4HANAの標準活用検討」や「他パッケージ製品の活用検討」といった「Fit to Standard」の検討を行っても、なお追加開発が必要な要件に対してはその実装方法を検討します。その場合の要件は「Fit to Standard」の範囲外となり、各社の価値創造や差別化の源泉となるプロセスで、どうしてもパッケージ適応が不可能な領域であることを再度確認しましょう。
「Key User in App Extensibility」
「Fit to Standardできない場合はABAPを避けてBTPを使うべき」という議論が多く見られますが、これは適切な考え方ではないと私は考えます。
S/4HANAには、アップグレード時に影響を受けることなくユーザー側で個別要件を実装できる「Key User in App Extensibility」という機能が用意されています。この機能で実現できる要件については、まずその活用を検討すべきです。なお、BTPとの混同が見られることがありますが、「Key User in App Extensibility」の場合、アプリケーションの実行基盤はS/4HANAのアプリケーションサーバーとなります。
詳細はこちらをご確認ください。ここでは、イメージをつかんでいただくために、いくつかの機能をご紹介します。
Custom Fields and Logic
標準のマスタ・トランザクションなどのオブジェクトに一部制限はあるものの、項目の追加やロジックの追加ができる機能です。従来は標準テーブルへの項目拡張やExitで実施していたロジック追加などをこの機能で代替することが可能です。
Custom Analytical Queries
簡単なレポートの作成などは該当機能（Query）を用いて実現することが可能です。
S/4HANA 上でのFiori開発
「Fiori開発にはBTPが必要」という誤解をしている方も少なくありませんが、FioriのカスタムプログラムはBTPを使用せずに（BTPを実行基盤としないで）、S/4HANAのアプリケーションサーバ（もしくはプライベートな領域に構築したFioriサーバ）上で実行することが可能です。
この話をすると「どういう場合にBTP上で開発するのか？」という疑問をお持ちの方もいらっしゃると思います。
個人的な経験から、BTP上で開発する理由には以下のようなものがあります。
- 複雑なビジネスロジックを実装する必要があり、アップグレード負荷の観点からABAPでの実装を避けたい場合、もしくはABAPでは実装できないような高度な要件を実装したい場合（逆に言えば、標準APIのみで構成される要件であればBTP側での実装は不要）
- 社外のユーザーなどにインターネット経由でアプリケーションにアクセスさせたい場合（逆に言えば、S/4HANAへの直接アクセスを避けたい場合）
開発環境としてのBTP
なお、ここまでは実行環境としてのS/4HANAとBTPについて説明してきましたが、開発環境としてのBTPは異なる観点から考える必要があります。SAPが公式に推奨するFiori開発環境は、BTP上で動作する統合開発環境「Business Application Studio (BAS)」です。BASを使用する場合、アプリケーションの実行環境がBTPでなくても、開発環境としてBTPが必要となります。
しかし、Fiori開発の手段は「BAS」以外にも存在します。現在最も一般的に使用されているコードエディタである「Visual Studio Code」に「SAP Fiori tools」というアドインを追加することでFioriの開発が可能です。ベーシックな開発はこちらでも実施できますが、最新機能が搭載されていないなどの制限があるため注意が必要です。また、基本的にローカルでの実行となるため、開発者ごとの環境準備が必要になります。その一方で、コストがかからず、ローカル実行のため常時のネットワーク接続が不要といった利点もあります。
どうしても開発が必要場合の手段がカスタム開発
「Fit to Standard」の検討、「Key User in App Extensibility」の活用を検討し、それでも実現できない場合はカスタム開発を選択することになります。
カスタム開発の選択肢の1つが「BTP上でのSide by Side開発」です。その他の選択肢として、ABAPを用いた「In App開発」や「BTP以外のプラットフォームでのSide by Side開発」があります。
これらの手法の詳細な比較は後続の記事で行いますが、どの方法が最適かは一概には言えず、個々の事例に応じて判断する必要があります。最近は「In-Appはアップグレードへの影響が大きいため、できるだけBTPを使うべき」という意見もありますが、ABAPならではの利点もあり、要件に応じて適切な選択をすることが重要だと考えています。
テクノロジーを理解し、自身の組織にあわせた手段の整理が必要
前述のような議論において、各手段に「○、△、×」の評価をつけたり、ベストプラクティス化を試みたりすることがありますが、私はそのアプローチがあまり効果的ではないと考えています。
そう考える理由は大きく分けて以下の2つになります。
- テクノロジーが複雑化し、単純な軸で評価がしづらいから
- 単なる技術比較でなく、会社全体のアーキテクチャ方針や組織の人材方針を考慮することが必要だから
テクノロジーが複雑化し、単純な軸で評価がしづらいから
IT製品を構成するテクノロジーは日進月歩で進化し続け、ITベンダーは市場の要求に応えるべく、これらの技術を活用して様々な製品をリリースしています。
その結果、製品の単純な機能比較が非常に難しい状況となっています。例えば、同じデータ連携製品でも、カバーする機能要件の範囲や稼働する基盤技術が微妙に異なっており、情報の整理は可能でも、単純な評価基準での比較が困難になっています。
文書作成ソフトを例に考えると分かりやすいでしょう。以前は「Word」と「一太郎」という似たような製品を比較するケースが主でした。機能と価格のトレードオフや、必要な機能の有無など、評価が比較的容易でした（「一太郎」をご存じない世代の方は、ぜひ調べてみてください）。
しかし、現在ははるかに多くの選択肢があります。WordにはOnline版があり、MSはOneNoteもリリースしています。さらに、マークダウン形式で利用できる「Dropbox Paper」や「Box Notes」、最近では「Notion」のようなツールも登場しています。「どれが最適ですか？」と問われても、単純な回答は難しく、個々のケースに応じて判断する必要があるのです。
単なる技術比較でなく、会社全体のアーキテクチャ方針や組織の人材方針を考慮することが必要だから
個別の比較だけでも複雑ですが、さらに製品間の組み合わせも考慮しなければなりません。判断の大きな軸となるのは、プラットフォームをある程度統一すべきという基本的なアーキテクチャ方針と、組織が持つ現在の技術力、将来的な技術発展の可能性、人材確保のコストを考慮した人材方針です。これらの要素をどう評価するかによって、最適な選択は大きく変わってきます。
結論どうすればいい
表題にあるように、私個人としては、どんな立場であれ、まずテクノロジーを理解することが重要だと考えます。
その後、責任者の立場にある人は、様々な状況を自らの判断軸で考えて決定する必要があります。テクノロジーの理解を前提として、最適な解決策について、様々な立場の人々が議論を重ねることが今後ますます重要になってくると考えています。
まとめ
少し最後は話がずれましたが、下記の順序での検討が大原則であると個人的には考えます。
次の記事では個別の実装手段の比較について記載しています。