読者です 読者をやめる 読者になる 読者になる

BASEに入社した

近況

ユビレジ での勤めを終えて、ネットショップ作成サービスの BASE(ベイス) で働きはじめた。

決済サービスのPAY.JP のプロジェクトにエンジニアとして参加している。

(何かを予期した二年前の投稿)

入社の経緯

時系列順にいうと

昨年末ぐらいに退職の打診をして今後どうしようかなーと正月だらだらしていた時に以下のニュースを読む。

jp.techcrunch.com

なんとなーくショッピングやフリマアプリもしくは金融サービス(フィンテッ・・)の方面の開発現場が楽しいんじゃないかと考えていて、 そういえばBASEが決済サービスをやっている会社だということを思い出して、どっちもやってる好都合な会社あるじゃんと膝ポンして*1「次のプロジェクト」の候補に入れた。

「転職ドラフト」というサイトに登録して好き勝手ウォッチしていたらCTOから声をかけられたので見学に行く

job-draft.jp

「面談に出てくる人たちが全員デカい」程度の好印象を得て帰宅する。

上記の募集だとどうやらBASEショッピングアプリのモバイル開発人材を探していたようなんだけど、面談でPAY.JPのことをしきりに聞いてたこともあってか後日「PAY.JPのチームにも会ってくれ」と連絡が来た。

PAY.JPはもともと外部の会社と合流してBASEの元にあるので、なんか組織形態的にも分かれているとのことだった(これは入社してから正確に理解した)

www.fashionsnap.com

業界や会社に勢いがあってええやんけと思っていたところいつの間にか内定が出ていたので働くことにした。

決済サービスやってる会社なんていくらでもあるじゃん? と思うかもしれないけどサービスの信用上詳細を書けないが、関っているプレイヤーや状況などを加味してユーザーに提供できそうな価値が、思想的にもビジネス的にも技術的にもイケそうな手応えがあった。(イケそうというのは「世界をより良くする世界をより良くする」のマントラを唱えながら労働するという意味です)

社内の印象

サービス立ち上げの時代から活躍している二十代若手社員中心の開発組織に、経験者の採用を強化してチームの成長を促すような人事面のサポート体制があるように感じる。どんどん新しいメンバーが増えていて、みんなでサービスを拡大していくぞ! というような空気がある。

事実とんでもない勢いでユーザー規模は増加していて、技術的な面でも組織的な面でも課題てんこ盛りで圧倒的人手不足なので優秀なエンジニアさんデザイナーさん今すぐジョインしてくれ!*2 という心境だろう。

www.wantedly.com (起死回生の求人の一手の様子)

BASEとPAY.JPはセキュリティ要件により物理的にオフィスが分断されていてあまり会社全体を見る機会がないんだけど、みんなSNSやチャット大好きインターネットピーポーなのでログで残ってる。

BASEチームはおたくサークルのような健全さがあり、みんな仲がいい。「Stay Geek」という社是がぴったり。すろっくさんという名物エンジニア(SRE)がおり、彼のタイムラインを見ていれば会社の雰囲気はだいたいわかる。

PAY.JPチームはコンピュータークラブのような御淑やかな雰囲気で落ち着いてる、あとなぜか冷房が寒い。Pythonコミュニティで活躍している人が何人も働いている贅沢な環境で、コードが超参考になる。

プロダクトに関しては来月の以下のイベントでバーンとやっていきますみたいな発表があるようだ(NO関与)

base.connpass.com

あと、みんな10時に出社してくる(すごい)

ユビレジをふりかえる

ブログで求職していたら突然連絡が来てかなり舞い上ったのを覚えている。その当時何十社か就職先をひたすら検討していたんだけどユビレジに参加できるとは全然思っていなかったので、候補を全部押しのけて入社を決めた。

なにせその頃は採用活動してる雰囲気はなくて、選ばれたOSS界隈のトップレベルの人達だけが加われる雲の上の存在のような憧れの会社だった。

業界の人材流動性的にこの面子で一緒のオフィスで同じソースコード触れるチャンスは今を逃すと一生ないなと思ったのでもう即決だった。

f:id:laiso:20160822234500p:plain 当時の筆者の心境 (アオイホノオ 小学館より)

Scala

入ってから一番ビビッたのは既にScala界のすごい人が全員ドワンゴに移ったのを知ったことだった笑*3。今でも他の会社の人に「ユビレジってScalaの会社ですよね」と言われるので相当Scalaな人たちが残した功績は大きかったのであろう。

ユビレジはすっかり今ではRailsの会社なんだけど(Railsコミッターがコード書いてた)、過去にScalaに移行しようとした形跡がGitHubリポジトリにあった。

Play2である時期まで活発にコミットされていたコード、これがひときわ禍々しさを放っていので後日退社前にリポジトリの管理を僕がしていた時に「バイバイ、スカラ」といって消した。

CTO

その次ぐらいに驚いたのが当時CTOの*4 soutaroさん の職業人としての能力の高さだ。これは外からは全然わからなかった。

朝から晩までフロントエンド-DB-ハードウェア-モバイルの全部のレイヤーのコード書いていて運用やユーザーサポートに借り出され帰ってきたらSketchでデザイン制作しプロダクトマネージャの全行程を勤め経営会議に参加しチームのマネジメントもするという寿命と頭脳を消費する滅茶苦茶な仕事をこなしていた。

彼のおかげでスタートアップのCTO像のハードルが一気に上がってたまったものではない。明かに業務が集中し過ぎているので入社してしばらくして社内の状況を把握した後は、soutaroさんの雑用が減るように動くことが組織にとって望ましいと思ったので意識して実行した。

iOS

ユビレジでは「iOSのことを最も知らないiOSエンジニア」という不思議な立ち位置で仕事をした。

入社する前は最前線のiOS開発現場なのでバリバリiOSのプログラミング能力を上げるぞ! と思っていたんだけど、いざチームに入ってみると自分よりiOS超得意な人にiOS方面は任せればよくて、現在チームに足りていない部分を補強するのが自分に向いているというのを感じたからだった。

なのでiOSの一線の開発情報とかはパタリとチェックしなくなっていたし、趣味でコードも書かなくなっていた。

具体的にはクライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要な領域を任せてもらえるのが僕の強みだというのがわかった。器用貧乏さという裏の弱点があるわけだけど、しょうにあっているしこれは今後も役に立つだろうとは思う。

フロントエンド

iOSのコードを趣味で書かなくなったかわりにフロントエンドやJavaScriptの最新情報をチェックしていた。

ユビレジはRailsデフォルトに乗っ取ってCoffeeScript+Backboneでフロントエンドを構成していたんだけど、シングルページアプリケーション化に舵をきってからとうもの規模が大きくなってきて自前で Marionette.js のような仕組みができつつあり、精鋭のRailsエンジニアが片手間で書いてたJSに苦労させられる場面が課題だった。

当時 6to5 プロジェクトこそ未来だというのは azu_re というBOTみたいな大量の情報を吐くアカウントを追っかけていれば当然のことだったので、RailsアプリからフロントエンドのGUI開発を解放するためにユビレジもその流れにのってもらうことにした。

Reactを実験的に試しつつSprocketsに巻き込まれ重傷を負いつつも少ししたらいきなり事態が好転して、JavaScriptをメインで書くことを期待された強力な新入社員たちが加わったのだ。かなり救われたと思って彼等と相談し当時鳴り物入りで登場したReduxをメインにフロントエンドを再構成する活動がはじまった。

そして強力なメンバーが入ったことにより僕は「JavaScript超できる人いるからわざわざやらなくていいか」(怠惰かよ) という思考に陥りはじめる……

プロダクトマネージャー

日々のタスクとしてはiOS開発が一番人手が薄く求められていたのでしかたなくオブシー*5を書いてだらだら仕事していたんだけど、その頃から ninjinkun's diary なんかに影響され「UXとは」と独り言をいいながらその手の本や知見を得て、色んなビジネスアプリを触りながら自社製品の改善点を黙々と報告していた。

ユビレジには伝統的にというか前述のCTOが全部やってる問題があったので開発ディレクター・プロダクトマネージャーの職位がなかった。しばらくしたら歩夢さんというキラキラネームの人がやってきてプロダクトマネージャーを兼任していた。彼もフルスペックな人でビビったのだけど、なにせ会社ごと一緒になったので製品とかシステムも増えてやることはたくさんある状況だった。

なので「各自必要を感じたらなんか関係者をつかまえていい感じにやれ」ぐらいのゆるい感覚で進行管理をしており「開発者を一気に増やしてコード書いてみたけど謎の要因で1年間リリースが凍結されている。謎の要因がはたして何なのか、それは関係者をつかまえていい感じにやれ」というようなプロジェクトがザラにあった。

これが結構「クライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要」というのにフィットしていたので助けることができると踏んだ。 やってみると爽快でコードを書かずに製品を良くできるんだ! という感動があった。今までは要求された仕様に対していかに良いコードを書くかテストを自動化するかというような価値観でプログラミングしていたので、世界が広がった。

ユビレジは「無断ユーザー訪問し放題」という性質があるのでこの頃はジャンジャン使っているお店に行ってみた。

チーム・労働環境

女性比が高く男子校っぽいノリがなくて快適だった。メンバーも謙虚で助け合いの精神を持った善良な人たちばかりだった(小池陸以外)。

みんな遅くまで残ることもないし、子育て世代もいっぱいて働きやすいと思う。

「開発合宿やるぞ!!!!」と盛り上っていた時も僕行かないッスと言ったら免除してもらえて快適だと思った。

出社時刻は完全に裁量労働に忠実な無法地帯で、午前に出社する定時組と昼過ぎにバラバラと来る人達「24時までは午後なので出社と言えそう」「出社失敗」などの概念があった。僕はだいたい午前中のんびり過しランチして出社20時ぐらいまでには帰ろーという生活をしていた。休日出勤はゼロで、在宅勤務もし放題だった。

入社した頃はなぜか朝会が17時にあり、夕方以降にものごとが動きはじめたりしていて完全にユーザーとのタイムゾーンのズレがあったので譲歩して15時にした。

退職

退職の話をマネージャや社長にしたらえっ、辞める要素ないのになんで!? と驚かれたので逆に僕はえっ理由用意しとかなきゃいけなかったかとビックリした。これに限らず僕のキャリア感というのはちょっと他人とズレていることを認識した。僕はユビレジもBASEも同じようなコミュニティの人たちで似たような会社だから異動みたいなもんかなと考えていたのだけど、世間ではそうでないようだ。

なぞの思考回路によるめんどうくさい持論みたいな理由はいくらでも出せるんだけど、めんどうくさいので「金と名誉のために転職した」というストーリーでお願いすることにした。実際給与は上っているし(逆にユビレジ入社時に給与交渉レベルのささいなことに関心がなかった)。

スタートアップと待遇

スタートアップ(ここでは出資を受けて拡大を目指す企業ぐらいの意味)で働くと薄給で長時間働くことになるんだろうなという古い意識を未だに持っている人を時々見かけるんだけど、それは良い環境の大企業と劣悪な大企業を見つける程度の差でしかないですよというのを言いたい。

大企業にしかないリソースの壁というのは確かにあると思うけど、大企業のリソースでしか到達できない領域に辿りつける人なんて全世界ランク10%以内の人達とかですので我々には関係ない。

BASEなんて「学生発」「インターネット」「シェアハウス」「家入」*6この時点でいかにもまともな給与出なそう会社に見えるけど、普通にユビレジと同じく良い待遇を受けられる企業なのでどんどん応募するとよいと思います。

www.wantedly.com

www.wantedly.com

ユビレジはまだエンジニア/デザイナー募集出てないけど単にWantedlyに投稿忘れてるだけなのでメールするか関係者にコンタクトを取るかすればいいと思います(しかしハードル高過ぎでしょう)

*1:正確には二子玉川方面にも1個ある

*2:大袈裟に書いています

*3:大袈裟に書いています

*4:俺と一緒に退任したのもビビった……

*5:https://twitter.com/laiso/status/758884371453530113

*6:オチにしてすみません。新刊を買いましょう → さよならインターネット

atteアプリ開発の話をイベントで聞いてきた

これ:アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog

Golang と Google App Engine

https://speakerdeck.com/ttsuruoka/atutekai-fa-falseji-shu-golang-to-google-app-engine

Datastore APIの話とかPython SDKが出た頃によく触っていたので懐かしかった。

App Engineは2013年ぐらいにやっとAPNSのPUSH通知ができるようになったのだけど、(http://blog.lai.so/entry/20130415/1366024996

最近他の会社でもGAE/Goの組み合わせて使っているプロジェクトを見かけるし。特にGCPリリース以降、バックエンドにAWSじゃなくてHerokuでもなくてGAEというのが選択肢になってきているんだなーと感じた。

そういえば2012年に調べたことがあるんだけど、インフラはAWS一色だなーというのhttp://blog.lai.so/entry/2012/02/16/003509 を思い出した。

また言語選定の話で、特にGo言語書き慣れている人たちを集めてきたわけではないというのが興味深かった。Scalaなども選択肢にあったのだろうけど、Goのスクリプト言語系の書き手への相性の良さとGAEの存在が決め手かなと感じた。

(PHPの優位性は協業するウェブデザイナーに一番リーチしているところだと思います)

また重厚なウェブフレームワークは使わずに標準的な小さいライブラリで構成していくのがGoのやり方だろうと解釈もなるほどと思った。

Goは以前話題になった時はCの替わりのシステム開発言語ぐらいに思っていたけど、これでウェブアプリ開発するのに俄然興味を持って帰りに入門書を買ってしまった。

スターティングGo言語 (CodeZine BOOKS)

スターティングGo言語 (CodeZine BOOKS)

Go言語によるWebアプリケーション開発

Go言語によるWebアプリケーション開発

Swift と RxSwift

https://speakerdeck.com/bricklife/atutekai-fa-falseji-shu-swift-to-rxswift

CocoaPodsが嫌いでCarthageが使えるiOS 8以上をターゲットに設定したというネタが枕にあって、パッチ2、3送っているぐらいのファンとしては気になったがビルドエラーのトラブルとかが嫌われてしまう原因かな。それはわかります。

RxSwift、というかリアクティブプログラミング(Rx)系のライブラリを採用した理由として「メルカリアプリでずっとReactiveCocoaを使っているのでなしでは組めなかった」というのが面白かった。

僕はWindows系のアプリケーション開発(Silverlightぐらいの時期)やHaskell for GTK+なプログラミング環境でリアクティブエクステンションとかFRPとかの概念を知り以前から興味を持っていて、 自社のアプリでReactiveCocoa本格的に使いたいなーと思ってもう2年できずにいるので羨ましかった。早い段階でReactiveCocoa導入していた人たちはあとはKobito(OS X), freee(iOS)なども居たと思う。

RxはUI非依存なストリーミング操作だけ保守的に使うというtipsもあるけど、UIコンポーネント拡張を取り入れた方が段違いに恩恵があっていいと思っている。

Reactと同じくプラットフォーム横断で思想が共通しているのがRxの良いところなので、AndroidのUIもRxJavaで組んでいるのでしょうか。ウェブアプリは?RxJS?

質疑応答で発言して「ネコ風のあいつ」が描かれたトートバッグをもらいました

「川」という隠語はよく把握していませんが内輪用方っぽい

アッテiOSの設計と開発フローの変遷

https://speakerdeck.com/ishkawa/atuteiosfalseshe-ji-tokai-fa-hurofalsebian-qian

MVVM

各タイムラインの要素を<Element>で表現したページネーションViewModelを複数のViewから参照する図が出てきたけど、複数のViewControllerにまた別の振る舞いを追加したくて実装をViewModelで共通化したい時にViewControllerはViewModelを一対多で持つのか一対一で巨大なViewModelを拡張していくのかというところが書き慣れてなくてピンとこなくてちょっと自分でやってみないとわからないなという感想だった。

Caching

RealmをキャッシュDBに使ってなんでもオブジェクトを作っていたんだけど破綻したという流れがあったけどちょっとこれも実際のソースコード見てみないと何が問題なのかわからなそうだった。

でもメモリに乗せてJSONに書き出して時限でいらなくなったら消すというのは普通に有効なパターンだと思った。Himotokiとかもいきなり出てきたし設計自体が流動的に変わったのだろうと推測。

ところでなぜRealmはライトウェイなキャッシュストアに使われがちなのだろうか。 というかマイグレーションが必要な永続化ストア需要が地下鉄で使われるアプリケーションとかにはあまりないのも関係していそうだ。

Deployments

結構自社とやっていることが似ていた。というかどこも似たようなものなのかも。

ユビレジではangleddeckというツールがあって、これがプルリクエストのOPENでインストールURL付きのウェブアプリをBOTがコメントでつけてくれてマージする前に非開発者でも確認しつつ作業を進められるのでみんな使った方がいいと思った(でもApple Developerエンタープライズ契約がいる)

ちょうど Quipper の開発事例 とかHerokuの Review Apps のiOS版という感じ

こういうツールはだいたいCTOのsoutaroさん(kではなくmの方)に「こういうのが欲しいんですよ〜」と話すと次の日に納品されてくる(関係性が逆だ……)

あと soutaro/Obihiro というPageObjectでのViewControllerテストツールもお気に入りでこれも使って欲しい

JSON RPC

さらっと出てきていたけど JSON RPC の採用は結構肝だと思った。クライアント側から各通信で欲しいデータを柔軟に取ってきたり調整が楽なんだろうなと想像した。この辺深掘りしたい。

(余談:某社ではNode.jsのAPIサーバーが各大規模サービスの前面にあって、フロントエンドエンジニアの人が自分が叩きたいWeb API自前しているという話も聞いたことがある。それに近い。)

monorepo

FacebookやGoogleのやり方に従って関連リポジトリを1つにまとめて管理する方法を取っていると聞いたのだけどサーバーサイドだけの話だろうか。

モバイルアプリも全部含めて会社で1つ? 聞きそびれた。

所感

メルカリ2年ぐらい前には他のフリマアプリよりは比較的ユーザー少なそうに見えていたんだけどよくこの短期間で急成長したなーとビックリした(偉そう)。

新しい価値を新しい事業で作るために新しい会社を設立して新しい人たちを集め*1新しい技術を使って開発したという意図があるように見えた。

技術者コミュニティへのブランディング活動の巧さはテックブログ黎明期の頃のウノウラボブログの存在を思い浮かべさせてちょっと面白い。

*1:中心となっている技術者は古株メンバーだったけど

株式会社はてなに入社しました

株式会社はてなに入社しました

そういえば先日naoyaさんにはじめて会いました。

株式会社はてなに入社しました - hitode909の日記

いのちの指輪としての技術顧問

新取締役及び技術顧問就任のお知らせ にあるとうり会社には技術顧問という肩書の人がいて、プログラマーの世界ではビッグネームなタレントが揃っているんだけど、はたして一般社員の開発者にとってこういう仕組みがどういう意味をなしているのかということに触れたい。

おそらくはてなブログ読んでいる技術者というのは技術顧問というお仕事 のNaoya Itoさんような現場に入って組織の課題を技術者の立場から意見して改善してゆくプロジェクトの請負人というのを想像するの? かどうかはよく分からないが、 ユビレジの場合は何か具体的なタスクを行っているわけではない。なのでレンタルCTO的なイメージと比較するとコミットが少なく見えると思う。 僕の知る限り他の会社では契約時に会社が週や月に何回かの定期訪問(もしくはビデオチャットなど)をセッティングしたりすることもあるらしいが、それもない。 これにはもともと技術顧問両氏はフルタイム、パートタイムで出社して他の開発者と同じように製品開発のタスクを何年か行っていたので、いざ技術顧問を受け入れて問題を解決や〜というきっかけはなかったという事情がある。

ウェブで見聞きできる中では「月に1回Matzと話せるという福利厚生がある会社」というのが近いのではないかと思うが、 それよりは若干チームにコミットしていてチャットに常時いるのでアドバイザーっぽく技術的な相談をけしかけたり、雑談したりは気軽にできる(まあお二人が多忙であろうのはなんとなく察しがつくのであまりやりとりは発生しないけど)。 あとは間接的には「あの凄腕技術顧問氏が目をかけるような会社だ」と人材市場にイメージを与えるという意味もあるんだろうなと思う。

ということでMatzがジャイアントパンダ的なモフモフであるとするのならユビレジの技術顧問は装備しておくとフィールドでHPが回復してゆくお得なアイテムである、というのが僕の見解です。

「死亡時にインターネットへの告知を希望しますか? はい/いいえ」

という項目をはてなブログの http://blog.lai.so/about へ載せれるようになるといいと思った。臓器提供カードのような役割で。

僕は以前からインターネットの人は死んだかどうかよくわからないので偲ぶタイミングがあんまりなくて不便だということをとなえていた。

しかし自分ごとをして考えると、生死不明のままインターネットのログになりたい人もいるだろうから各自選択できるのが好ましい。

インターネットへの投稿を個人の秘密として完全に墓場まで持っていけるケースがどの程度あるのかはよくわからないが、僕等のようなインターネットへ何か投稿し続けていないと自我が保てないような人々は身内や知人への根回しがないとこれは難しい。

そして独自ドメインには死後にURLが消滅してしまうリスクもある。それを考えるとはてなみたいな死人のログが手厚く維持されそうなプラットフォームを選択して投稿をすべきなのかもしれない(Twitterはまだいまいち信用できていない)。

debedebe

現在、この世の事象ほぼすべてが証券化され、市場原理の元に、売買がなされている。 ゲームを考えた 皆さんはもうおそらく意識することなく、まるで食事をとり、睡眠をとるかのようにブックマークをされている事かと思います。 次の事柄を、ブログ読者が引いてしまう度合いの小さい順に並べ替えよ。 結局自分が見つけたのは、肥大化した自己愛、でした。 ネビュラチェーンって何? だがな。たほいや倶楽部だけは邪魔したらマジで許さんからな。許さん。これだけは。 消極的なんかじゃない。突き詰めた結果なんだ。限りなく透明に近いだけなんだ。何の話だ。 はてブで人気エントリーになるような質問がしたいよぅ(´・ω・` ) こぼしてないですよ私こぼさせたら大したもんですよ

画像でふりかえる2015年