ブロックチェーン業界で活躍するプレイヤーにスポットライトを当てる特別インタビュー、今回は日本IBMのブロックチェーンテクニカルリーダー・IBM Cloud Meisterの紫関昭光氏です。
ここからインタビュー後編に入ります。
インタビュー:後編
Hyperledger Fabricを使ったプロジェクトにおいて気をつけること
Hyperledger Fabricを導入する際、ビジネス面において企業はどのような点に注意すべきか教えてください。
まずプロジェクトを立ち上げるときに重要なのが、先ほど言った「ポリティクス」です。どうやって仲間を広げていくか、仲間に信用してもらえるか、ここに尽きます。ブロックチェーンはなんとなくおもしろそうだから、でスタートしてはいけません。一見ネットワークができているようでも、ある一つの企業のガバナンスが非常に強く、そこにDBとWebサーバを置けば十分解決できるようなケースもあります。
企業が単独でやるよりも、チームプレーにした方が良くなるというのをまず認識し、開発に入る前にしっかりと見通しを立て、それを示しながらプレイヤーを巻き込んでいくことが大事です。例えば「TradeLens」では、いつ通関して船に載っていつ相手に届くかというのがリアルタイムに予測でき、追跡することが可能です。なので「このネットワークに入れば、こんなに便利になるので皆さん入ってください」という形で巻き込んでいます。
プロジェクトをスタートするときには最終形を描きますが、いきなりそこまではいきません。だから最終形を目指しつつも、一番はじめはグループ企業だけで、あるいは一つの企業内の二つのディビジョンでスタートします。それがいわゆる実証実験です。
Hyperledger Fabricが初めて出たころは「テクノロジー」を実証するものでした。でもテクノロジー面についてはもう十分実証されているので、それは無意味です。では何のための実証実験かというと、ビジネスネットワークに新しい人を招き入れるためのプロスペクタスをつくるためです。このユースケースにはこのテクノロジーでこういうように対応できますよ、と示すのが実証実験です。こうして仲間を増やしていくのです。
では今度はビジネス面ではなく設計(テクノロジー)という面で、気をつけるべきポイントはありますか。
ブロックチェーンはビジネスネットワークの参加者が能動的に出入りするので、それに簡単に対応できるかが重要です。Org(組織)やピアの追加などが簡単にできることや、チェーンコードのバージョンアップができることが大事です。
また、LOBも運用部門に注目すべきです。例えば今のビジネスネットワークにはどの組織が入っているか、どういうピアが立っているか、スマートコントラクトのバージョンはどうなのか、定義体を承認しているのは誰なのか、などといったことは、LOBにとっても重要です。なので、これらがパッと見てわかるようなコンソールがあることも大事な要素の一つになります。
最後に開発についてお話しします。結合テストを始めてからチェーンコードにバグがあると非常に苦労します。だから、チェーンコードは初めにクリーンな状態をつくっておくべきです。チェーンコードを実装する際は、単体テストの環境や、Postmanのようなテストツールがあると便利です。Webの世界で言うREST APIをつくるようなものですね。
我々がお勧めしているのは、皆さんが使い慣れていると思われるVisual Studio Codeに、IBM Blockchain Platformの拡張機能を導入するやり方です。この拡張機能を入れることで、チェーンコードにlint(コードチェックを行うプログラム)のような文法チェックがなされ、Mac上に小さなHyperledger Fabricの実行環境を構築することが可能になります。これは、Hyperledger Composerが廃止になった現状で、開発環境を提供する一つのソリューションになります。
Visual Studio Codeに、IBM Blockchain Platformの拡張機能をインストールするだけで簡単な環境が立ち上がるのです。
開発したチェーンコードはパッケージしてからそこにデプロイします。チェーンコードをキックするジャンプ台も用意されているので、これでチェーンコードがちゃんと動いているかがわかります。その後チェーンコードパッケージをクラウドやオンプレミスなどにデプロイします。これで、開発のきれいな流れができます。
なぜブロックチェーンなのかを考える
企業がプロジェクトを提案するにあたり、なぜブロックチェーンなのか(Why Blockchain)という説明は必須になりますよね。ここはどのように説明されてきましたか?
先にも述べたように、単独企業で解くよりも複数の企業で解いたほうがいい問題がたくさんあるということ、これが出発点です。複数の企業というのが、今後は必ずしも固い信頼で結ばれた関係だけではなくなっていきます。だからブロックチェーンによって信頼をつくっていこう、という言い方をしています。
また、IBMで評判のいい研修プログラムの一つに、ユースケース ワークショップというものがあります。問題の特性とブロックチェーンのテクノロジー特性がマッチしているか、10個の指標を提示し、ブロックチェーンにマッチした問題を2週間で考えて発表してもらいます。場合によっては、ここはブロックチェーンでないもので解いた方が合っているよね、というような議論をします。
PoCからサービス化へと移る際、例えば上層部を説得する場合はどのような判断軸で説明すると効果的ですか?
先ほど言った10の指標の中に、「儲かる」というのがあります。これを数値で示すことが非常に重要です。もう一つは、ビジネスネットワークの中において、ある程度主導的な立場がとれるかということです。
他には、ブロックチェーンは透明性があり、不正を排除できるのでCSR(企業の社会的責任)に効果的だという説明です。しかし企業の立場からすると、やはり「儲かる」ということを前面に押し出した上で、加えてCSRという価値もあります、と説明しなければエグゼクティブは投資しにくいのです。まさにROIを数字で表すということですね。
「儲かる」というのは、レベニューが増える、コストが下がる、総資産が圧縮できるといったことです。トランザクションをチェーンコードで自動処理できるようになると、コストが下がります。またサプライチェーンの場合だと見通しが良くなるので、中間在庫を持たなくて済む、つまり総資産が圧縮されます。そしてプラットフォームが大きくなってくると人が集まり、ネットワーク効果でレベニューがさらに増えるということです。
なるほど、それが「儲かる」ということなんですね。
はい。ただこれはブロックチェーンに限ったことではなく、DX(デジタルトランスフォーメーション)が目指していること、そのものなんです。ブロックチェーンが提供するさまざまなメリット(たとえば取引の自動化、トレーサビリティ、IDの管理など)はDXがやろうとしていることであって、ブロックチェーンの専売特許ではありません。
ではなぜブロックチェーンなのかというと、最初のところに戻って、単独企業でやるのかチームプレーでやるのかの違いになります。単独でDXをやるのであればそれは従来技術でやってください、チームプレーでやるならブロックチェーンを使ってください、という分かれ目があります。
再三ですが、「TradeLens」がいい例です。これは、例えばマースクといった船会社のレベニューが上がるというよりは、海運業界全体のパイが大きくなると考えています。まさにガバナンスが異なる組織が連携をしてDXに取り組んでいるという好例です。
Hyperledger Fabricが提供するもの
分散型ネットワークを構築・運用するにはコストがかかります。そこに対してHyperledger Fabricはどういったものを提供しているのでしょうか?
たしかにゼロから作ろうとすると非常にコストがかかります。そこがオープンソースになっているのがHyperledger Fabricのポイントです。
ときどき「ブロックチェーンだからものすごくセキュア」だとか「改ざんができない」と言う人がいます。改ざんできないというのは半分正しいのですが、ブロックチェーンだからセキュアだ、というのは違うと思います。ポイントは「データを共有しているにもかかわらずセキュア」というところです。データを単独で管理するのがある意味一番セキュアかもしれませんが、それだと管理している単体が好き勝手できるから、皆で共有し管理する。もし改ざんしようものなら犯人がすぐわかる、という仕組みが分散型にとって非常に重要です。これをゼロから作るのは大変なので、こういったフレームワークをHyperledger Fabricで提供しています。
改ざんが難しいという点については、ブロックチェーン(トランザクションのログをブロックの連鎖として記録しているファイル部分)の上ではその通りですが、StateDB (トランザクションの処理結果を key-value のペアで記録しているデータベース部分)の方は書き換えできる余地があります。ただ、自身のStateDBのみを書き換えても意味がありません。なぜかというと、他のStateDBは正しい値を持っているので、書き換えたものは排除されます。これが分散テクノロジーのいいところです。
実際にサービス化するにあたっては、GDPRの観点からも個人データブロックチェーンにを載せるわけにはいかないので、柔軟性を残しつつもセキュアであるべき部分を強固に作り、耐改ざん性を持つことが必要になると思います。
そうですね。個人データや巨大なドキュメントなど、そもそもブロックチェーンに載せるのが適当でないものもあります。こういった場合、テクノロジーの特徴を考えなければなりません。
結局、ブロックチェーン特にHyperledger Fabricが提供しているのは、「Trust(信頼)」なんです。かならずしも原本保証を直接おこなう必要はありません。たとえば大きなデータやプライバシーデータは、外のDB(オフチェーン)に置いておいて、そのハッシュだけをブロックチェーンに入れます。他の人たちはハッシュしか見えず、プライバシーデータは見えません。もし後に係争になったときには、ハッシュを比べれば改ざんが検知できます。
したがって、オフチェーンのデータに関してもトラストを保証できるような仕組みになっているというのが、Hyperledger Fabricのユースケースを考える上では大事だと思います。
ありがとうございました!