a16z：プログレッシブな非中央集権の高度なフレームワーク

著者：Jad Esber と Scott Duke Kominers

編纂：DeFi の道

画像出典：Maze AI によって生成された
分散化は Web3 の最優先事項であり、他のビジネス環境でも非常に有用です。Web3 では、安全性、オープン性、コミュニティの所有権のために中央集権を放棄することが目標ですが、より伝統的な企業においても、分散化は利害関係者の参加やより賢明な意思決定に寄与します。たとえば、分散化は「自己管理型組織」という人気の概念を実行するための鍵です。
しかし、最初から完全に分散化を達成することは難しい場合があり、さらには完全に非現実的であることもあります。プロジェクトや企業の初期設計要素は、しばしばより集中した視野とコントロールを必要とします。初期段階の中央集権は、プロダクトマーケットに適応するために、調整、リリース、迅速な反復を容易にします。

とはいえ、ある程度の中央集権から始めることが、必ずしもそのままの状態を維持することを強いるわけではありません。ここでは、将来の分散化を前提とした高レベルのフレームワークを説明し、いつ、どのようにそれを行うかについてのガイダンスを提供します。これらのガイドラインは、Web3 プロジェクトにも、より伝統的な組織にも適用されます。
私たちの目的は、分散化に興味のある人々がこの課題にどのように対処するかを考える手助けをすることです。しかし、分散化の正確なメカニズムは、具体的なビジネス環境によって大きく異なるため、普遍的な方法は存在しません。したがって、これは単なる紹介であり、コンポーネントに基づいて決定を下すためのゲームハンドブックではなく、全体的な問題を考えるためのフレームワークです。
覚えておくべきことは、分散化は必ずしも「全か無か」ではないということです。適切な計画があれば、時間をかけて分散化を進めることができます。効果的に計画するためには、あなたの企業がどの異なる側面で分散化できるか、そして適切なタイミングでどのように行うかを理解することが重要です。
私たちの多くの経験を例に挙げると、段階的な分散化は、組織が完全にリモート化することに似ています。最初は、単一の中央オフィスで対面の会議を行うことが調整に役立ちますが、時間が経つにつれて、より分散化することが意味を持ちます。しかし、分散型の作業を管理するためには、リモート通信技術への投資や、ビジネス慣行と構造の詳細な記録が必要です。組織を設計する際に、いつかあなたの仕事がリモートで行われることを知っていると、将来の状態がより容易になります。段階的な分散化も同様です。

分散化の価値

分散化とは、制御権と意思決定権を特定の個人、組織、またはグループという中央集権的な実体から分散型ネットワークに移すことを指します。これは、コンテンツ制作、組織ガバナンス、プロセス、さらには技術スタックなど、企業の多くの要素に適用できます。
分散化は通常、機能的です。たとえば、組織は分散型の個人ネットワークから意見を集約することができます。実際、Web3 の価値創造は、共有所有権を利用して多くの人々が同時に参加し、貢献することを促進することに大きく依存しています。（以前の記事では、「ユーザーと直接価値を共有するオープンプラットフォームを構築することが、プラットフォームを含むすべての人にとってより多くの価値を生み出す」と述べました。）
他の場合では、分散化はセキュリティを提供することができます。たとえば、検閲に対抗するためです（ただし、これを実現するためには、ガバナンス構造を正しく構築する必要があります）。さらに、自分のデジタル資産を活用しようとする Web3 プラットフォームは、規制上の理由から分散化が必要です。
おそらく最も重要なのは、分散化がユーザーの最善の利益に基づいて製品を構築するためのコミットメントとして機能することができることです。これは、共同ガバナンスが協同組合に健康的な文化を強調し、メンバー間で資源と利益を長期的に公平に分配することを導く方法に似ています。さらに、計画的に分散化を進めるプロジェクトに自発的に参加する人々がより多くいる可能性があり、これは原則から来るものであり、長期的にはそのようなプロジェクトがより価値があると信じているからです。

分散化は容易ではない

分散化は企業にとって価値があり、さらには必要である一方で、最初は困難な場合があります。多くの圧力が短期的に中央集権を促進し、長期的な分散化に取り組む企業でさえもそうです。

コアの中央チームや集中した意思決定プロセスなしで、製品を立ち上げたり、プロダクトマーケットフィットに達するために迅速に反復したりするという課題を想像してみてください。さらに、Web3 における分散化は、しばしば相互運用性への期待を伴い、他の人がスケールに達する前に「フォーク」するリスクをもたらします。適切に設計されたサポート構造なしで分散型の管理や他の形態のクラウドソーシングを頼ることは、プラットフォームが詐欺や贈賄のリスクにさらされる可能性があります。

これらの力は初期の中央集権を促します。しかし、これらが設計上の決定を導いて将来の分散化をより困難にしないようにすることが重要です。つまり、初期段階で中央集権が必要な良い理由があっても、将来の分散化のために設計を行うべきです。

段階的分散化

以下は、将来の分散化を積極的に計画するためのいくつかのガイダンスです。

まず、あなたのビジネスがどの異なる次元で分散化を実現できるかを特定する必要があります。たとえば、あるプラットフォームは、比較的中央集権的な技術スタックを持ちながら、コンテンツキュレーションを分散化できるかもしれません。特定の製品は「最小分権単位」（MDU）に分割され、これらの単位はほとんど独立しており、その次元に沿ってそれぞれ分権化を進めることができます。MDU にはコアチーム、外部貢献者、技術スタックなどが含まれる可能性があります。これらの次元については、以下で詳しく説明します。

特定の MDU 内でも、0 から 100 まで一気に移行する必要はありません。プラットフォームは、まずコミュニティからコンテンツの提案を求め、その後最終的にコンテンツの決定権を完全に移譲することで、キュレーション権を段階的に分散化することができます。

視覚的には、これはスライダーのセットのように考えられます。おそらく「分散化イコライザー」と呼べるもので、各 MDU に異なる調整があります。あなたは自分のペースで各スライダーを動かすことができ、各スライダーの動かしやすさは、企業がその次元の変化にどれだけ準備ができているかによって決まります。この意味で、分散化の構造を考慮することは初期コストが高いですが、長期的には分散化のプロセスを容易にするため、競争優位性の重要な源となる可能性があります。

MDU の説明

分散化の方法と何を分散化するかについての一貫性を保つことが重要であり、これにはいくつかの高レベルの調整が必要で、通常は「分散化イコライザー」の監視も必要です。異なるビジネスや製品カテゴリにおいて、MDU は異なる場合があり、以下は成功するための分散化の設定に関するいくつかの例です。

1. コアチーム。外部メンバーがいくつかの責任を引き継ぐ可能性があるように、仕事を設定できる人を雇います。たとえば、コミュニティマネージャーを雇うことで、メンバーが自己管理と自己ガバナンスの方法でコミュニティを設計できるようにします。さらに、チームのスキルを向上させるために投資し、分散化を長期的な目標として設定し、これらの努力を支援する新しい技術やベストプラクティスを導入します。

2. 外部貢献者。完全に分散化に向かうにつれて、コミュニティは製品の開発と管理にますます参加できるようになります。望む分散化の程度に応じて、参加型の方法で構築し、コミュニティが共有インフラの構築に参加し、コンテンツを貢献し、システムを管理することを促進します。これは単にコミュニティの参加を招くことではなく、人々が貢献できる方法で組織を設計し、貢献を奨励する必要があります。つまり、強力なフィードバックと参加のチャネル、そしてそれに応じた構造とプロセスを構築する必要があります。

同時に、報酬の面では、コミュニティの貢献を追跡し、報酬を与えるために報酬ポイントやデジタルトークンを導入することが、コミュニティの活動を促進するのに役立ちます（信用システム設計に関する詳細は、私たちのこの++記事++を参照してください）。たとえば、外部の開発者を引き付けてコアインフラをテストさせることから始め、プロトコルに基づいて活動を開始した開発者に報酬を分配することができます。

3. 技術スタック。スタックはモジュール化された方法で構築でき、最初に中央集権的なサービスの分散型バージョンに交換できるようにします。たとえば、最初は AWS にコンテンツを保存し、時間が経つにつれて Arweave や IPFS のような分散型ストレージサービスに移行します。
4. 財務。ビジネスを最初にどのように資金提供し、内部および外部でリソースを分配するかについて、分散化の計画を立てる必要があります。特に、中央の制御なしで組織を維持できるように、柔軟な方法で財務を構築する必要があります。たとえば、あなたが持っている投資家がコミュニティの制御からの退出（私たちはこれを「分散化された退出」と呼ぶことができます）にどのように反応するかを考慮し、定期的にコミュニティに財政的な助成を行うことを検討します。

5. 内部プロセス。分散化するビジネスやビジネスプロセスに必要なものを考えるために、初期段階で時間を投資することが重要です。たとえば、コミュニティメンバーがガバナンスの具体的な決定の前例や背景を理解できるように、豊富な文書が必要になるかもしれません。

あなたの組織の MDU を明確に列挙することは、さまざまな「スライダー」をチームやコミュニティと共有するための明確な視点を提供するのに役立つかもしれません。ロードマップを共有することは、分散化の精神に合致し、コミュニティが目標達成を助けることができます。一度 MDU のセットができたら、各次元におけるスライダーの現在の位置を把握し、時間の経過とともにどのように発展させたいかのビジョンを形成し始めます。もちろん、意味のある操作順序を持ち、問題が発生した場合には、チームが負の影響が少ない MDU から始めるべきです。

どのスライダーをいつ動かすか？

最後に、スライダーを上に移動させるべき時期、つまり、どのタイミングで1つ以上の次元の分散化を増やすことができるかをどうやって知るのでしょうか？

全体的に見ると、まず重要なのは、あなたの全システムが相対的に安定していることです。しかし、これは具体的に何を意味するのでしょうか？a16z の以前の記事で、Jesse Walden はチームに対して、プロダクトマーケットフィットへの道のりでの自分たちの位置を評価するよう促しました。どれだけの反復を経る必要があり、どれくらいの速さで進む必要があるのか？これは重要です。なぜなら、組織の変革は運営のスピードを遅くするからです。スライダーを動かすタイミングを把握し、スピードを遅くする長期的な利益が短期的なコストを上回るようにする必要があります。理想的には、プラットフォームの社会的および経済的ダイナミクスが十分に安定しており、分散化のレベルを調整することがコミュニティの行動や結果にどのように影響するかを強く予測できるときに、移動を行います。

次に、各 MDU を順番に評価する必要があります。スライダーを調整するかどうかを決定する際に、各次元には独自の要因のセットがあり、それを考慮する必要があります。

特定の次元で分散化を進めるように促されるかもしれません。たとえば、ユーザー生成コンテンツが多すぎて自分で管理する必要がある場合、より多くのコミュニティがキュレーションに参加することが重要になります。また、完全に自分の意志で分散化を進めることを選択することもあります。たとえば、分散化された方法でコンテンツを保存することの長期的なビジネス価値を見出した場合、そのようなサービスを使用することを積極的に選択することになります。

再度言いますが、これは全か無かではありません。分散化は各 MDU に沿って異なる速度で進行します。たとえば、最初の日から財務を計画し、「コミュニティからの退出」の選択肢を保持し、6 か月後にコミュニティ財務を構築し、その後完全に分散化された財務管理に移行することができます。

同時に、安定した製品を反復しながら、中央集権的な技術スタックを維持することもできます。

***

分散化は強力ですが、容易ではありません。特に初期段階では、迅速な反復、品質管理、安全性のニーズが中央集権的な開発を必要とすることが多いです（ただし、これは分散化された開発技術の改善に伴い変わる可能性があります）。

企業を長期的に分散化された状態に保つことが目標であるなら、初期段階で計画を立てて、構築プロセスで追跡を失わないようにすることが重要です。私たちは、CEO や COO の役割が「分散化イコライザー」を管理するために進化するのを目にするかもしれません。さらには、「最高分散化責任者」のような全く新しい役職が導入されるかもしれません。

MDU の観点から考えることで、ビジネスのさまざまな側面をどこで、どのように分散化するかを明確にすることができます。製品が進化するにつれて、タイミングが整ったときに、各 MDU に沿って段階的に分散化を進めることができます。