はじめに
本記事は「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に直接アクセスさせたくない）
また、上記の話は実行環境としてのS/4HANAとBTPですが、開発環境としてのBTPについてはこれとは分けて考える必要があります。Fioriを開発するためのSAP社としての推奨はBTP上で稼働する「IDE」である、「Business Application Studio (BAS)」です。「BAS」で開発を実施する場合はBTPが必要になります。
しかし、Fiori開発の手段は「BAS」以外にも存在しております。現在もっとも一般的につかわれてるコードディタである「Visual Studio Code」に「SAP Fiori tools」というアドインのようなものを追加することでFioriの開発が可能です。ただし、ベーシックな開発はこちらでも行えますが、最新機能等は搭載されていないことなどもあるので注意が必要ですし、基本はローカルでの実行になりますので、開発者ごとの環境準備も必要になります。その一方で、コストが関わらないのとローカル実行のため、ネットワーク接続が必要ななどの利点もあります。
どうしても開発が必要場合の手段がカスタム開発
「Fit to Standard」の検討、「Key User in App Extensibility」の活用を検討し、それでも実現できない場合の手段がカスタム開発となります。
そして、その1つのPlatformの選択肢が「BTP上でのSide by Side開発」となります。また、他に選びうる選択肢がABAPを用いた「In App開発」であり、「BTP 以外でのプラットフォームのSide by Side開発」になります。
これらの手法の細かな比較は後続の記事で実施するつもりですが、1：100でどの方法が適切であるという答えはなく、ケースバイケースで事例に応じて判断していくことが必要になります。（In-Appはアップグレードに弱いから可能な限りBTPでという論調もありますが、ABAPにはABAPの良さがあり、適材適所を見極めることが重要だと個人的には考えます。）
テクノロジーを理解し、自身の組織にあわせた手段の整理が必要
前述のような議論をすると、それらを手段別にベストプラクティス化できないかという相談や「○、△、×」をつけた評価などを実施することもあるのですが、個人的にはあまり効果的ではないと考えています。
そう考える理由は大きく分けて以下の2つになります。
- テクノロジーが複雑化し、単純な軸で評価がしづらいから
- 単なる技術比較でなく、会社全体のアーキテクチャ方針や組織の人材方針を考慮することが必要だから
テクノロジーが複雑化し、単純な軸で評価がしづらいから
IT製品を構成するテクノロジーが日進月歩で進歩する一方で、市場の要求に答えようとITベンダーはそれらをつかって様々な製品をリリースしています。
その結果として、単純な機能比較が非常に難しい状況になっていると個人的には考えています。同じデータ連係をする製品でも機能要件的にカバーする範囲であったり、稼働する基盤技術などの微妙に違っており、情報整理は可能なものの、そこらかの単純な評価がしにくいものになっています。
文書作成ソフトに置き換えてイメージして頂くとわかりやすいかと思うのですが、旧来は「Word」と「一太郎」という極めて似たような製品を比較するようなケースが主でした。ゆえに機能と値段のトレードオフやどうしてもこの機能が必要だからなど、評価が容易でした。（「一太郎」って？？って世代の人は調べて下さい。。。）
しかし、現在はもっと多くの選択肢が出てきています。WordにもOnline版がありますし、MSもOneNoteもリリースしています。外に目を向けると、マークダウン的な使い方をする「Dropbox Paper」や「Box Notes」があったり、「Notion」なんてツールも最近はでてきました。これらどれがいいですか？？と問われても、単純な回答をしにくく、個別のケースに併せていく必要があることが理解できると思います。
単なる技術比較でなく、会社全体のアーキテクチャ方針や組織の人材方針を考慮することが必要だから
前述の話のように個別の比較でも大変なのに、これらは製品間の組合せを考慮することが必要です。その大きな軸が、プラットフォームはある程度そろっていた方が望ましいという基本的なアーキテクチャの方針やその組織が現状保持しているケイパビリティや将来的に技術の発展性や調達コストなどを意識した人材方針となります。このあたりの要素をどのように仮定するかで判断は大きくかわります。
結論どうすればいい
表題にあるように、私個人としては、どんな立場であれ、まず、テクノロジーを理解することが重要だと考えます。
その後に、責任者の立場にある人は、様々な状況を自らの軸で考えて判断する必要があると思います。理解しているのを大前提として、どれが最適解なのかを、様々な立場の人が議論することがより今後は求られると思います。
まとめ
少し最後は話がずれましたが、下記の順序での検討が大原則であると個人的には考えます。
次の記事では個別の実装手段の比較について記載しています。