ビジネスとガバナンスの適合性について考えてみましょう。分散型ガバナンスはいつ開始すべきでしょうか?

著者: クリス・アン

出典: ハウン・ベンチャーズ

スタートアップ企業は製品と市場の適合性やビジネスモデルの適合性にこだわるが、ビジネスとガバナンスの適合性について議論することはほとんどない。 Web3 は、特定のガバナンス モデルが特定のプロジェクトにより適しているという、これまで無視されてきたこの概念に新たな注目を集めました。

非暗号ネイティブ プロジェクトの場合、よく知られているトレードオフのため、適切なガバナンス モデルを選択するのは比較的簡単です。専門家でなくても、プロジェクトが公的か民間か、営利か非営利かを答えることができます。暗号ネイティブ プロジェクトの場合、分散化という新しい軸を考慮する必要があるため、決定はより複雑になります。

分散型ガバナンスにより、中央当局の許可なしに誰もが貢献できるようになります。歴史的なガバナンスのパラメーターと同様に、分散化には明らかなトレードオフがあります。一般的な考えに反して、これは一部の Web3 プロジェクトに利益をもたらすツールですが、すべての Web3 プロジェクトに役立つわけではありません。 Web3 創設者は、自分たちのプロジェクトが分散型ガバナンスの恩恵を受けるかどうかを検討する必要があります。

歴史的なガバナンスモデル

歴史的に、ガバナンスの決定は、営利と非営利、公共と民間という 2 つの考慮事項に基づいて行われてきました。

• Apple などの上場営利企業は、取締役会の選出と管理を行う株主の基盤が分散しています。

• フィデリティのような非公開営利企業は株主基盤が集中しており、歴史的には家族経営です。

• 公立大学や病院などの公的非営利団体は理事会によって統治されており、理事会の 50% 以上がその組織に属していてはなりません。また、利益を組織外に分配することはできません。

• ゲイツ財団のような民間非営利団体は通常、寄付者の数が限られており、社外取締役を置く必要はありません。

これらの歴史的なガバナンス モデルの最も顕著な特徴は、人々は適切な許可 (通常は雇用を通じて) を通じてのみ貢献できることです。オープンソース プロジェクト (通常、正式な組織のように運営されていない) を除いて、誰かが単にプロジェクトに貢献することは不可能です。 Apple、Fidelity、大学、または Gates Foundation に貢献 (別名仕事) するには、まず従業員となり、熱心に働き、信頼される必要があります。

MakerDAO は、2018 年に最初の公開 MKR 投票を開催することを決定したとき、分散型ガバナンスの実験を開始しました。それ以来、Uniswap (74 億ドル)、Compound (5 億 2,100 万ドル)、Aave (14 億ドル)、Curve (41 億ドル)、dYdX (20 億ドル) など、web3 の最も著名なプロジェクトのいくつかは分散型ガバナンスを採用しています。これら 5 つのプロジェクトだけでも、完全希薄化後の時価総額は 150 億ドルを超えます (2022 年 7 月 25 日現在)。将来的には、さらに価値のある分散型プロジェクトが数多く登場するでしょう。

ビジネスとガバナンスの適合性の重要性

適切なモデルは戦略的利点として機能するため、適切なガバナンス モデルを選択することは創業者にとって重要な決定です。ガバナンスは、組織に関する 2 つの重要なシグナルを伝えます。

• 約束。企業がガバナンス モデルを選択すると、組織の目標が伝わります。 Facebook メッセンジャーとシグナルの違いについて考えてみましょう。 Signal には明らかに下心がないため、非営利団体としての地位はユーザー第一でプライバシーを保護するという価値提案を強化します。したがって、多くのユーザーは Signal を信頼し、忠実であり続けます。 Facebook Messenger が、たとえ機能が一致していてネットワーク効果が強力であっても、Signal と競合できない領域の 1 つはミッションです。

• 意思決定。各ガバナンス モデルには、誰がどのレベルで意思決定を行うかを決定する独自の意思決定フレームワークが付属しています。たとえば、公開企業は最終的には広範な株主基盤を代表する取締役会に対して責任を負いますが、民間機関は株主の過半数に対して責任を負います。取締役会での決定はハイレベルな決定となる傾向がありますが、取締役会が設定したハイレベルな方向性を実行するための戦略的および戦術的な決定は従業員に委ねられます。

なぜ集中化に進むのでしょうか?

分散化は、誰でも許可なく貢献できるようになるため、独自のガバナンス メカニズムです。たとえば、キッチンの速度が低下したり、場合によっては停滞したりする可能性があるにもかかわらず、なぜ組織はキッチンにもっと多くの有名シェフを配置したいのでしょうか?上記と同じフレームワークを使用して、分散化は次のことを伝えます。

• 約束。これは、組織のユーザー コミュニティと可能な限り連携したいという願望を示しています。歴史的なガバナンス構造において、従業員にならずにプロジェクトに貢献したユーザーの最大の貢献は、指定されたチャネルで製品のフィードバックを提供するか、特定の株主の決議に投票することでした。分散型ガバナンスでは誰でも貢献できるようになるため、分散型プロジェクトは、何をどのように開発するかについてコミュニティを調整し、直接関与させます。

• 意思決定。分散型ガバナンスにより、意思決定と執行があらゆるレベルのコミュニティに移管されます。コミュニティは提案に投票することで、どの変更を実装するかを決定します。また、従業員が担当する詳細な製品改善などの改善を提案し、実行することもできます。

多くの点で、分散型ガバナンスのケースは、ブロックチェーンなどのパブリック パーミッションレス データベースのケースと似ています。後者は集中型アプローチよりも遅く、高価ですが、許可なしの参加という 1 つの側面は、これまで不可能だったまったく新しい価値提案を開くという点で独特です。

分散型ガバナンスに対する最も一般的な批判は、参加者が増えると組織の効率が低下するというものです。この批判は間違いなく正しい。 5 人の意思決定者がいる組織には 10 の可能なコミュニケーション チャネルがありますが、100 人の意思決定者がいる組織 (20 倍の増加) には 4950 のチャネル (495 倍の増加) があります。人の数が増えると、人々の同意を得るための負担が飛躍的に増大します。だからこそ、政治的には独裁政権の方が民主主義よりも迅速に意思決定を下すことができ、ビジネスにおいては民間企業の方が公開企業より機敏に行動できるのです。

分散型ガバナンスを正当化する 1 つの方法は、「多様な視点を最適化する組織は、迅速な意思決定を最適化する組織と競争する価値があるか?」という質問に答えることです。民主主義社会に住む幸運な人々にとって、この例えは共感を呼ぶはずだ。最適化の軸は、速度やコストではなく、広範な表現である場合があります。そうすることで、スピードだけを追求して構築されたプロジェクトよりも、長期にわたって価値のある結果を生み出すことができます。

分散型ガバナンスを選択する

すべての営利組織が上場を目指しているわけではないのと同様に、すべての Web3 プロジェクトを分散化する必要があるわけではありません。このガバナンス メカニズムが戦略的利点を示す組織はプロトコルです。プロトコルは、ユーザーの同じニーズをできるだけ長く解決したいと考えている、完全に中立的なプロジェクトです。このプロトコルには 3 つの特徴があります。

1. 信頼性。製品がこのプロトコルを利用する場合、最も重要な考慮事項は信頼性です。このプロトコルは、100 年後にも現在と同じくらい確実に必要なことを実行できるでしょうか?潜在的な変更について何か意見はありますか?プロトコルの場合、分散型ガバナンスの選択は、その上に製品を構築したい人々との連携を最大限に高めるという意図を示しており、これらの構築者がプロトコルの開発において発言権を持つための直接的なパスを提供します。

2. 製品の表面積が小さい。プロトコルは、他の製品が利用できる最小公倍数の抽象化になるように設計されています。したがって、製品表面積が小さくなる傾向があります。これは、分散型ガバナンスにとって望ましいことです。なぜなら、そのような意思決定は単一の製品機能だけですでに複雑であり、製品の表面積が増えると意思決定がさらに複雑になるからです。

3. 標準化。プロトコルが成功した状態とは、ネットワーク効果を備えた標準となることです。プロトコルに基づいて構築された各増分製品により、次のプロトコルの価値が高まります。分散型ガバナンスは、他の人に参加するよう説得することで直接参加できる製品を提供することで、プロトコルが標準になるのに役立ちます。

さらに、分散化は二者択一ではなく、変動するスケールです。実行の複雑さには明らかなトレードオフがあるため、プロトコルは戦略的に適切な分散化レベルを選択する必要があります。これは、どのレベルの意思決定をコミュニティや事前に定義された (場合によっては選出された) チームと共存させるかを決定することで実現できます。

これには議論の余地があるかもしれませんが、非プロトコル Web3 プロジェクトでは分散型ガバナンスが役に立たない可能性があります。非プロトコル プロジェクトとして、プロジェクトの目標は成長です。成長は、より多くのユーザーとさまざまなユースケースに追加の製品機能を提供することで達成されます。その結果、製品の表面積が大きくなり、多くの意思決定者を不合理に管理することになります。

モジュラーの未来に向けて

適切なガバナンス メカニズムを選択することは、どの組織にとっても戦略的な利点であり、分散化の決定も例外ではありません。プロトコルは現在、分散型ガバナンスを活用するのに最適なタイプのプロジェクトを表しています。

そのような世界では、モジュール型の分散型プロトコル ブロックが独立したアプリケーションと並行して存在することが考えられます。この並行世界は創造するのが難しく、失敗したプロトタイプがたくさんあります。しかし、これは、コミュニティによってコミュニティのために構築され、ユーザーの興味に最も適した代替案に参加するのはエキサイティングな実験です。