| @技術/プログラミング

YAPC に行ってきた。ちなみに去年は嫁さんに↓のように言われて行けなかった。

今年は YAPC 最後なのでどうしても行こうと思って無理矢理チケット申し込んで飛行機と宿とって行った。帰ってきて嫁さんに感想を聞かれて、詳細を話しても意味わからないだろうから「がんばろうという気持ちにさせられた」と話したら、「えー、それだけ? 何も学んできてないわけ?」と言われた。


一日目

一日目の方は業務の一環として参加させてもらった(チケット代とか飛行機代とかは自腹)。 受付で YAPC Tシャツもらえると思って着替えを持ってきてなかったんだけど申込時にサイズ選んでないのでTシャツもらう意思がないと見なされTシャツもらえなかった。明日着る服がないと思って焦ったけどリュックの中に予備のTシャツ(実家に帰ったときに洗濯したやつ)があって助かった。

Effective ES6

ES6 、全般的に天国ぽかった。 Babel というの使えばもういまから ES6 で書けるっぽい。ただ Kaizen のサービスは JavaScript でやらかすと皆様に多大なご迷惑をおかけすることになるのでリストカット感覚で導入すると危なそうだった。まずは自分のブログとかで実験してみたい。

偶然居合わせた kitak (ペパボ時代の元同僚)と Kaizen Platform で同僚の t32k さんと、二人の金沢時代の友人の方たちと無料弁当を食べた。 YAPC 、飲み物とか弁当とかまで出てすごい。電車賃とチケット代さえあれば参加できる。

TBD

最近なんで並行処理に優れた言語とか流行ってるのかという背景を交えながら、なぜ Streem を作ったのかという説明や Ruby の未来の話しが面白かった。あと質疑応答の返しが面白い。 Matz さんは言語開発者として優れていると同時に優れた話し手でもあるなと思った。

たまたま mizzy さんと隣に座って聞いてたんだけど、 mizchi さんいて(mizchi さんが mizzy さんに話しかけた)こんちゃと挨拶した。 YAPC 有名人ごろごろいるのすごい。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜

爆笑トークだったけど、オブジェクト指向や DDD がなぜ大切なのか、というのを業務での経験を交えながら発表されていてよかった。「オブジェクト指向設計入門とか DDD 本とか難しいけどどうやって業務に活かすのか」という質問に対しては、「歯を食いしばって実装するしかない」と返していてよかった。

ロビーでだらだら

見たかった発表満席で入れなかったのでロビーうろついてたら hsbt さんいたので声かけた。そしたらどこからともなくペパボ、元ペパボの人どんどん集まってきて hsbt さんの自撮り棒の被写体になったりしてた。出戻り歓迎しますと言われてニヤニヤしたりしてた。ペパボ版 mizchi さんの gyugyu さんを生で見られたの良かった。

SaaSを組み合わせて作る, ぼくらの障害対応術!

障害発生時に自動的に Qiita:Team に対応報告ドキュメントが作成され、 Reactio というサービス内にチャットルームも自動生成され、チームメンバー全員に電話もかかってきて障害対応に SaaS を組み込んで効率的に仕事をこなす、という LT だった。 LT 中、アラートメールが来るという演出も面白かった(たぶん仕込みだと思う)。

Kaizen Platform への就職を決めたの、要因はいろいろあるんだけど、入社前に CEO の須藤さんが Qiita:Team に書いている Kaizen のモットーみたいなやつを読ませてもらって、それに感銘を受けた、というのがある。自分たちが本当にフォーカスすべきことに注力して、その他のことは外部サービスを利用して徹底的に効率化したい、というようなことだった。実際、 Kaizen は外部の SaaS を利用できる部分は極力利用して自前で実装しないようにしている。それでお金はかかるけど、エンジニアが無駄に秘蔵の社内ツールのメンテナンスで疲弊することがないようになってるし、スタートアップ同士でお互いのサービス使い合って良い循環が生まれている感じする。

ソロ懇親会

一日目は懇親会あって参加してみたかったけど気がついたら募集終了してて参加できなかった。なのでよく知りもしない東京ビッグサイトのプロントの店員に「お疲れ様です」と声をかけられながらビール飲んでスパゲティー食べてソロ懇親会やった。バスでホテルに帰ろうとしたらペパボの元同僚の人いて最近どうですかとか軽く話した。ホテルに着いてからは浜松町の激安寿司屋に潜入したけどシャリがねちゃっとしてて不気味な感じだった。量も多くて腹一杯になってしまってとにかくつらかった。

二日目

だいぶ早めに着いたので余裕をもって座れた。ただ午後のコマは混みすぎてて発表見られないことが何度かあった。次の発表の時間前に部屋の前に列を作ったりするの予備校に通ってた浪人生時代を思い出した。人気講師の講義に群がる代ゼミ生に戻った気分になった。

Adventures in Refactoring

GitHub の人の話、 RubyKaigi の動画とか福岡でのミートアップとかでも聞いたことあったんだけどいまいち何言ってるかわからなんぁという話しする人多かった。今回の人の話はわかりやすかった。リファクタリングしてコード量が増えるのようなのはダメだとか、パフォーマンス劣化させたらダメだとか。あと GitHub では scientist という gem あってこれでリファクタリングの前後のコードの A/B テストみたいなのをやってるそうだった。エラー発生率とかパフォーマンスを計測しているそう。すごい。

昼セッションの弁当売り切れててもらえなかったので下に降りてコンビニで何か買おうかと思ったけどコンビニが異常に混雑してて地方在住者にはあれに並ぶ気になれなくて、一旦はフードコートとか行こうとしたけど結局どこも激混みで、あきらめてセブンイレブンでサンドイッチとか買ってプロントで買ったビール飲みながらオープン席的な場所で食べた。偶然、隣にモテメンガールズを引き連れたモテメンさんがやってきてモテメンステッカーくれた。家の冷蔵庫に貼ろうと思います。

【特別企画】YAPCあるある(仮)

YAPC の 10 年間を振り返るという座談会企画だった。僕はミーハーなのでこういう話しを聞くのは好きなので面白かった。そもそも始まりは宮川さんが台湾で行われた Perl のカンファレンスで来年は日本でやってくれよと声かけられてスライドの最後に急遽やりますというのを盛り込んで宣言したのが始まりのようだった。最初の会場が大田区産業会館というの地味な感じがあってよい。2007年だか2008年だかの YAPC で利用したフランスの決済システムがちゃんと動かなくて宮川さんがフランスまで行って直した、という話すごかった。伝説っぽい。

あとは牧さんがどれだけこれまで YAPC で苦労したか、という話だった。こういうの若い人聞いてもあまりぴんとこないかもしれないけど、所帯を持ってたりするとなかなか家庭外の活動に時間を割くのは大変だし、結婚式挙げたことある人はわかると思うけど、人を何百人と集めてなにがしかの催し物をやるのはとんでもなく骨の折れる大変な作業で、それをボランティアで行うのは本当に大変だと思う。若い人はもっと牧さんに感謝した方がよい。

Evaluating your stylesheets

同僚の t32k さんが LT 通ってて発表した。伊藤直也さんのこといじって受けてた。作ったスタイル何とかという CSS を解析するソフトウェア自体も良さそうだった。

コミュ力あげてこ

一日目は hitode909 さんの発表の裏で話を聞けなかった cho45 さんの LT 面白かった。前の人がたまたま電話の話してて、その後に登場した cho45 さんがモールス信号の話というのが最高だった。 cho45 さん、ツイッター見てる限り気むずかしい人なのかなと思ってけどおもしろお兄さんという感じで良かった。

クロージング

ヒトデさんがベストトーク賞とってた。なぜか自分のことのようにうれしかった。

牧さんのこれまでの苦労話とかを最後にもう一回聞いたけど本当に大変だったと思う。2000人以上来場するイベントを取り仕切るのは筆舌に尽くしがたいほど大変なはず。牧さん、 udzura uzulla さん、運営の皆様本当にお疲れ様でした。

| @ブログ

セルフホストの個人のウェブログでも Twitter カード出てるサイトあることに気がついて個人でもできるぽかったのでやってみた。メジャーサイト感出る。

Twitter Card

Lokka 用のプラグイン作っといた。

| @技術/プログラミング

会社のアドベントカレンダーが空いてたので書きました。前日は @kenchan さんでした。


大学生の頃に書いてたウェブ日記を Day One.app に取り込んだ。このウェブ日記は Caldiary というソフトウェアを使っていて、KENT Web で配布されてた CGI をベースにデザインが良くなるように改良されてるやつだった。RSS とかはなく、まだブログがはやる前に作られたものだった。昔ながらの Perl の CGI でデータベースは使っておらず、日記自体はテキストファイルに保存されていた。なので簡単にデータをぶっこ抜けた。テキストエンコーディングが Shift_JIS なのに気をつけつつ UTF-8 に変換して Day One の中にぶっ込んでいった。 Day One が公式で用意してる CLI を Ruby から使いやすくする rb-dayone という gem を使ってやった。

10年前の日記を読み返すといろいろおもしろい。アルバイト先のいやなやつの悪口とかもあるんだけど、人から聞いたおもしろい話を備忘録代わりに書いてて記憶がよみがえったりする。読んでいる本の感想とかもある。黒歴史感あってよい。

Caldiary がすばらしいのはカレンダー形式のサイドメニューがあったことだ(おそらくカレンダー付きの日記だから Caldiry なのだろう)。カレンダー式だと一日もサボれない気がしてほぼ毎日日記を書いてた。 Evernote などパソコン上に日記を書けるソフトはいまいっぱいあるけど、カレンダーが出るのは(自分の狭い観測範囲では) Day One しかない。また Day One は見た目が美しく、過去に書いた文書を読むのに適したインターフェースだと思う。もっと活用していきたい。

むかし日記書いてた人は Day One に取り込んでみるとおもしろいのでオススメです。


この記事はPepabo Advent Calendar 2014 - Qiitaの3日目の記事でした。

明日は未定です。

| @技術/プログラミング

Lokka 、フォームの DOM が bot で解析しやすいのか大量にスパムコメントが登録される。スパムを一括削除する機能は自分で作って Lokka にパッチ送って取り込まれたけど、 Lokka の ORM の DataMapper は一括削除するときに馬鹿っぽい SQL 投げて一括削除は処理が重いし、そもそもスパムコメントを定期的に消すという行為自体が面倒くさい。

むかし P_BLOG でブログ書いてた頃もある頃からスパムコメントが大量に来るようになったので reCAPTHA を導入してみたらとんとスパム来なくなった。

また reCAPTCHA 使おうとして久しぶりに調べてみたら Google のプロジェクトになってた。

設置してから二日くらい経つけどとりあえずスパムコメントは来なくなった。便利。念のためプラグイン化しておいた。

| @Mac/iPhone

面白かったので便乗して書きます。

iPod 、大学3年の頃に友達が買って見せびらかしてまわってたのが最初の出会いだった。当時は自分は Windows 使ってて Apple 周辺の事情に疎く、特に iPod を欲しいとも思わなかった。

初めて iPod を買ったのは就職活動に失敗して留年していた頃だ。家の近所をぶらついていて、確か発売されたばかりで結構品薄だったのを偶然発見し、就職活動が終わって始めた居酒屋のバイトでもらった初めての給料で買った。第四世代 iPod のモノクロのやつで、ディスクの容量は 20GB だった。

iPod を買った年の冬に精巣腫瘍になって翌年の正月に病院に行ってがんだと分かり入院・手術した。病院はおそろしく退屈で病人生活を始めた最初の頃はパソコンとか持ち込んだりしてなくて、 iPod で音楽を聴くか新聞を読むくらいしか楽しみがなかった。抗がん剤の治療をするようになってからは、点滴されながらじっと iPod で音楽聞いてた。音楽聞いて抗がん剤の吐き気とかを紛らわせようとしてた。

第四世代 iPod は Apple タイマーが正常に機能して、購入からぴったり一年後に壊れてしまった。 HDD が死んだぽかったので開腹してハードディスク入れ替えたら良さそうだったけど当時はハードディスクもそこそこ高く、海外に旅行に行く直前に(飛行機に10時間以上乗るのに無音はつらかったので)第五世代の iPod を買った。こちらは 30GB のディスク容量で、カラー液晶になっていて写真を閲覧したりもできた。

第五世代 iPod は京都で半年入院してるときに重宝した。この頃は抗がん剤の副作用で耳鳴り・高音難聴に苦しんでいたのでよく音楽を聞いた。あと当時付き合っていた女性にふられたのでコールドプレイの "Warning Sign" をエンドレスリピートしながら京都の寺社仏閣を一人でふらふらと歩いて回ったりした。退院して北海道まで青春18きっぷで行ったときもひたすら第五世代 iPod で音楽を聞いていた。

第五世代 iPod は液晶から壊れはじめた。縦方向に筋が入るようになり、最終的には筋が広がって筋の隙間からのぞき見るようにして画面を見る必要があった。iPhone 3G を買ってからは歩くときは iPhone で音楽聞くようになったので、 iPod はもっぱら車の中で音楽聞くとき専用端末になった。最後はオートバックスの駐車場でドアポケットの掃除かなんかしてるときになくしてしまったっぽくて行方不明になった。

実は最初にインターネットに接続したパソコンは弟が音楽製作用に買っていた初代 iMac のタンジェリンのやつで、パソコンの原体験は Apple にあった。大学ではレポート提出とかの都合上 Windows を使っていたけど、数年ぶりに Apple 製品に触れて再び Apple 熱が高まり、 AirMac Express を買って Air Tunes で音楽聞くようになった。

iPod が画期的だったのは、 iTunes のライブラリと iPod を同期して使うところだった。それまでの MD や既存の mp3 プレーヤーは、プレーヤーに入れたい曲を選択してプレーヤーに移す、という作業が必要だった。昔の iPod の CM に、家の Mac で聞いていた音楽の続きを出かけるときに iPod で聞く、というやつがあったけど、そういう発想は他のプレーヤーにはなかったと思う。最初は馴染めなかったけど、曲のレートや再生回数が iPod と iTunes で同期される便利さに慣れると、 iPod 大勝利だなと思うようになった。2ちゃんねるで SONY のプレーヤーの悪口を吹聴して回るほどだった。

しばらく Apple 製品使ってないうちに OS X が出ていることを知り、 OS X の GUI の美しさにびっくりした。当時の Windows XP のフォントはアンチエイリアスがきいておらずシャギーだった。 OS X といい、 iPod - iTunes といい、 Mac/Apple の方が Windows/Microsft よりもだいぶ進んでいるなと感じた。 Windows に無理矢理 Osaka フォント入れたりして Mac 化したりしてた。次パソコン買うなら絶対 Mac だなと思うようになっていた。

大学卒業して入院しているときには病院があまりにも暇でノートパソコンが欲しくなったので、 DELL の安いノートとかにしたらと母親に言われたものの、どうしても Mac がいいとだだをこねて PowerBook G4 の 17 インチのやつを買ってもらった。これを使って病院でブログ書いたりしてた。ブログいじりが楽しくて PHP とか少し触るようになり( Mac は簡単にウェブサーバーを立てることができるので病院とかでも PHP のコードいじったりするのに向いてた)、結果的に Web の仕事がしたいと思うようになって今日に至っているような気がするので、 iPod 買ってなかったら Mac を欲しいとも思わなくてプログラミングをやり始めることもなく、何の能力を身につけることもないまま今も親のすねをかじってニートをしていたかもしれない。

| @技術/プログラミング

このブログを Capistrano 3 でデプロイするようにした。こちらを参考にした。

一点、 deploy:restart 内で、 invoke メソッドで他の namespace の task を呼び出すところ

The deploy has failed with an error: #<NoMethodError: undefined method `verbosity' for "/usr/bin/env unicorn:restart\n":String>

というエラーが出てた。調べたらどうも sshkit のバグっぽかった。

最新版では Pull Request マージされてて治ってるぽかったので Gemfile で

gem 'sshkit', github: 'capistrano/sshkit'

と書いておいた。

Capistrano 3、他の gem いれなくても色付いたりマルチステージになってたり rbenv 対応しててモダンになってると思った。あとシンボリックリンク作ってくれる task が便利。

| @労働

この記事は 闇アドベントカレンダー、 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 さんです。