「スモールスタートで構わない。早くリリースして、改善を繰り返す」− freee 山本伶（ymrl）氏

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

気になる”あの会社”の開発者がどんな感じで仕事をしているのか、記念すべき第1回のゲストは、クラウド会計ソフト「freee」のソフトウェアエンジニアである山本伶氏（@ymrl）。山本さんのキャリアや freee での開発について、じっくりお話しを伺いました。山本さんご指名のリレー相手は、インタビューの最後で！

「ヘンな Webサービス」から「ゲーム」そして「freee」へ

後藤
今回 Forkwell Jobs でこの企画をやるにあたって、社内のエンジニアに「最近気になるエンジニアいる？」というアンケートをとったんです。その中で特に声があがったのが山本さんで。山本さんは、エンジニアとしての経歴がユニークですよね。現在は freee で開発をされていますが、以前は「芸者東京エンターテインメント」でゲームを作っていらっしゃったと。最初はインターンだったと聞いていますが、大学でもやはりコンピューター関係を専門にされていたんですか。

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

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

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

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

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

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

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

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

後藤
山本さんのこういう経歴や、遊び心のある作品を見ると、クラウド会計ソフトという堅実なイメージのあるサービスを作る「freee」という会社とすぐには結びつかないんです。なぜ「freee」に入ろうと思われたんですか。

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

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

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

後藤
…朝が弱い（笑）。

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

後藤
前職では Web開発から離れていた時期もあったということでしたが、Webサービスである freee の開発作業に入っていくのは大変ではなかったですか。

山本
私が入った当時は、まだそれほど機能も多くなかったので、技術面でのキャッチアップよりも簿記会計などを覚えるほうが大変でした。

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

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

後藤
（笑）それで、チームの方とケンカになったりしませんでした？

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

フレームワークは？開発体制は？「freee」の最新状況

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

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

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

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

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

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

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

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

後藤
React に Vue.js に Rails と、どれも精力的に開発が続けられていて、頻繁にバージョンアップするプロダクトだと思いますが、追従するの大変じゃありませんか？私も Rails のバージョンアップ作業を何度かやったことがあるんですが、アグレッシブに機能を変更してくるので苦労も多くて。

山本
大変ですね～。実は Vue.js にも、そういうところがあって、今ちょっと困ってます（笑）。でも、方針として、上げられるものはなるべく早く上げて追従していこうとは思っています。対応が遅れれば遅れるほど、後々さらに大変になってしまいますしね。

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

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

後藤
「それ、君が書けるよ！」と（笑）。

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

小さく早く作って大きく育てる「ラピッドリリース」が根付いた現場

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

山本
「スモールスタートでいいので、とにかく早くリリースする」というスタイルなので、先週「あれ作ろうぜ」と話していた機能が今週出ているなんていうこともよくありますよ。そうしてリリースした機能を、後でフィードバックを得ながら改善していきます。小規模でも、何かしら使えるものをリリースすれば、それでトクをするお客さんは必ずいますよね。もし、最初の段階でトクをしたお客さんが全体の3割だったとしても、そのフィードバックを受けて改善すれば、それを5割、7割と増やして行けるわけです。そこから、さらに多くのフィードバックを得て、改善を重ねるということを続けています。

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

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

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

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

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

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

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

山本
freee を現在使っていらっしゃらない方が「これがあれば freee を使える、使いたい」と思ってくれそうな機能が優先されますね。製品ごとの開発チームがあって、ユーザーや市場の声を聞きながら、それぞれのチーム内で計画を定期的に見なおして優先順位を決めていっています。

後藤
上から「これをやれ！」という形では指示されないんですか。

山本
トップは数字を見ていますので、その流れで目標を指示することはもちろんあります。ただ、具体的にどう行動していくのかは、実際にプロダクトを作っているエンジニアや、業務に関する詳しい知識がある人間じゃないと分からないし、決められないですよね。それで、アンケートやログデータなどの分析を通じた改善のための仮説をチームごとに立てていますし、さらに営業スタッフはお客様から直接聞いた情報を持っていたりしますので、それらを現場で総合して優先順位をつけていくという感じです。

「27歳ですが、会社ではすでに『老害』と呼ばれています」

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

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

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

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

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

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

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

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

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

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

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

さて、次回のゲストは？

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

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

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

そしてfreeeさんでは、Rubyエンジニアを絶賛募集中のようです。ご興味のある方はぜひ気軽に話を聞きに行ってみてください。

執筆：高橋美津

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

Forkwell では、ITエンジニアが自身のアウトプットを簡単に連携・管理し、スキルを可視化することができる「Forkwell Portfolio」を運営しています。 GitHub アカウントの連携により、登録されたリポジトリのコミットログを解析。普段書いているプログラミング言語や、コードの変更量をグラフ化します。