ソフトウェアが成功する仕組み

優れたソフトウェアへの第一歩は「成功のシナリオ」である

ソフトウェアの成功を診断する

成功するソフトウェアを作りたいなら、まず成功例を調べることから始めるとよい。この記事では、よく知られた1つの事例を取り上げ、それが成功した理由、その秘訣を特定し、同じ戦略が同様の成功例にどう適用できるかを示す。

あるアプリが大成功した理由を理解しようとして、ユーザーにそのアプリが好きな理由を尋ねると「とにかくちゃんと動くから」という答えが返ってくることがよくある。これが何なのか、つまり「とにかくちゃんと動く」とは実際に何を意味するのかを明らかにするのは簡単ではないが、「とにかくちゃんと動く」の重要な要素を特定することは可能だ。後ほどやってみせよう。

ZoomがどうやってSkypeを倒したか

2019年、Skypeの登録ユーザーは40億人に達し、ビデオ通話市場の約3分の1を占めていた。その後パンデミックが発生した。ほとんどの人が聞いたことさえなかった製品であるZoomが普及し、"zooming"という言葉が一般に広まった。 2021年までにZoomは市場の半分を占め、10億ドル近くの収益を上げ、Skypeは視界から消えた。

Zoomは、人々が「とにかくちゃんと動く」と表現するアプリの1つだ。これを探るために、ユーザーの観点からZoomがどのように機能するかを考えてみよう。会議を作成すると、友人と共有するリンクが生成される。次に、会議を開始すると、友人はあなたが提供したリンクを使用して、好きなタイミングで参加できる。完了したら、会議を終了する。このシナリオは以下のような、実行されるアクションを示す図で表すことができる。この図の、複数の矢印が分岐し合流している箇所では、複数の人が任意の順で参加できることを示している。

これをSkypeを使用する場合と比較してみよう。 Skypeでグループビデオ通話を設定するには、それぞれの友人をグループに追加してから通話をかけ、何人かが応答して、そして切断する。

一見、特に悪くはないように思える。ステップ数やシナリオの構造という点では、それほど複雑ではない。問題は、赤いボックスで囲った手順の一部が煩雑なことだ。「追加」では連絡先リストを調べて、一度に1人ずつ検索する。友人が連絡先リストにない場合は、その連絡先情報を取得して追加する必要がある。さらに悪いことに、友人がSkypeユーザーでない場合、その友達を招待することが一切できない。応答のステップもそれほど簡単ではない。友人はアプリを開いて通話がかかってきた瞬間にその場にいるか、見逃した通知を見つける必要がある。

これは大げさに書きたてているだけでは、とあなたはもしかすると今思っているかもしれない。既にSkypeにいる友人2人と話すだけならさして問題はないし、その場合あなたは正しい。しかしパンデミックによって状況は変わり、人々はあらゆる異なる種類の人々――友人、同僚、近所の人々――と話そうとするようになり、一度に話す人数も増えた。そうして、Skypeのちょっとした面倒臭さは大きな障壁となったのだ。

この文脈において、Zoom のソリューションは、私の研究仲間であるメリック・ファーストが "not not"（「〜しないで〜する訳にはいかない」）と呼ぶものだった。Zoomのシナリオを持たないですませる訳にはいかなかったのだ。Zoomでは単にリンクを共有し、それをただクリックすれば会議に参加でき、しかもZoomアカウントを持っているかどうかは関係なかった。

それが全てではない

もちろん、それが全てではない。 Skypeのビデオ通話シナリオからZoomの会議シナリオへの変遷は、突然起こったわけでもなく、また明確に線引きができるものでもなかった。

Zoomのアイデア (会議リンクを事前に非同期で作成するという方法) は、2010年のLogMeInに由来すると見ることができる。LogMeInは、Citrixといった企業の既存製品よりもはるかに軽量なビデオ会議ソリューションを構築した。 Zoomは2012年の創業時からこのアイデアを使用していたが、2020年にその価値を認識していた唯一の企業ではなかった。 Skypeは2015年に会議リンクを追加し、その1年後にはGoogleハングアウトにも追加されていた。

しかしどちらの場合も、アイデアは中途半端な形で組み込まれていた。それは会議を開始するためのデフォルトの方法ではなかった。 Skypeでは、ビデオ通話に直接リンクすることはできず、チャットからのみビデオ通話を開始できた。 Skypeはこれに気づき（遅ればせながら、2020年4月に）ビデオ通話への直接リンクを可能にする "Meet Now" という新機能を追加した。またハングアウトは、ホストはアカウントを持たないユーザーを許可できたものの、Zoom の「待機室」のように承認が必要で、大規模な（プライベートではない）会議では邪魔だった。

他にも込み入った事情がある。 Zoomの成功は、間違いなくアプリのインストールの容易さによるものだったが、そこには、ユーザーによる追加の承認手順を必要とするOSの保護を回避するための（マルウェア開発者から学んだ）いかがわしい技術が使われていた。 Zoomはエンドツーエンドの暗号化についても虚偽の説明をしていた。

しかし、こうしたいずれの事情をもってしても、Zoomが競合他社よりも、ユーザーが必要とするものにマッチするシナリオ――つまり、対話のパターン――を提供したという事実は否定できない。

「とにかくちゃんと動く」とはどういう意味か

これらすべてを念頭に置いて、今こそこの疑問に取り組むことができる。つまり、「とにかくちゃんと動く」ゆえにZoomに切り替えたと人々が言うとき、それは何を意味するのか？

シナリオに説得力がある。それゆえ、どういうステップをどういう順で行わないといけないかが明白である。 Zoomの場合、ステップが非常に少なく、どのタイミングでも選択肢がほとんどないため、シナリオが簡単である。会議を作成したら、それを開始する以外にできることはほとんどない。そして、それを開始または参加した後は、退出する以外に何もすることがない（もちろん、マイクをミュートにするなど他にも実行できるアクションはあるが、それらがメインの会議シナリオと無関係なのは明らかだ）。
ペインポイントがない。このシナリオを実行する際に、追加する連絡先を検索しないといけないことや、通話の招待に応じるためにアカウントを作成する必要があることなど、Skypeでのグループ通話時のような面倒さが全くない。
目的がシンプルである。それゆえアプリがどんなものかを簡単に判断できる。Zoom の場合、その目的は複数の参加者とビデオ通話を開始することだった。すべてのアプリがそのような単一の目的を持っているわけではない。たとえばPhotoshopは、非常に多くの異なる複雑な目的を果たしているため、「ただちゃんと動く」と人々が考えるかどうか疑問だ。

ただそうなっているだけの話

先ほど "not not" という考えに言及したメリック・ファーストは、彼の言うところの「ただそうなっているだけの話」（Just So story）に懐疑的だ。それは、イノベーションがなぜ成功したか、あるいは失敗したかについて説得力のありそうな説明を提示するお話のことだ。
「ただそうなっているだけの話」は優れた用語で、ラドヤード・キプリングの童話を思い起こさせる。彼の童話は、生物学者ルイス・ヘルドによれば「ヒョウの斑点がどのようにしてできたのか、ゾウの鼻がどのようにしてできたのかなどについて素晴らしい物語を提供していた」とのことであり、驚くほどワクワクするが「真の理解には到底不十分な代物」だった。

もしかしたら、Zoom の台頭についての私の理論も「ただそうなっているだけの話」である可能性はある。たとえば、Zoomはもしかすると、たまたま時代の転換点にいて、ネットワーク効果で市場を占有しただけ、かもしれない。

しかし、ここからが核心なのだ。私の目標が、特定の企業のイノベーションが市場で失敗するか成功するかを確実に判断する方法を提供することだとしたら、それは画期的なものになるかもしれない。

むしろ私の目標は、ソフトウェアの設計を改善する方法を見つけることであり、その観点から見ると、Zoom vs Skypeの物語はしっかりした根拠があるように思える。 Zoomがその会議シナリオによって成功したかどうかは、それほど重要ではない。重要なのは、このシナリオを伴って成功したかどうかである。リンクが非同期で送信されるこの設計は、大規模でアドホックなビデオ通話の出現を考慮すると、参加者がプラットフォームの既存ユーザーとして直接招待される設計よりもはるかに優れていると認識できる。

他の例

このアイデアの例をさらに2つ挙げよう。 AppleのiPodは、2001年の発売当時、既存のMP3プレーヤーよりも洗練されていたが、爆発的に普及したのは数年後だった。これを説明する重要なイノベーションの1つがiTunesストアのオープン（2003年）である。ここでシナリオがアップグレードされ、CD をリッピングする（あるいは、さらに悪いことに、オンラインで海賊版の曲を見つける）必要があったところから、単一の曲を購入し、デバイスに同期してすぐに再生できるようになった。

ウォルター・アイザックソンはここでスティーブ・ジョブズが重要な洞察力を持っていたことを評価し、誰もこのチャンスに気付かなかったことに驚嘆している（特にソニーは、家電業界をリードしていただけでなく、独自の音楽スタジオも持っていたのに、だ）。

WhatsApp は2009年に創業したが、その急速な台頭は2011年に始まった。エンドツーエンド暗号化はまだ5年先で、フリーテキストメッセージは2006年から存在していた。では、2011年に何が起こったのか？グループチャットだ。これにより、各スレッドに受信者を1人ずつ追加するのではなく、友達をグループに招待できるようになり、参加した人とすべてのメッセージが共有されるようになった。

他の企業も同時にグループチャットを活用しようとしていたが、WhatsAppが明らかに勝者であった。おそらく、すでに強力なユーザー基盤を確保していたからだろう。

教訓

ここでの重要なポイントは、ある意味、驚くべきことではない。人々は新たなツールを使って行動パターンを変えることで、行動をシンプルにし、ペインポイントを解消する。

しかし、このアイデアは単純だが、ソフトウェアに大きな影響をもたらす。

シナリオがソフトウェアを説明する。ソフトウェアアプリは、他のイノベーションと同様、利用シナリオによって説明できる。これらのシナリオは、私たちがよく知っているありふれたユースケースやユーザーストーリーではない。これらは、機械設計の本質を捉えたマイケル・ポランニーの操作的原理に近い。
イノベーション = シナリオの変革。ブルーノ・ラトゥールも同様の方法でテクノロジーの出現を説明している。ドアがなければ、建物から出るたびに壁に穴を開け、戻ってくるときに補修する必要があり、決して便利とは言えない。ソフトウェアシナリオが単純または些末に見える場合、それを評価するには以前のものとの比較が必要かもしれない。
シンプルさこそが重要。ドン・ノーマンは、ドアの操作の方法を知ることさえ難しい場合があることを教えてくれた。ソフトウェアの場合、基本シナリオと、それをUIの文脈でどう実現するかの間に多くの落とし穴がある。シナリオが明確に伝わらず、実行しやすいものでなければ、それは存在しないも同然である。

あらゆるスタートアップに対して教訓を一言で言うなら、 「シナリオを知れ」 ということだ。そして、余計なことに惑わされず、できるだけ直接的かつ説得力のある形でデリバリーすることに集中するのだ。

しかしでは、より複雑な、複数のシナリオを備えていそうなアプリについてはどうすべきか？それは次回の記事に譲ろうと思う。