portal shit!

rebuild.fm でたびたび HipChat とか IRC の話がある。最近は Slack というサービスが流行っているらしい（Rebuild: 54: Email Will Never Die (naan, N)）。ウェブ開発者じゃない人の間にも広まってる感じなのかな。自分はいまの会社に入って初めて IRC に触れて便利だなぁと感動したし、もう IRC のようなチャットシステムがない会社で働くのは無理だなぁという感じがする。

これまで働いてきた会社の情報共有手段を振り返ってみる。

最初に就職して三日で辞めた会社

数人しかいない会社。なんかよくわからない P2P のメッセンジャーだった。一対一でしか情報やりとりできない。 URL の共有とかファイル共有に使ってた。口頭での情報共有がメイン。

二番目に勤めた地元のホームページ制作会社

10人くらいしかいない会社。 Yahoo! メッセンジャーだった。グループチャットとかできたのかもしれないけど一対一でしか使ってなかった。使い方は同じように URL とファイル共有だった。口頭での情報共有がメイン。

三番目に勤めた福岡のウェブ制作会社

社員数は70人くらいで東京やベトナムの社員とも協働することが多かった。基本的に ML でやりとりして、チャットは MS の Communicator とかいうやつだった。 Active Directory なやつ。グループチャットとかあったけど基本的に一対一で情報やりとりしてた。この会社くらいの規模から口頭での情報共有が厳しくなってくる。

現在の職場

社員数300人くらいで、 IRC でやりとりしてる。チームによっては Skype 使ってるところもあるけど、基本的には IRC 。 IRC の良いところは、話しかけることで会話が始まるのではなく、チャンネルがあってそこに人が入っていく感じ。たまり場感ある。大学生の頃サークルやってなかったからちょっと違うかもしれないけど、サークルのたまり場に似てるんじゃないかという感じがする。 IRC に接続すると誰かいてなんか返事が返ってくる感じがいい。

あと ZNC などの IRC バウンサー使うと自分が接続していなかった間のログも読めて良い。 Skype のチャットにもこういう機能あるけど、 Skype はグループを作ったりとか人との会話とかで、人と人のチャットに主眼が置かれる。 IRC はトピックごとに場所がある感じ。

社員全体へのお知らせとか #all チャンネルとか #fukuoka チャンネルに書かれるけど非同期に読めるのが良い。 MS の Communicator とかはその場ですぐ来たメッセージ読んで返事しないとちっこんちっこんアイコンが光ったりしてうざい。というか一対一の会話ツールは非同期コミュニケーションしづらい。 IRC だと手が空いたときにまとめて読んだりできるので良い。

あと IRC は Ikachan とか Hubot とか bot にいろいろやらせられるのがよい。 Jenkins のビルドが走ったら IRC に通知する、デプロイが始まったら IRC に通知する、 Hubot にデプロイをやらせる、 GitHub の Issue にコメントがあったら IRC に通知するなどなど。

三番目の会社は各人が情報にアクセスできるレベルが Active Direcotry で管理されてて必要な情報を必要な時に得ることが難しかった。 IRC でも選ばれたメンバーしか入れないチャンネルとか作ることもできるけど基本的に本人がこの情報欲しいと思ったときにそのチャンネルに入って情報を得ることができて効率が良いと感じた。

もっと多くの人が IRC とかチャット使って仕事して欲しい

IRC はずっと前からある技術だけどいまでも便利な情報共有手段だし何でもっと多くの会社で使われないんだろうという感じがある。小さな会社じゃ自前で IRC サーバーたてるのとかしんどい感じあるしある程度技術者がいて運用スキルがある会社じゃないと使えないのかも知れない。いまは HipChat とか Slack とかあって IRC サーバーたてなくても良いし ZNC とかの使い方がわからなくても過去ログ追えたりするわけだし、ウェブ開発者がうようよいるような会社じゃなくても便利なチャット使えるのだからもっといろんな会社に広がるといいと思う。自分がいまの会社に入ったときに感じた情報源の広がり感をもっと多くの人に味わってもらえると日本社会もっと良くなる気がする。

新卒研修の一環で、若者向けにおっさんエンジニアが座学をするという取り組みが会社にあって、自分も担当したので資料を公開します。自分は技術力低くて技術的に有益な話はできないと思ったので奇行に走ってポエムを吟じた。

うちの会社、技術基盤チームの面々がすごく熱心に教育するし前年に新卒で入った若者たちも研修に絡んで斧を投げてくるので新卒で入ると大変便利なのではと感じる。業務として Rails チュートリアルやらせてくれる会社とかあんまないと思うし、おっさんエンジニアによる座学とかもあって、自分のようなポエムから Go 言語の話とか AWS やらインフラの話まで聞ける。技術的に有名な会社とかだと新卒入社時からエンジニアとしての高い能力が求められたりするのではないかと思うけど、うちの会社は雑魚キャラでも入ってから育てる的な環境がある気がするので、当初は Visual Studio でしかコード書いたことないしコードのインデントは Tab とスペースが入り乱れ、そもそもインデントがおかしい、みたいな状態の若者でも研修後には割とまともになってて一年後には Emacs でバリバリコード書いて何食わぬ顔で新サービスリリースしてたりする。なので今は雑魚キャラだけど成り上がってやりたいという方にもおすすめです。

こちらからは以上です。

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

結論

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

---

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

会社、antipop さんという有名なプログラマーの人がいる。去年、はてな社からペ社に移籍してきた。antipop さんともう一人の有名プログラマー hsbt さんが旗振り役になって（人事部長を巻き込んで）スクラムを会社に定着させようとしている。

アジャイル開発とか、受託開発の会社にいる激務薄給な感じのプログラマーがウォーターフォール開発に絶望してたどり着くものというイメージがある。だからはてなのようなモンスター級のスーパープログラマーばかりいる自社サービスの会社にいた antipop さんがアジャイルに開眼するのは不思議な感じがした。なんですごい人たちばかりの会社にいてアジャイル良いと思ったんですか、と antipop さんに質問したことがある。すごいプログラマーがたくさんいてもすごいサービスができるとは限らない、はてなにもうまくいかなかったサービスはある、すごい人たちがおりゃーと開発するより凡人だらけでもアジャイルなやり方で開発した方がよいものができるのではないか、と思ったからアジャイルに傾倒し始めた、ということらしい。

なるほどなー、と思った。

RubyKaigi 、2010 年のに行ってすごく感化されて 2011 年も 2012 年の Sapporo も行きたかったけど結婚するといろいろあってそういうのは無理だった。当然のように今年も無理だった。恐らく自分は終生 RubyKaigi には行けないのだと思う。ああいうプログラミングのイベントに熱心に参加したり運営の方に回ったりする人は本当にすごいと思う。みんなそれぞれ家庭とか奨学金の返済とか住宅ローンとかあるんだろうけど、時間をやりくりしてコミュニティ活動を行っている。

受託の会社にいた頃、技術とかどうでも良くて言われたとおり作って金がもらえるならそれでいい、というような情熱がない感じの人だらけの職場がとても嫌だった。しかしいま自分が彼らのようになりつつあるように感じる。悪い感じにサラリーマン化している。このままでは新卒とか有能な若者にあっという間に追い越されて老いさらばえていくだけだと思う。それは分かっているけど 30 歳くらいになるといろいろ厳しい。

9月1日からシニアエンジニアを拝命しました。シニアエンジニアには 30days/Sqale の刺身☆ブーメランさんやインフラエンジニアの @lamanotrama さんなんかがいて、自分のような職業エンジニア歴の短い人間が同じ肩書きで仕事して良いのかと不安もあるんですけど、技術責任者の mizzy さんには業務内容の他、 Lokka のプラグイン作ったりバグを見つけて pull request 送ったりしてたことを評価して頂き、晴れてシニアエンジニアとなることができました。

ちなみに選考は刺身さんが書いてる前回の様子（シニアエンジニアになりました - 刺身☆ブーメランのブログ / @kyanny’s blog）からさらにラディカルになっていて、応募（pull request で行います）からレビュー、結果の発表まで GitHub のプライベートリポジトリで行われました。ジットハブ、本当に便利ですね。

シニアエンジニアの名前に恥じないよう、多くの人に喜んでもらえるサービスを提供するとともに、「所詮ペパボ」とか言われないよう、技術力を高めていきたいと思います。

福岡配属になった新卒氏が自分のチームに配属されたのでペアプログラミングをやってた。一応 OJT なんだけど、東京で @hsbt さんと @antipop さんによるブートキャンプを経験してきた新卒氏に「request spec を書く前に view を書くな、ハゲ」と自分の方が叱咤されたりしてこちらも良い勉強になった。

新卒氏に便利な UNIX コマンドを教えたり、rbenv の利用方法を教えたりしながら、自分で言うのもなんだけど、俺やシニアエンジニアの @linyows 氏が独学で覚えたことを口頭で教えてもらえてすごくラッキーだよなー、と思ってしまった。TDD とペアプログラミングで OJT なんてすごいと思う。特に福岡では。

訳の分からない SI 会社に入ってしまった若者は、コードを書きたいのに詳細設計書（実はなにも詳細に設計されてない、どうせコードを書く段になって仕様は変わるし設計通りに作るなんて無理だから）を方眼の Excel ドキュメントに延々書いたりとか、訳の分からないミーティングに出席させられて延々議事録を取ったりとかしてる。SI 会社の連中は FizzBuzz 問題も本当にこんな感じに「解く」。もしSIerのマネージャがFizzBuzz問題を解いたら - GeekFactory

仕事のことをブログに書くと毎回同じ結びになってしまってる気がするけど、クソみたいな SI 会社でつまんない仕事してる人は思い切って会社変えれば良いと思う。