新しいアプリを作りました。
リリースしました！
Ruriというアプリをリリースしました。
http://www.martianstalk.com/
（サイトがまだcoming soon状態なので書き換えねば…）
日本ではまだ未発売なのですが、とりあえず1st verはできたので、振り返ってどういう事を気をつけたかを書きます。
ただ、さすがに全部は書ききれないので、今回は前職を経験していたからこそ判断できたことを中心に書いていこうかなと思います。
前職ではITベンチャーで、サーバー側のプログラムなどを書いてました。
個人で開発する
前職
前職では、20人ぐらいの人達と働いてました。チームプレーは、苦手ではないと思います。前職の後半は、コードを書くよりも人と話すことのほうが多かったです。
今回
自分は英語が厳しいので、利用規約などの部分は手伝ってもらいました。それ以外、つまりプロダクト自体は、今回全て1人でやってます。
主張したいこととしては、「1人は良い」ということではなく、「企画と開発とデザインを通してできることは良い」ということです。
この体制の良いところの1つは、判断の精度が高くなることだと思います。例えば、開発が難しいこのデザインは、果たしてペイするだけの価値を持つか？ といった問いに容易に結論が出せます。一般的には「開発の難易度」と、「デザイン品質」と、「ペイするかの判断」は全く別の人が考えますが、これらをシームレスに繋げることができます。また、職をまたいだ柔軟性が簡単に発揮できます。例えば、あるロールに偏った難しさがある場合は、別のロールで解決するといった方法を容易に取れます。開発とデザイン、企画が分断されていないので、デコボコした難易度や工数をおしなべることが可能です。
印象として、馬力が足りていないようには思いません。基本的には「簡単だけど効果のあることをやる」という戦略でやっています。そこを上手くに選ぶことが強みであり、逆に上手く選べないと一瞬で馬力が足りなくなると思います。
多言語化をしない
前職
前職では、多言語化を2回ほどやりました。多言語化は大変です。
まず、初回の翻訳にアホみたいにコストがかかります。単に訳せばOKといっても、例えば、「アイテムが3こ」の”こ"の部分とかも変換が必要なので、日本語表だけを見ながら翻訳するのは至難の技です。”こ"だけ書かれていても、どう訳せば良いか分かりません。そこで、使われてる画面を確認したいのですが、どこに使われてるのか翻訳者は分かりません。よって開発者に確認が入りますが、開発側も正直忘れているので、grepしないと分かりません。そんなこんなで、訳者も開発者もみんな大変です。
また、維持も大変です。流行りのLean開発では、細かく文言を変えるのは当たり前です。しかし、そのスピード感に、翻訳作業はついていけません。開発者の母国語以外を変更するには、少なくとも訳者のチェックが必要です。ひとまず日本版だけ、とやった箇所が増えていき、プログラムとして許容できなくなったり、抜け漏れが多くなったりします。多言語をちゃんとメンテナンスするには、かなりのコストが必要です。
今回
多言語化しないという割り切りもありますが、今回は多言語化する選択をしました。今回は、たまたま見つけたお客さんが偶然買ってくれることに期待しているので、市場が小さいとヒット数が少なすぎて食べていけないという事情があります。そのために、最低限英語は押さえておく必要がありました。日本語版を開発するか迷いましたが、マーケティングなどの要素が絡んだ場合、母国語以外では効果的に施策が打ちづらいので、手札として日本語も準備しています。
今回は多言語化をするかわりに、文字をなるべく埋め込まないということに心血を注いでいます。ほとんどをアイコンで表現しています。1st verには12個ほど文言を入れていて、あとはアイコンです。アイコンは最高です。さらに言えば、vector形式が最高です。どの解像度でも1種類で済みます。
当然、説明の力が足りていないアイコンもあります。どうしているかというと、どうもしてません。より良いアイコンが浮かぶまで、そのままです。文字で表現しないと成り立たないものは別ですが、多少わかりづらいぐらいであれば、アイコンにしています。
ユーザが多少わかりやすく使える"かもしれない"程度では、多言語化するコストを支払えません。このコストには、単純な工数というだけでなく、管理の苦痛、アテンションを張る辛さなども含んでいます。
個人情報 and クラウドを避ける
前職
前職では、個人情報をバリバリ使うアプリを作っていました。そして、個人情報をクラウドのサーバで管理していました。
怖いことはたくさんとあります。攻撃は怖いし、セキュリティホールも怖いし、バグで他人のデータが見えるのも怖い。発行先のメールアドレスを間違うのも怖い。何もかもが怖いです。流出すると全ての苦労が弾けてしまうので、慎重にならざるをえません。そうしたことに精神を使うのは、怖がりの自分には合っていませんでした。
今回
全てをローカルに保存しています。まぁクラッシュログとかそういう話は置いといて、情報を自社サーバに置く気は今後も全くありません。
ローカルのデメリットとして、バグでデータを損失させた場合に取り返しがつかないということ、複数端末が当然の時代でユーザの利用価値が下がるということ、などがあります。これらを流出の恐怖と天秤にかけました。その結果、今回はサーバに何も置かないという判断になりました。
まだまだ頑張ります
まだ食っていけるほど稼げてないので、まずは食えるように頑張ります。前職と1番違うのは、モノが完成するまで給料が0、ということですね…。
KindleStoreの新刊を出すサイト使った
サイトできたよー
漫画やラノベの新刊を、KindleStoreから買うためだけのサービスを作った。
KindleStoreって、新刊コーナーが最近電子書籍化された古い漫画で埋め尽くされたりいるなど、諸々辛い点がある。現実の本屋の新刊コーナーのように、新しい書籍かつ一般的に売れてる書籍だけ並ぶようなものが欲しかった。
ただ、Amazonさんのアソシエイトの審査が通らないから、URLはここに書かないしこのままお蔵入りかもしれんね。それについては後述。
使用環境
使ってる環境は以下。
言語とフレームワーク以外は別のにしたかったのだけど（MariaDBとかにしたかった…）、時間がもったいなかったので、経験があるものにしておいた。
使用gem
主な使用gemは以下の通り。
# Product Advertising APIを使うため gem 'amazon-ecs' # 半角 <=> 全角 の変換 gem 'moji' # cronに作ったバッチ（rakeのコマンド）を設定するため gem 'whenever', :require => false
あとは自力でゴリゴリと。MySQLのgemとかは略してます。
実装
ざっくり言うと、以下のような実装をした。
サーバのセットアップとか合わせて、全部で50時間ぐらいかかったと思う。2番と3番がわりとキツくて、半分以上の時間を取ったのではないかと。かなりの表記ゆれ等があって、それの対処が辛かった。
入ってるデータがテキトーすぎる件
例えば、APIから取れる本のデータには、出版日とリリース日というものがある。多くのデータは、出版日を紙の本が出た日、リリース日をStoreで販売開始した日としている。
…のだが、何割かのデータは出版日が間違っている。1998年に出版された本の電子書籍版が、出版日とリリース日ともに2014年になっていたりする。今回のサービスでは、これを頑張って訂正するプログラムを書く必要があるのだ…。
他にも色々とあった。その一部をご紹介しよう！
- リリース日より出版日が未来になっている（本来は出版日が必ず古くなる）
- 出版日に日数がない（2014-06-24となるはずが、2014-06までしかない）
- 電子書籍には巻数があるのに、紙の本には巻数がないラノベ（サブタイトルのみある）
- 電子書籍版と紙の本で、著者の姓と名の間の空白があったりなかったり、全角だったり半角だったりする
- 電子書籍版と紙の本で、レーベル名があったりなかったりする
などなど…。
ここに書いていない事含め、いくつかは辛すぎて放置していることを、ここで懺悔する。
今後
AmazonのAPIを使うには、アソシエイトのIDが必要であって、ちゃんと運営するのであればアソシエイトの審査をパスすることは必要条件になる。
ただ、審査に全然通らないので…。10回審査に落ちたら諦めようと思う。今は3回落ちたので、あと7回はチャレンジしてみるかな。
次はiPad向けのアプリを作ろうと思っているので、そっちをやりつつ、様子を見て（色々変えつつ）もう一回審査に出してみようと思う。
