第29章 · Crypto BDは何をつなぐのか

現実の問題

同じプロトコル、同じ四半期に、二人のBDがいる。

一人目の報告は、新規連絡先400件超、業界会議六回、提携意向30件超、共同発表12件。どの発表にも戦略的提携と書かれ、美しい画像が付く。

二人目は三行だけだ。

ウォレットの資産ページに、プロトコルへの入口が加わった
マーケットメーカーが二つの取引ペアで継続的な気配値を出し始めた
広く使われる基盤が、データインターフェースを統合した

一四半期で三件。報告会では一人目の資料が厚い。

半年後、一人目の12発表に対応する測定可能な曲線変化は、一つもない。 第23章の方法で、発表前後のアクティブアドレス、取引量、資金流入を調べても、識別できる変化がない。

二人目には各一曲線がある。ウォレット経由の呼び出しは新規利用の主要な供給源になり、気配値の提供後には標準取引額のスリッページが十分の一になった。データ統合後には三製品が連絡なしに接続した。

同じ職務と時間でも、成果は全く違う。

問うのは、BDの成果とは何か。連絡先数でなければ何を数え、実現したとどう分かるか。

思考実験

知らない街でパン屋を開き、最初の週に必要な相手をリストにする。

相手は数種類に分かれ、欲しいものが全く違う。

仕入先。 小麦、バター、包装。安定注文と期日どおりの支払いが欲しい。予測可能な購入と、長く続く店だと判断できる根拠を渡せる。

販売を助ける人。 配達サービス、隣のカフェ、オフィスの受付。顧客を満足させ、手間を増やさないものが欲しい。安定した品質と、気を使わず受け渡せる手順を渡せる。

見えるようにする人。 商業施設が看板を一階入口に置くか、地下二階の隅に置くか。入口の店には人を呼び、自分の施設の評判を傷つけないことを求める。

貸してくれる人。 お金を回収したい。筋の通る収支を示せる。

技術を教え、信用を貸す人。 有名な職人が名前を掲げるなら、店で自分の評判を損なわないことを求める。

気づくのは、あなたは提携を望むが、提携そのものを望む人はいないことだ。 各自が評価される具体的な何かを求めている。

交渉は同じ三行にできる。

欲しいもの：       自分のどの曲線を変えるか
渡せるもの：       相手のどの曲線を変えるか
相手が応じる理由： 相手の評価で何番目の優先度か

三行目を書けない提携は起きず、起きても実行されない。

商業施設と戦略的提携を結び、双方が発表したとする。しかし店は地下二階に置かれた。

発表は本当でも、提携は実質を伴わない。 違いは、具体的なことが完了し、第三者にも見えるかだ。

パン屋をプロトコルに替えても同じだ。一つの違いは、オンチェーンでは具体的な完了を第三者が直接検証できる場合が多いことだ。

あなたが決める

新プロトコルでBDは一人、期間は三か月。四方向から最初の一つを選ぶ。

結果を観察する

異なる四方向の成果は三種類になる。

BDがつなぐのは流動性、流通、統合であり、連絡帳の長さではない。

実用的な共通点は、すべて第三者が検証でき、大半はオンチェーンで確かめられることだ。

提携を四問で点検する。

全問に答えられないものは、厳しいが正確に、発表が納品と呼ばれる。

発表自体にも価値はある。 採用、資金調達、コミュニティ心理に効く。問題はBD成果として評価することだ。提携の副産物であり、提携そのものではない。

モデルを作る

資源ネットワークの六役割

周囲の資源を図にし、六役割を置く。

一つずつ展開する。章の中心となる表なので、ノートへ写すとよい。

第四列は多くのBDが最も弱い列だ。 自分の製品の深さ、権限構造、API安定性、データ公開可能性を十分理解する必要がある。

BDを第五段階に置く理由でもある。 第15章の流動性、第24章の権限、第26章の収益配分を知らなければ第四列を埋められず、第一列の要求しか話せない。

交換モデルの三問

最初のメールを書く前に答える。

1. 相手の評価指標は何か。理念でなく、年末に問われる数字。
2. その指標を直接動かせるか。できれば方法を、できなければ別の切り口を探す。
3. 動かせないなら、この提携は何か。多くは広報なので、広報として扱い、BD評価にしない。

第一問が中心で、最も省略されやすい。

ウォレットは継続と自社収入、メーカーはリスク調整収益、財団は件数と利用量、取引場所は量と法令リスクを見る。統合側の開発者は、接続で手間が増えるかだけを気にするかもしれない。

同じ資料を六役割へ送るのは、最もよくある非効率だ。

市場心理に依存するかで優先度を決める

資源は足りないので、順番が重要だ。大物から、より良い基準がある。

第28章のファネルが根拠だ。第一群は流通に作用し、終了日がない。 第三群は注目で、半減期は日単位だ。

例外は、立ち上げでは第二群が第一群の前提になりやすいことだ。 深さ不足では入口も統合も進まない。まず深さを合格水準へ、その後に流通を交渉する。

提案の構造

有効な提案は四段で、一画面以内だ。

第一段：自分たちを一文で示し、検証可能な数字を添える。
        「業界をリード」より、「直近30日、XアドレスがY取引を完了。
          この場所で照合できる」。

第二段：実現したい具体的な一件。
        「提携の可能性を検討」より、「交換画面にこの経路を加える」。

第三段：相手のどの指標に役立ち、なぜか。
        手紙の中心で、最も欠けやすい。

第四段：準備済みのもの。
        API文書、監査報告、テストネット、担当者、日程。

第三段だけはテンプレートに任せられない。 評価指標を知るには、相手の製品、公開資料、過去の提携を研究する必要がある。

第四段は相手の着手費用を減らす。 拒否より、準備が重く無期限に保留される例が多い。先に準備すれば、依頼から用意済みの選択肢へ変わる。

何と呼ぶか

実践

select
  tx_from                   as caller,
  count(*)                  as calls,
  count(distinct tx_hash)   as txs
from <プラットフォームのイベント表>
where contract_address = <プロトコルのメインコントラクト>
  and block_time >= now() - interval '30' day
group by 1
order by 2 desc
limit 50

線に書く：具体的な相手
太さ：    実際の量（呼出量、深さ、利用者源の割合）
色：      検証済み / 発表のみ / 確認できない

最も強い資源接続：______。根拠：______
最も弱い接続：    ______。根拠：______
自分がBDなら次の四半期に最初にすること：______。理由：______

AI Lab

四段、一画面以内の提携提案を起草してください。

こちら：<名称、機能、検証可能な数字と出典>
相手：<誰か、六役割のどれか>
実現したいこと：<成果物を含む一文>

第一段：自己紹介を一文で。検証可能な数字と照合場所を必ず付ける。
第二段：具体的な一件。成果物と時期を含める。
第三段：相手のどの指標に役立つか。
        まず相手の中心的な評価指標だと考えるものを示し、どう動かすか説明する。
        分からなければ「分からない」と書き、創作しない。
第四段：用意済みの文書、監査、テスト環境、担当者、日程。

規則：
- 先進的、革命的、戦略的提携などの言葉は使わない。
- 履行できない約束をしない。
- 提携実績や数字を創作しない。数字には出典を付ける。
- 第三段を書けないなら、足りない情報を明示する。

実例

変数を一つ変える

持ち帰る問い

章末チェック