Skip to content

Why "Toban ‐当番‐"?

Yuki Kawabe edited this page Aug 27, 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の交換によるマイクロタスクの記録、貢献時間による重み付けを取り入れて貢献の記録を行います。そうすることで、タスクのマイクロマネジメントの煩わしさを取り除きながらも、小さな貢献をなるべく拾い、昔からいる人や継続的に貢献している人に対してのインセンティブを実現しようとしています。

報酬の分配について

どんなユースケースを想定しているか

DAO tool としてのToban

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

Clone this wiki locally