ベンチャーはやってみなければわからないことだらけ。まずはプロダクトを磨き、自分たちらしいやり方を発見しよう｜freee CTO 横路氏｜TECH TEAM BUILDERS #1

ソフトウェアビジネスで起業する際、サービス開発の中核を担うエンジニアの確保に悩むベンチャーは少なくありません。大企業でさえエンジニア採用に苦戦するなかで、無名のベンチャーはいかにしてエンジニアを集め、組織に定着させるべきなのでしょうか。

新連載となる『技術トップが語る。エンジニア組織をスケールさせるためのヒント』では、シード期、アーリー期に直面しがちな困難を乗り越え、成長を成し遂げた著名企業の技術トップに解決策のヒントやアドバイスを聞いていきます。第1回は中小企業から絶大な支持を集めるクラウド会計ソフト「freee」の創業エンジニアであり、現在CTOを務める横路隆氏の登場です。

▶︎採用担当者なら知っておきたいマーケティング知識を公開中｜資料を無料ダウンロードする

freee株式会社
CTO　横路 隆氏
慶應義塾大学大学院理工学研究科修了。学生時代よりビジネス向けシステム開発に携わる。新卒でソニーに入社。デジタルイメージング事業領域でさまざまなソフトウェア開発に従事後、2012年freee株式会社の創業に参画。サービス開発に携わる傍ら、エンジニアリング組織の拡大やソフトウェア開発基盤の整備に尽力。現在はCTOとして同社の技術戦略を主導している。

最初にマネージャーを置いたのはエンジニアが30名になってから

——本日はよろしくお願いします。最初に、現在のサービス開発・運用体制について教えてください。

エンジニアが所属する組織は、既存サービスである会計、人事・労務アプリケーションを開発する部門、新規プロダクトを開発する部門、ソフトウェア開発を支える共通基盤を構築する部門の3本部体制を採っています。これらのほかにも、セキュリティ監視や問題の解決にあたるCSIRT（Computer Security Incident Response Team）、営業やマーケティングといった社内の業務プロセスをITで改善する業務ハックチームに所属するエンジニアもいます。freeeのエンジニア部門は、プロダクトを貫く横串組で、各機能はプロダクト戦略部門に所属するプロダクトマネージャー、UXデザイナーを交えた5名程度のユニットで開発するのが基本です。

——なるほど。ではまず、現状の組織体制に落ち着かれるまでの開発体制の変遷を振り返っていただけますか？

はい。2012年の創業直後は、主にCEOの佐々木大輔と私で開発をしていましたが、3カ月後に現在VPoEとしてエンジニアをまとめている平栗遵宜が入社し、3人で開発にあたるようになりました。その後、本格的にエンジニア採用を始めたのは、2013年3月にfreeeをリリースしてから。当時は目新しかったB2B向けのクラウドサービスということでメディアやイベントなどで採り上げられる機会が多かったこともあって、2013年から14年にかけて私を含めて10名くらいの体制になりました。

——創業当初からエンジニア採用は順調だったのですね。

どこかでわれわれの存在を知りアプローチしてくださるエンジニアが多かったのですが、それだけでエンジニアの採用ニーズが満たせたわけではありません。WantedlyやGreenなどエンジニアに強い採用媒体で募集をかけたり、知人に声をかけたりして、週末だけ手伝ってもらえるエンジニアにもお願いするなどして開発リソースを集めていました。

——マネジメントについてはいかがですか？

freeeのビジョンである、中小企業をテクノロジーの力で支援するというビジョンに強く共感してくださる、自走型のエンジニアに加わってもらっていたので、エンジニアが30名を超えた2015年までは、組織内にミドルマネージャーは置いてませんでした。

——このときはどのようなマネジメント体制を？

まずは私が開発基盤チームのマネジメント、平栗がアプリケーション開発チームのマネジメントを担当することにしたのですが、エンジニアがどんどん増えていたので、なかなか行き届いたマネジメントが難しい状態でした。いま思えばマネージャーとメンバーの最適な比率やマネジメント手法を模索し始めた時代といえるかもしれません。

——50名を超えた後の組織体制はいかがでしたか？

2016年頃にエンジニアが50名規模になったあたりで、大手IT企業で一定の経験を積んだエンジニアが応募してくださるようになり、ミドルマネジメントを担う層を厚くすることができました。このほかにも採用チームを立ち上げたり、評価制度を整えたりといった取り組みに力を割ける状況になったのもこの頃のことです。17年からは新卒採用も開始し、それ以降は毎年数十名単位でエンジニアが増え、いまでは外部スタッフを含めて数百名規模の体制で開発にあたっています。

カルチャーを壊さず開発スピードを上げるには？

——創業から8年でかなり大規模なエンジニア組織になったんですね。

ええ。この間、会計に加えて、人事・労務サービスのほか、会社設立や運営に必要なさまざまなサービスをリリースしましたから、エンジニアが関与するドメインは創業時とは比べものにならないくらい大きくなっています。そのため、大規模なチームを抱えつつもさらなるプロダクト開発を加速させるために、2018年頃から本格的に業務委託や派遣、副業エンジニアの力を借りて開発にあたるようになりました。

——なぜ、外部スタッフを登用されるようになったのですか？

プロダクトが増え、かつ成熟が進んでいくと、既存プロダクトのメンテナンスに多くの工数がかかるようになります。利用してくださるお客様も個人から数百名程度の企業まで多様化が進み、さまざまなニーズにお応えしていく必要が出てきます。ここから先も成長を加速しようと思うと、どうしても開発者の数を増やすことは不可欠です。成長のスピードとプロダクトの質を求めた結果、正社員以外のスタッフを戦力として活用すべきという結論になりました。

——正社員エンジニアと外部スタッフのエンジニアで役割をわけていらっしゃいますか？

それぞれの能力や希望に合わせた仕事をお願いしています。アプリケーション開発チームの一員として特定の機能開発を丸ごとお任せすることもあれば、既存サービスのリファクタリングやメンテナンスをお願いすることもあり、お任せする仕事はさまざまです。「外部スタッフにはこの開発にかかわらせない」といった具体的な線引きはありません。

——エンジニアに限らずベンチャーでの採用は、よく「カルチャーフィットが大事」だといわれます。横路さんはどう思われますか？

そうですね。おっしゃるように自社の理念やプロダクトが目指すビジョンに共感してくださるエンジニアを採用し、組織に定着させるべきなのは間違いないと思います。

——外部スタッフの比率が高まると、立場や考え方が異なるエンジニアをチームに招き入れることになります。一枚岩だった開発カルチャーが変質する危険はありませんか？

当社も一時期、マネジメントの手がかからず、自ら仕事を見つけて動ける自走型のエンジニアでなければと考え、採用にこだわっていた時期がありました。しかしマネジメント機能を確立すれば、多様な働き方を志向するエンジニアや、ポテンシャルが見込めそうなエンジニアを許容することができます。もしも最初から外部スタッフの力を見込んでプロダクト開発に集中するのであれば、ごく初期の段階からマネジメント機能を整えるべきでしょうね。それがカルチャーを壊さず開発スピードを上げる秘訣だと思います。

——特定のやり方にこだわらなくても理想的な環境は作れるということですね。

そうです。理念、事業のビジョンや開発文化に共感してくださるエンジニアは必要不可欠ですし、理念を体現してくれるエンジニアを核とした組織づくりは重要です。しかし、プロダクトをリリースしてからでも、修正はできます。とくにシード期、アーリー期のベンチャーが、特定の手法にこだわり過ぎるのは考えものだと思いますね。

——御社がシード期、アーリー期にあった当時、開発プロセスやエンジニア採用、組織づくりの面で参考にされた「お手本」はありましたか？

そうですね。いまでこそ日本国内にもB2B向けのSaaSが多くありますが、われわれが創業した当時は身近な国内にベンチマークすべき先行事例が見当りませんでした。基本的には模索しながらの手探りでしたが、組織が大きくなるにつれ意識的にアメリカ西海岸のSaaS企業のトレンドは意識的に吸収するようにしていましたね。たとえば、実際に当社のマネージャー陣がアメリカで開かれるSaaS関連のカンファレンスに参加して、得た知見を持ち帰り、社内で試すような取り組みは積極的に行っていました。

——具体的にどういった知見を吸収されたのですか？

たとえば「エンジニア組織がどの程度の規模になったら基盤開発にどれくらいの予算とリソースを割くべきか」、「売上に対してどの程度の採用予算が適切か」といった、具体的な取り組みの目安になるベストプラクティスです。

——なるほど。freeeさんではアメリカ西海岸直輸入のベストプラクティスを活用されていたのですね。

ただ大事なのは、こうしたベストプラクティスはあくまでそれを生み出した人たちのものであり、過去のものだということ。そのまま真似てもうまくいかないことがほとんどです。他社のベストプラクティスを知ることは大切ですし、試してみるのも大事ですが、それを導入したからといって成功するとは限りません。自分たちが置かれている環境に合っているかどうか、冷静に判断すべきです。現在では、ユーザに価値を届ける独自のプロダクトで大きく成長するスタートアップが増えるにつれ、再現性の高いプラクティスが世の中に知られるようになりました。しかし、あくまでも本筋はマネージャー、メンバーが知恵を出し合い、頭をひねって、自分たちのベストプラクティスを見つけ出すことだと思います。

開発のハードルが下がっているからこそ、プロダクトや理念を大切にしてほしい

——スタートアップ期、アーリー期のエンジニア採用でとくに注意すべき点があれば教えてください。

弊社の場合、リファラルなど比較的エンジニアメンバーが採用に対して協力的でした。しかし、事業拡大の速度を考慮し、優秀なエンジニアには採用媒体やスカウトを活用して積極的にアプローチしていました。応募されるのを待っているだけでは、事業成長を担保するだけの採用枠を満たせなかったからです。いまはベンチャーにも使いやすいさまざまな採用ツールがありますよね。freeeでもWantedlyのスカウトメール機能がサービスに実装されたころからずっと使い続けていますが、こうした採用ツールの機能やメディアへの露出、イベント登壇などの機会を通して、自分たちのビジネスはもちろん、大切にしている価値観、ミッション、ビジョンを積極的に伝えていくべきだと思います。

——御社がスタートアップ期、アーリー期にあった当時、採用面接などで大切にされていたことがあれば教えてください。

そうですね。もちろん当時もいまもその方にどの程度の技術力があるかは見ますし、われわれが目指しているビジョンに共感していただけるかというところも見ていましたが、創業直後はとくにエアポートテストを重視していました。

——エアポートテスト？

はい。エアポートテストというのは「飛行機が飛ばず、ホテルにも泊まれず、一晩空港でこの人と過ごしても苦にならないか」という基準で相手を見極めるテストです。シード期、アーリー期はとくに、何日も缶詰になってプロダクトづくりやトラブル対応に励むことになるので、人間的に合うかどうか、一緒にいてお互いに苦痛を感じないかという面についても採用基準のひとつとして重視していました。

——なるほど。

もっとベーシックなことで申し上げれば、応募者の方の要望を聞いた後、その方がfreeeに来てどのような活躍ができるかイメージして率直に伝えるようにしていたというのもあります。「うちならきっとこんなことが実現できると思うので、一緒に実現させませんか」と、なるべく具体的にお話しするようにしていました。われわれがエンジニアを採用するのは欠員補充ではなく事業の成長のため。「個人の成長なくして会社は成長しない」というのはfreeeの信念ですし、それは事業がどれだけ拡大し、組織の規模が大きくなっても変わることはありません。ですからこの点は変わらず重視していくつもりです。

——現在の組織について課題はありますか？

これは規模の大小や事業ステージにかかわらず、多くのみなさんが感じていることだと思いますが、コロナ禍でテレワークが当たり前になりつつあるなか、どうやってチーム内で信頼関係を醸成していくかは、われわれにとっても大きな課題です。今年の春に入社してから、数回しか対面できていないメンバーも数多くいます。こんな状況ではエンジニア同士の親睦を深めるのに役立っていた社内LT大会は当分開けそうにありません。エンジニアが孤立感や疎外感にさいなまれることがないよう、リアルイベントに代わる別の取り組みや、だれに何を聞けばいいかすぐにわかるような新たなコミュニケーションの仕組みを作らなければと思っています。

——最後にシード期、アーリー期にあるベンチャーのみなさんにメッセージをお願いできますか？

みなさんにお伝えしたいのは、ソフトウェア開発のハードルが下がっている時代からこそ、プロダクトをしっかりとつくりきり、自分たちの価値観、ミッション、ビジョンを世の中に対して的確に表現してほしいということですね。プロダクトドリブンな組織には、価値観を共有するエンジニアが集まるもの。そのためにもまずはがんばっていいプロダクトを生み出して、世に問うてほしいと思います。

（取材・執筆協力／武田敏則）

▼あわせてこちらの記事もご覧ください

「エンジニア採用における6つの課題と解決策を解説」
https://www.wantedly.com/hiringeek/recruit/recruit_issue

「エンジニア採用が難しい3つの理由」
https://www.wantedly.com/hiringeek/recruit/engineer_recruiting_top