ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■エンジニアの軌跡
2015.12.15 2024.03.28 約4分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。記念すべきvol.1は、クラウド会計ソフト「freee」 のソフトウェアエンジニア 山本伶氏（@ymrl）氏にスポットを当て、「面白い」仕事の呼び寄せ方を伺います。
idesaku：Forkwellで本企画を実施するにあたって、社内のエンジニアに「最近気になるエンジニアいる？」というアンケートをとったんです。その中で特に声があがったのが山本氏でした。
山本氏は、エンジニアとしての経歴がユニークですよね。現在は freee で開発をされていますが、以前は「芸者東京エンターテインメント」でゲームを作っていらっしゃったと。最初はインターンだったと聞いていますが、大学でもやはりコンピューター関係を専門にされていたんですか。
山本：SFC（慶應義塾大学湘南藤沢キャンパス）の研究室で、主にユーザーインターフェースに関する研究をしていました。
idesaku：SFC ご出身ということで、失礼承知で聞いてしまうのですが、知人のSFC出身者は「SFC にはヘンタイが多い」と言っていました（笑）。本当にそうなんですか。
山本：まぁ、間違いではないと思います（笑）。
idesaku：じゃあ、山本さんも、在学中はユーザーインターフェースをテーマに数々のヘンタイ的な研究をしていたんですか？（笑）。あと、「死ぬ.jp」（http://死ぬ.jp/ ★閲覧注意）とか、Twitter上で設定した時間発言がないと「このまま眠り続けて死ぬ」と投稿する「このまま眠り続けて死ぬ.jp」（http://眠りつづけて.死ぬ.jp/）とかはわたしも知ってます。「このまま眠り続けて死ぬ」は、今でも Twitter のタイムラインで見ますよ（笑）。
山本：あれだけ使われた理由は自分でもよく分かりません（笑）。たしかにあの頃はちょっとおかしかったかもしれないです、ヘンタイかどうかは分かりませんが、バカっぽいことはよくやってましたね。
idesaku：仕事としてエンジニアをやるようになったのは何がきっかけだったんでしょう。
山本：大学院に上がるころから、SFC の先輩からの紹介で芸者東京エンターテインメントにインターンとして出入りするようになったことですね。最初のころは、スマホ向けの新サービスを作るためにアイデアを出したり、プロトタイプを作ったりしていました。なのでその頃は Web開発からは少し離れていたかもしれません。
idesaku：山本さんのこういう経歴や、遊び心のある作品を見ると、「freee」という会社とすぐには結びつかないんです。なぜ「freee」に入ろうと思われたんですか。
山本：ちょうど転職を考え始めていた時期に、知人から「freee という会社があるよ」というのを聞いて、行ってみたら面白かったので参加を決めたと。簡単にまとめてしまうと、本当にそんなところです（笑）。freee には今は100人を超える社員がいますが、私が入社した2014年1月当時は10数人だけでした。
idesaku：山本さんご自身は、転職のときにスタートアップ以外の企業を選ぼうとは思われなかったんですか？
山本：えーとですね、自分、朝が弱いんですよ（笑）。
idesaku：…朝が弱い（笑）。
山本：ついでに満員電車にも乗りたくなくて（笑）。今、自分は会社の近くに住んでいて、徒歩か自転車で通勤しているんです。いわゆる大企業的なところに勤めている知人の話なども聞いていたんですが、仕事の上でも、どうしても「面倒なことが多そうだな」と感じてしまって。そういったところに入ろうという気にはならなかったですね。
idesaku：当時、プロダクトが JavaScript 回りにだいぶ課題を抱えていて、移って早々にそれをかなり厳しく指摘したという話を聞いたことがあるんですが。
山本：「これは滅ぼしたほうがいい！」とか「殲滅する！」とか、わりと過激な表現で指摘していたというのは事実ですね（笑）。
idesaku：（笑）それで、チームの方とケンカになったりしませんでした？
山本：そういうケースもなかったわけではありませんが、freee という会社は全体としてプロダクト指向が非常に強いんです。「良いと思ったものを早くリリースして、さらに良くしていこう」という方向性は、全スタッフで一致しています。新たな技術の導入や修正についてもこの方向性で進めているので、最終的に決裂するようなことはほとんどないです。
idesaku：そういえば、1年ほど前に、風のうわさで「freee は、Backbone.js で作っているらしいぞ」と聞きました。
山本：今でも基本はそうなのですが、最近だいぶ状況が変わってきています。React が入ってきたり、私が現在関わっている給与計算では、Vue.js があったりとか、会社全体で見るとたくさんのフレームワークが混在していますね。
idesaku：そうした新たなものを入れようと思うきっかけはなんなのでしょう。
山本：「将来、こういう環境を作っておかないと困るよね」みたいなビジョンが見えたときですね。導入することで「プロダクトが良くなる」か「開発効率が上がるか」のいずれかを目指すことが前提です。開発効率が上がればそれだけ新しいプロダクトを作れるわけです。
idesaku：たしか、freee ではサーバー側を Rails で作っていたと思うのですが、今回のようにフロント側が「React 入れるゼー！」とか盛り上がっていると、サーバー側から「でもアセットパイプラインがー」みたいな声が出てぶつかるとかはありませんでしたか。
山本：うちの場合は、製品やターゲットとしているユーザーごとにチームで機能を作っていますが、それぞれのエンジニアが「フロント」か「サーバー」かといった分け方はしていないですね。もちろん、それぞれに得意不得意はあります。例えば、私はフロントエンド開発が得意ですが、高いパフォーマンスを出すための SQL設計なんかは苦手です。ですので、最終的なブラッシュアップは得意な人にお願いするんですが、開発の段階では自分で SQL を書いたりもします。逆に、DB のスペシャリストがフロントを書くという作業も普通にやっています。お互いに他の人が専門の分野についてもなんとなくは理解しているんです。
idesaku：つまり、何か新しいことをしたい場合に、一方的にそれを主張するんじゃなくて「落としどころ」が分かった上で進められるわけですね。
山本：そんな感じでしょうか。さっきの例だと「React 入れるゼー！」と推進している人が、バックエンドを見ている人と相談しながら、「アセットパイプラインについては、こういうふうにすればできるんじゃないか」とアイデアまで考えておいて、調整するといったことができる環境なんですよ。
idesaku：React に Vue.js に Rails と、どれも精力的に開発が続けられていて、頻繁にバージョンアップするプロダクトだと思いますが、追従するのは大変じゃありませんか？
山本：大変ですね～。実は Vue.js にもそういうところがあって、今ちょっと困ってます（笑）。でも、方針として、上げられるものはなるべく早く上げて追従していこうとは思っています。
idesaku：バージョンアップしたら動かなくなった！といった時って、パッチ投げたりするんですか？
山本：まずは「こんな問題が出てます」みたいなことを Slack に書いておくんですけど、そうすると CTO から「プルリクチャンス！」とか返ってきたりして…。
idesaku：「それ、君が書けるよ！」と（笑）。
山本：出せるときには出そうとは思ってるんですけどね。なかなか機会がないんですけれど。
idesaku：先ほど、開発効率が上がればそれだけ新しいプロダクトを作れる、というお話がありましたが、実際のところ開発スピードはいかがですか。
山本：「スモールスタートでいいので、とにかく早くリリースする」というスタイルなので、先週「あれ作ろうぜ」と話していた機能が今週出ているなんていうこともよくありますよ。そうしてリリースした機能を、後でフィードバックを得ながら改善していきます。
idesaku：そうなると、自然と頻繁にリリースすることになりますよね。
山本：はい、うちは毎日デプロイしていています。1日に複数回デプロイするのも普通です。
idesaku：そのたびにテストして品質を保つのは大変そうですね。自動テストでカバーできているということでしょうか。
山本：うちには QA部隊があって、彼らがブラウザを Selenium でオートパイロットして、IE、Firefox、Chrome といったブラウザごとに動作確認を行い、全画面の品質を担保するといった形でやっています。でも、新機能のテストだと Selenium側の準備が間に合わないことがあるので、手作業で対応することもありますね。
idesaku：小さくリリースして改善を繰り返す、といった手法では、世の中では「アジャイルプロセス」などが注目されていますけれど、freee では、なにかそうした決まったやり方は取り入れているんですか？
山本：最近は自分のチームが、しっかり「スクラム開発」をやろうとしています。これまでは、あまり型にこだわらずにエッセンスだけ取り入れていたのですが、適当にやっていたら担当者がやるべき毎日のタスクが増えすぎてしまったんです。そんなことがあって、スケジューリングやタスクの優先順位付けなどを、スクラムの基本に則って、しっかりやってみようということになりました。
idesaku：優先順位付けというと、やりたいこと、実装したい機能というのは、本当に数多くあると思うんですが、どのように決定しているのでしょうか。
山本：freee を現在使っていらっしゃらない方が「これがあれば freee を使える、使いたい」と思ってくれそうな機能が優先されますね。製品ごとの開発チームがあって、ユーザーや市場の声を聞きながら、それぞれのチーム内で計画を定期的に見なおして優先順位を決めていっています。アンケートやログデータなどの分析を通じた改善のための仮説をチームごとに立てていますし、さらに営業スタッフはお客様から直接聞いた情報を持っていたりしますので、それらを現場で総合して優先順位をつけていくという感じです。
idesaku：山本さんは、freee に入社して約2年ですよね。若い会社ですし、ポジションとしてはもう「中堅」と言っていい立場なんじゃないですか。
山本：いやぁ、もう「古株」のほうですね。自分は27歳なんですけれど、会社ではすでに「老害」とか呼ばれます。原因は、社内で2000年代初頭のインターネットの話とか、古い話をしたがるからですが（笑）。エンジニアとしては、一応最年少なんですよ。現在の中心は30代ですね。
idesaku：山本さん自身が、採用に何らかの形で関わったりすることはあるんですか。
山本：「面白い人だから会ってみて」と声がかかることはありますね。結果的に、エンジニアは私より少し上の30代の人が中心になっていますが、ビジネス職などでは「伸びしろ」を評価して若い人をとるということも積極的にやっているようです。もちろん、技術職であっても「伸びしろ」が評価されて採用というケースもありますよ。
idesaku：プロダクトを作っていくにあたって感じている課題はありますか。
山本：現在のスピード感でやっていると、結果的に妥協するような形で残ってしまう「技術的負債」のようなものは、どうしても出てきてしまいます。また、先ほど話したようなReactをこれからどうやって使っていこうとか、そもそも「本当に今、Railsなのか？」とか、本当にいろいろな課題があります。
idesaku：技術的負債の返却にまとまった時間を確保するのは難しいですよね。便利な新機能のようにメリットがわかりやすく見えるわけではないので。
山本：そうなると、まずはできるところから、小規模に入れていって、それで生産性が上がることを証明しながら、徐々に適用範囲を広げていくという形で進めていくことになりますね。
idesaku：環境についても、「スモールスタートで改善を続ける」というスタイルで作っていくわけですね。
山本：そうですね。「全面リニューアル！」みたいに大規模に変更してしまうと、それまで顕在化していなかったバグが出てきたようなときに、壊滅的なダメージを受けてしまいますよね。だから普通であればテスト期間を長くとるわけですが、そのやり方は freee という会社には合わないんですよね。期間も資金も限られた中で、会社がうまく回るように、少しでも現状を良くしようという思いで作業を続けています。
idesaku：この対談企画はリレー形式で続けていきたいと思っていまして、ぜひ次に話を聞いてみると面白そうな人を紹介していただけると嬉しいのですが。
山本：同じフロントエンドエンジニアで同い年の Incrementsの竹馬氏（@mizchi）はどうでしょう。たまに飲みに行ったりしている間柄ですが、僕よりも過激な発言が多くて楽しい方ですよ（笑）
idesaku：ご紹介ありがとうございます。では次回は竹馬氏のインタビューをお届けしたいと思います。今日は長い時間、楽しいお話をありがとうございました！
執筆：高橋美津
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。
