今から四半世紀前、「IT革命」というワードが流行語大賞になり、IT基本法が成立して内閣にIT戦略本部が設置されるなど、国を挙げてIT化の推進体制が整ったころのお話。日本の貿易業界では「TEDI（Trade EDI）」と呼ばれる貿易取引を電子化するための仕組みが構築され、商用化に向かっていました。この記事では、TEDI関係者の記憶をたどり、その貴重な経験から得られた教訓や、現代のデジタル変革に生かせるかもしれない提言をいただきます。後編は、問題点整理の続きと、TEDIの経験を踏まえた、これからの貿易DXに対する提言です。
元テディ・アドバンスト・ネットワーク（TEDIANET）社長 渡邊浩吉氏（談）
（編集部注）本記事タイトル、記事内見出しはtradigi.jp編集部にて作成。
TEDIの、各側面における問題点の整理（つづき）
ユーザー体験における違和感
貿易文書のデータを国内外で再利用できるようにするため、当時は構造化言語を使った標準フォーマットの導入が必要であると考え、ebXMLを使ったTEDI標準フォーマットを提供しました。しかしながら、利用される方にとって、TEDIを使うためには「従来の入力画面と似てはいるけど同じでない」画面に入力しなければならず、抵抗感を持たれることがありました。そのため、利用者から十分な理解を得ることは容易ではありませんでした。
貿易の実務現場からしてみれば、貿易文書を作成するために、紙やPDFといった従来の方法であれば使い慣れた画面に入力すれば済むことを、TEDIを使うためには、似たようなレイアウトだとしてもTEDI標準のフォーマットに入力しなければならないことになり、つまりユーザー体験の違和感に対する拒否反応が示されることがありました。
「標準フォーマットで送信すれば相手先も同じ標準フォーマットで電子データを受信します。紙やPDFで送ったのと同じように正しく情報が伝わり、さらにその電子データは取引関連の多くの後続業務に使い回すことができます。これを全ての案件で一般化させるのが、貿易における（当時注目を集めていた）ペーパーレス1化です」というような少し抽象化した説明をするのですが、実務的にはあまり歓迎されないこともありました。特に、受信よりも送信が多い場合は、恩恵よりも負担を強く感じることもあったものと思われます。
このような状況に対応するため、前編でも触れたようなフォーマットの変換支援をすることとなり、「いつものフォーマットに入力してもらえれば、後はシステム的に標準フォーマットに自動的に変換する仕組みをセットしましょう」というようなところに収めざるを得なくなるわけです。
標準フォーマットの是非と限界
次に、「ひとつの標準フォーマット」で全てのケースをカバーする必要があるのか、と言う点です。ある事業者にとって、貿易取引の相手や業界は不特定多数ではなく、自然と限られてくるものです。極端に言えば、鉄鋼製品を食品会社に輸出することは通常考えられませんから、鉄鋼分野と食品分野それぞれの貿易文書を、不合理を圧してまで同じ標準フォーマットとする必要は無いという考えが出てきます。
そんな中、TEDIはUN/EDIFACTやSWIFTという国際標準に沿って汎用のTEDI標準文書フォーマットを作成しました。後続業務の効率化も視野に入れ、ebXMLを基盤として設計されたTEDIとしては、パッケージの中で汎用の標準文書フォーマットを提供し、TEDI加入者が汎用標準フォーマットを日常的に駆使してもらえることを目指しました。後述するように、TEDIが貿易電子システムとして日本のインフラとなるなら、これは外せない部分でした。
TEDIのインボイスを例に採りますと、標準フォーマットは、前編で紹介したPAAの国際標準を踏まえた「PAA標準インボイス フォーマット」に準拠していました。PAA各国の貿易システム間ではそのフォーマットでデータが交換されますから、当時としてはそれが一番合理的と言えました。業界特有の情報などのために、標準項目外に自由記述欄を設け、添付も可能となっていました。また、UN/Layout Key2を参照し、A4用紙に自社書式に似た体裁で印刷可能なPDF画面も提供しました。
利用者に汎用の貿易電子システムの有用性を認知してもらえれば、フォーマットの標準化自体が利用者の直接のニーズではなくても、貿易電子システム運用には必要なものとして協力を得ることが出来るであろうとの考えでした。しかし、まだ貿易電子システムというコンセプトが芽生えたばかりの当時は、そこまで積極的協力的な認知が広く得られる状態ではありませんでした。
標準フォーマットの普及が進まないとTEDIの構想する貿易電子システムは思い通りには進まない、貿易電子システムの整備が進まないと、敢えて標準フォーマットを導入する必要はあるのか、という負のスパイラルに苦慮したこともありました。
時が経つにつれ、現実的には独自フォーマットがTEDIの標準フォーマットに十分にそぐわない場合は、標準フォーマットの方をカスタマイズする必要が生じる案件が出てきたと記憶しています。このようなケースが複数あると、標準フォーマットは細分化されてしまい、本来の「標準」の体を成さないものになります。
B/L機能の電子化
B/Lの電子化が貿易実務の効率向上という本来の目的の他に効果を発揮するのは「B/Lクライシス」の回避です。B/Lクライシスとは、荷受人によるB/L入手が、貨物積載船の揚港到着に間に合わないため、貨物が揚港の保税エリアから引き取れないというトラブルが発生してしまうことです。
その対応策としては、B/Lの有価証券性や安全性を犠牲にして、荷主が船会社にあらゆるトラブルについて船会社を免責にするという保証状(Letter of Guarantee)を差し入れて貨物の引渡しを受ける方法や、貨物の積港で船会社が発行したB/Lの本紙を、積荷主が荷受人に送らず、その場で船会社に回収してもらう（元地回収と言う）ことで、揚港の船会社代理人がB/L本紙を回収せずに貨物の引渡しが出来るようにするサレンダードB/Lと言う方法、あるいはB/L遅れが予見され、かつ信用不安が少ない場合は、最初からB/Lを使わずSea Waybillに切替えるなどの方法が取られています。
貨物船のコンテナ化が進み航海日数も短くなると、B/Lクライシスが起きる可能性はより高くなりました。このようなケースでも、国境を越えてコンピューターネットワークを瞬時に移動するe-B/Lを適用すれば、B/Lの安全性や機能を損なわずに、一挙にこの問題の回避ができるという、大きな貢献ができます。
TEDIでは「B/Lの電子化」を開発の主眼に据え、有価証券である紙のB/Lに代わって、第三者への対抗要件も具備した形で、権利移転機能をRepository Service Provider（RSP、詳細は前編参照）で実現しました。B/Lが輸出者の手から輸入者の手にわたる間、（貨物に対する権利関係は、B/L上の荷受人欄が記名式か指図式等かによっても違いますが、）柔軟に対応できるよう、所有権、船社が持つ占有権、銀行が持つ担保権に分離できる設定とし、揚地で貨物が引渡される時点でこれらの権利が再度一本に纏るまでをRSPで一元管理するような仕組みでした。
B/L電子化の提案に係る利用者の反応は、B/L発行者となる船会社にはe-B/Lを積極的に進める姿勢が見られましたが、利用者となる輸出入者のほうは、RSPでB/Lを電子化するなら、インボイスなどその他の貿易文書も、同じタイミングで電子化により機械処理ができるようにならないと、使用媒体が併存することにより、却って効率が落ちると考えられることが多かったと思います。結果として、折角のTEDI RSPの中心装置は、なかなか本来の機能を発揮できませんでした。
インフラ化 （日本の貿易に係るインフラという位置づけとビジネスの関係）
TEDIは日本のインフラというような矜恃が持たれていたと思います。ひねれば水が出るように、TEDIに繋げばいちいち技術的な仕組みや法的枠組みを気にしなくても、通信相手、取引相手と安全に電子データ交換が出来るような便利な存在を目指していました。これは、大企業はもとよりシステムの専任者がいないような中小企業でも、自社が従来使っていたフォーマットと恐らくほとんど変わらないTEDIフォーマットに入力するだけで、あとはTEDIにお任せ、というような使われ方を理想としたものです。
しかし、2000年当時の日本の貿易業界では、時流に乗ったITシステムとして電子データ交換による貿易電子システムに一般的な関心は持たれていたにせよ、待ち望まれていたと言えるほどの状況ではありませんでした。さらに、従来のコミュニケーションでもさほど不自由が無いという場合、TEDIを使うとどのくらい労力やコストが下がるのかという直接的なメリットが求められます。
TEDIの導入効果が現れるのは、一般的には利用者が多くなり日常業務に定着してからで、導入期にはTEDI利用料金だけでなく、煩わしい作業工数と費用負担が発生します。また、通信相手・取引相手がTEDIエコシステムの外にいる場合は、まず相手にもお金と手間をかけてTEDIに加入してもらう必要があります。得られるメリットが負担に見合うと考えてもらえるか、否か、の勝負になります。しっかりとTEDIの機能を評価してもらわないと、導入までに漕ぎつけるのは容易ではありません。
ブームとまで行かなくても、ある程度までTEDIの普及が進めば、仕組みに係る認知も高まり、何よりもTEDIがインフラとなりそうな予感を持ってもらえたかと思います。それが弾みとなってインフラ化の目途が立つこともあるのでしょうが、当時はどのくらいの期間でそのような状況になるのか、いつになったら採算が取れるようになるのかの予測が困難でした。
TEDIの経験を透かして見た、これからの貿易DX
改めてTEDIが立ちいかなくなった原因を纏めると、当時の時勢もあり、貿易電子化は世界的な動向も含めて気に掛けられていましたが、現実的には貿易電子システムをすぐにでも活用したい、という喫緊のニーズを持つところは少なく、むしろ貿易電子システムを使うには手間とコストが掛かり、かつ、少なくとも暫くの間は電子データと紙の二本立てを扱うことになるというマイナス面から割に合わないと考えられたことが多かったことであると言えます。市場からのこういった評価を受けやすい状況を易々とは変えられず、当初想定したようなペースでは利用者の参加が得られなかった一方、利用者対応やシステム改善でコストは掛かり続けますので、採算が採れる見通しを立てることが出来なかったということになります。
提言1：誰の、何のためのシステムなのかをはっきりさせること
TEDIは「誰の」「何のために」貿易電子システムを作るのか、という部分に課題が有ったかと思います。例えば「多くの貿易関係者の」「人手不足解消のために」というようなニーズが先行する状況であれば、開発段階からいろいろな注文が寄せられるかもしれませんが、完成すれば一定の利用者数が確保されている状態になるかと思います。しかし「システム開発側が」「貿易のあるべき姿を実現しよう」というような、言わば理念先行型でプロジェクトを進めると、利用者の理解がなかなか得られず、苦戦を強いられるかもしれません。
貿易電子システムに限らず、民間事業としてインフラ的要素のある案件を取扱うには、「利用者はこれが出来れば便利になり、歓迎する筈だ」という想定だけでは行き詰る可能性があり、少なくとも何らかの制度的なインセンティブでもあればスムーズに事を運べるのではないかと思います。
提言2：結論ありきのマーケティング調査にならないように
事前にマーケティング調査をする場合、言わずもがなですが、プロジェクト開発側が結論有りきでその論拠を集めるような調査はすべきではないと思います。「日本には電子貿易のインフラが必要ですか」と問えば誰も反対せず、それをもって賛意を得たと解釈した場合を考えてみます。この質問と回答では調査側のバイアスがかかった捉え方となる可能性が有り、もう一歩踏み込んで「何故そう考えるか」まで質問すれば、どの程度の必要性が感じられているかが分かるといった具合です。また、各方面からの情報収集も、ヒアリングを受けた人が質問の意図するところを十分理解した上で回答されたか、正しい情報をお持ちであったかなどを確かめるために、できれば同じヒアリングを別の機会に複数回行うくらいの慎重さがあってよいと思います。
また、関係業界にそれぞれの意見を聞くといった時に、業界の意見を集約したつもりが、現実からズレていた、あるいは業界としてプロジェクトに進言すべきことが抜け落ちて、プロジェクト側が問題を把握しないまま開発が進み、後から問題が起きたなどと言う事態にならないように留意すべきと思います。
提言3：標準フォーマットの限界をどのように超えていくか
貿易文書の標準フォーマットをどのように普及させるかは、貿易手続デジタル化の最大のネックと考えられます。TEDIの時代には考えられなかったことですが、近年は利用者の自社フォーマットと標準フォーマットとのマッピングにおいて、AIの支援による効率化などが提案されているという話も耳にしました。現在のところ結果責任は「人」にしか取れないので、作業負荷の軽減に留まるものと思います。AIの活用が最終的な解かどうかはさておき、ある程度の期間においては手っ取り早い現実解になるのではないかという提案をしつつ、本当の意味での限界突破については皆で知恵を出し合っていくべき重要テーマであることを強調しておきたいと思います。
提言4：インフラ構築には貿易業界全体の協力が必要
TEDIの時代と比べた場合、現在は技術の進歩で方法論的なオプションが広がり、貿易DXの推進には順風が吹いていると思います。また、その手段としての貿易PF利活用推進に向けた補助金も大きなモチベーションになると思います。一方、貿易DXはカバーする分野が多岐にわたるものですから、対象となる業務の現場がどのように捉えているのか、刻々と変わる状況の中で繰返し精査するという慎重な対応も重要と思います。TEDIは現場の声の捉え方が十分ではなかったきらいがあります。「TEDIを何とかしてインフラ化する」という方向で進めようと地道に市場開拓をしましたが、それはサービス提供者側の思いではあっても、それがキーワードとして市場に響くような反応は薄かった気がします。誰かがインフラを作ってくれるのは歓迎です、くらいの話になってしまい、インフラを作るために皆で協力して・・・といった展開にはなかなか結び付きませんでした。
TEDIは、その構築を志す段階では、恐らく「世界の貿易円滑化のため」あるいは「日本の国際競争力強化のため」といった部分では多くのサポートが得られるであろうとの心積もりをしていました。TEDIのようなシステムは、単にパソコンで文書を作ってメールに添付して送るだけとは違いますから、多くの参加者を得てインフラのような状況にならないと、これまでに述べてきたような不都合が生じる可能性が有ります。一方、仕組みが大きいためメリットは徐々に出てくるものですから、インフラのように使用され始めるまでの期間は、利用者の不都合を直接サポートし軽減する仕組みが必要だったかもしれません。
事業体の行動原理は経済合理性ですが、短期的には評価が難しいケースであっても、少しスパンを長くして評価すると、より大きな経済合理性が見えることがあるかと思います。貿易関係の電子システムも少し長いスパンで見ると違った経済合理性が見えてくると思います。その可能性は一社だけの努力で実現されるものではなく、貿易業界全体がベクトルを合わせる必要がある性格のものだと思います。TEDIの経験から考えますと、貿易DXにおいてシステム提供側がすることは、上記のような利用者の経済合理性の有り様を十分理解し、真摯に受け止め、そして一件ずつ、且つ一刻も早く、利用者を増やしていく地道な活動かと思います。必ずどこかに臨界点があるはずで、そこからは自然と伸びていくと思います。そこまで継続させる基盤を持つことが何より大切と思います。
おわりに
本稿前編の初頭で申し上げたとおり、現在の貿易現場にはデジタルに精通した人が恐らく大勢いらっしゃるというところが、TEDIの時代と大いに違うところであると考えます。しかし、そういったデジタルスキルやアイデアは、それが使える環境を官民挙げて作り上げないと発揮できないとも考えます。
例えばAIを導入するのであれば、各プレイヤーがその利便性やリスクに納得して、それぞれの必要性に応じて自ら投資を行って実行すると思います。しかしながら、貿易は「相手がいる取引」である以上、自己完結型にならないところが多々あると思います。連携するプレイヤー同士が、デジタル化に伴う利害のやりとりを含めて調整し、言わば満足度を平準化することが必要になると考えられます。このような調整は、各プレイヤーが貿易DXをどう捉えているか、本気で実現したい格別の理由があるのか、といった「本音の部分」に掛かってくると思います。
ただし、環境面の整備はプレイヤー同士の調整だけでは限界もあるでしょうから、官による政策的支援も欠かせません。補助金はもっと使いやすくするべきですし、プラットフォーム利用者に対する政策減税といったインセンティブも考えられます。一方、例えば協調領域に限っては（何が協調領域なのかは見極めが必要）公共プラットフォームを用意した上で利用の義務化、利用しない場合のペナルティ設置といった強制策も、場合によっては戦略的に用いるべきであると考えます。