Hatena::Groupbugrammer

蟲!虫!蟲!

Esehara Profile Site (by Heroku) / Github / bookable.jp (My Service)
過去の記事一覧はこちら

なにかあったら「えせはら あっと Gmail」まで送って頂ければ幸いです。
株式会社マリーチでは、Pythonやdjango、また自然言語処理を使ったお仕事を探しています

 | 

2013-06-19

[]土日でサービスを作っていて考えていたこと 00:01

f:id:nisemono_san:20130618210147p:image

 ふと、Bookableのコミットのパンチカードを見ていたら、本当に土日に偏っていたので、俺は嘘をついていなかった!

 ……という冗談は置いておくとして、この記事は、前回の続きとなります。今回は、じゃあ実際にはどういう風にやっていったか、という話を書こうと思います。

何を作るのか

 何を作るのか、といったときに、いろいろな考え方があるかと思われます。自分が思い付く限りでは下のようになるかなーと思います。

  1. 自分が作りたい、欲しいものを作る
  2. 人が欲しがっているものを作る
  3. 技術として試してみたいものを作る
  4. お金が欲しいので、お金になりそうなものを作る

 ここで重要なのは、たぶん何らかの形で、作ることがモチベーションになるものだと思います。

 例えば、自分がTornadoで作ったNotVJSというものがあります。このモチベーションは、Tornadoと呼ばれる、Pythonで作られた非同期ライブラリを使いたかった、どうせならPythonWebsocketを使いたかった、というのがあったので、「もしブラウザ間で同期したら面白いものはなんだろう」と考えたときに、知人が、HTML数枚で画像をjQueryで加工してVJみたいなことをやっていたことを思い出したので、「そうだ、そういうのをつくればいいじゃん」と思って作ったものでした。

 上記の場合はそうですし、例えば今回のBookableについては、下の本に憧れて作ったものだったりします。

f:id:nisemono_san:20130618234908j:image

 上の本は工作舎と呼ばれる出版社(松岡正剛がいたところ、というとわかりやすい?)が作ったもので、他の人はともかく、自分はとても感銘を受けたので、こういうものを作ろう、と思ったのが初期のきっかけでした。

 最初のころのコンセプトとしては、下のように整理されるでしょう。

  1. 本をキーワードでぶったぎって配置する
  2. そこから有名な本とあんまり有名ではない本を配置する
    1. 「有名」の定義は、ブックマークのユーザー数として定義する
  3. 有名な本をフックにして、知らない本に辿り着ける

 このようなものとして、最初Bookableは考えられていました(ついでにアフィリエイトで金がGETできるんじゃないか、という淡い期待もありました)。

知人に話をしてみる

 で、ある程度作りたいと思うものの確証が出来たら、とにかく人に自分のアイデアを説明してみました。そうすると、案外好印象だったので、「結構面白がってくれる人がいるのであるならば、これはもしかしたら面白いものになるのではないか」と思ったので、実際に作ってみることにしました。

 知人にアイデアを惜しみなく話してみる、というのは、そのサービスに対しての反応がダイレクトに伝わってくるし、また人に説明することで、自分の中で、どういうサービスにするのかというのが明確になってくる。そういう意味では、知人に自分のアイデアを言ってみるというのは、最初の反応を見るのには、とてもいいんじゃないかと思います。

とりあえず必要になりそうなところから作り始める

 じゃあ何処から作り始めたのか、というと、実は書籍データをどのように集めてくるのかというところからスタートしました。というのは、画面を作るのは、たぶん簡単だろうと思ったからでした。

 ただ、今から考えると、当たり前といえば当たり前なんですが、あまりにも書籍データが集まってしまったので(だいたい四万冊とかその辺)、「あー、これは整理するのが難しいなあ」と思ったので、とりあえず自然言語処理で、名詞部分を取り出して連結できないかなーと考えたりして、実はその辺の実装は未だにやっていたりしています。

 で、必要になりそうなところといえば、本を表示する部分だなあ、と思ったので、テンプレートをさくっと書いて、ランダムで本を表示してみたところ、配置の妙というべきなのか、そこそこ面白い結果が出てきたので、「とりあえずこれでサービスを認知させて、その後のことを考えるか」みたいな感じでリリースしたのでした。

知人と協力してモノを作ってみる

 当然の事ながら、全部の事を一人でやるのもいいんですけれど、当然のことながら、得意な分野と苦手な分野があります。自分の場合だと、実装やコーディングについては、特に苦にはならないわけですが、圧倒的にデザインというか見栄えを作るのが弱いところがありました。で、ちょうど知人であるところの、豊井さんに頼みました。

 で、そのときに意識したのは、自分は基本的に全くデザインはわからない、ということでオペレーターに徹したということです。普段から一緒にすごすことが多いので、お互いの気質が解っていたというのもあるのですが、そのあたりの役割分担を上手くやったので、スムーズに楽しくできました。たぶん、このあたりは信頼関係だと思います。あと、単純に自分のスキルをお互いに補完し合う経験というのは、普通に楽しかったというのもありました。

普段から試してみたい技術をストックしておく

 これは技術者よりの話になるのかもしれませんが、日々最新の技術が生まれていきますし、「これはヤバい」と喧伝されていますが、いきなり自社のプロダクトにぶち込むのは、さすがに問題があります。なので、こういう場所で自分で試してみる機会になることがあります。例えば、自分の場合だったりすると、compassやsusyは始めて使ったものではあったのですが、それを試せたのは何よりも収穫だったと思います。

 たぶん、そういうものを試していく場所というのは、自分にとっては楽しい場所であるので、とてもよかったと思います。また、そういう「自分を楽にしてくれそうなオープンソース」の情報を集めておくことで、開発が便利になる側面もあるように感じます。

一度必要な画面・構成を洗い出してみる

 今回は、必要な画面が一つしかなかったので、シンプルな作りになったのですが、画面数がおおくなればなるほど、やはりある程度実装量は多くなります。自分は、もう少し若い頃に「超大作システムのRPGを作ろう!」と思って挫折した経験がなんどかあります。実装量が多いということは、それだけ保つべきモチベーションの量も必要になってきます(モチベーションも大切に運用するべきリソースだと思います)。

 どれくらい大きくなりそうなのかというのは、画面数を洗い流してみるとある程度わかったりします。もちろん、クライアント側のJavaScriptが増えれば、また問題は変わってくるのですが、今回の場合は、一画面だったので、実装が割と楽だったというのがあるとは思います。

反省するべきところ

 とはいえ、反省するべきところも無いわけではありません。

作成中に、実際に使ってみてユーザーの反応を見る作業が必要だった

 あとでリリースしてみてわかったのですが、シンプルにすることに拘りすぎてしまったために、実際に自分たち以外のユーザーからどう見えているのか、という調査を怠っていたのが少し問題だったかなと。普通なら、リリース前に、ユーザーの反応というか、使い方を見て、それをフィードバックして必要な機能を追加するという作業をするのですが、今回それをしなかったのは、イケてなかったかなと。「実はこういうのを作ってみたんですよ」という話をすることはあって、そのときに「あー綺麗だね」の一言で終わって、そのあとすぐに閉じる感じだったのに気がつけなかったのはダメだったなと。

 要するに「フック」という部分と、「このサービスがどういうものであるのか」というのを説明する必要はあったなあというのは率直な印象だったりします。実際に、「このサービス、ふと見るとどういうサービスなのかわかりずらい」ということを言われました。そこに鈍感だったのはよくない、というのは反省するべきところです。というのは、そのサービスの「はじめの使い方」をよく知っているのは開発者であって、それはユーザーにとってはわからない。その辺の視点が抜けていたのはよくなかったなと。

まとめ

 いろいろと書き連ねましたが、現在のところ、Bookableについては、自分がハードユーザーであることは間違いではないです。ソフトウェア業界には「ドックフード(=自分が作ったもの)を食べる」という表現がありますが、だいたい自分のつくったものというのは、どことなく愛着が湧いてくるものです。HTML5Canvasにキャラクターを描いて動かしているだけでもニヤニヤできてしまうところは自分にはあって、たぶんそういうものだと思います。

 今後の課題としては、恐らく「自分が一番楽しんで、愛着を持って使っている」というところから、「他の人にも、暇つぶしとして楽しんでもらえる」というところに持っていくというところだと思います。そういう意味で、もし貴方がBookableを使って楽しんでくれるなら、それは自分としても作ってよかったと思える部分だと思います。

 それでは、改めて、Bookableをよろしくお願いします。

 FXでの失敗ケース | Just another WordPress site

 |