| @労働

この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。


2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。

サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。

FANIC とは

FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成&音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作ることができ、楽曲をアップロードして試聴公開したり、リスナーに販売することが出来た。月額利用料は 315 円で、曲が売れたときに手数料 15.75 % が従量課金される仕組みだった。 2012 年の 1 月に公開して、 2013 年の 8 月 31 日にサービス終了した。

FANIC に携わることになった経緯

ペ社に入社したのは 2 年前の 10 月だった。前の職場がどうしようもないブラック企業だったことは前に書いた。

会社の開発環境が地獄のレガシー環境だったので面談で社長に Subversion やめて Git 使いたいと言ったら、「会社が気に入らないならさっさと辞めろ」と言われたので、何とか反省して心を入れ替えたふりをしながら職探しをしていたところ、 Rails 、 Node.js 、 Redis 、 MongoDB 、 Nginx 、 AWS みたいな福岡の求人にしては珍しくナウいキーワードで募集していたのがペ社の Dazaifu Project だった。

プロジェクトの紹介ページが何となく面白そうだったのと Rails で仕事できそうだったので応募した。小さなチーム、大きな仕事を読んだり、RubyKaigi 2010 に行ったこともあって、DHH や RubyKaigi で登壇していた人達みたいにとにかく Ruby で仕事したいという思いが強かった。前の職場でも Ruby を使いたかったけど ColdFusion や Flex など旬を終えたプロプライエタリなテクノロジーばかりを触らないといけなくてとにかくつらく、わらをもすがる思いで求人応募フォームを送信した。

8 月に応募して 9 月に内定が出て 1 ヶ月後にペ社に入社した。入社するまで配属先を知らなかったんだけど、 Dazaifu Project の物販系と音楽系の二つのサービスのうち音楽系の方に配属されることになった。それが FANIC だった。

FANIC で良かったこと

一つのプロジェクトに集中できる

受託の会社とかだと受託案件があって、案件ごとにメンバーがアサインされるから同時並行的に二つか三つを掛け持ちで担当するということがあるけど、自社サービスの会社では基本的に一つのサービス(案件)にかかりっきりで仕事をすることができた。これがとても良かった。午前中に A 社の対応をして午後から B 社、夕方からまた A 社のタスクに取りかかって 20 時から終電まで C 社対応、みたいな複数の仕事の切り換えがない。タスクの切り換えにはオーバーヘッドが発生するから、一つのことにかかりきりになれる自社サービスの仕事はとてもやりやすかった。加えてプログラミング言語はずっとやりたいと希望していた Ruby だったので言うことなしだった。会社に行くのが楽しかった。

ナウでヤングなアーキテクチャー

求人に上に書いたようなナウいキーワードを混ぜていたのは先輩の @linyows さんで、FANIC はインフラは AWS を利用し、データベースに MongoDB 、音楽や画像は S3 に保存して、WAV や AIFF でアップロードされた音楽ファイルを試聴用の MP3 に変換するバッチ処理や、画像を S3 から取り出すリアルタイムリサイズサーバーは Node.js で実装してあった。フロントエンドのアプリケーションは Rails で構築されていて、自分は主に顧客管理とか決済部分なんかを開発した。

ペ社では通常、インフラを担当する専任のチームがサーバーの面倒を見る。しかし Dazaifu Project はスモールスタートを掲げていたので、インフラも @linyows さんが一人で構築していた。今自分が配属されているサービスは結構でかくて、サーバー管理はインフラチームが担当し基本的に自分たちで設定を変えたりサーバーを構築したりすることはない。ちょっと Nginx の設定を書き換えるのにも申請書出してハンコリレーしたりしないといけない。おかげで凡ミスで 500 エラーみたいなことにはなりにくい仕組みになってるんだけど、リリースのスピードを上げにくい。そういう状況からすると、 FANIC でミドルウェアのバージョンを上げるのなんかも部署間の調整が必要なくさくっと出来たのはとても良かった。加えてデータベースが MongoDB だったため、データ構造の変更が柔軟に出来たのも良かった。

社内でいち早く CoffeeScript 使ってみたほか、ペアプログラミングもやってみた。かなり疲れるけど集中して取り組めるし、プログラマー間で仕様を共有できるのでこれは良いものだと思った。 FANIC のおかげでずいぶん成長させてもらったと思っている。

FANIC でつらかったこと

FANIC ですべてが良い方向に向かっていたかと言えば、決してそうではなかった。技術的にもプロジェクト運営的にも、苦しい部分が多々あった。

MongoDB で金の計算

技術的にはまず MongoDB で金の計算をするのがつらかった。

決済部分の開発で MongoDB の Embedded Document でかなり苦しめられた。契約 Collection の中に Embedded Document として請求と入金があるという構造だったけど、契約日と入金日が月をまたいでいて、一つの契約 Document 内にある Embedded Document をそれぞれ別の月の入金と請求とする必要があり、かなり苦しい感じだった。前受金の概念とかも Document 指向のデータベースで対処するのは地獄的な感じがした。Document の中に何でもスポスポーと Embedded Document を突っ込んでいけるのは便利なんだけど、親 Document と Embeded Documet を別の文脈で使おうとするときに困難が生じると思った。

MongoDB を大規模に利用している CA 社も JOIN ができないので金関係だけは MySQL でやっているという話を聞いたことがある。金の計算をするときに JOIN の代わりに Map Reduce する必要があったけど、自分が開発に利用していた頃の Mongoid (MongoDB 用の ActiveRecord 的なやつ)は Map Reduce に対応しておらず、 Rails のモデル内に Map Reduce 用のクエリ(MongoDB のクエリは JavaScript で書かないといけないので Rails のモデル内にヒアドキュメントで JS が書いてあるという地獄っぽい感じになる)を書いたりした。Map Reduce しないのであれば二重 Loop でグルグル処理を回さなければならず、毎度これを Ruby にやらせるのはパフォーマンス的にしんどかった。総じて MongoDB は大量のデータを集計したりするのには向いてないかなーという印象を持った。それぞれを独立したドキュメントとして利用する機会が多いタイプのアプリケーションには向いてる気がする。設定情報の保存とかブログ記事の保存とか。金系のデータが沢山入っていてそれを月ごとに集計してどうのこうのとかやるときがつらい。

Mongoid のため便利 gem が使えない

Rails エコシステムの中で MongoDB は少数派だから、様々な便利 gem が ActiveRecord に依存していて使えないことがあったのも困った。たとえば ActiveAdmin が ActiveRecord に依存しているために利用することができず、顧客管理を一から実装しなければならなかった。なければ作る or Pull Request 出して取り込ませる、というようなマッチョマンじゃないと Rails でレールから外れるのは厳しいと感じた。

リーンスタートアップできていなかった

プロジェクト運営的には、チームの目標とか優先順序の付け方とかがハッキリせず、行き当たりばったりな開発・運用になっていたのがつらかった。

2012 年の春、『リーンスタートアップ』が流行ってた。みんな本買って読んでて、社内で antipop さんによる講義とかもあった。でもリーンスタートアップは本当に難しくて、誰でもリーンスタートアップ読めば新規事業で成功できるわけではないと思う。サービスの企画立案者が有能なだけでは不十分で、起業家に加えて、極めて優れたエンジニアが付帯していないと厳しいと思う。自分たちに必要だったのはリーンスタートアップを読むことではなかった気がする。全然そのレベルに到達していないという感じだった。

思い込み・お問い合わせベース開発

リーンスタートアップには、仮説の検証をものすごい速度で行ってフィードバックループを回さないといけないと書いてあるけど、そもそも自分たちには仮説の検証方法が存在していなかった。本に書いてあるとおりに様々な仮説を素早く検証していくには、企画担当者がやりたいと思ったことを一週間くらいで実装して次々に仮説を検証していかないといけない。A/B テストをやるにしても、A/B テストをやるための仕組み作りが大変だと思う。オープンソースで使えるものに Cookpad の Chanko とかあるけど、 MongoDB がネックになって利用できなかった。自分たちでそういう仕組みを作るにはかなり多くの時間を作らなければならなかったと思う。結局思いつきやお客さんからのお問い合わせベースで開発する機能が決定されて実装されていった。お問い合わせが結構あったから 1 ヶ月以上かけて実装してみたのに全く使われない機能とか、これは絶対に行けるはずと自分が思い込みで提案して実装したのに全く使われない機能とかあって、全然良くなかった。

ちなみに↓のスライドではてなブログのリーンな開発風景が紹介されてるけど、情報収集のところで紹介されてる手法を真似しようとするとかなり大変だと思う。雑魚いエンジニアしかいないとここまでやるのは難しい。

技術的に正しいことをしようとこだわりすぎて中途半端になっていた

入社した頃、テストを書くという習慣がプロジェクトになかった。プロジェクトに加入した初期の頃から自分はなるべくテストを書こうとしていて、テストを書く習慣を定着させたつもりだったけど、これも良かったのか悪かったのか分からない。テストを書くとどうしても時間がかかってしまう。 TDD BootCamp Fukuoka Vol.2 できしだなおきさんが言っていたんだけど、テストコードがあるとプロダクトコードのメンテナンスに加えてテストコードのメンテナンスも必要になる。そうすると俊敏に動くということが難しくなる。自分はテストを書くことに時間をかけすぎてしまってサービス開発のスピードを鈍らせていたような気がする。

テストを書いたりリファクタリングをしたりしないのは正しい行いではないと思うけど、会社に雇われて給料をもらっている以上、サービスを成長させることがエンジニア云々以前にサラリーマンとして大事だと思う(『情熱プログラマー』とかにも書いてある)。特にプロジェクトの最初の段階では、技術的な理想を追求するよりも、不完全でも良いのではやく製品を投入して一つでも多くの仮説を検証して学びを得ることの方が重要なのではないかと思った(Minimum Viable Product)。

自分のプロダクト感を持てていなかった

サービスに対して、「自分たちのプロダクトだ」という感覚が希薄だったと思う。そもそも hitode909 さんのスライドみたいにドッグフード食べてなかった。自分の FANIC 上のページは検証用に作ったインターネット上のゴミみたいなページだった。

みんなビラ配りとかオフィス外での宣伝活動とかに消極的だったし、このプロジェクトがぽしゃったら失職する、みたいな危機感が希薄だった。自分は机に座ってプログラミングできればそれでいいみたいな感じがあった。口ばっかりで手が動いてなかった感がある。

地元の野外フェスとかに行ってビラ配るとかオフラインでの宣伝が必要だったのかもと思う。終わるって決まったとき、やりきった感がなかった。これでうまくいかないなら仕方がない、と思えるところまでやれてなかった。

エンジニアであってもプロジェクトの当事者意識を強く持たなければならないのだと思う。いまいくら自分たちが稼いでいて、あといくら稼ぐと黒字になるのかとか、どのくらいのスピードで成長していかなければならないのかとか。

チームの雰囲気が良くなかった

一番の苦しかったのはこれだと思う。

いま思い返してみると、 1 年半の間でチームのメンバーが揃って食事をしたのは 1 回くらいしかなかった。お互いへの理解が欠如していたような気がする。雰囲気悪かったからサービスが崩壊したのか、サービスがうまくいっていないからギスギスした感じになったのかは分からない。ただ、雰囲気の良くないチームが作る製品が良いものになることは基本的にないと思う。

FANIC を離れたあとも、会社を挙げて永和システムマネジメント社の講習を受けてスクラムに取り組んだりしてる。しかし結局どんなプラクティスを導入しようとも、チーム内でコミュニケーションが取れていないと技術的に見過ごすことの出来ない問題に気づけず非常に大きな手戻りが発生したり、仕様上の大どんでん返しがやってきたりする。技術的に足りない部分があったとしても、コミュニケーションが機能していたらカバーできたのではないかと思う。

結論

結論としてはチームで寿司を食べたりするしかないと思う。銀しゃりのまばゆい輝きが、うにやいくらの神々しい光が、鋭利な刃物のように光るサバのにぎりが、闇を照らしてくれる。

上にぎり 1.5 人前


この記事は闇 Advent Calendar 2013 - Adventar 22 日目の記事でした。 23 日目は hurutoriya さんで、今日の担当は @udzura さんです。

| @ブログ

技術のことを書いてたブログ( tech.portalshit.net )を Amazon S3 で公開するようにした。9月くらいまでは EC2 の micro に置いてたんだけど EC2 micro でも高くて家族の理解を得られなくて terminate したので表示できなくなっていた。

やり方は以下の Qiita の記事を参考にした。jekyll-s3 という gem 入れればよかった。簡単だった。

手順ミスって US リージョンで公開することになったけど遅さとか感じないのでこれで良いかなと思う。

Jekyll 、なんか Liquid みたいな特殊なテンプレートエンジンだし、 Lokka の方が Rack アプリケーションの勉強になるし自分でつくった Syntax Highlighter 気に入ってるのでプログラミングっぽいこともここに書くようになってしまった。しかしそのうち気が変わってまたあっちに書き始めるかも知れないのでとりあえず公開できる状態にしておく。ちなみに tech.portalshit.net は最初、今はなき Mephisto という Rails 製のブログツールで構築してて、デザインは Mephisto 用のものを Jekyll に自分で移植して使ってる。

関連してそうな記事

| @散財

去年、嫁さんに強請られて GORE-TEX のコートを買わされた。自分はシェラデザインの 60/40 マウンテンパーカー/ショートパーカーを三着持っていて(SIERRA DESIGNSのマウンテンパーカー)、冬はこれを着て過ごしていたんだけど、最長老が5年目に入りくたびれてきたので自分にも GORE-TEX ものが欲しくなったのでだだをこねて ARC'TERYX というメーカーの Alpha SL というジャケットを買った。

買ってみての感想だけど、ぺらぺらの化学繊維なのに寒くなくてすごい。 GORE-TEX の衣類は一枚だけ着てても温かくないとは言われるし 60/40 パーカーもそれだけ着てても寒いだけなので防寒力は期待してなかったけど、中にヒートテック的な肌着を着て適当なトレーナーみたいなやつを着れば九州の平野部の冬は乗り切れると思った。風をシャットアウトしてジャケットの内側の温度を一定に保つ力がすごいのだと思う。

よくみんな冬はダウンとか分厚いコートとか着たりするけど、自分はああいう防寒の仕方には懐疑的だ。ダウンやコートが熱を発することはない。服を含めた人体の中で熱を放つことが出来るのは自分自身の体だけなわけだから、自分の体から発生した熱をいかに逃さないかが防寒のキモだと思う。ダウンも分厚いコートも結局外気と体の間に空気や繊維の層を作って体の熱を逃さないようにしているだけだと思う。なのでぺらぺらのウィンドブレーカーみたいな薄い化学繊維でも体温を逃さないという防寒の第一目的を果たせればそれで良い気がする。

肝心の GORE-TEX の透湿性だけどこれはよくわからない。 60/40 パーカーの方が良いような気がする。 GORE-TEX は雨合羽に近い感じがする。確かに水弾きはよさそうだけど、春先とか秋口に着るとわりと蒸れて肌にくっついたりして気持ち悪いかもしれない。 ARC'TERYX は同じ商品名でも生地の種類ごとに値段が違ってて、もう少し高いやつだと GORE-TEX を外側と内側に二枚貼りしていて耐久性が良く、肌触りも良いらしい。自分が買ったのは安い方の商品なので GORE-TEX 生地は 1 枚で、内側には経年とともにはがれ落ちてくるコーティング剤が塗ってあるだけとのことだった。なので金持ってる人は LT 以上のやつを買った方がいいと思う。着心地は正直 60/40 パーカーの方が良かった。肌が呼吸できてる感があるし、コットンが四割なので生地がやわらかくしなやかで無骨なナイロン感がない。

ネットで安く ARC'TERYX 売ってるけど、自分は試着してから買いたかったので観光がてら北九州の店まで行ってから買った。当方デブ体型だけど S で丁度良かったので標準体型の人は XS とか買った方が良さそう。

関連してそうな記事

| @読書

ピアソン技術書撤退で今は新品で買えない達人プログラマー、数年前に紙の本で買って持ってたけどでかくて重くて翻訳文体がつらい感じで 1/4 くらい読んだところで放置してた。裁断して Kindle とかに取り込んで気軽に持ち運べるようになったら読めるかなと思って去年 KINKOS で裁断して会社の ScanSnap で PDF 化した。しかし PDF 化して気付いたんだけど、達人プログラマー、以下のようなレイアウトで iPad とか Kindle で異常に読みにくかった。

達人プログラマーのレイアウト

これをスキャンして取り込むと一ページずつはこんな感じになる。

達人プログラマーのレイアウト

余白が多いため、 Kindle や iPad mini で読むとき文字が非常に小さくなり、拡大しながら読まなければならない。また左右の余白が異なるためページめくりをする度に視線を移さなければならずしんどい。こんな苦行に耐えられる人はいないと思います。

余白を削除すればいいんだけど、奇数ページと偶数ページで余白の位置が異なるので単純に余白削除できない。

達人プログラマーのレイアウト

達人プログラマーのレイアウト

Mac のプレビューの編集でトリミングとかあるので、奇数ページだけを選択して一括編集とかできるかなと思って調べてみたけど出来なそうだった。

ウェッブデザイナ〜になりたかった頃に買った Adobe CS4 があることを思い出し、 Adobe Acrobat Pro で PDF を開いてみたら、ページのトリミング機能の画面で適用先を「奇数ページのみ」とか「偶数ページのみ」とか選べることが分かった。

達人プログラマーのレイアウト

この機能を使ってなんとか Kindle でもギリギリ文字が読めるかなというところまで余白を削除できた。

パソコンで執筆・編集され出版された紙の本を裁断してスキャンして読みやすいように余白消したりするのものすごくアナクロ感あるので本当にやめたい。

| @Mac/iPhone

Reeder for Mac の新しいの出ないので ReadKit というの買ったらイノベーティブだった。RSS リーダーとしてだけではなく、Pinboard のブックマークとか Instapaper とか Pocket のやつも読めてこれまでの RSS リーダーとはひと味違う。これだけでフィードの購読、過去読んだ記事の検索までできるので最高だと思う。Google Reader 死んでからインターネットつまらないと思ってたけどこれでまたインターネット楽しくなりそうな感じする。

ReadKit

| @散財

結局 Happy Hacking Keyboard を自宅用にも買って、家でも会社でも Happy Hacking Keyboard 使ってる。会社で墨を使って家ではホワイトを使っている。キーの押し心地は何となく高級感のある墨よりもプラスチッキーなホワイトの方がマイルドな感じがして良い。しっとりした感じがする。墨はスカスカ感がある。

ホワイトを気に入って使っていたら、キーを押し込むとき本体左下部分がミシミシときしみ音をたてることに気がついた。1万8千円もするのにひどいなぁと PFU に問い合わせたら交換品を送ってもらえた。

全般的に Happy Hacking Keyboard 素晴らしいと思う。みんな買えば良いと思う。

キーボードのことばかり考えてるとそのうち Kinesis とか欲しくなりそうな気がして怖い。


追記

結局交換品もミシミシ鳴る。これは仕様だと思って諦めるしかなさそう。会社で使ってる墨はしっかりしてるんだけどな。

| @雑談

d4990c64f75ca38b6b416a9037adfed5.png (802×562)

Ruby 関連のことを検索していて Shopify の中の人のブログにたどり着いた。なかなか面白いことが書いてあった。

この人は去年の 11 月に iPhone 4 を落として割ってしまったらしい。すぐに iPhone 5 を買おうとしたのだけど、思いとどまって一月ほど iPhone なしで過ごすことにしたそう。自分がどのくらい iPhone に依存してるのか知りたかったのだとか。そしたら意外と良かったらしい。以下超訳。

iPhone があった頃は常に Facebook、Twitter、Email、iMessage、携帯、HipChat、Skype や対面での会話と心が安まらなかった。プッシュ通知を切ったとしても空き時間にメールチェックしたり Twitter や Facebook を見てしまう。常にオンライン状態で、どこにいてもどこにもいないような感じがつらかった。iPhone がなくなったらコンピューターの前にいるとき以外は目の前の友達や同僚のことだけ気にしていればいい。スマートフォンは作業と作業の合間の、さっきまでやっていたことと次にやるべきことについてに省みるべき時間を、ぼーっとゲームをしたり Twitter を見るような用途に費やす手助けをしていることに気がついた。スマートフォンがなくなってからアングリーバードやったり、Facebook を見たりして無為に時間を過ごすことがなくなり、やるべきことに集中できるようになった。

スマートフォンをやめて Nokia レンガ(昔ながらの携帯)で過ごすにあたって、心配してたのが以下の三点だった。

カメラがない

旅行するときはいつも iPhone で写真をとっていたけど、カメラは人に借りれば良いかも知れない。ひょっとするとなくても事足りるのかも知れない。

音楽がない

歩くときは気分を紛らわせるために音楽を聞いていた。しかし本当に音楽を聞きたいときはパソコンの前に座れば良いことに気がついた。音楽なしで歩いてもしんどくないし、周囲の物事に心を巡らせる良い機会になった。

地図がない

iPhone の Map は多用していたけど、方向感覚に自信があったのでどこかに行くときに地図を見るのをやめてみた。そうすると出発前に入念に準備が必要になった。外国に行くときは紙の地図を使った。また本当に迷ったときは人に道を聞けば良いし、尋ね先の人に電話して道を尋ねれば良い。

3ヶ月ほどスマートフォンなしで過ごしてみて、期待していなかった以下のメリットに気がついた。

よく人に電話するようになった

iPhone の頃はメールを多用していてほとんど電話をかけていなかったけど、古い Nokia の携帯だとメールを打つのがつらくてしょっちゅう電話をかけるようになった。同世代の人に電話をかけるとびっくりされる(みんなメールしか使わないから)。携帯の根本機能と会話の楽しさを再発見した。電話した方が話が早く済みそうな場合や深い話の時はメールではなく電話しか使わないようにしている。

携帯の存在を気にしなくなった

鞄の中に適当に携帯を突っ込んで出かけるようになった。ポケットに何も入ってなくて気楽になった。眠る前に携帯がどこにあるか探さなくていいし、安い携帯だからキズが入らないように気を付ける必要もない。心配事が減るのはいいことだ。

上に挙げた懸念事項は正しかったが、それなしでもやっていける

確かに色々不便だがなくてもやっていけることに気がついたし、スマートフォンを持たないことによって得られるメリットがあることもわかった。

“携帯を二週間に一度しか充電しなくて良いのは気が楽” というあたりはなるほどなぁと思った。寝るとき、出かけるときに iPhone を探さなくて良いのも羨ましい。随分楽だと思う。

自分もスマートフォンを使うようになってから Twitter 中毒が重症化し、移動中に本を読むということがまったく出来なくなった。iPad ではなく Kindle がいいと思ったのもネットを見る機能が付いてなくて読書に集中できそうだから。しかし結局手元に iPhone があると Twitter を見てしまう。この人みたいに思い切って落として割ってしまうのが良いのかも知れない。