IT専門の人材サービス・アウトソーシング事業を行うパソナテックが6月1日、渋谷のコワーキングスペースLightningspot内にWeb制作やスマホアプリ開発、ソーシャルマーケティング事業を展開する「渋谷Lab（ラボ⁠）⁠」をオープンしました。本記事では、オープニングイベントとして5夜連続で開催した「shibuya meets tech」イベントの様子を紹介します。

技術探究心、日々の些細な物足りなさ、自己表現など十人十色のモチベーションではじめるサービスやアプリ作りを成功させるためには、どういった着想や進め方、目標設定をすれば良いのでしょうか。

6月7日のshibuya meets techでは、株式会社ユーザーローカルの閑歳孝子氏とAppcelerator Inc.の増井雄一郎氏をゲストに招いて二人の経験を交えつつ、個人でサービスやアプリ作りをする際の勘所をディスカッションしました。

何のためのアイデアか

公私においてさまざまなアイデアを形にしてきた閑歳氏と増井氏。二人はどういう着眼、着想でアイデアを生み出しているのでしょうか。まずはじめに「アイデアを作るきっかけ」についてディスカッションしていただきました。

このテーマについて閑歳氏から自身のケースを挙げます。

「サービスを作りはじめる前に、個人の楽しみでサービスを作るのか、ビジネスでサービスを作るのか、何のためにアイデアを練るのかを決めています。たとえば最初にサービスを作った時は自分がほしかったサービスというのもありますが、初対面の人に企画担当と間違えられることが多く、自分が作りたいものを自分で作れるんだということを証明したかったという気持ちもありました。

家計簿アプリZaimを作ったときは『そのサービスがないと生活できない』と思われるくらい人生に欠かせないサービスをなるべく多くの人に使ってもらいたいと考えました。」

なかなか難しいことですがと前置きして、アイデアを作る前に「これは解決しなければいけない問題だ」と、一生懸命になれるテーマを見つけることが大切ですと述べました。

一方、増井氏は、

「僕は個人的な悩み、自分が使いにくいと思ったり面倒くさいと感じることを書き溜めて、そこからアイデアを作っています。エンジニアなので繰り返し発生することや自動化できるものは自動化したいと考えていますね。

よく『アイデアが思い浮かばない』と言う方もいますが、話を聞いてみると自分がアイデアと思っていないだけで『使いにくい』『⁠こうしたら良くなる』という発想自体は持っていることが多いです。そういう方は不満を改善する方法を考えてみるとアイデアを作れると思います。

あと、僕は新しい技術が登場するとそれを試してみたいという思いからサービスを作ることがありますね。」

不満ドリブンでアイデアを作ると、閑歳氏とは違う観点からテーマに応えました。さらに、アイデアの膨らませ方についても、それぞれのケースを紹介する両名。

閑歳氏は自身を「アイデアをどんどん出せるタイプではないのかもしれない」と考察しつつ、

「Zaimを作ったときはTechClunchを1年分読みました。シリコンバレーで流行っているサ―ビスは何か、それをどうすれば日本で流行らせることができるかを考えたんです。次に、アイデアをすぐ外へは出さず、自分でアイデアが出尽くすまで考えて、そのあと他人に聞いてみました。

作る前のアイデア段階で外に出せなかったのは、Zaimの利用ターゲットが一般ユーザだったためです。ペーパーラフを持っていってもイメージしてもらえず、フィードバックを得られなかったという事情があります。」

と当時の様子を振り返りました。

リリース後の運用フェーズでは人に聞いてサービスをブラッシュアップするし、実際、フィードバックを返して貰えたことで助けられた経験もあるが、アイデアの段階で外に出すか否かはサービスやアプリの性質によるとのこと。

これに増井氏は逆の意見を持っています。

「僕は思いついたらアイデアリストに載せてオープンにします。また、ツイッターで人に聞いてみたり、お客さんとの打ち合わせや懇親会で話しながら反応を見てアイデアを膨らませていきます。」

アイデアを外へ出すタイミングの違いについては、「⁠僕のアイデアは一般向けではないので、ホワイトボードがあれば伝わることがほとんどですね。」とした上で、アイデアの種類によって適切な作り方、膨らませ方があるとまとめました。

アイデアを形にする

「アイデアを形にしたいならコードを書け！」

どのようにアイデアを形にすればよいか、というテーマに即答する増井氏。自身は電車の中でコード中や、風呂にまでMacBookを持ち込んで開発をするなど、とにかく1日中コードを書いているとのこと。

「あと、自分でやらないこと、できないことを人にお願いしたりします。また、自分自身が飽きっぽいのでプロトタイプまで作って技術検証が済んだらアイデアを売却し、売却した先で製品になったこともあります。」

自身ですべて開発するだけでなく、外部に協力者を作って形にする方法もあると述べました。

続けて、閑歳氏は最後まで作りきる経験をすることが大切と言います。

「アプリ作りはマンガや小説みたいに最後まで書き上げるのが難しいです。とにかく一回でも最後まで書き上げて、リリースまで到達するという経験が大切です。私もアプリを実際にリリースしたことで、今まではわからなかった勘所を掴めるようになり、失敗も減りました。」

また、アイデアを形にするときの勘所として「アイデアをシンプルにする方法」についても閑歳氏から事例ベースで紹介がありました。

「私はボタンの数なども含めて、アプリをシンプルに作ることを心がけています。パッと見てわからない機能や、あまり使われない機能は作っても時間の無駄なので作らないようにしたいんです。機能は作ってしまうと削るのにパワーが必要だから作る前にしっかり精査します。8割の人が必要という機能は作らないとダメだけど、2割の人しか求めていない機能は思い切って削る決断も大事です。」

合わせて、リリース後にユーザから上がるフィードバックへの対応についても、

「ユーザ自身の言葉と本当のニーズが違うケースは多いです。たとえばZaimではもともと数字入力にネイティブのキーパッドを使っていのですが、途中から自作のキーパッドに変えました。しかしこれに、『⁠前の方が良かった』という意見が寄せられたんです。

ただ、よくよく聞いてみると前のキーパッドが良かったのではなく、ボタンが小さく押しにくくなったのが本質的な問題でした。」

と、ユーザの声を大切にしながらも、そのまま聞くのではなく本質的な課題を見つけるべきだと参加者に伝えました。

ところで、二人はサービス作りで行き詰まったとき、どうブレークスルーしているのでしょうか？

まずは閑歳氏。

「なるべく自力で解決しようと頑張ります。どうしてもわからない時は同じ課題を持つ人の解決例を調べたりしますが、他の人も同じように行き詰まっていて解決した事例に行き当たらないので、諦めをつけて別の方法探るためにみるカンジです。」

増井氏は、「⁠僕は5個10個並行してモノ作りをしているので、つまづいたら別のモノにシフトします。しばらく放置していたらその間に問題を解決するライブラリが出ていたなんてこともあります。仕事でつまづいたときは2、3時間、趣味の開発をしてリフレッシュしますね。」

と、自身の解消方法を紹介しました。

他のことをしてリフレッシュするというのには閑歳氏も賛成。

「私はコードを書いててつまづいたときはデザインに手をつけます。デザインがあるとサービスの完成を強くイメージできるのでモチベーションが上がってくるんです。」

適切なゴール設定とは

こうして作るサービスやアプリはどこにゴールを設定すれば良いのでしょうか。このテーマに対して増井氏は自身のスタンスを語ります。

「僕はゴール設定をしないので、モチベーションが下がったら手近なゴールに設定します（さすがに仕事では、そうはいきませんが⁠）⁠。以前、使いづらいと感じたevernoteのiPhoneクライアントを自分で作ろうとしたのですが、titaniumからevernoteへの接続ができないことに気づき、急遽モジュールを開発しました。しかし、その時点で飽きてしまった。最終的にiPhoneクライアントは作りませんでしたが、成果物（ゴール）としてはtitanium用のevernoteライブラリが残りました。」

閑歳氏は、ユーザに使ってもらうことをゴールに位置づけ、ランキングやDL数はその指標としてよくチェックしていると述べました。

この意見に増井氏から「サービスが続くことをどう思いますか」と質問が上がります。

「基本的にサービスが成長し続けることは嬉しいです。アクティブユーザが減ってコストだけがかかるようであれば、どこかのタイミングで引かざるをえない。逆にサービスが大きくなり続ければ、運営に適した新たな体制が必要なのではないかと感じています。」

と答える閑歳氏。継続を求められるwebサービスはゴール（＝終わり）の設定が難しいようです。

セミナーの最後に個人で作ったサービスと仕事との相乗効果について、それぞれの体験が紹介されました。

「個人で作ったサービスをきっかけに会社や自分自身を知ってもらえ、本業の仕事につながったこともあります。逆に、直接的ではないにしろ、仕事の経験は個人のサービス作りにも活きています。仕事ではアクセス解析ツールを開発しているのですが、家計簿とアクセス解析は難しくなりがちなデータ分析を分かりやすく表現する、という面で非常に似ているからです。」と閑歳氏。

増井氏も、「⁠Appcelerator Inc.に入社したとき、CEOに英語が苦手な自分を採用した理由を聞いたら『githubのフォロワー数が会社で一番多く、技術力と技術者としての認知度を評価した』と言われました。」

と、個人で開発し、公開したサービス（コード）が自身に新しいチャンスを作った経験を振り返りました。