読者です 読者をやめる 読者になる 読者になる

Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

RailsでWebアプリ「Zanmemo」を作った話と、その過程で考えたこと

f:id:nisemono_san:20141018015332p:plain

初めに

元々、自分自身は何かを考慮してから作り始めるよりも、作り始めてから考える方が性に合っている。もちろん、実務だとコストを考えなくてはいけないけれど、何らかの練習に関しては、実際に手を動かしてみるほうが練習になるので、実際に作ってみた。また、作ってみるからには、できるだけ公開できる形に整えたい、という気持ちもあったので、Herokuにデプロイした。

アプリの趣旨よりかは、どういう風に作ったかのほうが興味をもたれるだろうと思うので、アプリの意図については上記のメモに譲る。先にどういう意図なのか見たいという場合は、上のリンクを読んでもらったほうが解りやすいかもしれない。

ちなみに、アプリについては「残念なメモ」の略として「Zanmemo」とした。「Zenmemo」という案もあったけど、「禅」は気取りすぎなので、破棄をした。ちなみに実際のアプリについては、下から見られる。

作る過程について

コアのアイデアを決める

多機能にすることは幾らでも可能だけど、それだと公開も出来ないし、モチベーションも下がる。なので、「これがコアのアイデア」というのを考え、それに伴い学習するコストとして適切かを考える。

今回の場合、「コアのアイデア」というのは「メモをした記事をランダムに表示して、過去の投稿が掘り出されるようにする」ということだ。

あと、今回の場合、副次目的として「Railsの学習」というのもあるので、それに相応しい大きさのアイデアかどうかも考えてみる(大抵、大きいものを作ろうとして「アレやコレ」みたいな機能を盛り込んで破綻することも、過去の製作において多くあったりした)。

自分の為に作るならば、自分のワガママに最大限に答える

Webアプリというのは、大抵はターゲットユーザーみたいなのがいて、そこに対して何の価値を届けるか、みたいなことになると思う。今回の場合、最大のユーザーは自分なので、自分のワガママについて焦点を合わせてみる。例えば、メモの保存機能は出来たけど、やっぱりMarkdownで保存できたら便利だよね、と思ったらその機能を入れてみる。

作りながら使ってみる

「コアのアイデア」というのは、所詮仮説に過ぎない。例えば作ってみたら意外と対したことないということはありうるし、逆に自信の無いアイデアでも思いの他ヒットすることもある。なので、実際に使ってみながら作ることを意識してみた。属に言う「ドックフードを食べる」という奴だけど、高速でドックフードを食べると、だいたい不満が出てくる。

ポイントは、「コアのアイデア」がターゲットユーザーに本当に刺さっているかどうかを検証するということで、今回の場合はまず自分が優先されるので、自分に刺さらなければ意味がない。現状としては、そんなに悪くはないものの、まだ「コアのアイデア」が上手く言っているとはいいがたい状態なので、そこをなんとかする必要がある。

自分の都合から離れる

この場合「自分の為に作る」というのが基本だとは思うけれども、しかしやはり公開するとなると、自分の都合から離れる必要がある。例えば、現状として新しいエントリを表示させるとするなら、やっぱりRSSを配信する必要があるだろうし、そのほうがユーザーとしてはありがたい状態だと思う。

あと、割と直感的ではなく、例えばブログだとタイトルをクリックすると、一覧ページになるけれど、今のところその辺が実装されていないので、一覧に戻ろうとしてタイトルをクリックしようとしたりしていた。たぶんこの辺はメンタルモデルという話の問題なのだろうとは思うのだけれど、そういった「メンタルモデル」に整合する形に整えていくのは、今後の課題だと思う。

テスト駆動で無くても良い、ただしテストは書く

例えば、プログラマの良い習慣の一つとして、テスト駆動開発というのが挙げられる。過去のブログにも書いたとおり、僕自身はテスト駆動が「書きやすい」とは思うけれど、それで「するべき」ではない気もしている。今回の場合、Amazon経路で頂いた『パーフェクトRuby on Rails』の構成がそういう風になっていたというのもある。また、過去にも書いたとおり、例えば詳細設計で悩んでいるときとかは、簡単にテストは書けないし、試行錯誤でAPIを作ることはある。

今回の場合も、「Ruby on Railsの学習」という焦点があったため、まずテストを書くよりも、「実際に動くものを作る」ということを優先した。なので、途中までテスト無しでゴリゴリと実装していった。

ただし、公開するときは別だとは思っていて、例えばこのエントリを挙げる前には、既にHerokuにアップロードはしていた。だけれど、それをことさらに公開しなかった理由は、単純にテストが無い状態でユーザーに遣わせるのは、Webアプリケーションとしては不誠実だな、と思ったからだ。

少なくとも、データベースに副作用が発生するケース(「更新、削除」)に関しては、他人から操作出来ないということを保証するべきだし、適切なエラーメッセージを返す必要がある。自分のデータに関して、人から操作できるということは不愉快なものではあるので、少なくともテストで固める必要がある。そのため、テストが書けるまで、公開をことさらに言うことはなかった。

あとから改善できることはあとから改善する

コアのアイデアが実現することに集中して、デザインとかはとりあえず後回しにした。なので、Bootstrapむき出しのデザインになっているけれど、デザインに関しては、あとから修正できるので、後回しにしたりした。もちろん、これは修正されるべきものではあるので、その辺についてもちょこちょこ改善したいと思ったりしている。

課題

継続性の問題

自分の場合、あるアプリの骨格が出来てしまったら満足してしまうことが多いので、その辺を定期的に継続して成長させることができるのか、ということが重要な気がする。作ってみて、満足したのはいいんだけど、あとでメンテナンスを放置することが多いので、そこをちゃんと継続的に出来るのか、ということが重要になりそう。

参考文献

上記の話については、割とリーン・スタートアップを意識している。最低限から始めよ、と言う奴だ。もちろん、それが実際の開発と結びつくかどうかに関しては不明だが、アイデアを固めて、形にして、世に問うという意味では、参考になると思っている。

リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (92件) を見る

もちろん、リーンの場合、厳密にはリリースした直後に、「仮説」「計測」「検証」という三つの方法があって、そこで上手く行った施策がちゃんと機能しているかどうかを把握する必要があるんだと思うんだけど、今回の場合は、そこまで考えてはいない。もちろん、ちゃんとしたサービスを作る場合、この三つを考えながらスケールさせる必要があるとは思う。

あと、普通に『パーフェクト Ruby on Rails』は良書であり、「Railsで何か作ってみたいけど、どういう風に作ればいいんだろう」という場合、ちょっと冗長な部分は多いかもしれないけれど、確実に力が付くと思うし、ここをベースに知識を深めていければいいな、と思ったりした。

パーフェクト Ruby on Rails

パーフェクト Ruby on Rails

とはいえ、例えばRspecの書き方であったり、あるいはDeviseというgemの書き方は日々変わっていくので、そこのあたりは、あまりコードを鵜呑みにせず、上手く動かないところがあったら、適時調べる必要はある気がする(これは上の本が古いわけではなく(むしろ新しい)、周囲のエコシステムはコロコロ変わるので、少なくとも「今どう書けばいいのか」くらいは調べられるようになっている必要がある)。