--具体的には、どのように検証をしたのでしょうか。
もともと業務を回している本番環境ですので、SQLサーバのデータはそのまま残っています。それをmijinに取り込んで、パッケージソフト上の残高とmijin上の残高が同じかどうかを確認するということになります。パッケージソフトのトランザクション部分をログとしてブロックチェーンに入れているイメージですね。その状況について、1日1回来るメールで確認するという形です。
当時、ミャンマーでは大きな地震が合ったのですが、影響が大きかったのはバガンでしたので、BC Financeのあるヤンゴンにはほとんど影響はありませんでした。地震の際にもちゃんとメールが届いていました。
--今回検証したシステムで、今後どのようなことをしていくのでしょうか。
今回、BC Financeはブロックチェーンのシステムを追加したわけですが、業務としてはまったく変わっていないので、Jeremy氏も今後構築したブロックチェーンのシステムを使って何かをしていくということは、まだ考えていないと思います。ただ、パッケージソフトをすべてブロックチェーンに置き換えることはできないという認識は持っていると思います。
ブロックチェーンが今の金融システムすべてを置き換えるということはできなくて、あくまでもトランザクションの部分だけを改ざん不可能な形で記録していくことができるだけです。ですから、既存の周辺システムは絶対に残ります。残高やアカウントの管理は、ブロックチェーンの外でやっているわけで、その部分は必要です。
--ミドルウェアとブロックチェーンをつなげる作業の難易度は。
業務とプログラムを理解しているエンジニアがいれば、それほど難しいことではありません。ブロックチェーンは、「誰がいくら渡す」というデータだけですので、それを既存の業務から落とし込めばいいだけです。一方、金融システムやマイクロファイナンスをやっている銀行には、通常ブロックチェーンの専門家はいません。ミドルウェアとともにノンプログラミングの構築、いわゆる“グラフィカルなプログラミング”ができたからだと思います。
それに今回は、ミャンマー最大とはいえマイクロファイナンスの事業であり、データも数十万単位と大がかりなシステムではありませんでした。mijinはテックビューロに提供してもらったこともあり、インフォテリアではフローを提供して接続先の設定を担った程度で、あとは基本的にBC Financeに任せきりでした。ただ、一度もシステムが落ちることもなく、mijinが原因で不具合が起きたこともありませんでした。
実証実験の概要、日付は第1回実証時（インフォテリア提供）
