| @労働

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。

良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。

技術力に加えて、プロジェクトマネジメントのスキル(以下プロマネ力と省略)も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかもしれないが、技術的に秀でた人が必ずプロマネ力が高いわけではない。技術力さえ磨けば良いエンジニアになれると誤解してしまいがちだが、技術力だけ磨いてもみんなから求められる良いエンジニアにはなれないだろう。

ではなぜ技術力に加えてプロマネ力が必要なのだろうか。

一般に、コードを書かずに問題を解決できるならその方がよい。相手に言われるままにコードを書くよりも、コードを書かずに問題を解決できた方が時間も金もかからずみんなハッピーだろう。もしコードを書くとしても最小限の変更に抑えられるのが良いエンジニアなはずだ。技術力が高いだけではこういう発想は出てこないだろうし、真の問題が何なのかを見極め、解決策を考える能力が求められる。

良いエンジニアには先を見通す力も必要だろう。依頼された機能を開発するためにはどんな作業が必要か、どのくらい時間がかかりそうか、誰と調整しないといけないか。

関係者に働きかけ、周りを動かす力も必要だろう。理不尽な依頼が振ってきたときに、その依頼に対して反論し、相手を説得して実現可能なやり方を受け入れてもらわないといけない。

誰かに指示されるのを待たず、自ら動くことが出来る力も必要だろう。仮にプロパーのプロジェクトマネージャーがいたとして、プロマネの指示ばかり待ってコーディングしかしないようでは良いエンジニアとは言えないだろう。

このような、プロジェクトをコントロールし推進する力が良いエンジニアには必要なのではないかと思う。

そんなに何でも出来る人はいないのだから、スクラムをやれば良いのでは、という意見もあるだろう。確かに並エンジニアの集団ではスクラムが有効そうに思える。卓越したエンジニア一人で開発するよりも、数人の並エンジニアによるチームで難しい問題に立ち向かうストーリーの方がおもしろいだろうし個人的には好きだ。

しかしそうやって並エンジニアを寄せ集めても、そこから良いエンジニアは育たないのではないかと感じる。

スクラムチームでエンジニアは、スクラムマスターとスプリント計画、プロダクトオーナーとの「合意」により保護される。自分一人で問題に向き合い、問題を解決する能力がつきにくい。

一方でスクラムを採用していない荒野のような環境では、エンジニアはチームに頼れず、自力で要件を定め、関係者の合意を取り、自らプロジェクトを推進していく必要がある。そのような厳しい環境に身を置くことで、上に挙げたようなプロマネ力が身についていくのではないかと感じる。

これまでの自分のキャリアを振り返るに、以前勤めていた職場はまさに「荒野」といえるような環境だった。誰も何を作るかはっきり分かっていないんじゃないか、いきなり一人で工数見積もりやれといわれても出来るわけないだろう、こんなウォーターフォール開発はやめてアジャイル開発がしたい、こんなクソ会社辞めたい、といつも思っていた。

しかしつらかったのは自分にプロマネ力がなかっただけなのでは、と最近思うようになった。その後入った職場では、つらいこともありはしたものの、スクラム開発のおかげで個人が一人で抱え込んで苦んだりすることなく、チームで協力して開発することが出来た。その中で自分は自分自身の能力を過信したのかもしれない。実際には大してエンジニアとしての力は身についておらず、チーム開発やスクラムをやらない組織で働くことになったときに、自分の能力のなさを思い知らされたのだった。

本題に戻る。自分が良いエンジニアになるためには、技術力も当然足りていないと思うのだけど、プロマネ力を上げていかなければならないと思っている。来年の目標はそのあたりに置きたい。

Shut the fuck up and write some code.

はい。

| @労働

杖立の赤い吊り橋
杖立の赤い吊り橋

転職してリモートワーク始めて 5 ヶ月たった。 Basecamp (旧 37 Signals )の本で読んで夢にまで見てたリモートワークだけど、始めてみると理想と現実は違った。

良かったところは?

リモートワークだと通勤時間がないとかがよくあげられる。しかし自分の場合は福岡に拠点がある東京の会社に雇われていてそこで一人で仕事してるので通勤時間ゼロにはなってない。家で仕事する日もあるけど大体毎日片道40分くらいかけて通勤してる。必要なミーティングさえ外さなければ病院行ったりとか子どもの面倒見たりとかできるのはよい。あと午前中家で仕事して、昼間の空いてる電車に乗って座って仕事しながら出社できるのも良い。ただ仕事に時間の区切りがなかったり家で仕事できるということは、気になる仕事を夜や休みの日に家でやってしまって、フルタイムの社畜に成り下がってしまうリスクを伴うので注意が必要。

さみしいのか?

さみしいとか思うことはほとんどない。所帯持ちなので家に帰ったら嫁さんと子どもいるから全く孤独ということではないし、適度に前職の同僚の人たちと昼飯食いに行ったり酒飲みに行ったりしてる。ただ人と話すのに金かかるようになったの結構痛い。人と会うときは常にどっかに飯食いに行ったり酒飲みに行ったりという感じなので、交際費的な名目で毎月 2 万円くらい飲食にお金使ってる気がする。小遣い実質ゼロ円なので毎月子どもの頃に貯めたお年玉貯金を切り崩してしのいでる。

つらいか?

つらいかと言われればつらい。仕様の確認とか。毎日顔をつきあわせて仕事してたら簡単なことがリモートワークだとかなり難しい。 Slack や zoom などのコミュニケーションツールはあっても、姿が見えないのでいつ話しかければ良いかが分からない。大海原に一人で放り出された感がある。リモートワークできる人は限られてくると思う。

これらの経験を通して、大事だなと思ったことをまとめてみます。

大事なこと(道具編)

道具がリモートワークの質を左右する部分がある。インターネットの回線とかマイクとかカメラの品質を侮ってはいけない。

1. 良いインターネット回線

インターネットの回線悪いと会議してるときに聞こえないことあっても、大人数対一人でやってるとなかなか聞き返しづらい。なので回線はできるだけ太くて安定したやつを使うのが良い。よく分からない Public な共有 WiFi とかはネットを見るのには良くてもミーティングとかには使えない。インターネット回線は独自のものを使い、 WiFi は IEEE 802.11ac が望ましい。 Apple の AirMac Extreme が 50 デバイスまで接続できておすすめです。

2. 良いマイク

Rebuild.fm の初期エピソードと最近のやつを聞き比べて欲しい。 miyagawa さんがマイクにこり始めてからのエピソードの方が圧倒的に聞きやすい。会社でイエティマイクを買ってもらって使ってて、高いからもちろん高性能なのだけど、意外と良いのが iPhone についてくる Apple 純正イヤフォンマイク。高級イヤフォンつけてる人よりも Apple 純正の安いイヤフォンマイク使ってる人の方が声聞き取りやすかったりする。

3. 良いカメラ

カメラ、安いやつ使うと画質ひどい。変なエフェクトかかって真面目な話してるのにふざけてると思われたりして損な感じ。実はこれも MacBook Pro についてる Apple の標準カメラがかなり画質良い。

4. 良いビデオ会議ツール

Zoom というサービスを会社では使っている。複数人通話も無料で使えて Skype よりも便利。画面の共有も簡単。ユーザーアカウント作る必要もない。ほかにエンジニア同士だと appear.in というブラウザだけで完結するサービスを使ったりもする。

良い道具を使うことで避けられる問題は金で解決するのが一番です。

大事なこと(心構え編)

リモートワークをこなす上での心構えと、どんな人に向いていないかについて書きます。

1. 顔つきあわせて話す機会必要

全然人間的な関係が構築できていない状態でいきなりリモートワークやれっていうのは無理がある。人間は対面で話していると表情や身振り手振りなどで相手が冗談を言っているのか怒っているのかわかるものだけど、ビデオ通話越しだとその辺のことがとてもわかりにくい。なのでこの人はこういうとき冗談を言う人だとか、この人はとても怒りやすいとか、そういうパーソナルな情報を対面のコミュニケーションで補完する必要がある。自分は入社して最初の一ヶ月間、東京で仕事してある程度会社の人たちと仲良くなって、そのあとも月一回は東京に行って一週間ほど東京で仕事してる。ようやく最近同僚感出てきた。

2. オフィスにいる人たちの理解

リモートワークをする本人の能力が高ければ当然のことのようにリモートワークできるというわけではない。オフィスにいる人たちの協力がないとリモートワークは成立しない。たとえば職場では、ミーティングにリモートの参加者がいるときにはオフィス内にいるメンバーも全員ビデオ電話越しに話して同じ状況でミーティングに参加し、オフィス内のメンバーだけで議論が進まないように配慮している。リモートで働く人、オフィスで働く人お互いが協力して初めてリモートワークは成立する。

3. コミュニケーション不全を受け入れる

ビデオ電話で会話できるとはいっても、対面で話してたらすんなり頭に入ってくることも、ビデオ電話越しだとなかなか理解出来ない。人間は表情とか身振り手振りでのコミュニケーションが割合に多いということがよく分かる。思ったこと、考えていることを 100% 伝えられないかもしれない、という前提のもとで仕事する必要ある。なので確認はしつこいほど行った方がよい。

まえリモートワークつらい、みたいなことを Twitter に書いてたら、フリーランスで受託開発してる人だったら、顧客企業の担当と十分にコミュニケーションできないとか当たり前だし、リモートワークなんて余裕だと思う、という反応があった。確かにそうかもしれない。人から指示が来るのを待っているだけだと全然仕事が進まない。分からないことがあったらこちらからがんがん聞きにいって、自ら積極的に行動しなければならない。言われたことだけをやるという感じだと普通の会社でも使えない人みたいな烙印押されるけど、リモートワークだとその傾向が顕著になる。自分はこれまでの人生完全な指示待ち人間だったので普通の人以上にリモートワークをつらく感じるのだと思う。

このように圧倒的な当事者意識や頻繁な声かけなど、人間力の高さがリモートワークには求められると感じる。一人で誰とも話さずに仕事するのに逆説的な感じするけど、人とコミュニケーションとるのがいやな人にはリモートワーク向いてないと思う。

ここまで書いたところであらためて Basecamp の『強いチームはオフィスを捨てる』を読み直してみたら、自分が書いてきたことと同じことが書いてあった。リモートワーク、最近はニュースでも取り上げられたりしてサイコーみたいな扱いが多いけど、やっぱりつらい部分もあって、彼らもそのことについて触れていた。詳しくは「リモート時代のマネジメント」の章を読んでください。

まとめると、リモートワーク、本人の適性のほかに、会社自体がリモートワークを受け入れる準備ができていることが重要だと思う。また人とのコミュニケーションが好きではない人には向いていないと思う。むしろコミュニケーション能力高い人じゃないとつとまらない。

休みの日にゼータガンダム見てて、ニュータイプだったらリモートワークをうまくこなせるだろうなって思ってしまった。物理的に離れていても感覚で相手のことが分かるあの感じ。「この感覚、アムロ・レイか」。逆にいうとリモートワークをこなしていくことでニュータイプ特性を開花できるかもしれない。結論としてはリモートワークしたい人はゼータガンダム見てください。君は刻の涙を見る。


この記事はリモートワーク Advent Calendar 2015 の 23 日目の記事だけど二日遅れで書いています。遅れてすみませんでした。

| @労働

会社を辞めた。3年半在籍してた。

ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。

ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせてもらったり、ばあちゃんの具合が悪いときには会社休ませてもらったり早めに帰ったりしてたし、ばあちゃん死んだときにはお花とかも出してもらった。労働環境の他にも年末の社員旅行とかプレゼン大会とか社内の催し物があったりして良い雰囲気だった。課長が女性エンジニアにセキュリティルームでセクハラしてたり社長が気に食わない奴はいきなりクビにしたりしてたブラック企業から移ってきた身にはほとんど天国だった。

なにより自分にとってよかったのが、インターネットが会社になったみたいなところだった。会社に @shikakun がいて、あとから @antipop さん( Mr. CTO!)とか @udzura さんとか面白インターネットコンテンツな人も入ってきて、自分が @morygonzalez として存在することが是認される感じがとてもうれしかった。

とはいえペパボでもそれなりに厳しいことはあって、そういうのは一昨年の闇アドベントカレンダーに書いたのでこれも読みたい人は読んどいてください。

社内ではおおよそ一年おきに異動していて FANIC => MuuMuuDomain => minne と渡り歩いた。そう、僕はいま CM やったりしてる minne の中の人だったのです。

3年半の間に PHP を書くこともあったけど、自分の指向性とかを汲み取ってもらい、概ね Ruby を書かせてもらった。ウィンドウズを使えと強要されることはなかったし、 Ruby は書きたい放題だし、毎日会社行くのが楽しかった。

最後にいた minne は本当に良いチームで、みんなでリーンキャンバス描いたりエレベーターピッチを考えたりして、どうやったらサービスが圧倒的に成長できるのかを真剣に考えてた。

エンジニアはみんなできる人たちで、特に初期から minne を支えていた @mizoR さんが凄く、ちゃんとコンピューターサイエンスのバックグラウンドがあるため文系の自分にはない視点で問題にアプローチしていて非常に勉強になったし、また歩く UNIX の哲学みたいな存在で、小さく作ってこまめにリリースし検証することの大切さを教えてもらった。(@mizoR さん作の rake_notification は神 gem なのでオススメです)

新卒入社の @keokent もできる奴で、モバイル端末へのプッシュ通知をサクッと作るしサービス愛も厚いし、風紀の乱れにもうるさくて、Tシャツの裾は常にズボンにインするように指摘されてた。

去年の4月に入社してきた @amacou さんも凄くて、 Ruby/Rails も Objective-C も両方書けて、出張申請とか経費精算さえできればフルスタックおじさんという感じだった。

ムームードメイン時代に仲良くなりプラチナサーチャーで女性ファン急増中の @モノクロメガネ(いけすかないのでリンクはありません) さんに助っ人で来てもらうこともあって、絶対間に合わないだろみたいな無理めなスケジュールでタスクが降ってきたときにもみんなでホワイトボード囲んでワイワイ開発して余裕で終わらせたりして最高だった。モノクロさんは隙あらば Go で Ruby のコードを置き換えようとするところ以外はエンタープライズ力も高いしスクラムマスター業もこなすナイスガイだった。本当にいけすかない。

何をやらせてもスピーディーにこなす若手ネット芸人 @hisaichi5518 さんとも物理的に距離がある状態で仕事したけど、とにかく作り上げるという力はさすがだと思った。チーフエンジニアの @hsbt さんのオラオラと詰めてくる感じの Pull Request もサイコーだった。チームのエンジニアの間では「 @hsbt さんが通ったあとには草の根一本生えない」とよく言ったものだけど、こういう人がいないとフレームワークや言語のバージョンアップとかインフラ構成の大胆な変革はできないことがよくわかった。そういえば @udzura さんという人とも働いたけど、ギャグが寒いこと以外は問題ないです。

デザイナーやディレクター、サポートメンバーも良い人ばかりで、昨日は送別会を開いてもらったんだけど、こんなに良いチームを去るのは残念で仕方なかった。写真はトデガールズに対抗して森井ガールズが結集している様子です。

森井ガールズ

福岡でウェブサービスの開発やってみたいけどどこで働けばよいかわからないインターネットをこじらせたウェブプログラマーの人はペパボの門をたたいてみるとよいと思います。

で、誰?

無名のウェブプログラマーです、このような記事を書いてお目汚しをし誠に申し訳ございません。

なんで辞めんの?

「次に行く理由」があるだけで、「辞める理由」はないのです。

株式会社ドワンゴに転職します(4年3か月ぶり2度目) - Kwappa談話室

僕も同じ気持ちです。

次なにやんの?

Kaizen Platform という会社で働きます。無事試用期間を乗り切れるのでしょうか。ご期待下さい。

| @労働

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

結論

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

上にぎり 1.5 人前


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

| @労働

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

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

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