■ ブロックチェーン技術は、本当にシステム開発コストの削減につながるか？
同日の日本経済新聞に、金融系のシステム開発の話題が別々に掲載されていたので、それぞれを解説の後、「で、まとめるとどういうことなの？」というお話をしたいと思います。
2016/2/16付 ｜日本経済新聞｜朝刊 日本取引所、低コストで証券決済 中央サーバー不要に フィンテック活用
「日本取引所グループは金融とＩＴ（情報技術）を融合した「フィンテック」を活用し、証券決済などを低コストで行うインフラづくりに取り組む。日本ＩＢＭと連携した実証実験を３月にも始め、三菱ＵＦＪフィナンシャル・グループも参画を検討している。まずは未公開株など流通量の少ない金融商品での活用法を探る。」
（注）日本経済新聞の記事へ直接リンクを貼ることは同社が禁じています。お手数ですが、一旦上記リンクで同社TOPページに飛んでいただき、上記リード文を検索すればお目当ての記事までたどり着くことができます
日本取引所（東京証券取引所：いわゆる東証の持ち株会社で上場企業）は、2017年3月期からの中期経営計画に、新インフラの創設を視野に入れたフィンテック研究を重点施策の一つに盛り込み、先端技術のノウハウを蓄積して、将来の事業拡大に向けた布石を打つそうです。
そのフィンテックなるものの代表選手が、「ブロックチェーン」技術を用いた低コストの取引決済システムの開発、ということになります。
（下記は、同記事添付の新決済システムのイメージ図を転載）
まず、このイメージ図の概略を同記事説明文を用いて把握してみましょう。
「今回実験するのは取引記録を管理する「ブロックチェーン」と呼ぶ技術だ。従来、取引所は「台帳」に相当する取引記録を中央サーバーで一括管理しており、多額のシステム投資が必要だった。」
つまり、中央に大きな取引データ（膨大なトランザクションデータ）をため込んでおくシステムを用意することが無いから、低コストのシステム開発になるのだ、ということらしいです。
「ブロックチェーンは利用者全体で取引記録などを複数のコンピューターで共有する。互いに認証し合うことで、記録の「正しさ」を担保する仕組みだ。
第１段階として日本取引所と日本ＩＢＭが実験環境をつくり、仮想の有価証券を売買する。清算や決済といった手続きがブロックチェーン上で正しく認証されるかを検証する。」
日本経済新聞という経済紙でありながら、過去にブロックチェーン技術を詳解した記事があり、それも本ブログで取り上げたものがあるので、再掲します（説明チャートもあってそこそこわかりやすいです）。
（参考）
⇒「フィンテック（FinTech）の最新動向（2）ブロックチェーンを取り上げます 日本経済新聞より」
同記事では、
「今夏をメドに実験結果をまとめ、問題がなければ未公開株など取引量の少ない金融商品への活用を検討する。今のブロックチェーンの処理能力では、売買が活発な上場株の決済などへの利用は難しそうだ。」
とあり、現行取引決済システムの処理能力では、飛躍的に増えるであろうブロックチェーン技術を活用した各取引データの正当性確認の演算処理がこのままでは難しいと間接的に述べています。
「現状、未公開株の売買は証券会社などによる相対取引が中心で、値付けなどが円滑に進まない面があった。
新決済インフラを使った未公開株市場ができれば、流通量の増加を通じ、最終的に投資家の取引コスト低減につながる可能性がある。成長途上の企業にリスクマネーが行き渡りやすくする効果も期待される。」
ここの箇所は2つの伏線が張られています。
まず一つ目は、これまで取引が活発でなかった金融初品にも、適切に値付けが行われ、円滑な取引が可能になると思われている点。二つ目は、金融取引の決済管理機関の手数料ビジネスが成り立たなくなるという点。
これは、ブロックチェーン技術を取り入れると、第三者機関（カードは支払い決済におけるVISA・PayPal、融資や貸付取引等における銀行、株の売買は、証券会社を通して証券取引所で株を買い、株の保管・管理は証券保管振替機構（通称ほふり））のお墨付きをもらわないと、正当な取引と認められなかったのが様変わりするということ。当事者同士のやり取りだけで、その取引の当事者になっていなくても、決済システム自体に参加している第三者全員が当事者2間相互取引の正当性を担保できるように、当事者間の取引データを保有するため、システム参加者全員の保有データを改ざんすることが難しいことが根幹にあります。
特定の第三者機関を通さずとも取引ができるようになるから、取引自体が活発化するだろう。だから、第三者機関に支払っていた既存の取引仲介手数料が削減できるだろう、という考え方です。
前者は、取引参加者から見れば、取引コスト（実際に支払われる支出コストおよび、取引に係る事務の煩雑さや所要時間の削減効果を含む）の低減が見込め、「お得」感があるかもしれません。しかし、後者は、そもそもその取引決済システムを提供する側が、十分な仲介手数料を徴収して、システム開発コストを回収できるとは限りません。インターネット勃興期にも、インターネット事態を有料化するか無料化にするかで大変な議論が巻き起こりました。しかし、現代では、インターネットそのものの利用料は原則無料となり、回線使用料やネット上での各種サービス提供者が有償でビジネスをやっている状況。誰が頼んだわけでもなく、インターネット網は世界中に張り巡らされつつあります。
つまり、中央の大型データ管理サーバが不要になったからと言って、
① ブロックチェーンによる各取引の正当性を演算するための処理能力はどこかで開発・保持する必要がある
② そのための開発コストは、直接間接を問わず投資回収が見込めないと、誰もインフラ投資を行おうとはしない
ということなのです。フリーランチというものは世の中には存在しないのですよ！
インターネット勃興期、どことは言いませんが、インターネット使用料を取ることを前提にシステム開発した企業が倒産したことをふつふつと思い出させます。
■ システム開発の仕事が目先増えてくるのは間違いない。それで顧客がついてくるかが問題！
もうひとつ、同日掲載の記事を次に紹介します。
2016/2/16付 ｜日本経済新聞｜朝刊 マイナス金利でＩＴ各社 システム対応急ぐ ＮＴＴデータ系、資産運用管理更新 日立製作所、顧客向けに説明会
「日銀のマイナス金利政策の導入に伴い、情報技術（ＩＴ）各社が金融機関や機関投資家向けシステムの改修作業や顧客への説明に追われている。既に債券市場で国債利回りが一時マイナスとなったが、取引を管理するシステムで一部マイナスを想定していない場合があるからだ。」
この報道を見て、ちょっと違和感がぬぐえませんでした。
「これまでもコンピューターの誤作動が懸念された「2000年問題」など、大規模なシステム改修が必要になったケースはある。ただ今回は日銀の決定が突然だったため、前もって影響を調査する余裕がなかった。今のところ大きな混乱は起きていないが、各社は緊急対応を迫られている。」
（下記は、同記事添付の大規模なシステム改修が迫られたケースを転載）
マイナス金利の発表が急だったからというのは言い訳にすぎません。
（蛇足：うるう秒にまつわるウンチクはこちら）
⇒「絶対値とコンサルティング － コンサルタントに必須な素養とは？」
ここからは各社の対応。
● ＮＴＴデータグループで機関投資家向け資産運用管理システムを手がけるエックスネット
「金利を指定し債券の収益見通しを算出するシステムの変更作業に取り掛かった。一部で金利をマイナス入力できないためで、ソフトの書き直しや業務への影響の調査を進めている。生損保や信託銀行など顧客数は約160。現場担当の約100人が総出の状態だ。」
● 日本ユニシス
「銀行向けシステムのうち、マイナス金利の影響が大きい債券や為替を扱うシステムについて障害が発生する可能性を調べ、対応が必要な作業を顧客に通知した。」
● 日立製作所
「既に顧客向け説明会を実施。日本ＩＢＭでも顧客からの問い合わせが増えている。各社とも手作業も組み合わせるなどして人海戦術で対応している。」
そしてダメ押し。
「16日からは金融機関が日銀に預ける際の金利がマイナス0.1％に下がる。システムに想定外の影響が出る可能性も否定できず、各社は影響の広がり具合を慎重に見極める構えだ。」
筆者の辛口コメントは、、、
１．
数年前から、スイスやその他のEU諸国では既にマイナス金利に突入しており、業界として、日銀の発表が突然で対応できなかった、という言い訳は通じない。
２．
システム開発・設計を行うSEの業務知識が不足している。システム仕様は、SEがどれくらい深い業務知識を持っているかに左右されがち。一方で、開発依頼者側の要求仕様が甘いという声もあるが、開発を請負契約で承ったなら、委託者側の要求スペックの管理の責任も有するはず。
３．
閾値、異常値、正常値に対するセンシビリティが甘い。閾値チェックなどの品質テストの水準が低いのと、設計またはテスト仕様書などの開発ドキュメントの整理が不十分。
2000年問題も、うるう秒も、消費税の変動も十分に社会的常識があれば、想像できたはず。それでもシステム対応していない、百歩譲って仕様変更の影響範囲が分からない、というのははっきり言ってSEの名折れです。
筆者も、2000年問題の渦中で、両親を初めての海外旅行に連れて行ってあげようと旅行プランを組みましたが、「旅客機が墜落するかも」という風説の流布に抗えず、招待旅行を半年遅らせた実害を被っています。
システムを組むうえで、整数の正負の符号とか、それを基礎にした四則演算ぐらい、どういう計算結果になるか分かるはず。そこで、上記のような狼狽ぶりが新聞記事になるということは、そういう実業分析や広い視野での仕様決定の力量が無いか、知覚していても、開発工数の削減のため、依頼者側と開発受託側双方が見逃していたかのいずれかです。
まあ、目先のプロジェクトは黒字で終えて、こうした問題があれば、追加発注もらえればよい。そういうモラルハザードが現場に本当になかったのか、今一度、開発現場をよく点検した方が宜しいかと。おっと、そういう筆者も点検を受ける一人なのでした。。。(^^;)
コメント