Gaudiy Tech Blog

Gaudiyの技術、開発組織、カルチャーについてお伝えするブログです

Gaudiyの技術スタックと選定における思想

f:id:takuya510:20210917223149p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiy共同創業者の後藤(@PTeamd)です。

Gaudiyでは、ファンエコノミーの実現をめざして、ブロックチェーンを活用したファンコミュニティサービスなどを開発・提供しています。ブロックチェーンは事業価値を高める上でのコアな技術ではありますが、他にも様々な技術や開発手法を使っています。

今回はその技術選定における思想と、実際にGaudiyで採用しているアーキテクチャや技術スタックについて詳しくご紹介したいと思います。

Gaudiyで働くことに興味を持っていただいている方のご参考になれば嬉しいです!

1. Gaudiyの事業概要

多くの企業がそうであるように、私たちが採用する技術スタックや開発プロセスは、私たちの事業と密接に紐づいています。

Gaudiyでは、エンタメ企業に対して、独自のファンエコノミーを構築できるプラットフォーム「FPaaS(Fan Platform as a Service:エフパース)」を提供しています。

f:id:gaudiy:20210917174512p:plain

具体的にいうと、現在は以下3つのプロダクトを開発しています。

  • ファンコミュニティサービス
  • NFTなどを活用した新しいエンタメ体験、ソリューションサービス
  • ファンの活動を記録・蓄積する分散型IDシステム

Gaudiyの事業領域となるエンタメコンテンツ業界の特徴は、ステークホルダーの多い業界構造にあります。

たとえば、弊社が関わっているプロジェクトのひとつ、週刊少年ジャンプの人気漫画『約束のネバーランド』のコミュニティサービスでは、マンガ原作の集英社、アニメ制作のアニプレックス社、映画制作の東宝など、IPを取り巻く多数の関係者が存在しています。

また、ビジネスモデルとしてはBtoBtoCなので、クライアント(IP関係者)の要件を満たすだけでなく、ファン(エンドユーザー)にとって最高の体験を届けることが重要です。

そのため、ブロックチェーン技術を活用して顧客の課題を解決しながらも、ファンにとっては「ブロックチェーン技術を意識させない」良い体験づくりが事業のコアになっています。

2. 技術選定における意思決定の軸

こうした特性をもつ事業価値を最大化するため、Gaudiyでは以下の軸で技術選定を行っています。

  • コラボレーションを促せるかどうか
  • 仕様や要件の調整を、柔軟かつ低コストにできる仕組みか
  • 枯れた技術ではなく、将来性のある技術かどうか

f:id:takuya510:20210917223118p:plain

2-1. コラボレーションを促せるかどうか

まず前提にあるのは、開発というプロセスを通じて、あらゆるステークホルダーの「コラボレーション」を促せるかどうかです。

というのも、Gaudiyの事業特性上、エンタメ業界のDXに取り組む上では、業界や企業、組織、案件の単位で、さまざまな個別の要望が生まれます。そのため、単発の機能開発スピードを高めるよりも、そうした各方位の要求をどこまで考慮し、取り入れられるかが、事業価値を高めます。

ここで意識しているのは、DXという形で理想的な技術活用をめざしつつも、技術的な理想だけを追求してしまわないようにすることです。

技術選定の上では、特定の技術がどのような思想や歴史的背景で生まれているか、それがコラボレーションを重視する文脈に位置しているかを最も重要視してます。

それにより、技術的な理想を追求していったとしても、クライアント、ユーザー、開発者、デザイナーなど各ステークホルダーの視点を欠いたエンジニア組織にならず、プロダクトづくりの理想的なワークフロー構築に自然とつなげることができます。

2-2. 仕様や要件の調整を、柔軟かつ低コストにできる仕組みか

次に、コラボレーションを土壌として、そこで得られた様々なステークホルダーから求められる要件やワークフローに対して、柔軟に対応できる仕組みかどうかを重視しています。

社内のDXや、先端技術であるブロックチェーンを扱う事業では、単にプロダクト開発を進めるだけでなく、社内の規定や法務などのルールメイキングを同時に進めなければ着手ができないような案件もあります。

そのため、事業戦略上、クライアントとともに「時代を進める」ような取り組みを推進するためには、さまざまな特殊な障害を乗り越えるために、仕様の調整や拡張がしやすいシステムを構築できるかがカギとなります。

もちろんプロダクト全体のバリューとしては個別最適ではなく、レバレッジをどれだけ効かせられるかを意識して開発を行っていますが、多くの企業をDXに巻き込んでいくためには柔軟に対処する力が大事になります。

2-3. 枯れた技術ではなく、将来性のある技術か

上述した思想を踏まえた上で、必ずしも枯れた技術を優先するわけではなく、現時点ではまだ未熟でも、理想的な思想・性質を持っている技術かどうかを重視しています。技術はあくまで "手段" なので、新しい技術にこだわることは本末転倒です。

しかし、採用事例の多さや技術の経験者が多いなどの理由だけでは、選定すべきでないと考えています。それよりも、理想的な性質を備えている技術・フレームワークは、たとえ実用上の課題があったり、学習コストが高かったとしても、自分たちで実用方法を開拓するようにしています。

では次に、開発システムの全体像や、アーキテクチャ、技術スタックについてご紹介していきたいと思います。

3. 開発システムの全体像

f:id:takuya510:20210917223252p:plain

はじめに、全体の構成を簡単にご紹介すると、フロントエンドはReact × Next.js × Typescript、バックエンドはGo言語を使用しています。

またBFF(backend for frontend)にはGraphQLを導入しており、そのシステムではフロントエンドの開発者が柔軟に扱えるようにTypescriptを採用しています。

4. アーキテクチャ

4-1. マイクロサービス化

Gaudiyでは、マイクロサービスでバックエンドを構築しています。

背景としては、Gaudiyの提供するコミュニティアプリは、提供する機能が多いことや、クライアントの既存サービスに合わせてさまざまな拡張性に対応し、柔軟に入り込めることが事業価値に直結するため、スタートアップの規模感であったとしてもマイクロサービスとの相性が良いです。

ただ実際、マイクロサービスの採用には賛否あるとは思います。ECサイトやSNSなどのC向けのサービスや、同一の汎用的な機能を広く提供するようなSaasの場合は、プロダクトの中で使われている機能が組み合わさって全体が成立していることが多く、個々のサービスが疎結合である必然性が少ないケースが多いと感じています。

一方、Gaudiyが提供するサービスは、個別のIPにそれぞれカスタマイズ可能なファンコミュニティのシステムを提供しています。決済サービス・チケッティング・動画配信・ゲームアプリやファンクラブとの連携など、それぞれの依存関係を排して柔軟に提供したいという背景から、マイクロサービスを採用しています。

またスピード感を求めつつも、小規模な組織でマイクロサービスを行うために、コストの高いk8sではなく、CloudRunを採用して規模の拡大に伴って移行できる体制にしています。

さらに、そのマイクロサービス間をスキーマ駆動開発で進めることで、マイクロサービス間の開発やフロントエンドとの間におけるドキュメントなどの作成を減らしています。開発着手前に仕様のコラボレーションを行うことで、不要なコミュニケーションコストを下げています。

4-2. monorepo化

マイクロサービスを推進するため、シングルレポジトリ構成のmonorepoを採用しました。マイクロサービス化によって自律分散的な開発を実現しつつも、そのデメリットとして、ナレッジや運用ルールなどの統一性がなくなってしまうという問題が生じ得ます。そこをmonorepo化することで、コード、思想、言語、記述の仕方などが共通化しやすいといったメリットがあります。

さらに、レビューする人が増えたり、担当領域外の開発の可視化にもつながるので、よりコラボレーションを意識できる環境になっています。

5. 技術スタック

ここからは、各領域で採用している技術スタックをご紹介します。

5-1. React × Next.js × Typescript × Tailwind

■PWA

まず前提として、ユーザーが利用するアプリケーションは、Web上でアプリのような体験を提供できるPWA(Progressive Web Application)によって構築されています。

その背景としては、日本のエンタメコンテンツ事業者のプラットフォーム依存という問題を解決し、エンタメIP自体がプラットフォームとなる「ファン国家」の世界観を実現するためです。

iOSやAndroidのネイティブアプリを利用すると、どうしてもプラットフォーマーによる制約を受けることになるため、創業当初から理想的な技術としてPWAへの投資を続けていました。

現時点では、iOSでプッシュ通知が行えないなどの制約はありますが、自分たちでより良いやり方やUXの向上を通じて理想的な状態をめざしています。

■ React × Next.js × Typescript

Web上で柔軟に拡張性の高いアプリを構築する上では、Next.jsは最適な選択でした。もともと2018年の4月頃から、フロントエンドの設定などの煩雑な項目を廃しつつ、SSRなどの高度な機能が簡単に行えるという理由から採用していました。現在ではISRなどの機能も増え、ますます魅力的な選択肢かと思います。

■CSSフレームワーク:Tailwind

Webアプリの場合、ネイティブアプリとは異なり端末ごとに最適化されたネイティブUIが基本的には存在しません。そのために、1つ1つのパーツや、動作のインタラクションやUIを組む上での原則を作成、すり合わせて、高品質なものを担保できる状態を作ることが重要です。

そこで、デザイナーとエンジニアのコラボレーションを促進しつつ、品質の高いUIを安定的に組めるデザインシステムの構築を重視しています。

ユーティリティファーストであるTailwindは、Storybookなどでコンポーネントの管理をして使い回しをするよりも、さらに細かい粒度でデザインルールを実装に落とし込むことが可能であり、共通言語を作り上げる基盤的な役割を果たしています。

5-2. BFFとしてのGraqhQL

マイクロサービスを構築する上で、BFF(backend for frontend)をAPIゲートウェイとして活用することで、フロントエンドとバックエンドの連携をスムーズにしています。

言語としてはGraphQLを利用しているほか、こうしたクライアントとサーバーの両者を一貫して開発できるようにするために、Apollo Server&Apollo Clientを採用しています。

元々、フロントエンドとバックエンドでAPIインターフェイスの認識齟齬が発生することから手戻りが起こり、開発効率を下げているという課題があったため、GraphQLの導入を決めました。graphQL codeGen スキーマからtypescriptの型を生成することで、認識齟齬を減らしています。

この導入によってパフォーマンスが上がり、APIのレスポンス定義もエンジニア全員が随時アップデートしていくという開発スタイルが根づきました。また、スキーマを確認する会にプロダクトオーナーが同席することで、ドメイン知識を反映させるようなことも可能になりました。

さらに、コミュニティ毎に異なるカスタマイズ性なども、BFFが機能の出し分けを吸収することでフロントエンドでの複雑性を削減しています。

Gaudiyでは、特定のIPコンテンツのサービス同士をブロックチェーンを活用してつなぐDID(分散型ID)が存在していますが、最近ではGraphQL Composeを利用し、他社のサービスとの連携を行う場合などに、個別にバリデーションをかけるなどセキュアな体制を作る上で役立てています。

5-3. KotlinでDDDを推進

DDDの導入に合わせて、Kotlinを利用したサーバーサイドの構築を進める方針を採用しています。

ドメインエキスパートとエンジニアのコラボレーションを、業務フローでどう実現するかという課題がありましたが、バックエンドの設計はプロダクトの拡張性を根本から規定するにもかかわらず、非エンジニアが関わることが難しい領域でした。

そこで、DDDのドメインエキスパートのメンタルモデルを反映するという戦略的設計に取り組み始めました。

こうした社内の開発文化を強化し、導入を浸透していく上で、DDDの実践が行いやすいJavaベースの言語で、かつ導入事例はまだ多くはないものの開発者体験(DX)が良好なKotlinを採用することにしました。

(もちろん、要件に応じてサッと組みたい場合や、フロントエンドのメンバーが密に関わる場合などは、学習コストや記述のコストが低いGoNestJSを採用するなど使い分けもしています。)

5-4. Quorum(ブロックチェーン)

ブロックチェーンには、管理者が存在しない「パブリックチェーン」(ex. イーサリアム)と管理者が存在するプライベートチェーンの2種類が存在しますが、Gaudiyではプライベートチェーンを選択しています。

この主な理由は、著作権などの権利が絡むIPコンテンツ(知的財産権)に対して、パブリックチェーンを最初から本格的に導入することは、導入実績や権利関係の調整などの点から困難なことがあります。

しかし、私たちの理想とする「ファンの熱量が評価・還元される経済圏の実現」にあたっては、パブリックチェーンベースによる経済圏は実現すべきミッションだと考えています。その軸を、目先の事業機会や制約によって安易に流されることなく、理想的なシステムを常に追求し続ける意味で、通常のデータベースではなくパブリックチェーンを前提とした開発をめざしています。

Quorumは、今もっとも使われているEthereumをベースとしたプライベートネットワークを構築できるため、パブリックチェーンへの切り替えを視野に入れたノウハウの構築やプロダクトへの投資が実現できます。

現時点でも、パブリックチェーンで問題となる秘密鍵の管理やトランザクションなどを回避し、テクノロジーに詳しくない「エンタメのファン」でも快適に楽しめる設計を現在進行系で行っています。

また、KaleidoというフルマネージドのBaaS(Blockchain as a Service)を採用しています。Nodeの運用が不要になるほか、ブロックチェーンエクスプローラーやイベントフックの開発などもwebhookで提供してくれるなど、AWSと比べても高機能なサービスとなっています。

6. まとめ

今回は、Gaudiyの事業特性をふまえて、技術選定における思想や、各領域の技術スタック、アーキテクチャについてご紹介しました。

文中にも書きましたが、Gaudiyの事業価値を高めるためにはコラボレーションが重要であり、そのような開発を推進するには、個人がただ技術や手法を取り入れただけでは実践できないため、周囲の理解が必要です。

その点、Gaudiyでは、全員参加の輪読会で「エンジニアリング組織論への招待」を読み、アジャイルへの理解を深めたり、DDD勉強会が開催された際にはコーポレートなども含めたメンバーが参加したりと、全社でそのカルチャーを強めています。

全員がプロダクトに向き合う環境で、ともに時代を進めていく仲間を募集していますので、少しでも興味を持ってくださる方は、ぜひ気軽にお話ししましょう!

youtrust.jp

meety.net

DDDを試行錯誤しながら実践するチームの学びをまとめてみた

f:id:kei32bit:20210910165752p:plain

こんにちは!エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドエンジニアをしている椿(@mikr29028944)です。

Gaudiyは、まだエンジニア10名、デザイナー2名ほどの開発チームですが、今年の6月からDDDと呼ばれるドメイン駆動設計を開発に取り入れました。

DDDとは、一言で言うとドメインエキスパートと呼ばれる担当業務やシステム設計に最も詳しい人と、エンジニアが共創してソフトウェアを開発する手法です。

今回は、DDDを実践する中での気づきや学び、躓きやすいポイントをどのように乗り越えてきたかについて、ご紹介してみたいと思います。

DDDを検討しているチームや、導入して間もないチームのご参考になれば幸いです!

1.なぜDDDを導入したのか

Gaudiyでは元々、アジャイル開発を進めており、繰り返し小さくサイクルを回していくことで品質の高いプロダクトを作る、という開発スタイルを実践してきました。

また、エンタメ企業に対してブロックチェーンを活用したファンコミュニティサービスを提供している事業特性上、扱うドメインがかなり広いかつ複雑で、追加での機能開発が入ることも多いのが特徴です。

そうした中で、ドメイン知識のある人に開発者がヒアリングして実装する、という進め方は以前から個別では行われていましたが、それを体系的に行う開発スキームがなく、実際にドメインエキスパートと開発者の間で認識齟齬が生まれてしまうことも度々ありました。

そうした中で、コラボレーションを促進し、価値提供する対象のメンタルモデルを探った上でプロダクトの品質を高めていくため、2021年6月にDDDを導入することにしました。

DDDは、ドメインエキスパートがもつ知識をプロダクトに関わる全員がしっかり理解・共有するのに、とても優れたフレームワークだと感じています。

2.GaudiyではどのようにDDDを取り入れているか

DDDには、よく「戦略的設計」と「戦術的設計」と呼ばれる手法がありますが、その本質は、ドメインを理解して適切にコードに反映することで、事業価値の高いソフトウェアを開発することにあると思います。

Gaudiyでは、ドメインエキスパートに対するヒアリングからドメインモデルをつくり、それをソフトウェアの実装に反映する、といったDDDの一連の流れを取り入れています。

特に、ドメインの不確実性が高かったり、複雑なものであったりする場合は、率先してDDDを行うようにしています。逆に機能要件がシンプルでわかりやすいものは、DDDを行わないこともあります。

例えば、ある新機能の開発では、以下のようなチームでドメインモデリングを行いました。

  • ドメインエキスパート:プロダクトオーナー
  • 参加者:Bizメンバー2名、デザイナー1名、エンジニア5名

進め方は、一般的なDDDと同じく、まずはユースケースを全員で洗い出し、その全ケースを実現するための理想的なドメインモデル図を話し合います。ユースケースに基づいて、様々なステークホルダーの視点から質問していくことで、ドメインエキスパート自身も言語化できていなかったことがクリアになっていきます。

f:id:gaudiy:20210910124323p:plain

フォロー機能のドメインモデル図

ドメインモデルを作ったあとは、それをどうソフトウェアで実現するかを話すため、ユビキタス言語やドメインモデル図をもとにコミュニケーションを取りながら、実装コードへと落とし込んでいきます。

Gaudiyでは、バックエンドにNestJS(TypeScriptのフレームワーク)やGoを採用しており、オニオンアーキテクチャ構成を取り入れています。

f:id:gaudiy:20210910144751j:plain

オニオンアーキテクチャ構成

この一連のフローにおいて大事だと思うのが、ドメインモデルをつくるところに必要以上に工数をかけすぎず、ヒアリング→ドメインモデルの作成→実装のサイクルを細かく回すことです。

というのも、ドメインエキスパートが最初からすべてを話せるわけではないし、実装側としてもモックベースで一度作成してから、「こういうフローが必要だよね」「ここの処理どうする?」といった議論に展開しやすいからです。

その中でモヤっとしたら、ドメインエキスパートに再度ヒアリングして、ドメインモデルとコードをアップデートしていく方法が進めやすいと思います。

3.DDDの実践で生じた課題と乗り越え方

DDDを導入したことで、以下のようなメリットが得られました。

  • ステークホルダー間で共通言語ベースのコミュニケーションが生まれることで、ドメインへの理解・学習が効率的にできる
  • 頻繁な変更に耐えうる拡張性や保守性が高いソフトウェア設計が行える
  • 全てのコードがドメインの翻訳になる
  • コアドメインを理解し、ビジネス価値を最大化できる
  • 多角的な視点からドメインの新たな要素の発見やドメイン同士の重要な関係性を見出すことができる

一方で、チームの学習コストの高さや、モデリング実装の難しさ、抽象化と作り込みの問題など、さまざまな課題も感じています。

ここからは、実際にぶつかった課題と、そのときチームがどう行動したか、そこから何を学んだかを紹介したいと思います。

3-1.チーム全員でDDDを学習する

DDDでは、エンジニアだけではなくBizメンバーも含めてプロダクトに関わる全員が、以下のようなことを学ぶ必要があります。

  • ドメインモデリングの手法
  • ドメインエキスパートのメンタルモデルを探り、言外の背景まで引き出すスキル
  • チーム全員がドメインについての理解を深めるマインドや姿勢
  • アーキテクチャ設計やソフトウェア設計原則の理解

これを全員でキャッチアップする学習コストはかなり高いですが、僕たちのチームでは、以下の方法でキャッチアップしていきました。

3-1-1.外部講師を招いた

DDD界隈で有名なログラスの松岡さん(@little_hand_s)をお招きして、自分たちが普段扱っている開発のドメインを題材に、DDDの実践方法を教えていただきました。

オンラインでDDD勉強会を2回ほど開催いただき、実際にユースケース図の書き起こしからドメインモデリング、実装までの一連の流れを実演いただきました。

この勉強会を通じて、どのようにドメインエキスパートのメンタルモデルを探り、知識を引き出すことができるかを知ることができました。

f:id:gaudiy:20210910125835p:plain

エンジニアだけでなく、Bizメンバー、デザイナーも全員参加したDDD勉強会

自分が一番学びがあったのは「ドメインエキスパートへのヒアリングの仕方」でした。参考になった質問を以下に記載します。

  • このオブジェクトに足りない要素は他にはないか
  • この時のユーザーの状態はどういうものがあるか
  • オブジェクトの具体的な例が知りたい
  • キャンペーンとは期間限定のものなのか、それとも恒常的に開催されてるのか
  • このAオブジェクトとBオブジェクトの関係性はどうなのか
  • このクラスのルールや制約はどのようなものが存在するか
  • 強い整合性を表す集約の範囲はどうするか、それとも一旦実装してから検討する方が良いか

特に「このクラスのルールや制約はどのようなものが存在するか?」
という質問はプロダクト視点で「このサービスで何を実現したいのか」を言語化できる、非常に重要な質問だと感じています。

たとえば「キャンペーン中のミッションをすべて達成した場合に何か副作用がありますか?」というドメインのルールを質問することで、ドメインエキスパートから「実はフルコンプリートミッションというミッションを考えていたのでそれも考慮した設計にしたいです」という発言を引き出せました。

上にも挙げましたが、ドメインエキスパートが最初から何でも知っているというわけではない、という前提に立って、ヒアリングをする姿勢が大事になります。

3-1-2.DDDの書籍や記事、登壇資料などを読み漁る

書籍を読むことで理論を学びました。以下に、学びが多かった書籍を載せます。

booth.pm

最初にこの書籍を読みました。戦術的アプローチ・戦略的アプローチの違いから、モデリング→実装に落とし込むまでの流れがとてもわかりやすく説明されています。

また、ところどころにDDDでつまずきそうなQ&Aが記載されており、DDD初心者でも最後まで読み切れる構成になっています。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法(増田 亨)

こちらもドメインモデルの設計方法が手厚く書かれている良書です。またドメイン知識の重要さについての記載もあり、ドメインエキスパートとエンジニアの共創が非常に大事だと改めて実感できました。

さらに書籍だけでなく、DDDの記事や登壇資料を読み漁りました。

特に参考になった記事や資料は、以下になります。

tech.readyfor.jp

little-hands.hatenablog.com


3-2.モデリング実装に実際にどう落とし込むか?

また、ドメインモデル図を作成できても、それをどのようにソフトウェアに実装するか?も実際にやってみると難しかったです。

この際も、外部講師の松岡さんにチャットサポートしていただき、Slackでどんどん質問しました。

f:id:gaudiy:20210910124357p:plain

#ask_ddd_room での質問

DDD導入直後は、モデリングから実装に落とし込む際の懸念などを活発に質問することで、わからないことをわからないまま放置せずに理解を深めました。

後から振り返ってよかったことは、質問することで思考回路が言語化されるということです。

これにより、チームでDDDの振り返りをする際に「どういう判断基準が良かったか」「どういう進め方に改善の余地があるか」といったネクストアクションにつなげることができました。

3-3.「早すぎる抽象化」による不必要な開発の問題

ドメインモデル図の作成では、「いずれこういうユースケースにも対応したい」「きっとこういう使われ方をする」といった未来のユースケースを想定することもあります。結果として抽象化されたドメインモデル図から、いま不必要な開発までしてしまうことがありました。

不必要な開発をした結果、自分たちのチームでは以下の負債が発生してしまいました。

  • 複数のパターンに耐えうる汎用的な機能はあらゆるケースを包括的に対応できるが、そのケースが将来存在しなかった場合には、コードが負債に転じる
  • 不必要なコードが積もると、後からコードを修正する人がその複雑なコードを扱わなければならない、それよりは追加実装するほうが速い、などの理由で重複したコードが作られる

実際に、週刊少年ジャンプの漫画「約束のネバーランド」の展示会で、アプリでQRコードをかざすとNFTが受け取れる、という体験を開発した際、複雑で不確実性の高いドメインを扱う必要がありました。

コミュニティ内のあらゆる諸条件と、コミュニティ外でのユーザーの活動があり、無数の条件の組み合わせがある中で、複雑なユーザーの状態をあらゆるドメインから情報を集めて、判定を行わなければならないといった状況でした。

さらにNFTに関しては、メタデータを参照するケースも今後は増えてきたり、条件クリアのアイテムを付与するために外部APIやBlockchainとの通信、DBの更新を行わなければならないケースだったりと、様々なケースがありました。

そんな状況下、モデリングしたはいいけれど、将来起こりうる仕様拡張を考慮しすぎて汎用化させてしまった結果、コードを作り込みすぎてしまい、結果的に今も使われてない実装が残ってしまっています。

この反省を踏まえて、汎用的なドメインモデルを扱う際に、不必要に作り込まれたコード実装に陥らないよう、Gaudiyでは「早すぎる抽象化(早抽)」というパターン・ランゲージ(※)を作りました。

パターン化したことで「これって過去に失敗したモデリングの方向に向かってしまっている...?」と、レビュー時などに気付けるようになります。

※パターン・ランゲージとは、組織の中で暗黙知になっている行動様式(パターン)を言語化したもの。過去の複数事例に共通する性質を抽出することで、同じ問題が発生した場合に対処できるよう活用しています。

f:id:gaudiy:20210910124435p:plain

日常的に意識されている「早抽」

また、個人的には以下が大事だなと学びました。

  • 単一責任原則や高凝集・疎結合を意識し、適切なモデリングを行い、適切なタイミングで抽象化を行うことで「誤った抽象化」を防ぐことができる
  • 「仕様は変化し、その将来の姿は予測できない」という現実を受け入れる

一方、逆に「早すぎる抽象化」を意識しすぎると、今度はユースケースの幅を狭めすぎてしまって作り込み不足に陥るという事態も発生してしまいます。

作り込み不足で進めてしまうと、のちにリファクタリングが必要になり、保守・運用が難しくなってしまうため、その解決策のひとつとしてテスト駆動開発(TDD)を取り入れています。

また受け入れテスト駆動開発(ATDD)を導入することで、事前にドメインエキスパートとエンジニア達で決めたユースケースが満たされてるかを確認する方式を取り、作り込み不足になっていないかを確認しています。

4.おわりに

まだまだDDDの実践を始めたばかりではありますが、基本原則を守破離の「守」で学びながらも、自分たちのチームにあうやり方を模索していきたいと思っています。

また今後、DDDでソフトウェアをアップデートをしていく上では、以下のマインドと行動を継続的に実践して、DDDをブラッシュアップしていく予定です。

  • 上述した「早すぎる抽象化」「作り込み不足」などに気をつける
  • ドメインエキスパートへのヒアリングを通じて設計が再構築されるサイクルを回す
  • パターン指向リファクタリングなど、デザインパターンを使って設計を改善する

また、DDDの社内勉強会を開催して、エリック・エヴァンスの書籍もみんなで読んでいきたいと思っています。

もしこの記事を読んで、少しでもDDDの話を聞いてみたい!などご興味を持っていただけたら、ぜひお話しましょう!

meety.net

未経験から1年でキャッチアップしたブロックチェーンの学習法をまとめてみた

f:id:gaudiy:20210902104804p:plain

こんにちは。エンタメ業界のDXを進めるブロックチェーンスタートアップ、Gaudiyで主にバックエンドを担当しているkei(@kei32bit)です。

自分がブロックチェーン技術をキャッチアップし始めたのは1年ほど前です。最初の半年間くらいは趣味として、その後はブロックチェーン企業に入って仕事でもブロックチェーンに触れるようになりました。

もちろん全部を理解しているわけではないですが、次に来そうなブロックチェーン技術を予測したり、自分なりにテーマ課題を立てて調べたりできるようになりました。

(以前投稿した記事) techblog.gaudiy.com

本記事では、この1年間で自分がどういう情報ソースを元にブロックチェーンを勉強したかを紹介したいと思います。

今からブロックチェーン技術をキャッチアップするエンジニアの方々にとって、自分のキャッチアップの方法がご参考になれば幸いです。

1. 良質なインプットで理論を固める

「ガベージイン・ガベージアウト」というシステム用語がありますが、キャッチアップが早くても吸収する情報の質が良くなければ、何も得られません。以下に載せた内容は比較的、中立的な資料を選んで挙げているのでぜひ一読してみてください。

1-1. 先駆者の考え方をトレースする

自分がブロックチェーンを学ぶ上で参考にした方は、Matsuo Shin'ichiro先生(@ShaneMatsuo)です。

米国の大学でクリプトの研究を進めていらっしゃる方です。とても中立的な立場から、ブロックチェーンが現代社会に必要な背景を説明されています。自分はまず、この方がパブリッシュしてる資料をとにかく読みました。数年前の記事でも示唆が溢れているので現在でも読む価値が高いです。

ブログ

連載記事

レポート

この辺りを一通り読み終わると、ブロックチェーン技術に対する意見がぼんやり言えるようになってくるかと思います。

1-2. 各研究機関が出してる資料を読み漁る

ブロックチェーン技術をキャッチアップするときは、背景知識も必要です。なぜブロックチェーンが有用なのかを理解するためにも、国や研究所が出すような包括的にリサーチされているドキュメントにふれるのが自分には合っていました。

DXからスマートシティ、セキュリティのtopicまで様々なジャンルを挙げてますが、根底にあるブロックチェーン技術の思想としては同じものです。異なる視点から見ると理解が深まるはずです。 ※比較的新しい2019年以降の資料を選んでいます。

1-3. ホワイトペーパーを読む

ホワイトペーパーとは企画書のようなものです。暗号資産は各々ホワイトペーパーを持っており、そこでは使用するプロトコルなどが明記されています。この企画書を読むことで、各々の暗号資産が生まれた背景や解決するための思想について学び取ることができます。

ブロックチェーンを理解する上で、ビットコインとイーサリアムのホワイトペーパーはマストで読んだほうが良いと思います。

・ビットコインのホワイトペーパー

https://bitcoin.org/bitcoin.pdf

・イーサリアムのホワイトペーパー

https://ethereum.org/en/whitepaper/

1-4. 書籍で勉強する

以下は自分が読んだ中でおすすめの書籍です。ブロックチェーン理論と実践だけでなく貨幣の歴史についても学ぶと、多くのトークンが生まれる理由についても分かるようになります

ただし、基本的にコントラクト周りの開発をする際はあまり書籍を参考にしないほうが良いです。(古い情報になるのでコードが動かないケースが多い。)後述しますが、手を動かしたい場合は、直接GitHubのtutorialを実施するのが良いです。

・ビットコインスタンダード

www.amazon.co.jp

ビットコインがなぜデジタルキャッシュになれたかの理由を「貨幣の健全性」という定義に照らし合わせて解説した書籍です。 現在流通してる貨幣が不健全な理由についても触れています。既存貨幣が後続の貨幣に駆逐された歴史背景を学ぶと、なぜビットコインがデジタル・ゴールドと言われ、デジタルキャッシュとしての地位を築けたかが理解できると思います。

・ブロックチェーンの技術と革新

www.amazon.co.jp

「信頼」をテーマに、その再定義と、実態のない対象に対してブロックチェーン技術がどう信頼を担保できるかを説明した書籍。 この本の中で度々引用されるコモンズ/ローレンス・レッシグ著という書籍も名著なのでこちらも一読の価値があります。 信頼の歴史を動画でキャッチアップしたい場合はTEDのこちらの動画がおすすめです。15分くらいで信頼の歴史がlocal=>international=>decentralizedに変化した背景が理解できます。

・SolidityとEthereumによる実践スマートコントラクト開発

www.amazon.co.jp

原著は2019年の出版ですが体系的によくまとまっています。実際に手を動かすパートについては、コードが若干古いので目を通すだけで良いと思います。(Truffleや周辺ツールの使い方を勉強する場合は、Webサイトに訪れてtutorialを見ながら手を動かして実践するのがベストです。)ただトランザクションの実行結果の各パラメータの見方や、トランザクション発行までの流れを言語化されているので、現在でも学べる部分は多いです。

参考: Truffleのチュートリアル

・マスタリングイーサリアム

https://www.amazon.co.jp/dp/4873118964/

ビットコインと比較しながらイーサリアムの特徴とその歴史について書かれた書籍です。イーサリアムの仕様だけでなく、なぜスマートコントラクトがすごいのかを理解するにあたって良書です。

・Token Economy: How the Web3 reinvents the Internet

https://www.amazon.co.jp/dp/B08BKSY3QZ

これだけ英語です。実はGithubにレポジトリが合ってそちらであれば無料で読めます。トークンエコノミーについて理解を深めたい場合はこの本が一番おすすめです。(翻訳かけて読むとかで全然OKです) Web2.0からWeb3.0へへ移行していく所から説明されてるのでブロックチェーンが必要になった背景理解が深まります。

github.com

1-5. より専門的な記事を読む

ここまで挙げた資料を読み込むと、たとえば「セキュアでノンカストディなウォレットを作るために必要な技術とは何か?」といった知識が必要な問いには答えられるようになります。

さらに「これからブロックチェーン技術がどう発展いくか?」といった未来を仮説付けるような問いを自ら立てるためには、専門家の記事が有用です。

この辺りの問題提起などの言語化には、以下のサイトが非常に勉強になったので紹介します。

・HashHub Research

https://hashhub-research.com/

プランはいくつかありますが、個人で入るなら9,990円/月のBasicプランがあります。 リサーチャーの方の所感や考えが記事に反映されており、新しい情報だけでなく示唆も得られます。

自分が気に入ってる記事のひとつに「論考・ロングタームで大局観を持ちながら、 暗号資産・ブロックチェーンに投資をする5つの原則」というものがあります。これは投資に興味がなくても、技術者として「アプリケーションとインフラ周りのサイクルがどう発展してきたか、ブロックチェーン業界に置き換えると現在はアプリケーション層が発展してるが今後インフラ層のプロダクトもきっと発展するだろう」という示唆が得られます。今後来るであろう技術を予測するという観点で非常に学びがありました。

hashhub-research.com

・Token Lab

https://blog.token-lab.org/

こちらも4980円/月の有料レポートですが、最新のブロックチェーン動向を追えます。ブロックチェーン系プロダクトの内容を詳細に記載するスタイルで読み応えがあるので、ある程度ブロックチェーン用語に慣れてから読み始めるのがおすすめです。

また、記事のコメント欄で有識者の方々が議論しているのでそれを見るのも学びがあります。

・イーサリアム創設者ヴィタリック氏のブログ

https://vitalik.ca/index.html

正直、結構難しいことを書いている(しかも英語で)ので、イーサリアムの知識がある程度ついてから、今後イーサリアムの開発はどうなっていくのか知りたくなったタイミングで読むのをおすすめします。詳細な数式モデルなどは分からなくてもイーサリアムのシステムの方向性は掴めると思います。

1-6. クリプト業界のレポートを読む

自分は定期的にCryptTimesさんとCoinGeckoさんのレポートを読んでいます。技術だけでなくブロックチェーンの流行りを理解するのに最適です。直近1年間のレポートと、個人的に有用だと思う技術レポートを貼っておきます。これを読んでおくだけで最近のブロックチェーン動向については抑えられるかなと思います。

※ CryptoTimesさんのレポート一覧はこちら

1-7. YouTubeで学ぶ

イラストでブロックチェーンが学べるコンテンツです。英語ですがイラスト見るだけでも楽しいのでぜひ息抜きにでも!

・Finematics

https://www.youtube.com/channel/UCh1ob28ceGdqohUnR7vBACA

個人的にLayer2 Scalingの動画とか分かりやすくておすすめです。

www.youtube.com

1-8. 議論されてる場所に行く

現在進行系で今後のブロックチェーン開発をどうしていくか、といった議論がされてる場所があります。 Improvement Proposalsと呼ばれており、日本語でいうと改善提案を行う場所です。

全部の議論を把握する必要はないのですが、スマートコントラクト開発をしていて「こんな機能ないのかな〜」と思いものは大体議論されてることが多いので、該当するブロックチェーンのImprovement Proposalsをググると見つかるかもしれません。

ここではイーサリアムというブロックチェーンと、NEARというブロックチェーンのImprovement Proposalsを紹介します。

・EIPs(Ethereum Improvement Proposals)

https://eips.ethereum.org/

・NEPs(NEAR Improvement Proposals)

https://gov.near.org/

1-9. ブロックチェーン技術の全体像を掴む

技術の全体感を把握するのに良いなと思って拾ってたtweetや記事を貼っておきます。どの技術も関連性があるので、迷ったらこのようなマップにもどってくると理解が深まります。

・ブロックチェーン技術のコンセプトマップ

f:id:kei32bit:20210901155006p:plain
ブロックチェーン技術のコンセプトマップ

medium.com

・Bitcoin周りの技術ネットワーク図

1-10. (番外編)人から直接教えてもらう

自分でキャッチアップもしましたが、実際にブロックチェーン業界に入って周りの方々に教えてもらうことのほうが実りがあるものが多かったです。 最近Meetyが流行っていますが、「ブロックチェーン」というワードで検索をかけるとたくさんの面談が出てきます。興味のある業界や興味のあるアプリケーションがあったら、直接話を聞きに行くのが一番だと思います。もし今からブロックチェーンをキャッチアップするなら自分がやるだろうなという方法なので挙げました。

f:id:kei32bit:20210901155649p:plain
Meetyで「ブロックチェーン」というワードでの検索結果

2. 実践してみる

良質なインプットのあとは、実践です。ブロックチェーンの開発に着手する際は、できる限り新しく(直近1ヶ月にcommitがあるなど)、githubレポジトリにあるものを動かしながら学ぶのが良いと思います。

以下のような、最新のHow To Learn記事を参考にすると良いと思います。イーサリアムだとSolidityという言語を使いますが、基本的に普通のプログラミング言語と変わりません。

medium.com

また、イーサリアムとは別のブロックチェーンになりますが、Rustでスマートコントラクトを書きたい場合は、NEARというブロックチェーンもおすすめです。チュートリアルが充実しており、スマートコントラクトをデプロイするところまで実施できるドキュメントがあるのでこちらも紹介します。

learnnear.club

examples.near.org

3. おわりに

ブロックチェーン界隈は次々に新しいトレンドやプロダクトが生まれるので、追いかけ続けるのは正直言って困難だなと思います。

ただ、自分なりのキャッチアップの仕組みを整えておくと、1ヶ月ほどブロックチェーン業界から離れていても割とすぐにもどってこれます。必要なのはブロックチェーンの知識量ではなく、キャッチアップの速度をいかに早めるかです。

もし本記事を読んで少しでもブロックチェーンに興味を持っていただいた方は自分もmeetyやってるので声かけていただけると嬉しいです! 「ブロックチェーン技術を事業に結びつけてどうマネタイズするの?」など事業目線での疑問にもお答えします。

meety.net

スモールチームで始める、デザインシステムの第一歩

f:id:gaudiy:20210824232101p:plain

こんにちは。エンタメ業界のDXを進めるブロックチェーンスタートアップ、Gaudiyで主にフロントを担当しているkodai(@r34b26)です。

弊社は、まだエンジニア10人、デザイナー2人ほどの小規模な開発チームですが、デザインシステムの構築に取り組んでいます。

デザインシステムは、一貫性のある品質の高いUIを継続してデリバリーする上ですぐれた仕組みですが、リソースの限られた環境ではなかなか着手しづらい面もあると思います。実際、デザインシステムを導入している会社では、専任の人やチームを組成して取り組まれていることが多い印象です。

そこで今回は、スモールな開発チームで、デザインシステム、特にコンポーネントライブラリを構築する上で工夫していることをご紹介してみたいと思います。

デザインシステムとは?

デザインシステムとは、一言でいうと「一貫性のある品質の高いUIを継続してデリバリーするための仕組み」です。デザインの原則や基準をまとめたドキュメントと、それを満たすデザイントークンやコンポーネントから構成されます。

複数人のデザイナー/エンジニアが、複数アプリケーションの実装を進めていくと、各々の実装の仕方によって "似て非なるもの" が繰り返し生成されてしまいがちです。

デザインシステムを適切に構築することで、繰り返し生成するコストやUIの実装コストを削減したり、表現のブレをなくしてユーザー体験の向上を実現することができます。

なぜ導入したのか?

これまで、弊社ではMaterial Designをデザインシステムに、Material UIをコンポーネントライブラリに使用してきました。

プロダクトの検証フェーズでは、このようなOSSに完全に依存し、ごく少人数で高速に実装できることはValueの高いことでした。ですが、新しいファン体験をより高品質に提供していくフェーズに変わり、開発チームの人数も増えてきたことで、従来のやり方ではValueを出せなくなってきました。

例えば、

  • iOSはMaterial Designの表現やインタラクションの体験がなじまないこと
  • HIGベースに話すデザイナーと、MUIしか認知していないエンジニアでの認識齟齬
  • ありふれ"すぎた"体験のものしか作れないこと
  • MUIを都度上書きして使うことによる、表現のブレの多発
  • Figmaと実装のコンポーネントが結びついていないことによる、認識のずれ、再発明の多発

といった課題がありました。また弊社の特徴として、複数のコミュニティアプリを作っているため、レバレッジの効く仕組みづくりに早いうちから着手する必要があります。

このような課題を解決する手段のひとつとして、デザインシステムを導入する意思決定をしました。 

Gaudiyのデザインシステム

現在は、デザイナー1人、エンジニア1人の体制で、少しずつデザインシステムを構築し始めています。

f:id:gaudiy:20210824113530p:plain

デザイン原則、スタイルガイド

f:id:gaudiy:20210824113624p:plain

コンポーネント

弊社のデザインシステムを簡単にご紹介すると、デザインはFigmaを、フロントの実装はReactを使用しており、そのコンポーネントの組み方と命名を完全に一致させています。この組み方が違うと、のちにFigmaで新しく組んたものが実装で反映できないことがあるので、はじめに認識を合わせておきます。

また、細かい色やマージンなどのデザイントークンと呼ばれるものは、Tailwindのconfigで管理して、こちらも命名と内容を合わせます。さらに、実装したものはStorybookにすべて登録してFigmaに存在する使用例を再現し、次回の実装からStorybookの例からコードをコピペできるように用意しています。

f:id:gaudiy:20210824113221p:plain

実際のStorybook

実際にどう作っているのか?

フェーズが変わり、デザインシステムの導入を始めたとはいえ、まだまだ少人数で高速に開発しなければならず、プロダクト開発以外にリソースを潤沢に割くことはできません。

そこで、限られたリソースでどのようにコンポーネントライブラリの構築を進めているか、その工夫を3つほどご紹介します。

1. プロダクト開発の一部に取り込む

すべてのデザインシステムを揃えるには、相当な労力がかかります。そこで弊社では、「プロダクト開発の一環で使用したいもの」かつ「その時点で複数機能/環境で使うような汎用性をもちたい要件であった時」に、新しいコンポーネントを作成するようにしています。

具体的には、必要とする実装者がオーナーとなり、まずは既存のデザインシステムに存在するかを確認します。そこでなければ、他のエンジニアやデザイナーにヒアリングしながら実装のやり方を考え、プロジェクトのチケットの一部として進行します。

こうすることで、チームへのデザインシステムへの意識を伝え広げるとともに、プロダクト開発の一部として、デザイナー/エンジニア以外への認識向上も含めながら進めていくことができます。

f:id:gaudiy:20210824232828p:plain

PM的な立ち回りの人がコメントしてくれる

2. 完璧をめざさない

最初からベストプラクティスを追い求め、バグがなく、アクセシビリティも高く、汎用的なコンポーネントをめざしてしまうと、いくら時間があっても足りません。 また、実際に使うことでわかることもあるため、他エンジニアへのヒアリングやツールの導入で最低限の水準を担保しつつも、はじめから求めすぎないことが大切だと考えています。

実際に開発の一部として進めることで、自分たちのユースケースを反映することができるので、そこで実現できないものがあったときにはリファクタ、追加、修正することで改善の機会を逃さないようにしています。

f:id:gaudiy:20210824111103p:plain

story baseのチケットで、タスクの一部としてボタンの挙動を更新した例 

3. OSSの力を借りる

ModalやTransitionなど、若干の実装コストがかかるが車輪の再発明になってしまうようなものに関しては、OSSを使用するなどして、直近のコストを積極的に下げるようにしています。

その使い方に関しては、MUI v5のunstyledheaedlessui のようなものを使ってunstyledな層は任せ、styledな層を自分で実装する。もしくはstyledな層も任せるが、それらを組み合わせたutility的な層を自分で実装するなど、ケースによって柔軟に対応できるように工夫しています。

f:id:gaudiy:20210824111329p:plain

分割してlerna管理している

運用を始めてみての効果と課題

実際にデザインシステムを導入してみて、UI実装をするときの変化を感じています。

例えば、デザイナーと「デザインシステムに定義すべきか」を話したり、他のエンジニアに「どう使用すべきか」を尋ねたり、また「実現できなかったときはどのように調整すべきか」といった会話もチームでなされています。

デザイントークンとコンポーネントライブラリ自体の向上が少しずつ進んでいますが、 それ以上に、デザイナーとエンジニア間でのコラボレーション機会が増え、お互いにヒアリングし合うべき内容を伝播できていることに一番効果を感じています。

一方で、

  • プロジェクトでスピードが重視される期間に、導入/改善が挟みづらい
  • 初回の実装や相談相手が、まだまだ特定の個人に偏っている
  • デザインシステムの実装が絡まないパートである、デザイン原則などのドキュメント整備やその周知が進まない

といった課題もあり、この辺りは今後改善していきたいです。

まとめ

今回は、弊社のデザインシステムに関する取り組みをご紹介しました。リソースがない中でも工夫すれば始められないことはないので、初期フェーズからデザインに投資したいと思っているチームの参考になると嬉しいです。

整備しきるまでは長い道のりですが、コラボや会話促進といった+αの価値も出せているので、地道に改善していきたいと思います。 デザインシステムの相談相手いないのでほしい。。。。

meety.net

クリエイターに還元し続けるNFTの流通を考えてみた

f:id:gaudiy:20210819121649p:plain

こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしているkei(@kei32bit)です。

突然ですが、みなさんはNFTをご存知でしょうか? 聞いたことがある人や、中には実際にNFTを売買したことがある人もいるかもしれません。

Gaudiyでは、トークンエコノミーの実現に向けて、ブロックチェーンを活用したファンコミュニティサービスを開発していますが、その中で電子書籍やトレカ、チケットなどに「NFT」を活用しています。

今回は、そのNFTの売買、特に二次流通における課題と解決策をテーマに、リサーチした内容と私の考えをご紹介したいと思います。

本記事で取り扱う内容は以下です。

  • NFTの流通プロセスとロイヤリティという概念
  • クリエイターに永続的に報酬が入る仕組みは作れるのか?
  • ロイヤリティに関する課題とその解決策

本記事を読む前にNFTをキャッチアップしたい方は、日本総研が出しているレポートをご一読いただくのをおすすめします。

NFT(Non-Fungible Token)に関する動向

テックブログではありますが、コードを読まなくても理解いただける構成を心がけたので非エンジニアの方にも読んでいただきたいです。

1. NFTの流通プロセスとロイヤリティ

最初に、NFTの売買や流通の仕組みについて簡単にご紹介します。

NFTは、基本的には「NFTマーケットプレイス」と呼ばれる取引所で売ったり買ったりすることができます。

f:id:gaudiy:20210819112252p:plain
NFTの取引の流れとブロックチェーン
ref. NFT(Non-Fungible Token)に関する動向 p4

例えば、有名なものだとNBA TOPSHOTが挙げられます。バスケのプレー名場面を収録した動画コンテンツの売買ができる取引所です。

https://i.gyazo.com/0631b3ccafae952bdf95d7010090c957.gif

上記であげたNBA TOPSHOTは、NFTコンテンツ作者から直接購入できる「一次流通」のマーケットプレイスです。

これに対して、一次流通で売買したNFTコンテンツが売買されることを「二次流通」と呼びます。

イメージとしては、中古品の販売に近いです。コンテンツ作者から購入するのではなく、既に購入した人からNFTを購入する取引で「転売」と言われることもあります。

有名どころだとOpenSeaやRaribleが二次流通の機能を持ったマーケットプレイスとして該当します。

※厳密にはOpenSeaもRaribleも認定クリエイターとしてNFTコンテンツ作者が登録できるので、その人達と売買する場合は一次流通となります。なのでOpenSeaは一次流通と二次流通の機能を持ち合わせたNFTマーケットプレイスと言えます。

OpenSea: Buy NFTs, Crypto Collectibles, CryptoKitties, Decentraland, and more on Ethereum

Rarible – Create, sell or collect digital items secured with #blockchain

また、二次流通の手数料のことを「ロイヤリティ」といいます。NFTのユニークな機能のひとつで、上図の赤枠で囲んだ部分を設計することで得られる収益です。

NFTコンテンツ作者はもちろん、NFT購入者も自身がNFT販売者の立場になる際はロイヤリティ配布対象になり得ます。

ロイヤリティがあると、二次流通以降の取引でも継続的にNFTコンテンツ作者(+NFT購入者にも)に収益が入るので、NFTコンテンツの取引の活発化にむけたインセンティブになります。

例えばメルカリのようなプラットフォームで書籍を売っても本の作者には1円も入りませんが、NFT化した電子書籍コンテンツであれば、二次流通(転売)するたびにロイヤリティが作者に入ります。

2. クリエイターに永続的に報酬が入る仕組みをどう作るか?

NFTコンテンツを売買するとき、おそらく多くの方は、前述したNFTマーケットプレイスで取引するはずです。

大手のNFTマーケットプレイスでは、二次流通におけるロイヤリティを自身で設定することができます。例えば大手取引所のひとつRaribleでの具体的なロイヤリティ設定は以下です。

  • Raribleで取引されるNFTコンテンツに関しては10%のロイヤリティが設定できる
  • NFTコンテンツがRaribleで二次流通(転売)される場合も転売される度に10%のロイヤリティが作者に入る

しかし現状、RaribleとOpenseaといったNFTマーケットプレイス間でのロイヤリティの配布はできないので、別の取引所でユーザーが出品してしまうとNFTコンテンツの作者にはロイヤリティが入りません。

同じようなことは個人間売買にも言えます。作者にロイヤリティを払うと自分の取り分が減ってしまうため、この流れは想定できます。

f:id:gaudiy:20210818180524p:plain
二次流通をRarible以外の場所で行ったケース

このように、ロイヤリティを付与する/しないがユーザーに委ねられてしまうので強制力が働きません。これはユーザーがロイヤリティを設定するというUXに委ねられているのが原因です。

なので視点を変えて、アプリケーションレイヤーでの解決策ではなく、もう一つ下のプロトコルレイヤーでの解決策を深堀りしていきたいと思います。

NFT取引所ごとではなくデフォルトのNFT機能としてロイヤリティの仕組みを持たせたい

ひとつ下のレイヤー層でロイヤリティ機能を入れられたら、NFTマーケットプレイスごとに独自実装しなくて良いですよね。

結論から言うと、Ethereumというブロックチェーン上ではこの機能を提案する議論がされています。(提案のステータスがドラフト段階ではなく、最終段階のステータスになっているのでおそらく標準実装として入ると思ってます。)

また、Ethereum以外のチェーンだとNEARというブロックチェーンでもロイヤリティを配布する機能が実装がされているので、こちらも合わせて紹介したいと思います。

※レイヤーについての補足・・・ブロックチェーンには大きく分けてアプリケーションレイヤーとプロトコルレイヤーがあります。ブロックチェーンの機能として担保できるものが後者です。NFTマーケットプレイスはアプリケーションレイヤーにあたります。

f:id:gaudiy:20210818201305p:plain
ブロックチェーンにおけるアプリケーションレイヤーとプロトコルレイヤー
ref. https://www.fsa.go.jp/policy/bgin/ResearchPaper_MRI_ja.pdf

Ethereumにおけるロイヤリティ実装

Ethereumがもっているロイヤリティ機能の要約です。

  • 複数人に対して異なるパーセンテージでロイヤリティを配布できる(ex. NFTコンテンツの売上金のXX%はロイヤリティとして作者Aに、YY%は作者Bに対して支払われる)
  • ロイヤリティ機能が実装されたNFTコンテンツであればどこのNFTマーケットプレイス OR 個人売買でもロイヤリティが作者に配布される

github.com

複数人で作った共同作品を出品した場合、各々が異なるロイヤリティ額を受け取れる設計にできます。著作権の帰属先が複数ある場合などに使えそうです。

実際のサンプルプロジェクトを日本人の方が作成されていたので紹介させていただきます。 バーチャル空間で使えるNFTコンテンツを販売するマーケットプレイスのようです。ここで買ったNFTコンテンツは以後、転売する場合に作者のもとに一定のパーセンテージでロイヤリティが入る設計になっているとのことです。(詳細はこちらのnoteの記事が参考になります)

github.com

NEARにおけるロイヤリティ実装の仕組み

NEARというブロックチェーンでもEthereumと同様にロイヤリティを実装できます。 ロイヤリティ機能もEthereumとほぼ同じです。

Ethereumと異なるのはロイヤリティをパーセンテージではなく、額指定(単位は$NEAR)という点です。個人的にはNEARの価値が上下した際に一定額のロイヤリティ配布だと柔軟性がないようにも感じました。

具体的なNEARのロイヤルティ実装のインターフェイスは以下になります。

github.com

EthreumとNEARの両方の課題

ロイヤリティが配布されるタイミングですが、厳密にはNFTの売買するタイミングではなく、NFTが転送されたタイミングです。 問題はこのNFTの転送が行われたタイミングが「NFTの売買」なのか「NFTの移管」なのか区別ができない点です。

f:id:gaudiy:20210819071013p:plain
NFTの売買と移管はどちらも転送なので区別がつかない

本来の売買のタイミング以外でロイヤリティが過剰に発生してしまう課題に対しては今後方針を決めるようです。

One more reasonable approach MAY use the number of transfers of an NFT to decide which percentage value is used to calculate the royaltyAmount. The idea being that the percentage value could decrease after each transfer of the NFT. Another example could be using a different percentage value for each unique _tokenId.

Ethereumでは一つの提案として転送回数ごとにロイヤリティのパーセンテージを減らす、というアプローチ方法を挙げています。

3. さいごに

NFTコンテンツ作成者も購入者もお互いに取引したくなるようなインセンティブ設計していく上で、ロイヤリティの仕組みをどう扱っていくかが個人的には鍵になってくると思います。

本記事を読んでいただいて、NFT自体の本質的な価値などに興味が湧いた方は弊社CEOの石川が書いた記事がわかりやすいのでぜひこちらもご一読してみてください。

note.com

Gaudiyでは流通プロセスに関わる人全員がNFTコンテンツを扱いたくなるような世界を実現しようとしています。

自分は一年くらい前までブロックチェーンのことは何一つ知らないソフトウェアエンジニアでしたが、Gaudiyに入ってブロックチェーンの思想をチームで議論したり、最新の技術動向を教え合ったりしてこの世界にのめり込むようになりました。

少しでも興味を持っていただけたエンジニアの方は、ぜひTwitteri(@kei32bit)やMeetyなどお気軽にご連絡ください。

▶Meetyはこちら

▶オープンオフィス・オープン勉強会はこちら