ブロックチェーンで受発注プロセスを”デジタル化”する
～ブロックチェーンで世界を変えるための第7歩～
--
____________________________________________________
＜お知らせ＞
SBI R3 Japanブログは、MediumからSBI R3 Japanのポータルサイトに引っ越ししました。引っ越し先で、mediumの過去記事も閲覧可能です。今までとは異なる新しいコンテンツも発信してまいりますので、お気に入り登録をぜひお願いします！
____________________________________________________
ブロックチェーンでよく議論されるユースケースとして、紙の”電子化”があります。もちろん、紙を”PDF化”する話をしている訳ではありません。貿易金融等、様々な種類の紙が飛び交う取引をどう改善するか、が紙の”電子化”であり、一番多い場面は受発注プロセスです。発注書、納品書、請求書等をブロックチェーン上に載せ、取引相手と共有する。何となく良さげな話ですが、その嬉しさをもう少し丁寧に読み解いていきましょう。
受発注プロセスにおけるコンフリクト
受発注プロセスは、英語でProcure2Payと呼ばれたりします。バイヤー目線で、Procureは「調達」、2(=to) Payで「支払まで」を意味しており、厳密には調達から支払まで一連の手続きをエンド・ツー・エンドで繋げるというスコープで考えるのがこのユースケースです。当然このプロセスには、サプライヤー側のプレイヤーも登場します。
最初に理解しておきたい状況は、受発注におけるバイヤー（購入する側）とサプライヤー（販売する側）は異なるモチベーションを持っている点です。つまり、バイヤーは先に商品を受け取り、出来るだけ遅く支払いたい。一方、サプライヤーは、運転資金を効率的に回すために、早く入金して欲しい、もしくは入金を確認してから出荷したい、と相反する考えを持っています。
このような二者が受発注するとき、微妙なモチベーションの違いに気付いておく必要がありますが、お互い「業務を効率化したい」思いは変わりません。
受発注プロセスに関わる現状の課題
例えば、単純に１つのコンテナを海上輸送するだけで、36種類、計240ページの書類を27人の関係者が介在して処理する、と言われています。このように大量の書類を全て最新の状態で取引相手と過不足なく保持し合うことはほぼ不可能です。受発注の交渉プロセスでは、発注情報は何度も書き換えられますし、決まった後も変更依頼があったり、確定後も発注確認書が飛び交います。
請求・支払段階においては、サプライヤー側が実際に納品したモノと入金情報が一致しないケースもあります。これは集計単位や集計タイミングの違いが原因です。例えば、月末の締日直前に、バイヤー側がモノをいくつか返品します。すると、サプライヤー側は返品前の認識でいますが、バイヤー側は返品後の認識でいます。異なる事実に基づいて金額計算していますので、認識相違が発生し、バイヤー、サプライヤーの担当者はその調整作業に時間が取られます。
このように受発注プロセスにおいては、バイヤーとサプライヤーは互いの目的に沿って目の前の事務を処理しますが、友達ではないので必ずしも協力し合うのではありません。その結果、認識相違が発生してしまいます。
Eメールじゃだめですか？
バイヤーとサプライヤーの認識相違を埋めるにはどのような手段が有効でしょうか？今でもFAXは健在ですが、一旦FAXは忘れましょう。はい、忘れましょう。FAXの”高度化”を考えると思い付くのは、「書類をPDF化してEメールで送る」ですね。これは確かに電子化はされていますが、交渉過程を含め、担当者レベルでは毎日100件のメールが入り乱れ、受信箱を埋め尽くし、何が最新かを把握するだけで一日が終わってしまいます。一番の問題は、その人が最新だと思っているファイルは、別の人にとって必ずしも最新ではない点です。
いくらサプライヤー側の担当者が、最新のメールに添付された発注書を参照していても、バイヤーが「それは最新ではない」と言えば、それはやはり最新ではないのです（悲しいことに）。さらに、PDF化されている情報を受け取った人は、社内システムへのマニュアル転記が必要となります。PDFファイルを送り合っても受発注は完結しません。PDFが電子的であるとは言え、これでは業務改善には繋がりません。書類を電子化して送るのが目的はなく、業務効率を上げたいのです。
EDIじゃダメですか？
Eメール（＋PDF添付）だと転記が必要となりますし、相手方との認識共有が必ずしも一致しません。受発注で情報を一元化するなら、やはりEDIですね！これについて見ていきましょう。
そもそもEDIとは、”Electronic Data Interchange”の略で、日本語だと「電子的データ交換」となります。EDIの目的は、受発注情報を電子的に取引相手に早く届けることで、人件費や印紙代等を削減し、業務改善を図る、です。PDFファイルを送りつけるより良さげです。
EDIにはいくつか種類がありますが、これまで製造業や流通業を中心に利用されてきたものは、商流EDIと呼ばれます。最近では、これに金流（決済情報/入出金情報）を加えた金融EDIを目指す取組みもあります。具体的には全銀が推進する全銀ZEDIは、金融EDIの具体的な実装になります。目的は、サプライヤー側の売掛金の消込業務の効率化です（ZEDIはバイヤー側のインセンティブに関する問題を抱えていますがここでは割愛）。
その他、実は国際送金のSWIFTもEDIの一つとして位置付けられます。確かに金融機関同士の電子的データ交換ですね。
EDIという技術の限界
そもそもEDIは1970年代からある、恐ろしく古い技術であり、個別VAN型EDIの場合、専用ソフトのインストールが必要です。インターネットの時代（2000年頃）になってからはWeb型EDIも登場し、インターネット環境さえあればブラウザだけで使用することが出来ますが、ブラウザからのデータのダウンロード等が逆に人の手が必要となります（以降Web型EDIを前提に説明）。EDIでは受け取ったメッセージをどう処理するかは、完全に相手任せでありスコープ外です。相手方の処理方法次第では、結局のところ受発注情報の認識は一致しません。またEDIを使用すると、サプライヤーは発注先ごとにポータル画面を使い分ける必要があり、新たな煩雑化を引き起こします。
EDIによる電子化は、EDIの提供者（多くの場合、バイヤー側）の情報一元管理には貢献しますが、必ずしも受発注プロセス全体の最適に繋がる訳ではなさそうです。
最大の課題は、EDIを企業間で構築する場合、基盤を統一して拠点間を個別に接続する必要がある点です。取引相手の片方だけが対応していても意味がないのです。そのため、例えばグローバルSCMのような多：多の取引環境が前提となる場面では一気に導入障壁が高くなります（いや無理です）。そして、EDI接続にかかるコストを負担できない中小企業はEDIのメリットを受けられません。
でも頑張って高度化すれば…
EDIは電子化の良さである「早さ」を活用した取組みであり、電子化の別の側面である「書き換えられる」「コピーできる」という特徴のデメリットが出ないよう、各社の社内システムと連携した制御が必要となります。つまり、一つの取引に対し、複数の異なる事実を示すデータが存在しないように、社内で情報の一元管理を組む必要があるのです。しかし、EDI活用部分以外は各社任せであり、必ずしも情報が確実に同期されるとは限りません。ブロックチェーン的に言うと、相手方のデータベースに入っている内容は信頼出来ません。社内の情報統合はSTP化（Straight-Through Processing）の一環して行われます。しかし、残念ながらSTP化により実現する社内のゴールデンレコードは、取引相手にとっても同様に「真実」ではありません。当たり前ですが、自社の社内システムにどう記帳されているかは、取引の相手方にとっては何の意味もありません。
さらに、仮にデータベースの情報が完全同期出来たとしても、ブロックチェーン的に言えば、そこで保存されるデータにはトレーサビリティーがありません。対改ざん性のないデーターベースをお互いに持ち合っているので、普通に後から覆せてしまえます。
でもEDIの理想は素晴らしい
EDIは受発注プロセスを効率化し、企業間のコラボレーションを促進しようとしている点で素晴らしい取組みであり、その”高度化”の方向性は歴史の延長として自然の流れです。しかし、ここで立ち止まって考えて欲しいのは、近年ブロックチェーンという技術が登場しており、既に受発注プロセスの分野で実用化されているという事実です。EDIはインターネットの登場と共にWebEDIとして進化しました。今まさに「ブロックチェーンベースEDI」として、さらなる進化を遂げる時が来ています。さらなる進化はスマートコントラクトによる完全自動化の世界を実現させます。
ブロックチェーンでEDIを高度化する
EDIは既に取引のある相手方と確定情報としての受発注データ等を電子的に投げ合うことで、業務スピードを高める取組みである一方、ブロックチェーンは信頼しない取引相手、つまりモチベーションの異なる相手同士が取引に合意し、互いに同じ内容をそれぞれ記帳することで、認識相違を失くそうとする取組みです（エンタープライズ・ブロックチェーンの場合）。このように両者は目的と前提とする場面が異なりますので、「EDI vs ブロックチェーン」という構図で見る必要はありません。要はバイヤーとサプライヤーがお互いにメリットのある仕組みが構築できれば良いですね。ここからはブロックチェーンが実現する受発注プロセスの世界を思い描いていきましょう。
①受発注前後のトレーサビリティー
ブロックチェーンベースEDIを検討する場合、受発注前におけるバイヤー、サプライヤー間の交渉プロセスも含めてワークフローを設計します。受発注前段階から相手方と同一基盤上で、例えば見積データ等のやり取りがスムーズに行えます。ここからシームレスに受発注の確定までをサポートします。対改ざん性を持ち合わせた交渉プロセスの記録は担当者レベルでは非常に重要です。受発注の金額だけでなく、どのような経緯でそれに至ったかは、サプライヤー、バイヤー間の関係において、ノウハウとして引き継がれる情報です。多くの場合、メールのやり取りの中にこの重要な情報が埋もれてしまい、「担当者じゃないと分からない」状況が生まれています。受発注前後の情報を確実に残していくことは現場担当者にとってはプライスレスです。
②社内システムのように使える
ブロックチェーンベースEDIを導入する場合、バイヤー、サプライヤーはそれぞれ自社ノードを立て、共通のアプリケーションをインストールして使います。このアプリケーションを通じて相手方と取引が出来るようになり、個社毎の接続は必要ありません。これだけで多：多のネットワークに参加出来るのです。それでもあくまで社内システムです。社外のEDIシステムを共通利用する感覚ではありません。Cordaであれば社内のリレーショナル・データベースに受発注情報がひたすら蓄積されていきます。ポータルサイトからCSVをダウンロードして、社内システムに食わせるなんてことは必要ありません。自由にSQLでデータを抜き出して、自由に別のデータベースと連携させてSTPして下さい。
既にEDIで受発注ネットワークを構築済ですと、導入効果（置き換え効果）は未知数ですが、これから受発注を改善するんだ！という段階にいる企業であれば、間違いなく低コストでの”EDI”導入のメリットを享受出来るでしょう。
③証票類のリアルタイム監査
ブロックチェーンベースの受発注データには対改ざん性があり、論理的には「紙」の証票類と同じ意味を持ちます。つまり原本性を有します。面白いのは、このデータには原本性があるにも関わらず「紙」ではないので、リアルタイムにインターネットを通じて、第三者と安全に共有することが出来ます。例えば監査主体側にオブザーバーノードと呼ばれる「読み取り専用機」を置いて、日中の生取引をリアルタイムに共有してしまうなんてことも可能です（したくないですが…）。この仕組みがあれば、証票監査時のデータ準備、書類の整理等の作業は完全に不要となります。
本当に普通のEDIじゃダメですか？
ここまでブロックチェーンベースEDIのメリットを見てきましたが、おそらく「普通のEDIでもやはり出来るのでは？」と思われた方もいるかもしれません。もちろん、普通のEDIである程度は実現出来ます。ブロックチェーンは従来のEDIの目的に異なる実装方法を提示しているだけのように感じます。しかし、バイヤーはEDIを通じて受信した請求書データを基に、自動支払する訳にはいきません。請求書の金額が本当に正しいかを確認する必要があるからです。この点、ブロックチェーンベースEDIは、スマートコントラクトによる次元の異なる完全自動化を目指しています。ブロックチェーンベースEDIをもう一歩深堀する前に、何度も出てきているキーワード、「スマートコントラクト」について改めて復習しましょう。
スマートコントラクトってよく聞くけど…
スマートコントラクトは、契約書を電子化だけのように見えますが、EDIの文脈で考えると、「人の手を一切介さずに自動発注・受注をしてしまう」くらいのことが出来ます。ここで押さえておきたいのは、スマートコントラクトで契約を自動執行するためには、与えるインプットデータについて、取引当事者のAさんとBさんは１００％確実に同じ認識に立つ必要がある点です。なぜでしょうか。
スマートコントラクトはDeterministic（決定性がある）と呼ばれています（もしくはDeterministicに作りこむ必要があります）。これは、「同じインプットをスマートコントラクトに与えれば、必ず同じアウトプットが出る」という特徴を意味しています。
例えば、Xを与えれば必ず100万円を出すスマートコントラクトがあるとします。面白いところは、このスマートコントラクトに”誰が”Xを与えても、必ずアウトプットは100万円となる点です。
もちろん、中央管理者でも良いですし、Aさんでも、Bさんでも構いません。よくスマートコントラクトを説明するとき、自動販売機の例が取り上げられます。誰がお金を入れても、同じ商品が出てきますよね？つまり、スマートコントラクトの世界では、”誰が”はもはや問題ではなくなるのです。同じインプットを与えれば、誰でも期待通りの結果が出せる、ということはこの仕組みを誰か信頼出来る中央管理者が提供しなくとも、AさんでもBさんでも良い、ということになります。同じインプットさえ与えられれば、プレイヤーは別々にスマートコントラクトを実行しても良いのです。
だから、AさんとBさんは、お互いが持っているデータベースの内容について、認識相違を失くしたいのです。認識相違さえなければ、サプライヤーは受信した請求書データを基に、自動支払が出来そうです。
実は今は分散型の世界
よく勘違いされていますが、今エンタープライズの世界では、多くの場合、データはどこか中央に集約されているのではなく、分散しています。よく「中央集権型ではだめですか？」と聞かれますが、今現在データが分散しているのに、なぜ中央に集めたいのでしょう。わざわざ頑張ってデータを中央に集めず、今の分散型の欠点を克服すれば良いですね。今の欠点は、企業が分散して持っているデータの認識が合っていない状況です。
ブロックチェーンを使い、分散型でデータを持ちつつも、確実にインプットデータを同期して、かつ後から変更出来ないようにする。そしてスマートコントラクトにこのインプットを与える。そうすることで、AさんとBさんは認識相違なく契約を自動執行し、アウトプットとなる結果についても認識相違なく合意出来るようになります。
この仕組みの意味するところは、ただの自動化に留まりません。ブロックチェーンに刻まれたアウトプットデータは対改ざん性を備えており、一度記録された後に覆されることはありません。この特徴があるおかげで、このデータは外部の金融機関にとっても信頼出来る情報として扱えるようになります。つまり、このデータの信頼に基づき、ファイナンスを受けられる仕組みが構築出来るのです。
受発注プロセスに見るブロックチェーンの可能性
さて、これまでの話を纏めると、下記のようなブロックチェーンベースEDIの世界を創造できます。
まず、バイヤーとサプライヤーは、ブロックチェーンベースEDIを通じて完全に認識の一致した発注データを持ち合います。認識相違がないため、サプライヤー側は安心してモノを自動出荷できます。その後、同じくブロックチェーンベースのサプライチェーンマネジメント・システムから、モノが納品される情報（トレーサビリティー情報）が上がってきます。発注データと納品データが、請求書自動発行の契機となります。発注データをインプットとして請求書が発行されますので、サプライヤーは間違えることはありません。とは言えバイヤーは無意識に支払う訳にはいきませんので、発注・納品・請求データの3点セットを自動マッチングさせ、整合性を確認します。問題がなければ、バイヤーは期日まで待機し、支払を自動執行します。請求データはサプライヤーが勝手に生成したものではなく、バイヤー側と合意して保存された対改ざん性のある情報です。このデータを銀行側にそのまま共有してしまえば、サプライヤーは支払期日まで待たなくとも、銀行からファイナンスを受けることも可能です。
これらの動きは全て事前にプログラムされておりますので、人手を介さずルールベースで自動実行されます。
電子化から”デジタル化”へ
受発注プロセスが完全に自動化される世界は、もはや単なる電子化とは呼べません。次元の異なる業務改善であり、もう漢字では表現出来ず、カタカナで”デジタル化”と呼ぶしかありません。その基盤に保存されるデータは、ブロックチェーンにより圧倒的な信頼性を得ます。そして、データの信頼性がこのレベルまでくると、出来れば考えたくないユースケース「納税」までも視野に入ります。もう概念としてはここまで来ています。後は”誰が”やるかだけです。
