先日、自分が最初のユーザである場合の製品開発の進め方のヒントを教えてもらったので、それを今回は書いていこうと思います。

（注）Web記事を音声読み上げするiPhoneアプリを作ってます

＠目次
「最初の動機は、自分が欲しいから作り始めたのであった」
「自分が欲しいモノなら最初の課題は認識している」
「最初のユーザ１人用に作るとシンプルな製品になる」

最初の動機は、自分が欲しいから作り始めたのであった

先日、Aというターゲットに向けて作っているのに製品がウケない時、Bというターゲットに向けて方向転換するか、Aというターゲットが欲しいモノに作り替えるかどっちがいいでしょうかと新規事業開発専門のお方に質問してみた。

すると、まずなんのために製品を作っているのかで決まると言われたわけです。

そう考えると、別に世界を変えたいとか、世界中の人に使ってもらいたいとかは実は最初は考えてなくて、単純に自分が死ぬほど欲しいから作り始めたんだなと思い出した。

あくまでもその後に、他の人も使ってくれたら嬉しいなとか、耳から活字に慣れていって結果的に本好きが増えると嬉しいなとか、語学学習の神アプリにならないかなとか、お金儲かってポルシェ乗り回してウハウハになりたいなとか下世話な事まで考えるという欲求段階説があるわけですね。

先駆者達が、「スタートアップをする理由はお金ではなく、世界を変えたい気持ちでないといかんよ」とよく言うから、自分もそうなのかなあと思って「世界中の人たちが読み上げをきっかけに読書に目覚めると、世界が変わるんじゃないか、うんぬん」とかわけのわからない思想を後づけで考えてたわけです。

自分が欲しいモノなら最初の課題は認識している

となると、自分が最初のユーザであり、ペルソナであり、抱えている問題もはっきりと認識しているのであった。

その場合、まず最小限の機能で自分がまず満足する製品を作り、その次に簡単な説明を作って、アーリーアダプター向けに改良するという、上から降りていくイメージで作るのがよいらしいです。

そういや、Ash師匠も問題がはっきりと認識できている製品は、最初の問題把握のインタビューは飛ばして、シンプルでストレートな製品を速攻で作って、その次のインタビューを始めればよいとブログに書いてた。

いやいや、自分が欲しいもの作る場合も顧客の声を聞かないといけないって話と矛盾しているじゃないかと思うかもしれないのですが、まあ、これは同時並行でやればいいんじゃないかなと。

つまり、ブログとかで最初のターゲット向けの記事を書いたり、ヒアリングもしつつ、まずは自分専用にシンプルな尖った製品を開発していくと。まずは質で検証して、量で検証すると言いますが、質の検証はかなりの部分は自分で検証できることになる。

スピードとの兼ね合いもあるので、初期バージョン開発の時間がかからないのならオッケーだと思います。ちなみに、自分の場合、ヒアリングの結果、特に欲しいと言ってくれる人と自分が最初に欲しいものはほぼ一緒だという確認もできている。

最初のユーザ１人用に作るとシンプルな製品になる

さて、まずは自分が満足できるアプリとなると、かなり機能が削られ、とてもシンプルになるのが容易に想像できたのですが、紙でプロトタイプを書くと実際その通りになりました。

ユーザビリティの部分も、上級者に合わせるか、中級者に合わせるか、初心者でも使いやすくするかという悩みもありますが、この場合は上から順番に降りて行くんだよと教えてもらうと、なるほどと思いました。

Lisgoの時はなんでも出来るようにブラウザを搭載しましたが、自分が使うにはいろいろな記事の到着地点であるReadItLaterのリスト抽出が一番使いやすいんですね。

これは、RSSのスターが最後の人もいれば、Instapaperの人もいれば、Twitterのお気に入りの人もいるので、ひとつひとつ対応する予定です。

UIや仕様の固め方は、自分が使っててちょっとイラっとする仕様をバグリストとしてメモっていき、それをガンガンつぶしていくのが、有名な製品デザイン会社IDEOのノウハウらしい。

例えば、ReadItLaterのリストをアーカイブするのに右スワイプで一発でやるとストレスがない。左スワイプでプレイリストに一発で追加、戻すを切り替えると速い。初心者には分かりづらいけど、簡単な説明で理解してくれるアーリーアダプターには最高にウケるんじゃないかと。

既存のアプリでいうとReederというRSSリーダアプリがよい例で、かなりシンプルで使いやすい反面、初心者が最初に使ったらさっぱりわけわかめな仕様です。でも、慣れると最高だし、そもそもRSSなんて初心者あまり使わないからあのレベルの感覚でちょうどよいのかも。