2020年05月21日　日本総研　林　翔太

対外取引業務から見える受注者側のITシステム複雑化の要因

新型コロナウイルス感染症への対応としてリモート勤務を推進する中で、多くの企業が、「出社しなければ対応できない業務」に直面している。

原因としては、社内的側面（『リモートワークを阻害する紙・印鑑文化からの脱却』参照）と対外的側面があるが、対外的側面に目を向けると、例えば次のような状況に陥った企業も多いのではないか。

受発注や出荷、請求といった日々の取引について、取引先が指定伝票での対応を要望しているため、専用プリンタで印刷し送付するために出社せざるを得ない。あるいは、EDI(Electric Data Interchange:電子商取引)等でシステム化していても発注者から貸与された専用端末はオフィスでしか使用できないために出社せざるを得ない、等。

デジタル化の進展が叫ばれて久しいにもかかわらず、未だにこうしたアナログな業務対応が必要な取引は多数存在する。そして、これらをリモート対応に切り替えることは実にやっかいであり、場合によっては取引の遅滞等にまで影響を及ぼしてしまうことに気付いて、改めて愕然とした企業も存在するだろう。

こうした実情から見えてくるのは、「大企業等の発注者側がアナログな業務対応を取引先に強いていること」と、「受注者側もアナログな業務要件をそのままシステム化していること」という傾向である。発注者側が、業務を変えたくない、自社が楽になるようにしたい、この商材はこの個別伝票で管理したい等、自社の都合に合わせるように取引先に要求してきたことが、大きな要因である。また受注者側が、発注者の都合を優先し、業務の流れは見直さず、ITシステムの処理機能の中にそのまま埋め込む、等の形で場当たり的に対応してきたことも大きな要因である。その結果、非効率でアナログな業務対応と、それをサポートするために複雑化し拡張性が低下したITシステムが多くの企業で生まれてしまったのである。

今回のコロナショックにより、こうしたアナログな業務対応と拡張性が低下したITシステムによってもたらされる弊害が改めてあぶり出された。眼前では取引の継続性に関する支障の発生であり、将来においては、DX（Digital Transformation）等の様々な変化対応を妨げかねないといった懸念である。

こうした弊害が顕在化した今こそ、社内システムの在り方はもちろん、企業間の取引システムの在り方にまで踏み込んで、本質的なデジタル化とその先の革新であるDXに向け、抜本的に取り組んでいくべきである。

この問題は、発注者、受注者双方にまたがるものであるが、本稿では、特に受注者側に焦点を当て、アナログな業務要件をそのままシステム化していることにより、特にITシステム面で発生している複雑化の実態の分析と、今後の対応に関する提言を行う。

業務改革・システム構想策定現場から見えるITシステム複雑化の実態

ITシステム面で発生している複雑化の実態について、今回は、取引先と取引先をつなぐという業種上、対外取引に対応するための業務要件が多様化する傾向にある卸売業界をイメージして整理した。これまで当社が行ってきた業務改革・システム構想策定支援を踏まえると、その要件対応の在り方は、少なくとも以下の3パターンに整理できる。

図表1：対外取引先との業務要件へのシステム対応パターンと複雑性

これらの対応パターンから見えてくることは以下である。

まず、パターンAは、多様な「アナログな業務対応」を迫る取引先による業務要件に対し、どうすれば現場職員が違和感を覚えることなくシステムでの処理を効率的かつ高度に進められるかという方針の下、システム化を断念せずになんとか機能の中に盛り込むといった注力を続けてきた結果である。注力すればするほど、複雑化し刷新が難しくなり、結果的にDX推進を含む変化対応といった大局的な視点での効率化および高度化の足かせとなってしまっている。他方、パターンCのようにシステム化を断念すると、手作業が増え、そもそもの業務が非効率化してしまう。このように、アナログな業務要件は、そのままシステム化すればシステムが複雑化し、システム化しなければ業務の効率性が妨げられるというトレードオフ関係の中で対応の選択を迫られるのである。その中庸としてパターンBが存在するようなイメージである。

こうした関係性にあるが故に、一度複雑化したシステムの見直しは困難を極める。刷新後の新システムのサービスレベルを現行システムよりも下げるということが容易には許容されないためである。

対応方針　～システム複雑化解消に向け、いかに取り組んでいくか～

前述のITシステム複雑化の対外的側面からの要因と内情を踏まえ、ここでは対応方針について、「システム化範囲」、「システム構造」および「システム化計画」の3つの観点から言及する。

（1）システム化範囲　～判断基準を設け範囲を見極める～

前段の図表１およびその分析で示したとおり、アナログな業務要件をそのままシステム化すればシステムが複雑化し、システム化しなければ業務の効率性が妨げられるというトレードオフ関係が存在する中で、複雑化と非効率の両極端に陥ることはいずれも望ましくない。従って何らかの「判断基準」をもってシステム化すべきかどうかを見極めることがまず重要である。

「判断基準」については、基本的には各社が最適なものを策定すればよいが、様々なやり方が考えられる。例えばパッケージシステムの活用を想定し、かつ、基準を金額換算して判断する場合を想定してみよう。

個々の要件がシステムにもたらす「複雑性」の影響度合いについては、「標準機能で対応できず、カスタマイズ対応するために必要な構築費用の多寡」で把握し、「効率性」は「システム化することにより、手動対応と比べた場合の作業の削減時間と従業員の時間単価を掛け合わせ」で算出し比較する、というやり方が最もポピュラーなものとして考えられる。

その他、事務のミス率や手戻り時間を指標にする、パッケージシステムを導入する前提であれば、「標準機能と要件の適合率」を指標にし、一定の率を下回らない範囲でシステム化を実施するといった考え方と組み合わせることも一手である。

図表2：システム化範囲見極めのイメージ

また、月に一度しか取引が無いような特殊パターンまで、現場の要望を精査することなく、システム化しているケースがある。現場から、「そういえばこういうケースもある」という話が出てきた際には、必ず、それがどの程度の頻度で発生するのか、それがシステム上のデータとなることで、業務上どのような価値が生まれるのか、等について合わせて確認しながら、システム化の範囲を検討していくべきである。

（2）システム構造　～キーワードは疎結合～

今回のケースのような複雑化したITシステムの構造に関しては、「疎結合」というキーワードからの見直しが重要である。「疎結合」とは、その名のとおり、システムを構成する要素間の結び付きが「疎」、すなわち各要素の依存関係が薄く、独立した要素同士が連携している形態を指す。対義語が「密結合」である。

ではなぜ「疎結合」が必要なのか、それは、端的に言えば、「①現行の複雑性を解消しやすい構造」および「②将来のIT技術やデジタル技術への対応を進めやすい構造」を実現しやすいためである。

まず①について、前述の図表１の複雑性が高いと表現したパターンAの「出荷」に関する例をもとに確認していきたい。例えば、特定の商材の出荷実績について、対外取引の個別要件として、EDIで取引先へ送信するデータを基幹システムの出荷機能の中で変換・作成する構成が存在した場合、仮に業務の流れ上連続して処理ができる面はあったとしても、そこには「出荷」機能と「EDI」機能の「密結合」状態が発生している。こうした機能レベルでの「密結合」が発生していると、例えば取引先都合で、「EDI」連携データの要件の見直しが発生した場合に、「出荷」機能にまで影響が生じ修正が必要になりかねない。この積み重ねがシステムを複雑化し、その分だけ刷新対応の難易度が向上していくこととなる。

システム全体の見直しには時間がかかるとしても、複雑化の要因となっている特殊要件のみを見直すのであれば対応しやすい。システム化では、企業活動における共通要件を整理した上で、可能な限り特殊要件を外出しする形で機能化し、共通要件部分の機能と疎結合な仕組みにしておくことが有効である。そうすれば、将来的に取引先が要件を見直した際に、その影響範囲の見定めや対応の迅速化を図ることができる。

先ほどの出荷の例で言えば、疎結合化する対応として、出荷機能はあくまで標準的な範疇に止め、基幹システムの外の仕組みで、出荷データをEDIデータに変換し送信する形にし、かつ、データ連携モジュール等を介して基幹システムと連携する構造に改善する、といった形が考えられる。

図表3：密結合システムの疎結合化イメージ

機能が過度に密結合な構造例

例えばEDIの連携要件が変わると、出荷機能にまで影響が及んでしまいかねない

疎結合化を図った構造例

特殊要件はコア基幹システムから外出し、データ連携モジュールを介すことで、影響範囲を最小化、変化対応に強くなる

共通部分と特殊部分を分けることにより、共通部分に対し、パッケージシステムを適用できる可能性が高まる、ということも見逃してはならない。逆に、構想段階での検討がどうしても難しければ、パッケージシステムの標準機能との適合可否を見定めながら、パッケージベンダーとともに外出しすべき機能を見極めていくアプローチも良いのではないかと考えられる。

②のポイントは、ガートナー・ジャパンが「ポストモダンERP」という概念の説明において言及している「アプリケーション疎結合」という考え方である。

これまでのERPが業務機能を統合・集約した密結合型であったところに対し、業務機能を分解した上で、機能群単位に最適なアプリケーションやSaaS型サービスを選択し、疎結合で連携させることにより、変化に対して柔軟かつ俊敏な対応を実現し、高いビジネス価値をもたらそうという考え方である。

このような考え方のシステム構造を担保することで、機能群単位で最も自社にとって価値の高いアプリケーションに置き換えていくことが可能になる。

大きなレベルで言えば、例えば、NEC社のように、国内外の主要グループにはコアERPとしてのSAP　HANAを、中堅・中小規模の海外グループ会社には親和性の高いクラウドERPであるSAP　Business ByDesignを導入し連携するようなケースが挙げられる。コアERPとグローバルなクラウドERPと組み合わせることにより、中堅・中小規模にとって過剰なERPの仕組みを導入することを避けられると同時に、システムの複雑化を避けつつ、各国の法制度の変更やM&A、市場変動等の変化に柔軟に対応できるようになっている（※1）。こうした取り組みは二層ERPと呼ばれ、ポストモダンERPの実現の一つの形である。また、そこまでの規模でなくとも、これまでスクラッチ開発で基幹システムを構築し、購買機能や経費精算機能等についても基幹の機能に融合させる形で構築していた企業が、コアとなる基幹ERPパッケージを導入するとともに、SaaS型の購買パッケージシステムや経費精算パッケージシステムを組み合わせる形に刷新することも、ポストモダンERPの実現の形の一つである。旧来の密結合なERPでは、そうした購買や経費精算機能も一つのERP上で実現していたが、実際は機能の充実性について、個別のクラウドアプリケーションの機能と比較して見劣りするといったケースも多かった。

前者の例は、拠点の統廃合等を含む変化対応に対する価値、後者の例は、個別業務の高度化や効率化という価値、とそれぞれ求めるものに違いがあるように、システムの構造を検討する際に、自社にとっての価値の見極めが必要であることも同時に忘れてはならない。

（3）システム化計画　～個々の状況を踏まえ段階的な刷新も視野に～

「計画立って」対応を進めていくことの必要性は論を俟たないが、計画を策定するにあたって重要なポイントは「契機の活用」と「段階的な刷新」であると考える。

まず、「契機の活用」に言及するのは、過度に受け身になってしまわないためである。取引先による要件見直しが進むタイミングが不透明になりがちな状況を放置することなく、双方に影響のある契機を交渉材料として、まずは取引先と積極的にコミュニケーションをとり、その反応も踏まえながらシステム化計画を策定することを推奨する。契機の例としては、まさしく今回の「コロナショックによる取引に関する影響」や「2024年のISDN終了に伴う電話回線を用いたEDI仕様の見直し（EDIの2024年問題）」等が挙げられる。

続いて「段階的な刷新」については、複雑性の深刻度、刷新コスト、体制面等の状況によって、複雑化したシステムを一足飛びに目指す姿まで刷新することが難しいケースが十分に想定される。この場合は、実現可能な範囲で、かつシステム構成上の影響範囲も見定めながら、段階的に刷新を進めていくという工夫も必要である。例えば、まずはEDIの2024年問題に対応するために、EDI連携の部分から、より汎用性の高いSaaS型サービスの適用も視野に入れながら対応を進めていくというのも一手である。

図表4：段階的な刷新イメージ
（図表3と関連した例：青い部分が開発範囲）

一次開発時点

対応期限等も踏まえ、EDIの連携部分や、着手しやすい部分から取組み、下地づくりを進めるのも一手

二次開発時点

一次開発でできた下地を基に本格的に構造を刷新

終わりに

本稿は、コロナショックで改めて浮き彫りになった対外取引のアナログな業務対応とその帰結としての受注者のITシステムのひずみについて、現場のシステムの実態を覗きながらその発生プロセスを明らかにし、変化対応に強い疎結合な構造へITシステムを刷新していくべきであるということを述べた。

本稿は受注者に焦点を当てたため、発注者への言及は割愛した。当然のことながら取引は企業間のものであるため、今回の新型コロナの影響により取引が滞ったケースも然り、今後、より多様な企業間の情報連携や協業・協働が求められる未来において競争力を維持するためには、大企業等の発注者が、率先して要件を見直し、取引先や業界を巻き込んで取り組みを推進していくことが重要である点は忘れてはならない。

（※1） NEC「NECグローバル経営改革＜＜第五弾＞＞」（2020年5月12日参照）

※記事は執筆者の個人的見解であり、日本総研の公式見解を示すものではありません。