続・Why Blockchain 証券ポストトレードにブロックチェーンを適用する意味
Fintertechの相原（@Kaz_Aihara）です。
前回投稿にてDLT(※)約定照合プロジェクトのワーキングペーパーの解説を行ったところ、ありがたいことに大変多くの反響と、続編へのご要望をいただきました。そこで、今回はプロジェクト・フェーズ2のワーキングペーパーについての解説と、プロジェクトでの議論を通じて考えてきた内容について述べていきます。
※DLT・・・Distributed Ledger Technologyの略。分散型台帳技術のこと。厳密にはブロックチェーンと定義が異なりますが、本稿では区別なく使っています。
前回記事をご覧になっていない方は、この機会に是非こちらを読んでいただければと思います。
また、コンソーシアム運営のポイントや実現したいビジョンなどについては別の記事にて川浪が語ってくれていますので、まだご覧になっていない方は是非こちらも合わせて読んでみてください。
ワーキングペーパーについて
今回ご紹介するワーキングペーパーはこちら（↓）です。
JPXワーキングペーパーVol.22（追加分）「約定照合業務におけるDLT適用検討 フェーズ2」（2019/2/19）
プロジェクトのフェーズ2として、2018年9月から12月まで日本取引所グループ（JPX）さん全面サポートのもと業界32社で議論を行った内容をまとめたものです。もしお時間があれば、是非ワーキングペーパー本体にも目を通していただけるととても嬉しいです。
プロジェクト概要（フェーズ1とフェーズ2の違い）
フェーズ１の議論を簡単におさらいすると以下の通りです。
・証券ポストトレードにおけるセルサイド(おもに証券会社)が集まって議論
・現状、規格やシステムが統一されていないため特にセルサイドにとっては負担大
・非競争領域においてはDLTの活用によって相互扶助での改善手段が獲得できる可能性
・構想実現にはバイサイドやサービスプロバイダ（以降、SP）の賛同、参画も必要
このワーキングペーパーの公開後、業界全体の機運醸成、巻き込みのために、フェーズ１参加の各メンバーがセミナー講演や勉強会、意見交換会などをそれぞれ行っていきました。その努力の甲斐もあり、セルサイドだけでなく、資産運用や信託を行うバイサイド各社や、証券ポストトレード領域でサービス提供を行うSP各社に多くの参加表明をいただき、フェーズ２の開始にこぎつけることができました。
フェーズ２においては、以下の観点、方針で議論を行っていきました。
・業界各社における立場ごとの課題の確認と各課題の共通点の洗い出し
・課題解決に向けて必要となる業界標準（ルール、規格等）の策定
・業界標準のDLTでの実装に向けた具体的な要求、要件の洗い出し
・業務視点を重視しDLTソフトウェアの選定や実機を使った検証は行わない
※実機検証を行わないことに決めた理由については後述します
現状と課題の整理
プロジェクトの前半は、業界各社における課題の確認とそれらの共通点の洗い出しを行いました。議論を通じて、それぞれの立場では「相手が直してくれればすぐに解決するのに」と思っていた課題であっても、実はもっと深い部分に原因があるということが浮き彫りになっていきました。
議論にて挙がった課題と、解決策について検討した結果は下表の通りです。
フェーズ１でも触れられていましたが、まずは業界標準を策定することが必要ということがあらためて確認されました。そしてその実装においてDLTが適合していそうだ、ということは前回投稿にてご説明の通りです。この整理を経て、プロジェクトの中盤では各項目についての業界標準のあるべき姿についてを議論し、その標準の実装方式について具体的な検討を進めていきました。
DLT適用による課題の解決（DLT適用構想）
データ共有へのDLT活用検討
ここまでは業務課題と業界標準に関する議論でしたが、ここからは課題解決のために技術をどのように適用していくか、についての議論結果を説明していきます。まずフェーズ１の検討結果に、ここまでの議論をプラスしてアップデートしたものが下図になります。
SPシステム間での標準化データ連携を可能とするDLT基盤を表しています。既存のSPシステムとDLT間をETL※等で接続する想定です。また、約定情報以外の情報連携への活用（ex. 新規ファンド口座情報）や、各種レポート作成、BCPとしての役割にも期待できる構成となっています。
※ ETL・・・Extract(抽出)/Transform(変換)/Load(読み込み)の略。異なる形式のデータを持つシステム間の連携に用いられる方式、ツールを指す。
プロセス共有へのDLT活用検討
ここまではデータ項目の標準化と台帳共有にて実現できることでしたが、もう一歩踏み込んで、プロセス標準化とスマートコントラクト実装についての議論も業務プロセスごとに行いました。かなり難航したものの、実現可能性と期待効果の2軸にて対応施策を分類し、それら施策の実現のために以下の構成が考案されました。
共通コントラクト
標準化可能なものや、各社がおもに採用しているベストプラクティスを実装。DLT基盤運営側からの提供を想定。
個別コントラクト
標準化が難しいバイサイド固有の一部ロジックやSPの独自サービスを実装。セルサイドやSPによるサービスでの提供を想定。個別コントラクトと合わせて個別台帳の登録も可能とする。
こうした議論をまとめたDLT適用構想のフェーズ２最終形が下図となります。（説明簡素化のためワーキングペーパーより一部改変）
PJ推進における運営方針、工夫
せっかくなので、議論の中身だけでなくPJ推進そのものについても少し触れておきたいと思います。
まず上述の通り、DLTプロジェクトなのに実機検証を行わない、というところは特徴的だったかなと思います。そのような進め方を選んだおもな理由は以下2点です。
・既存業務へのDLT適用に向けては実機検証よりも業務要求、要件整理の優先度の方が高いと判断した点
・DLTの進化速度を考慮すると、詳細設計への踏み込みは陳腐化により無駄になる可能性が高いと判断した点
前者について、DLTはフロントサイドの技術ではないので、UIの視点では、良くて現状維持、たいがいはレベルダウンと見られてしまいます。（フェーズ１の実機検証にてそのことを痛感しました。。）
せっかく実務者を集めて議論するのであれば、他に時間を使う方が有益だろうと考え、このような選択としました。
各検討会での議論のファシリテーションについても、毎回かなりの工夫をしました。普段は顧客とサービス提供者、という関係の方々も多かったため、様々なワークショップ技法（たとえば下図）を活用し、円滑な議論の促進に努めました。コンソーシアム運営においてはこういったコンサルティングやファシリテーションも重要になってくるのですが、そのあたりを得意とする枝廣を参画させることができたのは大きかったです。（本記事で使っているパワポ資料もかなりの部分を彼が作っているので、お礼も兼ねて名前を出しておきます 笑）
なお、プロジェクト推進過程の詳細については、ありがたいことにJPX近藤さんが別のワーキングペーパーのなかで触れてくださっているのでこちらも是非ご一読ください！
JPXワーキングペーパーVol.26「証券業界におけるブロックチェーンの活用に向けた検討とオープンイノベーションの推進」
DLT基盤の適用による短～中長期の期待効果
本プロジェクトにて各社が目先の利害関係を越えて活発な議論を行えたのは、業界各社が「非競争領域業務を共通化して顧客サービスを向上させる」という高い視座での共通認識を持つことができていたからだと思います。ここまでは約定照合業務を対象に議論をしてきましたが、議論の結果まとめた要求、要件は汎用的なものであり、参加者やデータ、機能を拡大させることで、更なる利便性向上が期待できると考えています。具体的に参加者から候補として挙がったのは、証券ポストトレードにおける後続業務である決済領域や、データビジネス向け基盤、当局へのレポーティング、投信販売会社との情報連携などです（下図参照）。
まずは小さな領域からでも業務適用し時計の針を進めることが、こうした将来像実現やその他のDLT適用プロジェクト促進のためにも重要と考えていますので、チーム一同引き続き尽力をしていく所存です！