10倍優れた体験を
USで得た気づき
「優れたプロダクトは、たった一つのジョブを他のアプリより10倍素晴らしく満たすものだ。」
2022年頃、米国拠点に移すことを視野に、サンフランシスコとオースティンを訪れた。現地のアプリを体験し、起業家と対話し、大手テック企業やスタンフォード大学を訪問する中で、重要な気づきを得た。
それは「シンプルかつ根源的なニーズに対し、圧倒的に優れた解決策を提示すること」の重要性だ。
特に、キックボードのBirdに乗った際の衝撃は忘れられない
「思い立った時に、他の移動手段よりも手軽かつピンポイントで移動したい」というニーズに対し、
どこにでもあるキックボード
シームレスなオンボーディング
目的地の手前で乗り捨て可能な
これらの要素が、ユーザーに圧倒的に優れた体験を提供していた。
Teracyの本質的価値を問う
「Teracyの一番の価値は何？」
2022年頃SFで、とある起業家から問われた。
ひとことで答えられなかった。
いや、正確に言うと答えたが、「答えるために答えた」という感じで、この本質的な問いに「自分自身の中」で腹落ちできるレベルにシャープではなかった。
穴があれば入りたかった。
今思い返すと当時は、「レコード×AIで、同期会話の非同期化(Sync-to-Async)」こそがコアであると説明していた。
でもそれは今思うと違った。
重要なバリューであっても、コアではない。
人々が求めている「根源的な願いを叶えるもの」ではない、と。
悔しくて、近くのメキシコ料理が立ち並ぶ通りでピッチャーでビールを頼み、それを飲みながらその時の感情や何をするべきなのかを必死にPCに書きまとめていた記憶がある。テキーラを頼まなかったのは、まだ正気を保っていたのかもしれない。苦い想い出だ。
そんな苦い想い出の当時に作っていた2つ目のバージョンは以下だ。
1つ目のバージョンでは、リモートの気軽な会話や環境をつくっていたが、それでは組織のワークフローに乗せ切ることが難しく、シームレスにアクティベーションできる体験ではなかったという反省があった。
そのため、2つ目のバージョンでは、社内外の同期会話をトレーサブルに、また非同期化することで、チームのコンテキスト格差をなくすものを目指した。
しかしこれには、マーケティング視点でも構造的課題があった。
この製品体験は、エンタープライズに営業で導入するような製品体験であり、スモールチームや個人からボトムアップで広がる、世界で普及したプロダクトの法則性・性質を捉えたものでもなかった。
FigmaやNotionを使い始めるのに、誰かから営業を受けただろうか？
ある意味、1つ目のバージョンの失敗を繰り返したのだ。
捻り出す
新たな大きな気づきを得た自分はキックボードでサンノゼ周辺を走っていた。
ボードを走らせながらも頭の中はそのことでいっぱいだった。
「どうすれば人々の願いを満たすことができるのか」
「人々は潜在的に何を願っているのか」
ということを。
そこで何かが頭の中に落ちてきた。
そうか、「タクシーのトランシーバーだ。」と
トランシーバーUXへのピボット
BirdやUberの体験から着想を得て、
「人々はすぐに話せる"状態"を求めているのではないか」
という仮説に至った。
言葉の妙だが、すぐに話せるということよりも、その状態が確実かつ無意識に用意されていることが必要なのではないかということだ。
そこで、タクシーのトランシーバーのアプローチは実は優れているのではないかという仮説だ。なぜなら常に同期されている状態で、それを意識せずに認知負荷はさほどかかっていない。
その状態をリモートワークで実現することができれば、今のリモートにおけるコミュニケーションの課題はシンプルに解決できるのではないかと考えた。
サンフランシスコからオースティンに移ってすぐに、検証を開始した。
今でも鮮明に覚えている、オースティンの灼熱の太陽を歩き、カフェに入り没頭した。
簡易的なFigmaのプロトタイプやスライドを作成し、日本にいたデザイナーと連携しプロトタイピングを開始。
またレンタルした実機のトランシーバーを各メンバーへ配布し、その価値を開発せずに検証した。
そこから一定の確信を持てたので、開発を始め2022年末にはテストリリースに漕ぎ着けた。
まさにトランシーバーをPCに拡張機能のようにインストールし、いつでも話せる状態を構築した。
それらはコミュニケーションにおける
あらゆる承認ステップを取り除いたものだった。
電話を「受ける」
Slack Huddlesの「話せるかの確認」「ルームに入る」
バーチャルオフィスツールの「ブラウザアクセス」「入室」
ZoomやGoogle Meetの「スケジュール調整」「リンク発行」
といった承認ステップを省き、
認知負荷を最小化した「PCの拡張機能のように」ミニマルに使える点が特徴だった。
また、相手がPCオンラインかがわかることで「声を発すれば、聴こえる」という前提を担保し
「人々はすぐに話せる"状態"を求めているのではないか」
という仮説へ、当時の自分たちなりの解を出した。
以下が、3つ目となるトランシーバーアプリである。
Transceiver for Remote Workといったところだろうか。
スクラップアンドビルド、チーム解散へ
このUXピボットの際にはコードも書き直し、アーキテクチャ自体も見直すことにした。
2つ目のバージョンでは自分の未熟さもあり、本質的なPSFがなされていない状態で月に1000万円ほどを投下し開発を進めていた。
ゼロからつくり直す必要を感じていたため、15名ほどのエンジニアに一人ずつ頭を下げて業務を終了してもらう決断をした。
自分を信じてついてきてくれた方々に心苦しい思いで一人ずつ、USの後に移動した南米でリモートで面談を行い、手に汗が滲むなか、一人ずつに頭を下げた。
(ホテルでオンライン面談を詰め込み、その時の心情を残すため。窓からの景色を撮ったもの)
・・・
ゼロから技術的な基盤も、チームの基盤も、UXの基盤も作り直すんだ。
そう強い意志で向き合った。これで活路を見出すんだ。
と、信じていた。
これでは問題を大きく解決できない
そして、そこから3ヶ月ほどの開発期間を経て生まれたTransceiver appのMVP。
しかし、このアプローチも完璧ではなかった。
心理的なハードルが高く、期待したほど会話が増えなかったのだ。
愕然とした。
期待していただけに、目の前の景色全てがブラックアウトするような感覚だった。
タクシーのトランシーバーは「運転をしている人」と「配車の指示をする人」という明確な役割の間において、声かけの内容が事前に想起できることをお互いに認識しているためハードルが低いコミュニケーション手段になっていた。
しかし、リモートワークにおいては相手が忙しいか、話せるかどうかなどの状態、また内容がどの程度の時間がかかるものなのか、などの暗黙知を形成するのが難しい高いため、心理コストが高いままだったのだ。
仲間の存在・状態、という非常に曖昧で重要なピースが欠けていた。
別事業を売却した資金があったため投資を続けてこれたが、
その資金さえもじりじりと減少する中、
最後の光を求めて思考を深めた。
そこから、世界を変えうる本質的な要素を見出すことになる。
