Web3をどう進めるか：グーグル、リブラを経験した開発者が得た教訓【コラム】

画期的なテクノロジーは、その価値を約束したうえで開発される。人間の協調の何らかの要素を紛れもなく改善する新しいものを生み出すことができるという約束だ。

サトシ・ナカモトがビットコインのホワイトペーパーを発表して以来、暗号資産支持者たちはこのテクノロジーが秘める、巨大で革命的な価値をアピールしてきた。サプライチェーンからアイデンティティ、金融まで、あらゆるものに活用できるWeb3は、世界のシステミックな問題に対する万能薬のように言われている。オンチェーンにすれば、すべて解決できると。

グーグルとリブラ

私が初めてブロックチェーンを知ったのは、グーグルでKubeflowというオープンソースプロジェクトの責任者をしていた時だ。開発者としての私にとって、オープンプロトコルの方がウェブを席巻していたクローズドシステムよりも優れていることは明らかだった。

しかし、Web3の初期の盛り上がりサイクルを牽引していたユースケースは実験的で、リスクが高いものも多かった。グーグルのモットーは「邪悪になるな」だったが、初期のWeb3のスローガンは「小心者はお呼びでない」のようだった。

私は2018年、当時のフェイスブックに加わり、野心的であると同時に、議論を呼んだステーブルコインプロジェクト「リブラ（Libra）」の設計・開発に携わった。批判もあるが、フェイスブックが画期的なテクノロジーだったことは間違いない。人間の協調を国際的に変えるコミュニケーションとコネクティビティという形で巨大な価値を解き放った。フェイスブックのアプリは直感的で便利、アクセスしやすいものだった。

フェイスブックはリブラのローンチによって、Web3にフェイスブックアプリと同じユーザーエクスペリエンス（UX）をもたらそうとしていた（Web3の基本的なオープン性を放棄した形だったが）。

リブラが成功していれば、ステーブルコインと金融プロダクトのエコシステムへのアクセスを何十億もの人々に届け、ブロックチェーンのデイリーアクティブユーザー数を一晩で桁違いに増加させていただろう。

しかし、そうはならなかった。そして世界にとってはその方が良かった。

Web2での教訓

私はWeb2大手で働きながら、エンジニアとして多くの教訓を得た。クローズドソーステクノロジーの限界、それが生み出す不平等を身をもって体験した。だからこそ、Web3での開発はエキサイティング。

分散化のメリットは、コンセプチュアルなことが大好きな開発者にとっては魅力的だが、潜在的ユーザーである多くの人に説明することは難しい。そもそも多くの人が理解できない問題をWeb3がどのように解決するのかを多くの人に説明することは困難。既存のソリューションが問題なく機能しているように思える場合は、なおさらだ。

分散型テクノロジー上でアプリケーションを開発する複雑さが開発者とユーザーの間にギャップを生み、ギャップは広がるばかりだ。

Web3で意義あるインパクトを生み出すには、技術的なプロセスにこだわるのではなく、ユーザーがすぐに感じられる価値にフォーカスする必要がある。技術的な完璧さを目指す代わりに、実世界の問題を解決し、Web3のメインストリームでの普及を後押しするユーザーフレンドリーでアクセスしやすいアプリケーションを開発することを優先すべき。

究極的に、価値はテクノロジーの中身がいかに洗練されているかではなく、プロダクトを使う人たちが決める。

Web3は何の役に立つのか？

分散化による革命が始まって約15年。すでに無数のエキサイティングなユースケースを支える堅固な技術的基盤は整っている。紛れもなく価値を生み、メインストリームの認知を獲得したWeb3モデルの上に新しい業界が構築され、生まれている。しかし、認知されていても、メインストリームに普及しているわけではない。

Web3は変革を生むテクノロジーだが、ブレイクスルーを実現するには、価値の捉え方をイデオロギー的な未来から、ユーザーがすぐに享受できる価値を中心としたものにシフトさせる必要がある。よりユーザー中心的なアプローチを採用し、Web3の価値をより多くの人にとって重要なものにし、人々が認識できる非効率性に対する魅力的なソリューションを提供する必要がある。

十分に定義されているがあまり理解されていないフレーズよりも開発者が好きなものがあるとすれば、それは十分に整理されたリスト。テクノロジーと顧客にとっての価値のバランスを取るための、私のエンジニアリング原則を紹介しよう。

顧客を優先する：私たちの究極のゴールは顧客に価値を届けること。私たちが下すすべての決断、開発するすべての機能、従うすべてのプロセスは、顧客のニーズを理解することに導かれるべき。
技術的な洗練だけではなく、顧客価値のために最適化する：技術的に最も高度なシステムが必ずしも顧客にとって最善の選択肢とは限らない。技術的性能と、価値提供までの時間を天秤にかけ、顧客に最短で最大の価値を提供できるものを選ぶべき。
プロセスだけでなく、インパクトにフォーカスする：顧客にとっては、我々がここに至ったプロセスではなく、私たちがもたらす結果が重要だ。厳格なプロセスを選ぶことよりも、有意義な結果をもたらすことを優先すべき。
機敏に、迅速に動く：私たちは複数のプロダクトのアイデアを素早く、繰り返しテストし、その成果を顧客に届けなければならない。きわめて機敏かつ市場/顧客からのフィードバックに合わせて方向性を変えられるようにしておかなければならない。
完璧を目指すのではなく、完成させる：優れたものを目指すことは大切だが、与えられた時間の中でできることには限りがあることを認めることも同じくらい大切だ。
集団的オーナーシップと個人の説明責任：チームの全メンバーがコードに責任を持ち、変更を加える権限を持つ。だが同時に各メンバーは個々に自らの作業のクオリティと保守性に責任を負う。

ハードルは高い。だが、これがマスに普及するためのブレイクスルーには必要だ。