Forkwell Press

エンジニアの生き様をウォッチするメディア

エンジニアとしてやっていくために必要だったものは「音楽」が教えてくれました-Proper 藤村大介(ffu_)氏

この連載では、「Forkwell Jobs」の開発にも関わるフリーランスエンジニアの後藤大輔(@idesaku)が、さまざまな企業で働くエンジニアとリレー形式で対談を行っていきます。

前回のIncrements竹馬(mizchi)氏からご指名のあった第3回のゲストは、藤村大介(@_ffu)氏です。

これまで、groovesMercariQuipper など、さまざまなスタートアップでのプロジェクトに関わり、現在は自ら共同創業者として起業した「Proper」の CTO を務める藤村氏。インタビュアーの後藤は、grooves で藤村氏と一緒に仕事をしていた「元仕事仲間」の間柄です。そんな立場から、藤村氏のキャリアや、好きな技術、これからエンジニアとしてやっていきたいと考えている人たちへのアドバイスなどをたっぷりとお伺いしました。

藤村さんご指名のリレー相手は、インタビューの最後でご紹介します!

mizchi氏も驚いた「藤村流」の新人教育

後藤
リレーインタビュー第3回目のゲストは、前回の Increments 竹馬(mizchi)さんからご紹介のあった藤村大介さんです。

藤村
よろしくお願いします。

後藤
mizchiさんによると「藤村さんにはだいぶお世話になった」ということなんですが、知り合われたのはどういう経緯だったんですか。

藤村
僕は以前 Aiming というゲームの会社にいたことがあり、そこで分析のための基盤を作っていました。最初僕1人だったそのチームに、その後インターンだったか、アルバイトだったかで入ってきたのが彼だったんですね。で、そこで彼に Git の作法を教えたり、trailing whitespace を指摘したりしてまして(笑)。

後藤
(笑)あの mizchiさんにも、そんな指摘を受ける時代があったんですね。

藤村
その後、僕がゲームのプロジェクトに移ってその開発リーダーになったんですが、そこで彼と一緒に HTML5/JavaScript でアプリケーションを作りました。で、実はそれで終わりではないんですよ。僕はその後フリーランスになって「Mercari」を手伝ったりした後に「Quipper」に入ったんですが、そこにもしばらくすると彼が入って来たんです。

後藤
それは、藤村さんがスカウトしたとか、そういうことではなくて?

藤村
ええ、違います。面接など採用プロセスからも外してもらいました。

後藤
mizchiさんには Aiming のインターンだった当時の思い出もちょっとだけ聞いたんです。それによると「『Haskell で KPIサーバを書くぞ!』と言われて『えっ?』という感じだった」そうなのですが。

藤村
たしか、その分析基盤のプロジェクトで使う言語を決めるにあたって、最初に何種類か言語を試したんですね。で、彼が Clojure で書いて、僕が Haskell で書いてみたんじゃなかったかな。結果的に Haskell のほうがうまくいったんで、彼にも Haskell を覚えてもらって、ペアプロしつつ開発を進めたということなんです。3~4年前の話になりますかね。

後藤
言語を選ぶにあたって、言語そのものの使いやすさというのも大切ですが、特に仕事で使う場合には周辺のライブラリやコミュニティが充実しているかというのも重要な選択基準になると思います。そのあたり Haskell ってどうでしたか?

藤村
Haskell は自分で前から触っていて、バックエンドにデータベースを置いたアプリケーションをどうやって作るかみたいなことをいろいろ試していたんです。当時 Haskell で使える「Yesod」という Rails的なフルスタックのフレームワークが出ていて、完成度もかなり上がっていました。本家 Rails にはかないませんが、ライブラリの充実度という面では十分実用的という印象でしたね。

後藤
われわれが以前、grooves で一緒に仕事をしていたときには Ruby on Rails で Webアプリを作っていたわけですが、それ以外の部分での藤村さんに対する私の印象は「Haskell の人」なんですよね。そもそも、何がきっかけで Haskell を使い始めたんですか。

藤村
えーと、Rails や Ruby を始めて1年くらいしたころ、Ruby が「Matz LISP だ」と評されているのを見たことがあったんですね。で、それはどういう意味なんだろうと気になって調べているうちに、「The Little Schemer」という本(日本語訳はオーム社より「Scheme手習い」として刊行)に出会ったんです。この本を読んで Scheme を使ってみたところ、自分には関数型プログラミングが「性に合っている」気がしました。

後藤
まずは Scheme からだったんですね。

藤村
それからしばらく Scheme を触っていたんですが、そのうちに Bruce A. Tateの「Seven Languages in Seven Weeks」(日本語訳は「7つの言語 7つの世界」としてオーム社より刊行。監訳者は、Matz こと、まつもとゆきひろ氏)が出版されました。この本の最終章で紹介されていたのが「Haskell」だったんです。Haskell には当時の自分が求めていたものが全部あると感じました。それで本格的に使い始めたと。

後藤
藤村さんが求めていたものって、具体的には何なんでしょう。

藤村
僕、割とざっくりとコーディングをするんでミスをしがちなんですよ。そうしたこともあって、開発者側のミスをカバーしてくれる仕組みが好きなんです。だから TDD なんかもやるんですが、Haskell のようなリッチな型システムがある言語を使うとさらにミスを減らせる。そういうところが自分に合っていると思います。僕の見解として、Haskell は実用レベルの言語の中では型システムが一番良くできていて、安全で正しいプログラムを書きやすい言語だと思っています。

後藤
難しいことやろうと思えば思うほど、Haskell がいいということですね。

藤村
難しいロジックほどしっかり書けますね。また、バックグラウンドの理論などは知的にも面白いです。Haskell を使うためには覚えなきゃいけないことがたしかに多いのですが、ひとつひとつ理解していけばそれほど難しくもないと思いますよ。

後藤
たしかに藤村さんは、TDD にペアプログラミングと、開発におけるミスを減らして品質を上げるようなプラクティスには昔から熱心でしたね。Haskell用のテスティングフレームワークである「hspec」のコントリビューターもされていませんでしたっけ。

藤村
はい。もっとも、僕自身は直接コミットすることはほとんどないんですけれど。

後藤
作者の方に会われたんですか。

藤村
ええ、夏休みに。Quipper を辞めたあとにしばらく海外旅行をしたんですが、その時にシンガポールに寄って会ってきました。いろいろ話したり、ペアプロしたりとか。

後藤
ペアプロを。hspec を直したんですか?

藤村
hspec の周辺ツールを直しましたね。

後藤
あと、最近見たものだと、Haskell プロジェクトのテンプレート生成ツールのようなものを作っていましたよね。あれは完全な自作ですか。

藤村
そうですね。Ruby だと Bundler でプロジェクトのテンプレートが作れるじゃないですか。ああいう機能を持った Haskell用のツールでいいものがなかったので、とりあえず作ったんです。結構多くの人が使ってくれていたようですが、その後別の人が Haskell版 Bundler の「決定版」的なものを作ってくれたんで、僕のほうはやめてしまいましたね。

後藤
Haskell を本当に気に入っていらっしゃるんですね。ただ、Haskell のコミュニティでやっていくには数学的な素養が必要で、そのあたりが苦手だとアカデミックハラスメントを受けることもあるというウワサを聞いたんですが、それって本当ですか?他でもない藤村さんから聞いた気がします(笑)。

藤村
まぁ、ライブラリそのものが数学理論を前提とした作りになっていたりするので、どうしてもそういうのに強い人がコミュニティの中心になりますよね。議論も「代数がどうした」とか「圏論がうんぬん」みたいになるし、カンファレンス発表もスライドの3枚目あたりからはずっと数式が並んでいるというような事もあります。もちろん、Haskellコミュニティの人が全員そんな感じだというわけではない…はずですよ。

後藤
なかなか敷居が高い世界ですねぇ。

藤村
そうですね。使うにあたって多少ハードルがある言語だとは思います。ただ、Haskell が使える人材の募集は多いですし、実際に堅牢性が求められる金融機関などで使われている例もあります。使おうと思えば、使える言語ですよ。

「音楽」がつないだ縁が現在の「grooves」の原型に

後藤
さて、先ほどもちょっと出ましたが、grooves で一緒に仕事をしていたときの話をしましょうか。ずいぶん昔のことのように感じますね。

藤村
Ruby on Rails のバージョン3が出てすぐのころですから、たぶん2011年くらいですよね。

後藤
私が grooves からの仕事を受けるようになったときには、藤村さんはすでにいらっしゃいましたよね。

藤村
そうでしたね。一緒にご飯食べた気がします。

後藤
もともと、どういう経緯でエンジニアの仕事を始められたんですか。文系の学部卒だと伺っていますけど。

藤村
大学では哲学が専攻でした。で、昔から音楽が好きで、並行してバンドでギターを弾いていたりして、「仕事」や「就職」というものにあまり関心がなかったんですね。最初は研究職に進もうかと思っていたのですが、特に文科系だとその後の生活が厳しいというのも分かったので、その時ようやく就職しなきゃと思うようになって。

後藤
最初に入ったのは、業務システムの開発会社だったんですよね。

藤村
そうです。SAP のアドオンを ABAP で作るようなことをしていました。

後藤
そこから、なんで grooves に移られたんでしょう? 当時の grooves はエンジニアリングに強いわけではなかったですよね。

藤村
それは単純な理由で、人材紹介会社からの紹介です。本格的にエンジニアとして仕事をしていこうと決めて、最初の会社を辞めたあと、今はすでになくなってしまったスタートアップで Ruby を1年ほどやっていたんです。次の候補となる会社はいくつかあったんですが、Ruby でとなると当時はあまり選択肢が多くなかったので、自然と決まった感じですね。

後藤
とはいえ、エンジニアリングの文化がまったくないところで、文字どおり一から環境を作っていくのは大変じゃなかったですか。

藤村
そのへんは、松田さん(現 grooves 取締役で、Rubyコミッター、Railsコミッターの松田明氏)がいたんで…。

後藤
たしか藤村さんが松田さんに声をかけたんじゃなかったでしたっけ。

藤村
松田さんとは、Twitter でイタリアのプログレッシブロックの話で盛り上がって仲良くなっていたんです。で、その流れで「今、Ruby でこういうことやっていて…」という話をしたら、来てくれたんですよ。

後藤
そんな経緯があったとは。当時すでに松田さんは Ruby on Rails の世界では有名人でしたけど、それゆえの声のかけづらさとかありませんでした?

藤村
僕は、あんまりそのへんのことを気にしてなかったですね。むしろ僕の中での松田さんはプログレとかメタルの話が分かる人だという認識だったんで。

後藤
音楽と Twitter の力だったんですね。でも、それがきっかけで grooves に松田さんが入って、松田さんが私に声をかけてくれたという流れになるので、 grooves のエンジニアリング文化のルーツは、やっぱり藤村さんにあるということになりますよね。

藤村
僕のツイートと音楽のおかげというわけです(笑)。

「フルスタック」の追求はまるで新たなエクストリームスポーツのよう

後藤
当時の grooves では、使う技術や開発スタイルの選定は松田さんが?

藤村
今となっては記憶があいまいですが、100% 松田さん任せではなかったと思います。僕も最初と次の会社でプロジェクトの立ち上げ方、進め方などは経験していたので、ある程度は手分けしてやっていたはずです。

後藤
mizchiさんと同じように、馬場達郎さんをはじめ、grooves で新人時代に経験を積んだメンバーの中にも「藤村さんには大変お世話になった」という人が多いです。

藤村
当時のエピソードとして、grooves で松田さんが新人とペアプロしながら、Rails 3 を直している場面に遭遇したのが個人的には衝撃でした(笑)。

後藤
grooves で藤村さんはプログラマーをメインとして仕事をされていたと思うんですが、grooves を離れた後はどんな感じでしょうか。やはりプログラミングが仕事の中心ですか?

藤村
だんだんと、マネジメントに関連した仕事の比率が増えてきていますね。マネジメントといっても「チームのお世話」とか「仕組みを作って回す」といった意味合いですが。ただ、それだけをやっている期間というのはあまり多くなくて、並行してコードも書いているといった感じです。

後藤
仕事の範囲としては、幅広くやられているんですね。

藤村
そうですね。今は起業していますが、「投資家と会った後に CSS を直す」といった感じで。

後藤
目指すは究極のフルスタックエンジニア。

藤村
どこまで「フルスタック」になれるかを突き詰める、ある種のエクストリームスポーツをやっているような感覚になりますね。今はアドビの Illustrator もちゃんと使えるようになりたいんです。本職のデザイナーさんに作ってもらったデザインを、開発の過程でほんのちょっとだけ直さなきゃいけないケースが出てくるじゃないですか。その時、それが自分でできなくて、やりとりに時間をかけてしまうと誰も幸せになりませんよね。その程度のことはできる限り自分でやれるようにしておきたいとは常々思っています。

業界に波紋を呼んだ「退職エントリ」

後藤

藤村さんと言えば、昨年 Quipper の退職&求職エントリを書かれた直後、即座に60件ほどのオファーがあったというのが話題になりましたが。

藤村
あれは自分でもビックリしました。結局あまりの多さに心が折れてしまい、きちんとお返事できなかったところもあって、ちょっと失敗したかな、と反省しています。

後藤
最近、退職エントリを書くエンジニアも増えてはいますけれど、それだけの反応がある人というのは珍しいんじゃないですかね。

藤村
いや、そんなことはないと思います。結構、みんなオファーを受けていると思いますよ。エンジニア採用の界隈では常に「この人そろそろ動くんじゃないか」みたいなことをSlackの、エンジニアの集まるチャンネルで逐一チェックして待ち構えている人も多いみたいですから。ただ、具体的な件数を発表したのは僕だけかもしれませんね。

後藤
会社の人事担当者から直接連絡をもらうというのが多かったんでしょうか。

藤村
そうですね。エージェントからの連絡はなかったんじゃないかな。あと、スタートアップ界隈だとエンジニア以外の友人も比較的多いほうなので、彼らが「とりあえずメシ行きましょう」みたいな感じで声をかけてくれたというのもありました。

共同創業者となった「Proper」でやりたいこと

後藤
今やっている新しいお仕事は、その中から選んだという感じですか。

藤村
そうですね。その時期に紹介された話の中で一番面白いと思ったところと継続的にコンタクトをとって、いよいよ本格的に始動という段階です。

後藤
今回は共同創業者という立場ですよね。社名は決まりましたか?

藤村

Proper」にしました。

後藤
Proper ではどんなことをやるんですか?

藤村
まだ具体的に何をやるかを話せる段階にはないんですが、テクノロジーを使って地域社会における人々の「暮らし」を今よりも豊かに、快適にするようなことをやっていきたいと思っています。事業領域は定まっていて、開発もスタートしています。

(藤村さんより追記: インタビューの後、ちょうど良い距離感でご近所さんと交流できる SNS「マチマチ」を公開しました。現在エリアを限定して展開中です)

後藤
Proper のメンバーは今、藤村さんとパートナーの方の2人ですか?

藤村
ええ。その2人が共同創業者です。僕は CTO で、もうひとりがビジネス面を見る CEO になります。

後藤
基盤としては Ruby on Railsを採用するんですね。共同創業者で好きなことができるのに、なんで Haskell 使わなかったんですか?(笑)

藤村
この間会った hspec の開発者にも「今度新しいサービスやるとしたら、何使うの?」と聞かれて、「Rails。だって、静的アセットを AWS とかにアップロードするような仕事、Haskell ではやりたいと思わないでしょう」と答えたんですね。そしたら「うん。俺もやらないと思う」って(笑)。

後藤
たしかに、実務に使える周辺環境は、Ruby on Rails だと充実していますからね。とりあえずやりたいことは、すぐにひととおりできてしまいますし。

藤村
プロジェクトの初期段階では、プログラミングに関して非常に複雑で難しい課題が出てくることは実はあまりないんですよね。その意味では「どれを使っても一緒」というか。むしろ、問題が出てくるのはサービスが始まって、機能が増え、規模が大きくなってきた段階なんで、そこでまた改めて考えようかとは思っています。

後藤
藤村さんがこれまで関われた仕事の中には、それなりに大規模なサービスも多かったんじゃないですか。

藤村
Quipper はそれなりに大規模でしたが、それ以前のものはそうでもなかったと思います。あと、既にできあがったシステムがあるところに途中から入るケース自体、実は少ないんですよ。大抵は新しいプロジェクトで、ゼロから作り始めるみたいな感じでした。

後藤
今回の「Proper」でも、まさに「ゼロ」から「イチ」を生みだすことをやっているわけですよね。期待しています。

若手へのアドバイスは「エラーメッセージをきちんと理解しよう」?

後藤
藤村さんにインタビューするということで、grooves 社内のエンジニアに「どんなことを聞きたい?」と聞いて回ったら、「新人、若手のエンジニアに対してのアドバイス」を聞きたいという意見が多かったんですよ。これまで、いろんな会社で新人やインターンの面倒を見てこられた知見から、何かアドバイスはありませんか。

藤村
うーん。難しいですね…。

後藤
なんか、先日 grooves の若手がイベントの懇親会で藤村さんと話をして、非常にテンション上げて帰ってきたんですけど、その時ってどんな話をされたんでしょう?

藤村
…どんな話したんでしたっけ? その時、酔っぱらっていたんですよ(笑)。

後藤
(笑)

藤村
あ、「エラーメッセージをきちんと理解しよう!」というのはどうでしょう?

後藤
「エラーメッセージを理解しよう」ですか。それは「英語に憶さずきちんと読もう」みたいな意味ですかね?

藤村
そもそも、システムのエラーメッセージやログをしっかり読んで、何が起こっているのか理解した上で対応をしている人って少ないんじゃないでしょうかね。

後藤
あぁ、そうかもしれません。「何か動かないや」って言いながら、とにかくコード書き直してしまう人のほうが多いかも。

藤村
あと、翻訳された情報だけでなく「オフィシャルのドキュメントをきちんと読もう」とか…。うーん、後藤さんからは、なんかないですか?

後藤
私、今回はインタビュアーなんですけどね(笑)。うーん、たしかに改めて聞かれると難しいですね。ただ、藤村さんの流れに合わせると、面倒くさがらずに「英語を読む」習慣を付けておくことは、たしかに大切だと思いますね。いろんな分野でドキュメントの日本語化は進んでいますけれど、最終的には英語の一次情報にあたらないとどうしようもなくなるケースは多いと思いますし。

藤村
そもそもプログラミング言語自体も、ほとんど英語がベースですしね。英語以外の自然言語をベースにしたプログラミング言語って、そうないでしょう。

後藤
ちなみに藤村さんは、もともと英語ができたんですか?

藤村
普通に日本で高校と大学を出たので、大学受験レベルですよ。ただ、音楽が好きだったのでインターネットを使って海外から情報を仕入れることに熱心でした。その点で普通の人よりは英語に触れる機会が多かったというのはあると思います。

後藤
ここでも音楽がカギに!

藤村
好きなバンド見るために海外に出かけたり、同じバンドの海外のファンと交流したりといったことは普通にやっていましたからね。エンジニアとしてやっていくにあたって、音楽、特にメタルは重要な役割を果たしたと言ってもいいでしょう。

後藤
英語以外では何かありますか。

藤村
そうだなぁ、あとは「マスタリング TCP/IP」を読むとか、アルゴリズムよりも低レベルなコンピュータサイエンスの理論的な基礎についての本を読むとかでしょうか。このあたりは、一回読んで、そのあと忘れてしまってもいいんですよ。ただ、ネットでサービスを作っていくにあたっては避けて通れない知識になってくることもあるので、何かのきっかけで思い出せる程度にはなっていてほしいと思います。

後藤
あと必要なのは「セキュリティ」に関しての基礎知識でしょうか。

藤村
そうですね。ただ、こうやって挙げていくと「基礎知識」だけで大変な量になってしまうんですけれどね。

「ストックオプション」はスタートアップエンジニアの必須知識だ

藤村
あと、スタートアップに関わる人には「ストックオプション」に関する知識を絶対に身につけたほうがいいです。自分がどこで働けば、どのタイミングでいくらもらえるのか。もし何年か働いて上場すれば、いくらになるのか。その期間、別のところで働いた場合と比べて、どれくらい「お得」なのかといったことは、エンジニア自身がきちんと理解して、シミュレーションしておくべきだと思います。それは、自分が将来的にエンジニアとして生きていくためのスキルアップのプランと密接にリンクしてくるわけですから。

後藤
たしかにエンジニア界隈には、お金というか、自分のスキルに対する報酬が適切かどうかという点についてあまり頓着しない人が多いかもしれませんね。

藤村
僕はいろんな会社で働く機会があったので、そのあたりは勉強して意識するようにしていましたね。スタートアップにおけるスキルと報酬の関係に関しては、海外のサイトではたまに情報を見かけますけれど、日本だとほとんどないですよね。そこはもっと議論されてもいいし、エンジニア側にもリテラシが必要だと感じています。

後藤
今は共同経営者の立場で、ファイナンスについて学んだことも生かせる状況にあるわけですね。そういえば、Quipper を辞めて求職中の時期に、あるイベントのライトニングトークで「次は一番ツラい選択肢を選ぶ」と発言したと聞いたのですが、その真意は何だったのでしょう。

藤村
「大企業に入る」から「起業する」まで、選択肢はいろいろあったんですよ。ただ、これまで経験したことがなくて、そして一番「ツラい」のは何だろうと考えて選んだら「起業」になったと。ちょうど次の仕事を考えていたときに「ハード・シングス(Hard Things)」という本が話題になっていて、それを読んだんですよ。

後藤
どんな本ですか?

藤村
マーク・アンドリーセンと一緒に「アンドリーセン・ホロウィッツ」というベンチャーキャピタルを立ち上げたベン・ホロウィッツという人が書いた本なんですが、起業家がスタートアップ企業を作るときに直面した「ツラいことあるある」がひたすら出てくるんです。

後藤
それを読んで、よく起業しようと思いましたね。

藤村
うーん、自分の「伸びしろ」を試したくなったというのが大きいと思います。これまでのキャリアの中でファウンダーや CTO をやった経験はありませんでしたが、近いところにはいたことがありましたから、自分から見えていた範囲で次にチャレンジするとしたら、そこだろうと思ったんですね。

後藤
その「ツラい」選択をされて、いかがですか。

藤村
見えていた以上に「高いハードル」だったんだなぁと実感しています。でも、実際に「ツラい」ことは多かったとしても、人間そう簡単には死ぬことはありませんからね。大丈夫です。

藤村氏が紹介する次回のゲストは……

後藤
本日は、お忙しいところありがとうございました。さて、最後にリレーインタビューのバトンを渡す方をご紹介いただきたいのですが。

藤村
島崎清山さんに話を聞きたいです。非常に頭がいい人で、「一緒に仕事してみたい人リスト」に常に入っています。昔、Haskell の勉強会で知り合って仲良くなりました。

後藤
音楽で?

藤村
いや、普通に Haskell仲間です。あと、mizchi のことも知ってますよ。三人で飲んだりしました。

後藤
それにしても藤村さんに「非常に頭が良い」と言わせるとは、お目にかかるのが楽しみです。それでは今日は本当にありがとうございました。

執筆:高橋美津



[PR] Forkwell Portfolio で、ご自身のスキルを可視化しませんか?

Forkwell では、ITエンジニアが自身のアウトプットを簡単に連携・管理し、スキルを可視化することができる「Forkwell Portfolio」を運営しています。

GitHub アカウントの連携により、登録されたリポジトリのコミットログを解析。普段書いているプログラミング言語や、コードの変更量をグラフ化します。

  • 自身の経歴をまとめたいが、公開しているアウトプットが各サービスに散らばっている
  • 非公開での活動(社内業務など)内容を開示するのが難しい

といった様々な課題を解決し、あなたの技術力を可視化します。