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


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

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

FANIC とは

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

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

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

前働いていた会社の思い出と近況 - portal shit!

会社の開発環境が地獄のレガシー環境だったので面談で社長に 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 ヶ月以上かけて実装してみたのに全く使われない機能とか、これは絶対に行けるはずと自分が思い込みで提案して実装したのに全く使われない機能とかあって、全然良くなかった。

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

高速にドッグフードを食べる方法 // Speaker Deck

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

入社した頃、テストを書くという習慣がプロジェクトになかった。プロジェクトに加入した初期の頃から自分はなるべくテストを書こうとしていて、テストを書く習慣を定着させたつもりだったけど、これも良かったのか悪かったのか分からない。テストを書くとどうしても時間がかかってしまう。 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 入れればよかった。簡単だった。

静的ウェブページはJekyllとAWS-S3が簡単確実 - Qiita [キータ]

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

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

関連してそうな記事

Lingrlingr-irc + ZNC 経由で見てるんだけど、 5 分おきくらいに接続が切れて辛い感じだった。vim 界隈で有名な mattn さんがエラーにならないように改修してるぽかったので (Pull Request 出してあるけどまだマージされてない ping pong by mattn · Pull Request #3 · psychs/lingr-irc )ブランチを拾ってきて Merge してみたらかなり良い感じに Lingr を IRC クライアントで見られるようになった。併せてこちらの Pull Request bot message should be NOTICE by mattn · Pull Request #4 · psychs/lingr-irc のパッチも当てると GitHub からの通知とかは PRVMSG 扱いではなく NOTICE になるのでより IRC っぽくなる。便利。

FANIC

会社で何の仕事をしているか書いてなかったので書いておきます。DAZAIFU プロジェクトの FANIC というプロジェクトでプログラミングをやってます。FANIC とは音楽をやっている人のためのサイトで、デザインのカスタマイズがわりと自由な音楽ホームページです。ご自分が作った曲をアップロードしてインターネットユーザーの皆さんに音楽を聴いてもらうことができます。

先日やっと、音楽を販売する機能がリリースされました。ここまで結構長く時間がかかってしまい、販売機能を待ちわびていたミュージシャンの方々には申し訳ない限りです。

自分で作った音楽を売ろうと思っているけど売りたい場所が見つからなかった方、是非一度 FANIC をお試し下さい。いまなら月額の利用料金(315円)がかかりません。

FANIC が他の音楽販売サイトと異なる点は、非圧縮の音源をアップロード出来る点だと思います。AIFF や WAV といった高音質の音源を販売することが出来ます。圧縮音源では自分の音楽を売りたくないとお考えの方にもご満足頂けるのではないかと思っています。また iTunes や Amazon と違って、仲介業者を通さず個人が直接 FANIC で音楽を売ることができます(これが意外とハードル高いっぽい)。仲介業者を通さないので手数料が安めです(販売額の 15.75%)。

ここで読者の皆様にお知らせです。shikakun という若者がいて、僕はこの人の作る音楽が好きなんですけど、これまで shikakun のサイトなどから曲をダウンロードしても shikakun に投げ銭をする方法がありませんでした。しかしいまは FANIC があります。http://fanic.jp/shikakun にアクセスすれば、shikakun が作った音楽を試聴し、気に入ればその場で購入&ダウンロードすることができます。是非、shikakun の音楽を買ってあげて下さい。shikakun にメロンパン以外のものを食べさせてあげて下さい。

FANIC と shikakun の音楽をよろしくお願いします。

自分にとってTwitterでfavする行為、面白いものを見つけてきて☆をつけて遊ぶというか、DJが面白レコード発見してきて人に自慢するのに似た感覚があって、@wyinoue さんとか、箸を転がしただけでも50favされるような人をfavるのは掘ってる感がなくてつまらないと感じる。

Backlogユーザーのミートアップに行ってみた。Cacooなどで注目されているヌーラボのイベントなので何か面白い話が聞けるのではと期待して行った。

Backlogユーザーの集い in Fukuoka|どこでもプロジェクト管理バックログ

Backlogのそもそもの開発経緯は、自分たちが受託開発のプロジェクト管理のために作ったものを公開したのだそう。37signalsのBasecampと一緒だなと思った。『小さなチーム、大きな仕事』に書いてある。「自分たちが必要なものを作れ」、「最初の顧客になれ」ってやつ。自分たちすら必要としないものは誰からも欲しがられないのだろう。

ユーザーの活用事例で面白かったのがドメインの失効管理にBacklogを使うという使い方。前勤めてたとこでドメイン切れ事故が起きてしまったんだけど、ああいうのはExcelで管理してるだけじゃ確かに忘れやすい。Backlogに課題として登録してリマインダーの設定しとくと安全だなと思った。

意外に知らなかったのが開発者向けAPIの存在。シャノンの堀さんはAPIにアクセスするプログラムを書いて月初にBacklogにタスクを登録してしまうそう。これをアジャイル開発の手法であるスクラムと組み合わせて運用しているとのこと。生産性が3倍以上になったそうです。

Backlogユーザ会

人生初体験だったワールドカフェもなかなか興味深かった。テーブル上の紙にどんどん各人がアイディアを書いていき、時間を区切って席を替わりながら討論していく。紙の上にアイディアを書くので、声が小さい人の話も紙の上に残るし、話し好きの人が延々話し続けるタイプのディスカッションより話題に広がりが生まれるなと感じた。

ワールドカフェの議題は「あなたなら今後のBacklogをどうしますか」というもの。自分はGit対応や、37signalsのBasecampが幅を利かせている海外で勝負するには、オープンソースコミュニティには無償で使わせてあげるとPRになっていいのじゃないだろうか、といった意見を出した。

SkypeやGoogle Appsとの連携を希望しているユーザーが多くいる一方で、非ウェブ系企業ではファイル共有はおろかSVNさえ外部のリポジトリを利用することが禁じられ、Backlogの機能を十分に生かし切れていないとのことだった。

Backlogという製品に関してよりも、いろんな業種の人が異なる様々な条件でウェブサービスを使ってるんだなーということを知ることができて楽しかった。

また懇親会ではアラタナ研究所の @shunsuk さんとVimやRubyトークに花が咲いて非常に楽しかった。阿蘇にいた頃は技術の話ができる人が身近にいなくて悶々としてたもんだから、田舎から出てきて良かったなーとしみじみと感じた。天神で Kumamoto.rb やりたいです。

ヌーラボさんにはこのような場を提供していただき感謝しております。楽しかったです。ありがとうございました。

IMG_0109

先々週になるけど、福岡に新しくできた [アラタナ研究所](http://lab.aratana.jp/ “アラタナ研究所 aratana laboratory”) のレセプションに行った。研究所の所長であらせられる @rytich さんに招待してもらった。

なんと同研究所には熊本にいた頃からお会いしてみたいと思っていた @shunsuk さんもお勤めであり、お目にかかってご挨拶することができた。

@shunsuk さんのブログ「 で写真が見られるけど、パーティションが全面ホワイトボードのオフィスはとてもかっちょよい。ホワイトボードに↑の落書きを施した後、他の人が書いたのを見てたらウェブアプリケーションのスキーマを書いたとおぼしき走り書きが目にとまった。前の職場で一人でプログラム書いてた頃が無性に懐かしくなった。ああでもない、こうでもないと考えながら、作っては壊し、作っては壊しを繰り返してプログラムを書いていくのがとても楽しかったことを思い出した。

レセプションの最後に若くてイケメンな株式会社アラタナの濱渦社長が「九州から面白いサービスを作っていきましょう」とスピーチしていたけど、すごく楽しそうで羨ましかったし、自分もなんかしなきゃと焦ってしまった。

何はともあれアラタナ研究所オープンおめでとうございます。