アドオン開発の方針決定基準とSalesforceとSAPの役割範囲について

駒形：最初にSAPによる実装の上で大きなポイントとなるアドオン開発についてお伺いします。
まず、アシストにおけるアドオン開発の方針について、AMIS(現行の販売管理システム)では機能拡張を頻繁にしていたと伺いましたが、機能拡張するための判定基準はあったのでしょうか。

岡田：AMIS観点の場合、年間の業務量と利用頻度が基準になります。その機能を作った場合にどれぐらい社内の業務効率が良くなるかという観点が一番主軸でした。
現場の皆さんからの拡張を行いたいという意見を伺うと、それに対して具体的な要件をヒアリングして、どの機能をどのように拡張するかを決定していました。
また、法的な理由、例えば現在の電子帳簿保存法などへの対応のために開発が必要となることもありました。

駒形：SAPでは、機能拡張、いわゆるアドオンは大幅に減っていく可能性が高いのでしょうか。

岡田：減らしていく前提で考えています。あくまでその業務が本当に必要なのかどうかという点と、パッケージの機能に合わせて業務を整流化できるかどうかが判断基準として入ってきます。

真下：AMISでは現場のヒアリングを行った上で決定していたとのことですが、今後のSAPについてはどのように変わっていくのでしょうか。

岡田：SAPでは全社的な影響度と業務を変えるためのコストとシステム変更のコスト、その運用メンテナンスコストなどを見極めながら判断していく必要があると考えています。

駒形：全社的な影響度やシステム改修コスト、運用メンテナンスコストは本来であればAMISでも考えなくてはいけない話ではないのでしょうか。

岡田：そのとおりです。
AMISはフルスクラッチのシステムだったため、人件費（開発工数）と維持・メンテナンスのコストが重要なポイントになっておりました。
今後は、本プロジェクトの目的でもある業務の標準化・整流化に寄与するか否かの観点が強くなります。

駒形：「今までは業務量や開発コストを基準としつつも現場視点を強めに判断していた。今後はより標準化・整流化の視点を強めに判断する」ということでしょうか。

岡田：はい、ビジネスインパクトをより重視した判断基準として取り入れる必要があると考えています。

石川：平たく言えば、SAPはパッケージのため、いくら要望が挙がってきても、できないものはできないということになります。今後は何かをやる場合には必ずコストが発生することになります。

岡田：そのため、確実に経営のジャッジが必要になります。
AMISでは大塚さん（社長）が指摘しているように、年に数回しか発生しない業務処理であっても、業務が効率化されるということであればシステムの機能として取り入れてきていました。SAPに移行した後は、業務をパッケージの機能に合わせられないかどうかを最初に考える必要があります。その後、アドオンするかどうかの判断になりますが、会社としてのあるべき姿（ToBe）という視点を入れて基準は作っていかなければならないと考えています。
その方向性に向けて、SAP導入完了後以降は、プロセスマイニングツールであるSAP Signavioによって、社内の業務フローの維持・メンテナンスを行い、最適な業務を作っていく予定です。

石川：導入完了後は、パッケージなので大きく手を入れることはできません。そのため、手を入れられない中で、運用してみて業務効率が悪かったら、SAPの周りで何かそういうサービスがないか探してみて、外付けでやるしかないです。

駒形：まさにアシストの出番ですね。

駒形：次に、アドオンとも関連してきますが、扇子（Salesforeを利用した営業支援システム）とのすみ分けについて教えてください。

石川：扇子とのすみ分けは、図1のようなイメージです。SAP導入後の扇子の役割は案件の受注を管理する部分までです。具体的には受注を確認し受注伝票の作成に必要な情報をSAPへ受け渡すところまでとなります。以前は案件と紐づけて見積もりを作成し、受注後、AMISに見積もりを渡しAMIS側で業務処理を行うという流れでした。今後は注文書を受領したら、扇子側で注文上の管理を行うことになります。これは、お客様から注文書を受け取る際、使用権開始日など見積もりには含まれていない情報を追加するためです。これらの確認が行われたら注文処理が完了し、仕入先への発注、得意先への請求情報を揃えて受注を確定させます。その確定した情報をSAPへ連携し、SAP側で業務処理が行われます。これが扇子とSAPのつながりとなります。

駒形：今回、アドオンをSalesforceで作ると伺っていますが、一般的にOutSystems（ローコード開発ツール）などメジャーな製品がある中で、なぜSalesforceを使うのでしょうか。

石川：開発者のリソースの観点と、現状、受注前の活動については見積もりなど扇子を使って仕事しているところが多いため、扇子に寄せた方が良いと考えました。ローコードツールなどで新規開発することも考えましたが、そうするとまた新しいシステムが1つ増えることになるため、Salesforceの中にあった方が良いと思いました。

岡田：今後、新基幹システムリリース以降は、お客様との接点をSalesforceにまとめていくことを考えています。お客様との接点のために作りこみが必要な部分はアシストにとってコアな業務処理だと思うので、その観点でSalesforce側で巻き取るという検討を進めています。

駒形：受注伝票から先は、アドオンせずに済むだろうという見通しがついているのですか。

岡田：次年度、継続予定のデータを作成するところだけアドオンが必要だとみています。他にも項目追加や一覧画面の表示項目修正、データ連携のアドオンはありますが、ロジックを含むプロセスを追加するという観点では、継続予定データ作成のところだけに絞りたいと思っています。

駒形：ちなみにSalesforceの改修は外注せずにアシストの社員が作っているのですか。

岡田：全部内製しています。構築当時に関してはベンダーに入ってもらっていましたが、そのタイミングで社内で技術者を育成し、ITサービス企画部（社内情報システム部門）で内製できる体制を作りました。

駒形：その人たちは、ゆくゆくは外販の方にも関わっていくのでしょうか。アシストのビジネスとして取り組むなどの話はあるのでしょうか。

石川：SalesforceとSAPを両方使っているお客様は結構いるのかなと思います。そう考えるとアシストのような使い方ができるのであれば、喜んでくれるお客様はたくさんいるかもしれませんね。

岡田：アシストの取り組みについては、今までもお客様に事例としてお伝えしてきていますし、今後はSAPとの連携やすみ分けについても事例としてお客様へお伝えしていければと考えています。

真下：案件の受注管理やライセンス管理などSAPの標準機能で持っているものはあるのでしょうか。

石川：見積もりはSAPでもあります。

真下：見積もりだけですか。

石川：SAPのプロセス上は見積もりからスタートして受注管理までできます。

真下：案件という概念はSAPにはないのでしょうか。

石川：あります。引き合いから見積もり、受注までの管理はSAPの機能としても提供されていると思います。

岡田：あるけれども、ライセンス費用も考慮しなければならないです。

真下：確かにそうですね。

岡田：あとは、そもそもSAPはSalesforceと比較すると作り込みができないので、逆に使いにくそうなところが出てくる可能性が高いです。そのためデータの流れでいうところの入口である受注伝票に対して、必要な情報をSalesforce側で作る方がアシスト的には最良と判断しました。

駒形：すこし話は変わりますが、周辺システムとの連携でお客様でも導入実績の多いDataSpiderはどこで動いているのでしょうか。

岡田：SAPとのデータ連携は全てDataSpiderで行う予定です。

真下：SAPと連携予定のシステムは扇子だけでしょうか。

石川：BlackLine(クラウド型決算業務の支援サービス)との連携でDataSpiderを利用しています。将来的には楽楽精算（経費精算サービス）との連携も検討しています。

岡田：BlackLineはどちらかというと日本特有の商習慣にパッケージとして合わせられるというところが良いと思っています。これがSAPで実現できないところを吸収してくれることを期待して今、構築しています。

駒形：全てDataSpiderで連携するのでしょうか。

石川：今のところはDataSpiderです。しかし、このままずっとDataSpiderを使い続けるかどうかはわかりません。

駒形：それはなぜですか。何か問題があるのでしょうか。

石川：問題はないです。ただ、SaaSのベンダーが増えてきている中で、SaaSベンダーは自社サービスの生き残りを図るために、SAP連携コネクターを作るのではないかと予測しています。それができあがってきたら、それに任せてもいいのではないかと思っています。例えば楽楽精算やBlacklineにSAPと連携するコネクターが準備され、設定ベースで連携できるようなサービスがあるのであれば、わざわざ自社でロジック開発するよりも、そのサービスを利用した方が運用の観点で維持しやすい可能性も出てきます。そうなった場合には、全体のバランスを見ながら検討していく必要はあると考えています。

岡田：パッケージ同士のジグソーパズルじゃないですが、その時々で何が最適かというのは変わってくると思うので、ずっとこの方式と決めつけず、常に情報収集し検討することが最適なシステム運用につながると考えています。

駒形：色々な連携先があるけれど、それぞれの接続の仕方を覚えるのではなく、DataSpiderだけ覚えておくだけでつなげられるので開発工数の削減ができます、というDataSpiderのセールストークがあります。それぞれのSaaSベンダーが持っている連携機能を使うと、製品ごとに連携方法が変わってくるので大変になるのではないでしょうか。

石川：アシストでは、Glean(AIを活用した企業向けの横断検索エンジン)とSalesforceをつないでいますが、ここにロジックは必要ありません。GleanからSalesforceへ接続する設定を行うだけで良いのです。それと同じで、楽楽精算等がコネクターを出すとしたら、そこにロジックは必要なく設定するだけで接続可能になると考えています。ここにプログラムの要素が入ってくるならば、DataSpiderを使うことでスキルが分散しないので、先ほどのセールストークどおりですね。

沖：最近は、どんどんAPIが共通化されてきています。SAPもAPI SaaSをリリースしており、SAPとつなげたかったらここに来てくれれば全部つながります、というサービスを提供する予定があるそうです。
ECCを使っている間は、絶対にロジックが必要になりますので、すぐにDataSpiderがなくなることはありませんが。

石川：すぐにSAPにつなげることができる外付けの良いものを探してきたら、どんどん提案できると思います。あとSAPの周辺で、SAPには一切手を入れずに外で処理を行うようなソリューションを探してきたりするとよさそうだとも思います。その1つがBlackLineです。

沖：データ活用系だとSnowflakeが盛り上がってきているのではないかと思います。

駒形：アシストでもSnowflakeとQlik Cloudを組み合わせたソリューションを取り扱っていますが、採用する予定はありますか。

岡田：データ活用については今後の検討事項です。

沖：今はオンプレミスのVerticaにデータを置いていますが、どのような状態になっても対応できるように、今後データはSaaSに置く方が良いのではないかと考えています。

駒形：今回も長時間にわたりありがとうございました。