自宅宴会の料理
いまの家は二人で住んでいる。
当然二人で住めるぐらいの広さはあるので、宅飲みをしようという話になると、自分が場所提供することが多い。
料理を作るのも好きなので、会場が家だと（幹事から依頼があれば）料理を作っている。
すすんでポテチを食べながら飲むような年齢でもなくなったせいか、「つくろうか？」と聞いて「いや、持ち込むよ」と言われたことはない。もしくは、料理作りたい圧力をかけているつもりはないが、もしかしたらそう思われているのかもしれない…。
今回は、どういう思考回路で作っているのかとか、そういうことをざっくり書く。
特にオチもないし言いたいこともなく、自分でも何を思ってこれを書き始めているのかよく分からない。けど書き始めたので、始めます。
コース
真面目に作るときは、だいたいコースっぽい形式になる。
とはいえ、本当のフルコースとか作ってしまうと自分が死んでしまうので、だいたい以下になる。
- 和食…前菜、吸い物、魚料理、肉料理、ご飯もの
- 洋食…前菜、スープ、魚料理、パスタ、肉料理
申し訳ないのだが、自分が中華をほぼ食べないので、中華は分からない、つまり作れない。ごめんよ。食べる分には嫌いじゃないんだが、選択肢があると必ず中華以外を選んでいる気がする。
お金をかけると、和食は段々懐石っぽく、洋食はフレンチっぽくなっていく。お金をかけないと家庭料理っぽい感じ。
和食の場合は、ご飯ものをシメとして食べたいという要望が多いので、だいたいラストに出すか、お腹いっぱいであれば出さない。もしくは常にそのへんに置いておく。ご飯は残ってても翌日以降食べればいいので、わりと融通が効く。
洋食はパスタが必ず込みのコースになるので、一品の量が多いと前菜と魚料理がマージされたりする。パスタがグラタンになったりする事はあるが、パンになることは少ない。近くて美味しいパン屋さんを知らないから。
料理を出す順番はフライパンや鍋の空きが最適化される形になっている。スープとパスタは同じ鍋を使うので連続して出すことができないとか、そういう制限が色々とある。
男が多い場合はご飯で量を稼ぎたいが、それでもツマミが足りなければ、コースが終わっても延々と冷蔵庫の食材で作ることになる。遅くに続々と合流を始めるとその傾向が強く、最終的には食材が何もなくて蒸し野菜みたいな料理が出たりする。なので、豚の細切れみたいなのを、必要なくても用意している。
男が多いと、こうした予備食材も必要になるので、値段帯が若干下がってしまう。かわいそう。
値段
だいたい、お酒抜きで1000円〜で会費を回収している。ただし1000円だと本当にイマイチになるので、空気を読みながら提案している。
最初の頃は自腹を切っていたが、回数もそこそこな上に一度の人数も多いので、最近はほぼ回収している。後輩や、1人で来た人とか、コースじゃなくてツマミ程度であれば取らない事が多い。幹事がいれば必ずどうするか聞いている。
なお、よく来る男メンバーの場合、会場提供＆調理の対価として自分（と同居人）の金は出さなくて良いと言ってくれることが多く、本当に払ってない。よく考えると酒代も払っておらず、いつもタダ酒を飲んでいる。悪魔の所業。
一人3000円の場合、男で量が必要なのでランクは2500円ぐらいになる上に、俺と同居人分を肩代わりするので実質2000円ぐらいのランクになっている。 ボッタクリじゃないよ！
まぁ、男衆の場合は人数が本当に多くて作るの大変なので、許してほしい。
〜1000円
この値段帯だと和食というか家庭料理的な感じになる。
例：冷奴、味噌汁、刺身、肉じゃが、白おにぎり
2000円
全体的に食材グレードが上がる。居酒屋っぽい感じになる。
汁物がつみれ汁になったり、魚が中トロになったり、肉が角煮になったりする。前菜も選択肢が広がるので、面白いものがチョイスされる。
3000円
本当のコースっぽい感じになる。紀ノ国屋に行って買い物できるレベル。このへんから、自分の技術的に洋食が若干有利になり始める。
活きた車海老とか、蟹とか、美味くて厚い牛肉とか盛り盛りで食べられる。盛り盛りは言いすぎた。そこそこは食べられる。
4000円
野菜にまでこだわれる。めちゃくちゃ美味いパプリカとか、ジューシーな茄子とか、そういうのまでこだわれる。
こういう野菜こそが本当に美味しくて、とても高級感を感じられるのだけど、肉じゃがと一緒に出しても場違いになってしまうので、ある程度メインが満足できるレベルじゃないと出せないという…。
5000円
フォアグラとかアホみたいな食材をたくさんリクエストされなければ、常識的な範囲で何でも高級食材を食べられる（ゆーても紀ノ国屋で売られてるレベルだが）。
4000円もそうだけど、この値段帯になると、味付けがどうこうというより食材の問題になってくる。特に素人だと、味付けを頑張ろうとすればするほど駄作になるように思う。
過度な味付けはせず、岩塩やソースをかけて食べる。ソースもデミグラス！ みたいなのではなく、素材の味を引き出すのがメインになる。
ショボイと思われると味もつられてしまうので、一生懸命見た目も考える。
素人としては、洋食の方がソースにバリエーションがあって素材の味を引き出しやすいので、この値段帯だと間違いなく洋食にする。
ただ、このぐらいお金出すんなら、わざわざ宅飲みする意味ないと思う。高級食材出るからなんやねん的な。それより、ちゃんとした店に払った方が良いと思う。
うちは食材の値段しか取らないので、たぶんお店に行けば3倍以上取られると思うけど、素人に5000円払うよりも価値があると思う。
…とはいえ、自分のためだけに作るのに5000円の材料費とかもっとありえないので、出す人がいれば作ってはみたい。あれとかこれとか、作ってみたくはある。
宴会中の調理時間
実は、値段帯に比例している。高いほど時間がかかる。
値段が低いと、素材があまりよろしくないので、それを隠すために漬けにしたりするので、宴会中の調理時間は短くなる傾向にある。また、素材が高級になればなるほど、鮮度や焼き加減にこだわる必要があるので、その場での調理が重視される。ぶっちゃけた話、肉じゃがは作って置いとけばいいんだよ的なところがある。
あと、高ければ高いほど素材数を多くできるので、調理工程が複雑になったり、盛り付けにこだわりが出てきたりする。肉じゃがの盛り付けとか気にしたことない。
新しいアプリを作りました。
リリースしました！
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向けのアプリを作ろうと思っているので、そっちをやりつつ、様子を見て（色々変えつつ）もう一回審査に出してみようと思う。
