不動産仲介特化型のコミュニケーションクラウド「Facilo」を開発するCTOの梅林泰孝さん。これまでGoogle, サイバーエージェント、SmartNewsでソフトウェアエンジニアとして働き、アメリカに移住。幅広い規模のシステム開発に携わってきました。

Faciloでは「運用のしやすさと人とのスケールを考えながら、開発の効率化には積極的に投資したい」と語る梅林さんに、共同創業者の市川紘さんと共にFaciloを立ち上げた経緯や、自身のこれまでのキャリア、開発の背景にある思想、組織づくりにおける価値観などについてお話を伺いました。

大規模なシステム開発、「プロダクトを大きくする」経験が基礎に

ーーまず、これまでのキャリアについて教えていただけますか？

大学時代は機械工学科でエンジンの設計について学んでいました。IT企業でのインターンを機にソフトウェアエンジニアに関心を持ち、大学院からコンピュータサイエンスを研究しました。

新卒でGoogleに入社することになり、検索結果の品質改善チームに所属。スパムサイトの分析やトレンドの調査など、検索結果を良くするという業務を担当していました。

ーー大規模なシステムに関わってきたのですね。

そうですね。Googleではチャレンジングな経験がたくさんできたのですが、もう少し自分の裁量が大きい組織でキャリアを築きたいと思い、転職してサイバーエージェントに移りました。

そこでは広告配信システム開発チームに入り、「AirTrack」というシステムの開発責任者として約4年間働きました。

1秒間に何回外部からのアクセスを処理するかという「QPS（クエリ毎秒）」でいうと、900や1000を超えるようなシステムの立ち上げを経験できて、ソフトウェアエンジニアとして学ぶことが多かったです。この時の開発経験が、今の自分の基礎になっていると思います。

当時、サイバーエージェントでは広告プロダクト組織のアドテクスタジオができたばかりでした。自分と同じようなタイミングで何十人も入社したり、別の広告システムがいくつも立ち上げられていて、「プロダクトを大きくする」というのを肌で感じることができたのも大きな経験だったと思います。

まずはエンジニアとして成長するためにアメリカへ

ーー将来的に起業したいという思いが当時からあったのでしょうか。

その頃はIT系スタートアップの創業ブームのような時期でもありました。成功している人を横目に見ていたのもあり、漠然と「いつか自分で会社をやってみたい」という思いが芽生えはじめていました。

ただ、まずはソフトウェアエンジニアとして成長したいという気持ちがあったので、そのためにはアメリカで仕事をするのが近道ではないかと思い、アメリカに進出していたSmartNewsに転職しました。

スマニューでは、広告配信に加えてニュース配信のシステム開発にも携わりました。アメリカに異動したときは、まだエンジニアが数人だけという状況で、週に何人も採用面接をしながら開発もして、組織作りの楽しさと難しさをリアルに体感できた期間でした。

「実績と人柄」への信頼。二つ返事で共同創業者に

ーーベイエリアで働くなかで、Facilo共同創業者となる市川さんに出会うんですね。

市川さんのことは普段「紘さん」と呼んでるのですが、紘さんと知り合ったのはベイエリアの日本人コミュニティでのBBQに参加したのがきっかけでした。お互いの子どもどうしを遊ばせたり、公園に行ったりするなかで仲良くなっていったんです。

あるとき、紘さんから構想しているビジネスについて話をされて、「一緒に会社をやらないか」と。二つ返事で引き受けました。

『起業家はどこで選択を誤るのか』という有名な本で、創業メンバーは「自分とは異なる属性が良い」と書かれていたのを思い出しました。自分はエンジニアで、もし起業するなら一番欲しいパートナーとしては営業の人だと思っていたので、紘さんとは属性としても相性が良いと思ったんです。

ーー市川さんという「人」に対する信頼も大きかったんですね。

もちろん紘さんのリクルート時代の実績や、ずっと不動産業界に携わってきたこと、不動産テック領域でかなりプロフェッショナルであることを知っていたのは前提です。

その上で、「人柄が良いな」と思ったんです。エンジニア畑と営業畑でコミュニケーションの仕方も違ったりする。でも、紘さんはゴリっと相手の懐に入っていくというより、相手に合わせて柔軟にコミュニケーションをとる人なので、居心地が良い。それもあって、紘さんから誘われてすぐ「一緒に働きたい」と思いました。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Photo in San Francisco

ユーザーと近い「BtoB」プロダクト開発の魅力

ーーこれまでは「BtoC」のプロダクトに携わることが多かったと思うのですが、Faciloは「BtoB」になりますか？

そうですね。自分にとってははじめてのBtoBのプロダクト開発になります。

今まで関わってきたプロダクトを振り返ると、BtoCでは、多くのユーザーがアクセスしたり、スケールが大きくなる時に、バックエンドエンジニアの技術的チャレンジが起こると思います。アーキテクチャやコードを見直す必要性などの課題が発生する時のチャレンジが、楽しいし成長できる機会だと思うんです。

一般的に、BtoBの場合はサイズがすごく大きいわけではない一方で、ユーザーのフィードバックが近いのではないかと思います。

Faciloを開発する中でも、クライアントが実際にプロダクトを使ってくれて、すぐ「こういう機能が欲しかったんだよね」「次はもっとこういう機能が欲しい」など、リアルタイムにフィードバックをもらえて、すぐにまた開発に着手できたりする。現場のリアルなニーズを汲み取って、プロダクトに反映するサイクルが速いです。

自分たちの作ったものによって、現場の人が本当に喜んでくれているかをかなり近い場所で、肌で感じられるのが面白いなと思っています。

「運用のしやすさと、人とのスケール」Facilo開発の“思想”

ーー「Facilo」はどのように開発されているんですか？

創業メンバーはJavaエンジニアが多いのですが、僕らのシステムは「Ruby on Rails」というフレームワークを使っています。

いくつもある選択肢のなかでどういう技術で開発するか、いくつも試してみて、Ruby on Railsに決めました。そこに至った思想としては、まず「管理画面の作りやすさ」と「効率性」があります。

Railsはフレームワーク自体の規約がとても強く、誰が書いても似たようなコードになりやすいと思います。ある意味、柔軟性はなくなるけれど、フルリモートの組織体制を想定したときに、大切にしたい「運用のしやすさと、人とのスケール」という価値観に合うと思いました。

サービス自体が1000台を超えるようなサーバーのオーケストレーションの世界観ではないなかで、サーバーやシステムの細かい最適化より、現実的なシステムと人とのスケールを考えると、この開発言語が良いのではと思ったんです。

設計する上で大事なのは、オンライン処理かオフライン処理なのか、プッシュ型かプル型なのか、将来のメンテナンス頻度とアーキテクチャの複雑さを天秤にかけたときに「良い塩梅」を考えることだと思っています。

技術が全てではない、問題の本質を常に探っていきたい

ーーCTOとして、開発においてどんな価値観を大事にしていきたいですか？

エンジニアは「技術で問題を解決するのが得意な集団」だと思っています。ただ、解決方法がすべて技術であるべきとは思いません。技術で解決することにこだわらずに問題の本質を常に探っていきたいです。

一方で、「開発の効率化」は一つのミッションだと思っているので、積極的に投資していきたいです。具体的には、静的解析、lintなどのツールについては積極的に採用するし、ソースコードの均一化や解読効率、ひいては人のスケールにじわじわ役に立つのではと思います。最近話題の「Copilot」や「ChatGPT」などのモダンな開発手法も積極的に検討したいと思います。

コードの品質はもちろん大事ですが、プロダクトがちゃんと動くことが大切です。僕たちはサービスを提供しているわけで、ライブラリの開発を生業としているわけではありません。コードの品質とサービスの品質は必ずしも一致しないこともあります。マーケットのニーズに合わせた速いプロダクト開発を大切にしていきたいですね。

また、流行りの技術を取り入れることを「技術的チャレンジ」とは捉えていなくて、表面的に取り入れるくらいなら、今の技術を深掘りした方がエンジニアリングとして強くなると信じています。

基本的には既存システムとの親和性を考えて、最適解を導きたいなと思っています。それが結果的に「流行りの技術」であればもちろん取り入れますし、そうでないなら取り入れないという方針です。

エンジニアの成長環境「優れた同僚 x 難しいプロジェクト」

ーーエンジニアの採用や働く環境についてはどうしていきたいですか？

エンジニアが成長できる環境は、「優れた同僚 × 難しいプロジェクト」という掛け合わせだと思っています。CTOとしては、入社してくださる方のキャリア的な成長を考えなくてはいけないのは当然だと感じています。

ただ、「難しいプロジェクト」を常に提供するのは難しい。これを提供したいがために、問題をより高度にしたり、必要以上にアーキテクチャを複雑にしたりするというのはやりたくないと思っています。

「優れた同僚」は実現可能だと思います。これはジュニアレベルの方を採用しないということではありません。

採用の幅が広がったときに現場のエンジニアが感じる疲労やストレスの要因は、教育する相手の「スキル」の問題というより、「飲み込み」によるものが大きいのではと思っているんです。スキルあるエンジニアを採用するのはもちろんですが、性格や素養によってはもちろんジュニアの方も採用したいと思っています。すぐにキャッチアップして、優れた同僚の一員なると信じています。

柔軟で自律的な組織として、大きく成長したい

ーー社内の雰囲気や今後の組織体制についてはどう考えていますか？

自律的な組織を作りたいと思っています。

現在の創業メンバーはそれぞれプロフェッショナルな人ばかりです。「無駄なミーティングはしない」というのも大きなカルチャーかもしれません。定例のミーティングはかなり少なくて、テキストで済むことはSlackで、口頭で説明したほうが効率的であればミーティングをする。そうした意識が根付いていると思います。

紘さんも僕も、それぞれアメリカで働いた経験もあり、例えばダイバーシティについて気を付けることは当たり前のカルチャーとしてありました。僕自身の経験で言えば、例えば子どもができるまで、子育てしながら働くことについてわかっていなかったことも多くて、そうした経験から培った意識は、組織作りに活かしていきたいです。

ーー働き方も柔軟に、効率化していくということですね。

紘さんは日本にいますが、僕自身はいまアメリカから仕事をしています。日本の良いところとアメリカの良いところを混ぜたような会社にしていきたいですね。

活気ある賑やかなメンバーで、意見を交わしやすい環境だと思います。働き方や制度面でも、メンバーそれぞれの経験や属性、価値観に応じて柔軟に整えていきたいです。

組織の成長のスピード感はかなり速いですし、これからさらに大きくしていきたいと思います。一緒に不動産業会のDXを推進したい人や、僕らの開発組織に興味を持ってくださるエンジニアの方は、気軽にご連絡いただきたいと思います。お待ちしています。