略歴
島根県松江市出身。慶應義塾大学大学院理工学研究科修了。学生時代より大手企業向けシステムの開発に携わり、卒業後はソニーに入社。エンジニアとして活躍。2012年に佐々木大輔氏とともにfreee株式会社（旧CFO株式会社）を設立。趣味はピアノ、オルガン、シンセサイザーなどのキーボード演奏。
freee株式会社 公式サイトはこちら → http://www.freee.co.jp/
Q：横路さんのご経歴をお聞かせ下さい。
高校生の頃からコンピューター音楽が好きで、クラブミュージックなどに思いをはせていました。
その思いが高じてコンピューターで音楽を作り始めるようになり、音声処理や音声認識などの分野に進みたいという気持ちが芽生えてきて、情報系の大学に進学しようと決めました。その後、コンピュータサイエンスを専攻することにしたので、結局は音声系の道には進まなかったのですが。
ですからプログラミングを始めたのは大学時代からです。特に3年生のときに入った研究室ではかなり鍛えられました。また、研究室の先輩が代々受け継いでいたアルバイト先の存在も大きかったです。そこは社長とエンジニア1人の小さな会社なのですが、地方銀行向けのシステムや、Eラーニングのシステムを作ったり、大企業にもソフトウェアを納めたりしていました。スキルも鍛えられましたし、そういった仕事に携わる中で、大企業でも、バックオフィスのオペレーションの部分などはまだまだ進化の余地があるなと感じました。また、もともと技術一本というよりは、技術を使って何か社会に対して大きな価値を生み出したいと考えていたので、その経験が今のfreeeにつながっています。
Q：学生時代の経験がfreee開発の背景になっているんですね。
そうですね。もう一つの背景としては、実家が自営業をやっていたことも大きいです。
たとえば実家はお菓子屋さんをやっているのですが、お菓子屋さんは常にお客さんにおいしいお菓子を提供したいという気持ちでお店をやっています。でも、ビジネスとして成立させるためには当然その気持ちだけではやっていけません。在庫管理や経理など、そういったバックオフィス業務にも多くの手間と時間を割いているのです。私は両親がそれで苦労しているのを常に見ながら育ったんです。
学生の頃は実家に帰ると、ネットワークの設定をしたり、家の在庫管理や発注管理のための表をエクセルで作ったりしていました。これがなかなか大変な作業なのですが、世の中の人達は一体、皆どうしているんだろうと。そこで調べてみたところ、日本の労働人口の半分以上がスモールビジネスに携わっていることがわかりました。国内の企業に至っては8～9割が小規模法人ですから、やはりバックオフィス業務で困っている人が多いんだろうなと感じました。そんな時に佐々木（freee株式会社 CEO）に出会ったんです。
Q：起業に至るまでにはどのような経緯があったんですか？
彼もまた、小さい会社でのCFOの経験や、Googleでスモールビジネス向けのマーケットを見ていた経験から、スモールビジネスのバックオフィスを楽にするシステムの需要を感じていたんですね。そこで意気投合して、一緒に簡単なプロトタイプを作ってみて、「いけそうだね」ということで起業を決めました。
彼はもともとデータサイエンティストで、Webアプリの開発経験はなかったんですが、1ヶ月くらい根をつめて勉強して。起業してからパブリックローンチまでは、完全にエンジニアをやっていましたね。最初は2人だけしかいませんでしたから、自分達でエンジニアもやってしまうのがプロダクトのための最短距離でした。「サービスを創ること」「サービスをよくすること」にとことんこだわるプロダクト志向は、当社の理念でもあります。
Q: 御社のビジョンをお聞かせいただけますか。
当社のビジョンは、スモールビジネスのバックオフィス業務を全部自動化することで、彼らが本業だけに集中できるようにするところにあります。ですから、バックオフィス業務にあたる業務をどんどん自動化していくことを狙っています。
バックオフィス業務の中でいちばん大変なのはやはり会計決算業務なので、まずは会計ソフトを作り、次に大変だと思われる給与計算も自動化したところです。そのようにしてプロダクトの横展開をしていくのが当面の目標です。業界ごとに会計、業務の違いにも対応していく予定です。長期的には、海外展開も考えています。
Q: 2人で立ち上げた頃から比べ、エンジニアの人数も増えるにつれて、チーム編成も必要になると思いますが、どのようにされていますか？
2人で始めてから少しずつ人数は増えていきましたが、しばらくはチームを分けずに、朝から深夜までとにかく一丸となって開発していました。進行に関しても、それぞれ自分の強い部分に関して、朝イチで「俺はここをやる」と宣言して、開発していくといった感じで。2013年3月に正式リリースをした後、エンジニアもどんどん増やして、10人を超えたところで、チームを分けることにしました。
10人が同時に等しく開発していくと、プロダクト自体がどんどん大きくなりますね。そうすると、一人一人が全体を把握するための負担もどんどん大きくなってくるのです。それが今後、サービスの成長にとっても負担になってくるのではと思いました。オーナーを分ける、役割を分ける、という主旨でチーム分けを行いました。ファンクションごとにチームを分け、モバイルアプリチーム、会計チーム、インフラ・基盤チーム、といった感じです。
「チーム」というのは何か課題があったときに、その課題を解決するために集まるものであって、動的なものであると思っていますので、チーム編成も3ヶ月に1回ほどのサイクルで見直しています。チームごとの進行に関しては、チームリーダーを一人立て、そのリーダーがチームとしての課題をリストアップして、チームの中でそれらをタスク分解して、チーム全体として3ヶ月の中でこれだけやりますよ、というのを決めます。そして、それがうまく走れているかを定期的にチェックし、社内全体でも共有し合う、というやり方をしています。
Q: 社内のコミュニケーションや情報共有で工夫されていることはありますか？
コミュニケーションに関しては特に注力しています。コミュニケーションを円滑にすることは、「サービスを作るスピードを保つ」という課題に対する解決方法の一つだからです。たとえば何かモノを作ったり、プロジェクトを進めていくうえで、人が増えれば増えるほど生産性が上がるかというとそうではないですよね。それは、コミュニケーションコストがそこに取られているから、というのが原因の一つだと思うんです。ですから、それを解決するための手段として、コミュニケーションを円滑にしたいですし、結局は「サービスをよくすること」にもつながるからです。
ツールとしては、Qiita:Team（キータチーム）を使っています。「ここ間違ってたんでこうしました」「これって何でしたっけ？」といった気軽な会話もそこでできるようにして、同時に記録も残るようにしています。色々なバックグラウンドを持ったエンジニアを日々採用していますし、途中から入ったメンバーにも共有しておきたい情報がたくさんあります。今までいた人しか知らない知識をなるべく減らしていきたいですし、新しく入ってきた人が負い目を感じないで気軽に発信していける環境を作れるように心がけています。
Q： 「サービスをよくする」ために取り組まれていることは何ですか？
最近、「カスタマーサポート留学制度」という試みを始めました。エンジニアが一人で丸一日、カスタマーサポートの部署に行き、そこで実際にお客様サポートをするんです。お客様からのメールでの問い合わせに対して、現象を確認したり、直接メールを返信したりします。
通常のカスタマーサポートでは、Asanaというチケット管理ツールを使って、お問い合わせに対応しています。プロダクトに何か問題があれば、そこでサポートチームがチケットをきって、エンジニアが「これは自分のバグだ」と確認して、バグを直す。そしてチケットがクローズされると、サポートがお客様に「直りましたよ」と報告する流れです。でも、このチケット上にはお客様先で起こっている現象しか書いていないので、お客様の生の声や温度感が伝わってこないことも多いんです。実はすごく怒っていたりだとか、本当に困っていたりだとか。それも含めて体験して欲しいと思って作った制度です。
そうすると、やはり開発側にとっても新しい発見がかなりあるんです。普段エンジニアとして使う言葉と、サポート側の人間として使う言葉は違ったりしますよね。ユーザーの目線になって説明していると、ユーザーが誤解しやすい部分もよくわかります。「これってどういう意味ですか？」「ここが使いにくいんですが」と細かい部分も吸い上げられたりします。
また、会計ソフトって難しいので、時々意図の汲み取りにくい問い合わせが来ることもあります。僕らは当然、会計の知識をある程度身につけてから開発しているのですが、会計の知識がないユーザーにとっては実はこの部分ってすごく難しいんだな、とか。そういう気づきもあります。
プロダクトありきのサービスとはいえ、やっぱりエンジニアって、ユーザーの見えないサービスを作りがちなんです。僕らは、そういった細かいところも含めて開発を進めることで、よりよいサービスをつくっていきたいです。
Q: エンジニアの採用基準は何ですか？面接ではどんなところを見ますか？
採用基準は色々あります。
地頭が良い人。論理的な思考ができる人。そして、「よいサービスとは何か」が共有できて、建設的な議論ができる人かどうか、を見ています。
エンジニアとしての経験がある人の場合は、自分はこの部分が得意だから、それをfreeeのサービスの中でこんな風に活かしたい、と明確に持っている人がいいです。経験の浅い人、または若い人の場合は、モチベーションとポテンシャルの高さを評価します。プログラミング自体に興味はないけれど、あることを達成するためにプログラミングが効果的だと思って頑張ってマスターして達成した人、などもいいですし、何か情熱を持ってサークルを作った、とかでもいいと思います。常に「自分の期待値を超えてきた人」に期待しますね。
一口にエンジニアといっても色んな種類の人がいて、ある特定の技術を極めたいというエンジニアもいますが、freeeは「サービスを創る」ことにとことんこだわるエンジニアの集団でありたいと思っています。その一人として、一緒に働きたいかどうか、を総合的に判断しています。
Q: 採用面接では実際にどんな質問をするんですか？
たとえば、「Webサービスってどうやって動いているんですかね」といった曖昧な質問をよくします。自分のPCのブラウザからWebサーバーに行って返ってくるまでに何が起こっているのか、あなたの言葉で説明してください、と。
すると、それぞれ自分でスコープをきって話し始めるんですね。Webサービスって色んなレイヤーで、本当に色んな技術が組み合わさって動いているわけですが、その中でもその人がどういうところに詳しいのか、どういうサービスをやってきたのかがわかるんです。そして、その人の強いところに関して、一緒に議論をしていく、というパターンをとっています。
Webがどうやって動いているのか、コンピューターがどうやって動いているのか、など普遍的な仕組みに関してはとても重要なので、ここは社内メンバーにもきちんと知っておいて欲しいと思う部分でもありますね。
Q： 若手のエンジニアの方々に向けてアドバイスをお願いします。
技術を覚えるにしても、何かを作って覚えるというのが一番だと思うのですが、作って覚えるためのその「何か作る」をなかなか見つけられない人も多いです。サンプルアプリみたいなものや、Twitterのボットを作って満足してしまう人も多いと思います。でも、せっかく作るんだったら、自分が本当につくりたいと思うサービスを早めに設定して、それを作って欲しいと思いますね。それは自分がオリジナルで考えついたものでも、そうでなくても全然構いません。
また、僕自身がそうなのですが、自分が成長して世の中に価値を出していきたい、という強い思いだけでなく、自分の環境をコントロールする力も必要だと思っています。人間ってやはり環境に左右されやすいので。志の高い人と一緒に働くと自分の志も自然と高くなったりしますよね。あとは自分が何かおかしいなと思うことがあったときに、自分がその環境を変えていくか、または違う環境に飛び込んでいくかしないと思うんです。何かおかしいと思いながらその環境に居続ける意味はないと思うので。最初から自分で環境を作る必要はないのですが、自分は今ここにいていいのか、というのは常に考えて欲しいなと思います。
技術そのものに興味がある人はオープンソースコミュニティやアカデミックの世界、ぜひ飛び込んでみていただきたいです。技術という自分の強みを活かして社会にインパクトを与えたいと考えている人は、ぜひスタートアップで、どんどんチャレンジと失敗を積み重ねて実績を作っていって欲しいですね。
