実装方式の分析

78 求書メッセージを新規開発した。

79

発したデータ連携ITツールのEDIエンジン）を実装するケース

⑤ クラウドサービスが他社共通EDIプロバイダーに接続

クラウドサービス事業者が自社のサービスから、他社が提供する共通 EDI プロバイダーサービス（本事業で新規に立ち上げるスマイルワークスのEDIサ ービス）に接続するケース

⑥ ユーザーが共通EDIプロバイダーのサービスを利用

ユーザーが共通EDIプロバイダーのサービス（既に実績があるグローバルワ

イズ社のEcoChangeによるサービス）を利用するケース

以下に、中小企業共通EDIプロバイダーの機能の実装方式の分類結果を示す。

（表 8）

表 8 共通EDIプロバイダー機能の実装方式

共通EDIプロバイダー機能の実装方式 対象PJ数 既存EDIに新規開発エンジンを追加実装 3 既存EDIに他社開発エンジンを追加実装 1 クラウドサービスに新規開発エンジンを実装 5 クラウドサービスに他社開発エンジンを実装 3 クラウドサービスが他社共通EDIプロバイダーに接続 1 ユーザーが共通EDIプロバイダーサービスを利用 2

合計 15

※既存EDIとクラウドサービスの両方を提供するベンダーが新規に

共通EDIプロバイダー機能を開発・実装するケースが3件あるため①③は重複あり。

以上の通り、中小企業共通EDIプロバイダーの機能の実装について多様な方式が みられた。

傾向としては、クラウドサービスを提供しているベンダーが、新規に共通EDIプ ロバイダー機能を実装するケースが 5 プロジェクト（ベンダー）と最も多く、既に EDIプロバイダーサービスを提供しているベンダーも3社含まれる。

これは、既にプロバイダーサービスとクラウドサービスを提供しているベンダー は、EDI に対するノウハウ及び技術基盤を保持していることに加え、既存システム に対して追加実装することで、新規開発をする場合と比較して、共通EDIプロバイ ダーを実現することが技術的にもコスト的にも比較的容易であり、参入障壁が低い ことが理由として考えられる。

それに次いで、クラウドサービスを提供するベンダーが他社の提供する共通 EDI エンジン（既に実績があるグローバルワイズ社のEcoChange、本事業で開発したデ ータ連携ITツールのEDI エンジン）を実装するケースが3プロジェクト（ベンダ ー）となっている。

これは、共通EDIプロバイダーサービスの提供はクラウドが前提となっており、

クラウドサービスを提供するベンダーには参入しやすく、自社のサービスの付加価 値を向上するためにも有効と捉えているが、共通EDIプロバイダー機能を新規に開 発することによる技術的リスクや開発コストの増大を懸念したための選択と考えら

80

れる。この懸念を払拭するためにも、共通API の早期仕様化、技術仕様および事例 の公開等が急務である。

(2) 実証検証対象の業務アプリケーションの形態

実証検証の対象となっている業務アプリケーション（クラウドサービスを含 む）の形態を以下に従い分類・分析した。

① オンプレミス業務アプリケーション

ユーザーのパソコンまたはサーバーにインストールされて運用される業務ア プリケーションで、以下の２つの形態がある。

・ユーザー個別アプリケーション（パッケージのカスタマイズを含む）

ユーザー企業がスクラッチ開発またはパッケージソフトのカスタマイズによ り独自の仕様で導入したアプリケーション

・パッケージアプリケーション

パッケージベンダにより販売・提供されているパッケージソフト

② クラウドサービス

クラウドサービス事業者がインターネット上で提供するサービス。Web 型に 加え、リッチクライアントをパソコン等にインストールするものも含む。基本 的にデータベースはクラウド上に保持する形態とする。

以下に、実証検証対象の業務アプリケーションの形態の分類結果を示す。（表 9）

表 9実証検証対象の業務アプリケーションの形態

実証検証対象の業務アプリケーションの形態 対象数

① オンプレミス業務アプリケーション 26 ユーザー個別アプリケーション 9

パッケージアプリケーション 17

② クラウドサービス 15

合計 41

オンプレミス業務アプリケーションは26システムが対象となっており、ユーザー 個別アプリケーション（パッケージカスタマイズを含む）は 9 システム、パッケー ジアプリケーションは17システムと最も多くなっている。

一般的に、中小企業においては、まだ、クラウドサービスよりもオンプレミス業 務アプリケーションの普及率が高く、独自仕様のユーザー個別アプリケーションと 比較してパッケージアプリケーションが多い傾向にある。

81

本実証検証対象の業務アプリケーションも、この傾向と一致しているが、最も多 いパッケージアプリケーションはカスタマイズが困難なケースが多いため、中小企 業共通EDI実装ガイドラインで仕様化している、最低限のカスタマイズで共通EDI プロバイダーとの連携を実現する連携共通I/Fは有効である。

クラウドサービスについては15システムとなっており、全ての実証プロジェクト において検証対象となっている。中小企業での普及度はまだ低いものの、今後、確 実に普及が進むと思われ、クラウドサービスが共通EDIプロバイダーと連携するた めの共通APIの早期仕様化が望まれる。

(3) 実装ガイドラインの更新

実装方式の分析結果を踏まえ、実証検証に必要な連携仕様の要件をもとに「中小

企業共通EDI仕様v3.1」実装ガイドラインの更新を行った。

(ア) オンプレミス業務アプリケーションと共通EDIプロバイダーの連携仕様 オンプレミス業務アプリケーションと共通EDIプロバイダーの連携仕様につ いては、「中小企業共通EDI仕様v3.1」実装ガイドラインにて連携共通I/Fが仕 様化されている。これに排他制御機能を補完し実証検証仕様「中小企業共通EDI

仕様v3.1rev9a_draft」とした。

共通EDIプロバイダーは、連携共通 I/Fを実装し提供することを原則必須と する。これは、前述の通り最も多数を占めるパッケージアプリケーションは、

カスタマイズが困難なケースが多く、最低限のカスタマイズで共通EDIプロバ イダーとの連携を実現可能するには、連携共通I/Fが有効であることによる。

中小企業共通EDI連携機能を実装するパッケージ業務アプリケーションにつ いては、連携共通I/Fに対応する連携機能を実装することとする。これは、パッ ケージ業務アプリケーションを使用するユーザーが、自由に共通EDIプロバイ ダーを選択することを可能とするためである。

但し、パッケージ業務アプリケーションのベンダーが共通EDIプロバイダー も運営する場合は、ビジネス戦略として独自のインターフェースとすることを 制限するものではない。

また、ユーザー企業がスクラッチ開発した業務アプリケーション、および既 存のパッケージ業務アプリケーションにおいても中小企業共通EDIプロバイダ ーと連携するためにはカスタマイズが必要になるが、連携共通I/Fを利用するこ とにより、カスタマイズを最小限に抑えられため、比較的容易に実装すること ができる。

(イ) クラウドサービスと共通EDIプロバイダーの連携仕様

クラウドサービスと共通EDIプロバイダーの連携仕様については、「中小企業

共通EDI仕様v3.1」実装ガイドラインにて以下の２つの方式が提示されている。

・ 独自連携方式

ベンダー独自の方法で連携する方式である。主に、同一のベンダーによっ

82

て、クラウドサービスと共通EDIプロバイダー機能を併設する形態（以下、

便宜上「一体型」という。）に用いられることを想定している。

・ API方式

API により連携する方式である。主に、それぞれ異なるベンダーが運営す るクラウドサービスと共通EDIプロバイダーが連携する形態（以下、便宜上

「分離型」という。）に用いることを想定している。

「分離型」の連携における API は、都度個別の協議にて仕様を決める手間お よび接続先ごとに開発するコストの発生を回避するために、仕様の共通化が求 められる。

実証検証仕様の策定に際し、モデルプロジェクトに提案を求めたが、実証プ ロジェクトは「一体型」が大半を占め、この形態においては独自方式が有効で ある。他方、「分離型」の実証プロジェクトは2件であり、1件は独自APIで接 続し、他の1件はJX手順で接続したため、共通APIについての実証検証は各 モデルプロジェクト単位では実施していない。

(ウ) 共通EDIプロバイダー間連携仕様

共通 EDI プロバイダー間の連携については、「7.2. データ連携システム同士 の連携実証」にて示す。

既存のEDIとの連携仕様

共通EDIプロバイダー間の連携についても、同様に「7.2. データ連携システ ム同士の連携実証」にて示す。