SHARE

目次

目次

SHARE

エンジニアの軌跡

DevRelay- vol.01「スモールスタートで構わない。リリースと改善を繰り返す」フリー株式会社

topの画像

さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。記念すべきvol.1は、クラウド会計ソフト「freee」 のソフトウェアエンジニア 山本伶氏(@ymrl)氏にスポットを当て、「面白い」仕事の呼び寄せ方を伺います。

DevRelay全25回はこちらからご覧いただけます

「独特なWeb開発」から「freee」へ

idesakuForkwellで本企画を実施するにあたって、社内のエンジニアに「最近気になるエンジニアいる?」というアンケートをとったんです。その中で特に声があがったのが山本氏でした。

山本氏は、エンジニアとしての経歴がユニークですよね。現在は freee で開発をされていますが、以前は「芸者東京エンターテインメント」でゲームを作っていらっしゃったと。最初はインターンだったと聞いていますが、大学でもやはりコンピューター関係を専門にされていたんですか。

山本SFC(慶應義塾大学湘南藤沢キャンパス)の研究室で、主にユーザーインターフェースに関する研究をしていました。

idesakuSFC ご出身ということで、失礼承知で聞いてしまうのですが、知人のSFC出身者は「SFC にはヘンタイが多い」と言っていました(笑)。本当にそうなんですか。

山本まぁ、間違いではないと思います(笑)。

インパクトのあるWebサイト「死ぬ.jp」

idesakuじゃあ、山本さんも、在学中はユーザーインターフェースをテーマに数々のヘンタイ的な研究をしていたんですか?(笑)。あと、「死ぬ.jp」(http://死ぬ.jp/ ★閲覧注意)とか、Twitter上で設定した時間発言がないと「このまま眠り続けて死ぬ」と投稿する「このまま眠り続けて死ぬ.jp」(http://眠りつづけて.死ぬ.jp/)とかはわたしも知ってます。「このまま眠り続けて死ぬ」は、今でも Twitter のタイムラインで見ますよ(笑)。

山本あれだけ使われた理由は自分でもよく分かりません(笑)。たしかにあの頃はちょっとおかしかったかもしれないです、ヘンタイかどうかは分かりませんが、バカっぽいことはよくやってましたね。

idesaku仕事としてエンジニアをやるようになったのは何がきっかけだったんでしょう。

山本大学院に上がるころから、SFC の先輩からの紹介で芸者東京エンターテインメントにインターンとして出入りするようになったことですね。最初のころは、スマホ向けの新サービスを作るためにアイデアを出したり、プロトタイプを作ったりしていました。なのでその頃は Web開発からは少し離れていたかもしれません。

入社直後に発した「これは滅ぼしたほうがいい!」

idesaku山本さんのこういう経歴や、遊び心のある作品を見ると、「freee」という会社とすぐには結びつかないんです。なぜ「freee」に入ろうと思われたんですか。

山本ちょうど転職を考え始めていた時期に、知人から「freee という会社があるよ」というのを聞いて、行ってみたら面白かったので参加を決めたと。簡単にまとめてしまうと、本当にそんなところです(笑)。freee には今は100人を超える社員がいますが、私が入社した2014年1月当時は10数人だけでした。

朝が弱く、満員電車にも乗りたくない

idesaku山本さんご自身は、転職のときにスタートアップ以外の企業を選ぼうとは思われなかったんですか?

山本えーとですね、自分、朝が弱いんですよ(笑)。

idesaku…朝が弱い(笑)。

山本ついでに満員電車にも乗りたくなくて(笑)。今、自分は会社の近くに住んでいて、徒歩か自転車で通勤しているんです。いわゆる大企業的なところに勤めている知人の話なども聞いていたんですが、仕事の上でも、どうしても「面倒なことが多そうだな」と感じてしまって。そういったところに入ろうという気にはならなかったですね。

freee は全体としてプロダクト指向が非常に強い

idesaku当時、プロダクトが JavaScript 回りにだいぶ課題を抱えていて、移って早々にそれをかなり厳しく指摘したという話を聞いたことがあるんですが。

山本「これは滅ぼしたほうがいい!」とか「殲滅する!」とか、わりと過激な表現で指摘していたというのは事実ですね(笑)。

idesaku(笑)それで、チームの方とケンカになったりしませんでした?

山本そういうケースもなかったわけではありませんが、freee という会社は全体としてプロダクト指向が非常に強いんです。「良いと思ったものを早くリリースして、さらに良くしていこう」という方向性は、全スタッフで一致しています。新たな技術の導入や修正についてもこの方向性で進めているので、最終的に決裂するようなことはほとんどないです。

フレームワークは? 開発体制は?

idesakuそういえば、1年ほど前に、風のうわさで「freee は、Backbone.js で作っているらしいぞ」と聞きました。

山本今でも基本はそうなのですが、最近だいぶ状況が変わってきています。React が入ってきたり、私が現在関わっている給与計算では、Vue.js があったりとか、会社全体で見るとたくさんのフレームワークが混在していますね。

新規導入は「プロダクトが良くなる」「開発効率が上がる」が条件

idesakuそうした新たなものを入れようと思うきっかけはなんなのでしょう。

山本「将来、こういう環境を作っておかないと困るよね」みたいなビジョンが見えたときですね。導入することで「プロダクトが良くなる」か「開発効率が上がるか」のいずれかを目指すことが前提です。開発効率が上がればそれだけ新しいプロダクトを作れるわけです。

idesakuたしか、freee ではサーバー側を Rails で作っていたと思うのですが、今回のようにフロント側が「React 入れるゼー!」とか盛り上がっていると、サーバー側から「でもアセットパイプラインがー」みたいな声が出てぶつかるとかはありませんでしたか。

山本うちの場合は、製品やターゲットとしているユーザーごとにチームで機能を作っていますが、それぞれのエンジニアが「フロント」か「サーバー」かといった分け方はしていないですね。もちろん、それぞれに得意不得意はあります。例えば、私はフロントエンド開発が得意ですが、高いパフォーマンスを出すための SQL設計なんかは苦手です。ですので、最終的なブラッシュアップは得意な人にお願いするんですが、開発の段階では自分で SQL を書いたりもします。逆に、DB のスペシャリストがフロントを書くという作業も普通にやっています。お互いに他の人が専門の分野についてもなんとなくは理解しているんです。

idesakuつまり、何か新しいことをしたい場合に、一方的にそれを主張するんじゃなくて「落としどころ」が分かった上で進められるわけですね。

山本そんな感じでしょうか。さっきの例だと「React 入れるゼー!」と推進している人が、バックエンドを見ている人と相談しながら、「アセットパイプラインについては、こういうふうにすればできるんじゃないか」とアイデアまで考えておいて、調整するといったことができる環境なんですよ。

1枚目の画像

CTO から送られてくる「プルリクチャンス!」

idesakuReact に Vue.js に Rails と、どれも精力的に開発が続けられていて、頻繁にバージョンアップするプロダクトだと思いますが、追従するのは大変じゃありませんか?

山本大変ですね~。実は Vue.js にもそういうところがあって、今ちょっと困ってます(笑)。でも、方針として、上げられるものはなるべく早く上げて追従していこうとは思っています。

idesakuバージョンアップしたら動かなくなった!といった時って、パッチ投げたりするんですか?

山本まずは「こんな問題が出てます」みたいなことを Slack に書いておくんですけど、そうすると CTO から「プルリクチャンス!」とか返ってきたりして…。

idesaku「それ、君が書けるよ!」と(笑)。

山本出せるときには出そうとは思ってるんですけどね。なかなか機会がないんですけれど。

「リリースはとにかく早く」が根付いた現場

idesaku先ほど、開発効率が上がればそれだけ新しいプロダクトを作れる、というお話がありましたが、実際のところ開発スピードはいかがですか。

山本「スモールスタートでいいので、とにかく早くリリースする」というスタイルなので、先週「あれ作ろうぜ」と話していた機能が今週出ているなんていうこともよくありますよ。そうしてリリースした機能を、後でフィードバックを得ながら改善していきます。

idesakuそうなると、自然と頻繁にリリースすることになりますよね。

1日に複数回デプロイするのも普通

山本はい、うちは毎日デプロイしていています。1日に複数回デプロイするのも普通です。

idesakuそのたびにテストして品質を保つのは大変そうですね。自動テストでカバーできているということでしょうか。

山本うちには QA部隊があって、彼らがブラウザを Selenium でオートパイロットして、IE、Firefox、Chrome といったブラウザごとに動作確認を行い、全画面の品質を担保するといった形でやっています。でも、新機能のテストだと Selenium側の準備が間に合わないことがあるので、手作業で対応することもありますね。

idesaku小さくリリースして改善を繰り返す、といった手法では、世の中では「アジャイルプロセス」などが注目されていますけれど、freee では、なにかそうした決まったやり方は取り入れているんですか?

山本最近は自分のチームが、しっかり「スクラム開発」をやろうとしています。これまでは、あまり型にこだわらずにエッセンスだけ取り入れていたのですが、適当にやっていたら担当者がやるべき毎日のタスクが増えすぎてしまったんです。そんなことがあって、スケジューリングやタスクの優先順位付けなどを、スクラムの基本に則って、しっかりやってみようということになりました。

市場の声を聞いて優先順位を確定する

idesaku優先順位付けというと、やりたいこと、実装したい機能というのは、本当に数多くあると思うんですが、どのように決定しているのでしょうか。

山本freee を現在使っていらっしゃらない方が「これがあれば freee を使える、使いたい」と思ってくれそうな機能が優先されますね。製品ごとの開発チームがあって、ユーザーや市場の声を聞きながら、それぞれのチーム内で計画を定期的に見なおして優先順位を決めていっています。アンケートやログデータなどの分析を通じた改善のための仮説をチームごとに立てていますし、さらに営業スタッフはお客様から直接聞いた情報を持っていたりしますので、それらを現場で総合して優先順位をつけていくという感じです。

2枚目の画像

「すでに『老害』と呼ばれています」

idesaku山本さんは、freee に入社して約2年ですよね。若い会社ですし、ポジションとしてはもう「中堅」と言っていい立場なんじゃないですか。

山本いやぁ、もう「古株」のほうですね。自分は27歳なんですけれど、会社ではすでに「老害」とか呼ばれます。原因は、社内で2000年代初頭のインターネットの話とか、古い話をしたがるからですが(笑)。エンジニアとしては、一応最年少なんですよ。現在の中心は30代ですね。

idesaku山本さん自身が、採用に何らかの形で関わったりすることはあるんですか。

山本「面白い人だから会ってみて」と声がかかることはありますね。結果的に、エンジニアは私より少し上の30代の人が中心になっていますが、ビジネス職などでは「伸びしろ」を評価して若い人をとるということも積極的にやっているようです。もちろん、技術職であっても「伸びしろ」が評価されて採用というケースもありますよ。

freee が現在抱える課題 - それはどう解決していく?

idesakuプロダクトを作っていくにあたって感じている課題はありますか。

課題は技術的負債

山本現在のスピード感でやっていると、結果的に妥協するような形で残ってしまう「技術的負債」のようなものは、どうしても出てきてしまいます。また、先ほど話したようなReactをこれからどうやって使っていこうとか、そもそも「本当に今、Railsなのか?」とか、本当にいろいろな課題があります。

idesaku技術的負債の返却にまとまった時間を確保するのは難しいですよね。便利な新機能のようにメリットがわかりやすく見えるわけではないので。

山本そうなると、まずはできるところから、小規模に入れていって、それで生産性が上がることを証明しながら、徐々に適用範囲を広げていくという形で進めていくことになりますね。

スモールスタートで改善を続ける

idesaku環境についても、「スモールスタートで改善を続ける」というスタイルで作っていくわけですね。

山本そうですね。「全面リニューアル!」みたいに大規模に変更してしまうと、それまで顕在化していなかったバグが出てきたようなときに、壊滅的なダメージを受けてしまいますよね。だから普通であればテスト期間を長くとるわけですが、そのやり方は freee という会社には合わないんですよね。期間も資金も限られた中で、会社がうまく回るように、少しでも現状を良くしようという思いで作業を続けています。

次回のゲストは…

idesakuこの対談企画はリレー形式で続けていきたいと思っていまして、ぜひ次に話を聞いてみると面白そうな人を紹介していただけると嬉しいのですが。

山本同じフロントエンドエンジニアで同い年の Incrementsの竹馬氏(@mizchi)はどうでしょう。たまに飲みに行ったりしている間柄ですが、僕よりも過激な発言が多くて楽しい方ですよ(笑)

idesakuご紹介ありがとうございます。では次回は竹馬氏のインタビューをお届けしたいと思います。今日は長い時間、楽しいお話をありがとうございました!

執筆:高橋美津

※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。

Forkwellキャリア相談

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。