「スタートアップがものごとを最初から正しくやるということはほとんどない。それよりずっとありそうなのは、何かをローンチするが、誰も注意を払わないということだ。」

Y Combinatorのポール・グレアムは、「死なないため」にと題したエッセイでそう述べました。

そして他の多くのスタートアップと同様に、僕が開発した本の問題集アプリ「BooQs」も、ポールの予言を的中させました。
つまり、ローンチしても、誰も注意を払わず、誰も使ってはくれませんでした。

ただ、そうした鬱屈した状況にも、先日あたりから一筋だけ光が差し込むようになりました。

やっと１人、本のクイズを熱心に投稿してくれるユーザーが現れたのです。

正直、最近挫けそうだったので、本当に嬉しいです。
バグの報告や追加機能の要望までいただける上に、ネイティブアプリでも欲しいと仰ってくれるなんて、開発者冥利に尽きます。

この記事では、そんな1人に出会うまでに、僕がプロダクト開発で重要だと学んだ点を２つ紹介していきます。

「本のクイズ投稿サービス」という特異な事例だけれど、僕と同じような無名の個人開発者、とりわけCGM（ユーザーが投稿する系のアプリ）を開発している人たちのお役に立てれば嬉しいです。

1,待っているだけでは、人は使ってくれない。

待っているだけでは、驚くほど、人は来ません。

そしてCGMの場合、過疎っているサイトに自身の労力をかけてコンテンツを提供するのは、普通の人にとってかなり心理的な抵抗感が大きい。

じゃあどうすれば使ってもらえるのか、といえば、それはもう、地道にお願いするしかないのではないでしょうか。

「一度このアプリを使っていただけませんか？あるいは、使いたくない理由を教えていただけませんか？」

という風に。

こうしたお願いは、見知らぬ相手よりかは、一度アプリに登録してくれたユーザーに行ったほうがいいです。

会員登録はしたが、まだ使っていないというユーザーは、一度アプリに興味を持ってくれたユーザーです。
そして繰り返すように、過疎っているアプリにコンテンツを提供するのは、心理的に抵抗感が大きい。
けれど、こちらが誠意と敬意をもって、熱心にお願いすれば、「お願いされれば・・・」というふうに、抵抗感を乗り越えて、一度使っていただけることがあります。

そもそも過疎っているアプリでは、ユーザーは「自分が投稿してもいいのかわからない（不安な）」場合だってあります。
誠意をもって、投稿をお願いするべきです。

もちろん、使っていただけないことの方が多いし、拒否されれば傷つきます。
しかし、そこは開発者として、タフにならなくてはいけないと思います。

2,「使いたくない理由」を教えてもらい、改善する。

アプリを使ってもらうお願いの例として、

「一度このアプリを使っていただけませんか？あるいは、使いたくない理由を教えていただけませんか？」

という文句を紹介しました。

実は、このお願いで重要なのは、最初のお願いよりもむしろ、「あるいは」の後につけたお願いのほうです。

「使いたくない理由を教えてもらうこと」は、使ってもらうことと同じくらい重要だと僕は思います。

僕らアプリ開発者がまず自覚しなければならないのは、「開発者は開発したアプリの熟練者である」ということです。

この点は、とても見落とされがちなので気をつける必要があります。

僕ら開発者はナチュラルに、「初心者目線で設計できる」と驕っています。

しかし、そんなことは絶対にありえません。

「絶対」という強い言葉をあえて使ったのには、科学的な根拠があります。

人間には、心理学で「知識の呪縛(Curse of knowledge)」と呼ばれる現象（認知バイアス）があるからです。

人間は、どんなに相手の目線に立とうと努力しても、無意識に自分のもつ知識に影響されてしまいます。

開発者がいくらそのアプリを初めて利用するユーザーに優しい設計を考えても、開発者はすでにアプリについて熟知している熟練者です。

なので、思わぬところで、初心者であるユーザーは問題を感じます。

たとえば、僕が登録ユーザーに「使わない理由」を聞いたときには「面倒くさい」という言葉が返ってきました。

今となっては当然に思えますが、クイズを１つ投稿してもらう時点で、初めてのユーザーにとってはすでに負荷は大きかったのです。

しかし、その当時僕が何を実装していたかというと、「複数のクイズを１つのタイトルにまとめて投稿できる」というような、いわゆる「アプリ熟練者向けの機能」でした。

当時、この機能については、「自分が欲しい便利な機能であり、ユーザーも求めているだろう」と僕は考えていましたが、それは明らかに、アプリの熟練者としての自分の考えを、アプリ初心者であるユーザーにまで広げた考えでした。

自分がすべきことは、便利な機能を実装することではなく、クイズ投稿の負荷を減らすことだったのです。

耳の痛い「使いたくない理由」を聞いたおかげで、僕は問題に気づき、アプリを適切にブラッシュアップすることができました。

機能を追加するのではなく、むしろ機能を減らし、根幹の機能については画面遷移させずに非同期で利用できるようにすることで、クイズ投稿のストレスを減らしました。

熱心に使っていただけるユーザーをやっと1人獲得できたのは、利用のお願いと同時に、こうした「減らす改善」ができたからだと思います。

ただ繰り返すように、こうした「減らす改善」ができたのは、アプリ初心者であるユーザーに「使いたくない理由」を聞いたからです。

僕は、ユーザーの声なしにこうした改善ができたとは、今なお絶対に思えません。

なにせ、開発者はすでにアプリの熟練者なのですから、熟練者にとって便利な機能を追加したくなるに決まっています。
しかし、往往にして、熟練者にとっての便利は、初心者にとっての不便なのです。

プログラミング初心者だった頃を思い出してください。
あの時の僕らを悩ませたのは、熟練者にとって便利な省略記法でした。

ユーザーファーストとは、初心者ファーストです。
だから、プロダクトを考える時には、プロダクトについて無知なユーザーの声を聞かなくてはなりません。

開発者はすでにプロダクトについて知ってしまっているので、無知になることはできません。

だからこそ、無知なユーザーに「使いたくない理由」を聞き、使いたくない理由を潰すようにして、プロダクトを開発すべきだと思います。

C2C、つまり、流入してくるユーザーのほとんど全員が「プロダクトについて無知」であるサービスについては、これは非常に重要な点だと感じました。

まとめ

長くなりましたが、僕がプロダクト開発で重要だと感じた点は、シンプルに２つです。

1, 使ってもらえるのを待つのではなく、使ってくれるよう「お願い」する。

2, 「使ってもらえない理由」を聞き、「使ってもらえない理由」を潰すようにして、開発する。すでにアプリ熟練者である自分が求める機能を実装しない。

基本的なことなのかもしれませんが、僕にとっては大きな学びでした。

これからもユーザーの声を聞きながら、アプリを改善していきます。

BooQsは、みんなでつくる本の問題集です。

BooQsは、「テスト効果」という心理学的知見に基づいた、効果的な本の学習ツールです。

開発者の「かわんじ（@kawanji01）」は、Twitterでは、先ほどの「知識の呪縛」のように心理学の図解をしています。
興味のある方はぜひ！

ここまで読んでいただき、ありがとうございました！

よかったら、Twitterで「かわんじ」をフォローしてあげてください！