リクルートテクノロジーズの社内ラボで行っている、主に非金融領域に対するブロックチェーンの活用に向けたR&Dを紹介する本連載。初回は、同ラボにおけるブロックチェーンに対する見方から、その検証の全体像を紹介します。
リクルートテクノロジーズの社内ラボ、ATL(Advanced Technology Lab)で行っている、主に非金融領域に対するブロックチェーンの活用に向けたR&Dを紹介する本連載「ブロックチェーンの検証現場で何が起きているのか」。
初回は、同ラボにおけるブロックチェーンに対する見方から、その検証の全体像を紹介します。
なお、本連載ではブロックチェーンの基礎的な仕組みなどは深く解説しない予定です。必要に応じて以下などの記事を参考にしてください。
昨今、ブロックチェーンは特に多くの注目を集めている技術の1つです。その背景には、ビットコインがブロックチェーンをベースに、独自のネットワークを安定的かつ自律的に維持していることがあります。そしてATLでは、ここには2つの注目すべきポイントがあると考えています。「特権的な中央機関がない状態で、改ざんなどの不正行為を排除し取引データが全てきちんと記録できていること」が1つ、もう1つは、「正常な動作を自律的に維持できていること」です。
特にリクルートは、例えば転職関連サービスの領域や飲食店集客の領域でB2Cプラットフォームを提供している点から、中央機関としての機能を提供することを1つのなりわいとしていると考えることができます。これに対し、2点目のような「自律的な、中央機関がない形でそれら仕組みが継続的に使われ得る」ことは、技術ドリブンによる大きな変化であり、これは脅威とも、新たなビジネスを作り上げるチャンスとも捉えられます。
これを推し進め、「1つの営利企業が多くの個人情報を保持、莫大な利益を得ることに対する防衛に使おう」というムーブメントもあります(主に個人情報の扱いに敏感な欧州を中心に)。もちろん、このような世界へ全体が一足飛びに移行することはなかなか考えづらいですが、この観点での動きがある可能性は否定できません。
また技術視点では、そのようなベクトル、環境の下で多くのスタートアップが興隆し、多くの付随する技術革新が起こっている現状を踏まえると、この技術をその時々の背景と共に十分に理解し、ウォッチしていく必要があると考えています。
この自律的な、中央機関がない世界でのビジネスについて考えようとした場合、現時点ではそのような例はビットコインくらいしかなく、参考となる先行事例はほぼありません。このため、ATLは本業たる技術視点から、「現時点の技術要素では実際に何ができて何ができないのか」をまず実践的に整理することが必要だと感じています。
この整理を通じて、「実際にそのようなビジネスができるかどうかはさておき、その周りで生まれている周辺技術を活用するチャンスも出てくるのでは」と考えています。また、実際に検証を行うことを通じて、
目的のサービスが設計、開発できるか、という観点での知見を得られるとも考えています。あまりに未完成な技術はデファクトになる可能性が低い他、仮に実現できても膨大な時間やパワーが必要となるものは、企業がビジネスで実際に活用していくことは難しいのが一般的です。従ってATLには、たとえ新しい技術のビジネス活用がかなわずとも、それを通じてビジネスに役立つさまざまな知見は確実に獲得していく狙いがあります。
まずATLは、ブロックチェーンの一番理解しやすいポイントである「改ざんなく情報を記録していける」機能と、自律的な仕組みのうち、「分散的にデータが保全される」機能にフォーカスし、ユースケースを幾つか考えました。
その中から、現在展開中のビジネスとの近さ、既存ノウハウを適用できる可能性の高さを基準に、「(転職市場などで必要となる)学歴や職歴の確認系業務を簡略化する」というユースケースを選択しました。これに「履歴書公証データベース」という仮称を付け、複数の技術要素を使って何度か設計&開発することを通じ、ブロックチェーン技術そのものの検証をしています。
なおプロックチェーンのポイントである「分散的にデータが保全される」の、「分散的に」の部分ですが、これは技術的に「冗長性を持たせるためなどの分散」だけではなく、その「システムのオーナーが分散している」(例えば、異なる思惑を持つ複数の企業が、1つのシステムを維持するためにサーバを提供している)という意味での「分散」も意味しています。
ブロックチェーンを見ていく上では、この後者の視点がとても重要です。
なぜなら、後者の分散が実現されている状態であれば、1つの企業がサーバなどリソースの提供をやめたとしてもサービスが継続されるからです。
では、その履歴書公証データベースとは、どのような機能を持つものなのでしょうか。
まずシステムを利用する人は、転職者など「自らの履歴、経歴情報を誰かに見せたい人」(A)と、企業の人事部担当者など「その情報を見る人」(B)、大学の事務局など「履歴、経歴情報を正しいと認証する人」(C)、の3種類を想定します。ここで、(A)さんは自ら称するだけではなく、その発行元である(C)さんが「その事実を正しいものである」と宣言していること、そしてその宣言は詐称されないことが重要です。
これを前提に、(A)さんが職歴などを登録、それを(C)さんが正しいものであると認証、その後、(A)さんが(B)さんに対して期間を限定して閲覧できるようにするという全体のフローを考えます。
なお、今回の設計&開発は技術の検証のためのステップであり、実際にサービスとして使うわけではないので、例えば「申請された情報が間違っていたときに(C)さんが一部修正できるようにする」などの細かなフローは考慮外とし、基本的なフローについて設計&開発を行います。
Copyright © ITmedia, Inc. All Rights Reserved.