Skip to content

Why "Toban ‐当番‐"?

Yuki Kawabe edited this page Aug 29, 2024 · 9 revisions

このページではなぜ貢献の記録と報酬の分配のしくみであるTobanをつくりたいと思ったかをいくつかの観点からまとめています。 共感したり、応援したいとおもった方はぜひ小さくてもお手伝いいただけたら嬉しいです。エンジニアの方はGitHubへのコントリビューション、デザイナーの方は1つのページやいくつかのコンポーネントだけでも、実際に使ってみたい・使うと良さそうなところを知っているという方はぜひ課題やほしい機能、懸念していることなどを教えて下さい。

コミュニケーションはGitHubのIssueを作っていただいてもいいですし、HackdaysコミュニティのDiscordで発言もウェルカムです。

だれが、なぜ、必要か

インターネットネイティブなコラボレーションによって新しい価値を生み出そうとしている人たちやコミュニティが、手伝ってくれる人たちや自分たち自身に適切に還元していき、活動を持続可能にするために必要だと考えています。

インターネットネイティブなコラボレーションの中には、リモートベースのソフトウェア開発やアート制作、音楽制作だけでなく、森や川などの自然や美しい景色をもつ地域を残していくための活動も含まれます。地方創生へのアプローチにDAOを使う方法が実験されていますが、そういった活動はひとつのコアユースケースになります。

このような活動には大きく以下の特徴があると考えています。

  • たくさんの人が入れ代わり立ち代わり関わり、少しづつ貢献していく。長く貢献しつづける人は一人または数人と稀。
  • 最初はボランティア精神で参加しはじめるが、長く続けてもらうためには何らかの還元が必要になる。プロジェクトオーナーも手伝ってもらうばかりでは心苦しい。
  • 活動が長くなるにつれて、前提となる情報やコンテンクストが積み上がり、深みを増していく。一方で新しい人がどこから入っていくといいのかわからなっていく。
  • 活動スタート時点では資金・人・つながりなど様々なリソースが足りないことが多い。

このような条件の中で、Tobanは「当番ベースの報酬分配(Role Based Rewards Distribution)」の仕組みなら、継続的に活動していくことを支えるひとつの道具になるのではという仮説で開発を始めました。実際の現場で使って実験しないことには、検証も改善もできないのでOSSとして一緒につくる仲間や実際につかったり、使える場所を探してくれる仲間を集めてつくり始めています。

貢献の記録と評価について

インターネットネイテイブなコラボレーションにおける貢献を記録する仕組みは様々なものがあります。

  • タスクベースで作業を用意し、コントリビューターが1つづつ申請していくもの。(Ex. DeWorkCharmverseGithubTrello
  • 期間を決めてその間に行われた仕事やコラボレーションをP2Pで評価をしあうもの。(Ex. Coordinape, Praise
  • GitHubやDiscordでの相互エンゲージメントに重みを付けてアルゴリズムでスコアリングするもの。(Ex. SourceCred

どのアプリケーションも機能が充実しており様々なコミュニティでも利用してきました。一方で、これらの仕組みを使い続けるための文化や習慣がなかなか根付かないとい課題も感じています。例えば、タスクを実行したあとの申請をいつの間にかやらなくなっていたり、相互評価で点数をつけあうことに違和感を感じたり。また、頑張って貢献を記録し始めてもその実績に対して還元を得られるときまで続けることができないという、プロジェクトの成長速度と人間の報酬系の時間軸の不一致などもあります。

Tobanでは、役割ベースのオプティミスティックな貢献記録をベースに、P2PでのFraction Tokenの交換によるマイクロタスクの記録、貢献時間による重み付けを取り入れて貢献の記録を行います。そうすることで、タスクのマイクロマネジメントの煩わしさを取り除きながらも、小さな貢献をなるべく拾い、昔からいる人や継続的に貢献している人に対してのインセンティブを実現しようとしています。

報酬の分配について

プロジェクトが始まったときには貢献してくれた人に還元するための資金がないプロジェクトでも、プロジェクト活動での収益や寄付によってそのリソースが入ってくる場合があります。また、コミュニティによっては独自トークンを発行して、それをコミュニティ内で流通させることでエンゲージメントを高めようとする場合もあります。 その時に誰にどれぐらい分配するか、分配の作業はどのように行うかという2つの問いがあります。

誰にどれぐらい分配するか

まず、人が少ないときや、プロジェクトの先行きが全く読めないときから支えてくれた人たちにたくさん還元したい、ということが言えます。一方で、昔からの人を優遇しすぎると、最近参加した人が昔からいる人に追いつくことができずアクティブに貢献する動機が弱くなってしまう問題もあります。 そこで、Tobanでは貢献期間による重み付けを貢献時間の平方根にすることで、差をつけながらもあとから追いつくことができるような仕組みを作ろうとしています。

他にはコミュニティにたくさん貢献している人にたくさん還元したい、ということも言えます。その一方で手数が多く一見たくさん貢献しているように見えるタスクもあれば、時間がかかったり地味だったりあまり貢献していないように見えても実は重要なタスクもあります。 そこで、Tobanでは役割ごとに重みをつけられるようにして、その重み付けも投票で決められるような仕組みを作ろうとしています。また、同じ役割でも期間によってはその貢献度合いが異なることもあるので、何度でも分配比率を見直せる設計にしています。

分配作業はどのように行うか

コントリビューターそれぞれが異なるスキル・キャパシティで貢献するなかで、一人ひとりの額を計算して分配するのを手作業でやるにはかなりの手間がかかります。また、コントリビューターへ還元する何らかのトークンや資金が入るタイミングが読めないもしくは不定期であると、その作業はより複雑さを増します。 そこで、Tobanでは分配率を決めたらそのルールに則って自動的に分配される仕組みをSplitsとSuperfluidを取り入れてつくっています。あるスマートコントラクトにネイティブトークン・ERC20トークンをいれるだけで自動的に分配されるようにします。

DAO Tool としてのToban

TobanはDAO Toolの1つとしてつくろうとしています。メンバー管理、投票、貢献記録、報酬分配、資金管理、資金調達などさまざまなツールが世界中で開発されています。 それぞれのツールは特徴があり使い所や強みは異なりますが、多くの人がもつ理想像はそれらのツールを組み合わせて(スマートコントラクトのコンポーザビリティを活用して)自分たちに合った意思決定や資金の分配方法を行う状態です。

Tobanは世界で開発されている様々なDAO ToolやProtocolと相互運用性をなるべく持ちながら育てていきたいと考えています。現在のプロトタイプではHats Protocol、Sprits、Superfluid、ENSと組み合わせて使えるように進めていますが、DAOHausやSafe、Zodiacなどその他とも組み合わせて使えるようにしていきます。

これは、今日本にあるDAOやDAO Toolが世界との接続をあまり考えず、独自の道を進んでいるのとは異なるアプローチだと考えています。

なぜ"Toban -当番-"という名前か

いまインターネットネイティブなコラボレーションを支えるツールのほとんどは欧米のチームがつくっており、ツールごとの発想も欧米の考え方からつくられています。これらを日本、アジアの国々がそのまま使っても文化的にフィットしない経験を何度かしています。

そこでTobanは日本・アジアの文化にフィットしたツールであることを目指すために日本語の「当番: 順送りに仕事の番に当たること。また、その番に当たる人。」からとっています。その上で、世界中で使われているツールと相互運用性をもたせることで、世界にアジアの考え方が伝わっていくことをねらっています。