「トレンド通りの開発＝自社の正解」とは限らない。エンジニアの“腕っぷし”を最大限に生かす方法【Facilo CTO 梅林泰孝】

次々とトレンドやベストプラクティスが更新されていくソフトウェアエンジニアリングの世界。「自社にも取り入れなければ」と焦ってしまうのも無理はありません。

しかし、不動産仲介会社向けSaaSを提供するFacilo社のCTO・梅林さんは、過去の経験も踏まえて「世の中のトレンドやベストプラクティスが、自社にとって正解ではない場合もある」と語ります。彼は今、「エンジニアの事業貢献を最大化すること」を目的として、トレンドや一般的な手法とは少し違う方針をとっているそう。その結果、現在は非常に優秀でエンゲージメントの高いエンジニアが15名も集まっていて、この方針をシリーズAの資金調達後の今だけでなく、中長期的にも維持したいといいます。

トレンドについていくことが正解でないならば、どうやって強い開発組織をつくっていくべきか？　梅林さんの考えと、Faciloでの取り組みを深掘りしました。

• keyboard_arrow_down 大規模開発では「エンジニアにしかできない事業貢献」の追求は難しかった
• keyboard_arrow_down 「納期なし」で、生産性を“中長期的に”最大化する
• keyboard_arrow_down 「システムがシンプルであること」が、属人性やメンテナンスコストを下げる
• keyboard_arrow_down ベストプラクティスの「真似しなくていい部分」をいかに見極めるか

――Facilo社の創業CTOである梅林さんは、どのような考えのもと、組織づくりに取り組んでいるのですか？

梅林：根本にあるのは「エンジニアにしかできない事業貢献を最大化したい」という想いです。

僕は「プロダクトが売れると開発組織が評価される」という構造には違和感があるんです。売れる要因はさまざまですし、きっとそこには運も含まれているはずなのに、「売れたかどうか」によってエンジニアの評価が決まるのはおかしな話ですよね。本来評価されるべきなのは、ソフトウェア開発に関わる高い専門性をもってして、社内のさまざまなチームに貢献したエンジニアです。

そのため僕たちは「技能的にも、ビジネスパーソンとしても優れた少数のエンジニアを採用し、自律分散的に各々の強みを生かす」というやり方をとっています。最近は「多少のスキルのばらつきはあったとしても多人数のエンジニアを採用し、多数のチームでアジャイル開発を行う」といった方法が一般的になりつつありますが、Faciloはそうした方向には進んでいません。

――なぜそう考えるようになったのでしょうか。

梅林：これは僕自身の経験に基づいています。僕はいわゆる現代のエンジニアリングのベストプラクティスを最前線で実践している企業で働いてきましたが、そうした手法では「エンジニアにしかできない事業貢献」に集中するのが難しく感じるときも多々あったんです。

具体例を挙げるとしたら、例えばチケットに納期が定められていたこと。良いプロダクトや、良いユーザー体験をつくっていくためには、チケット対応以外にも、CSからの問い合わせ対応といった他部署とのコミュニケーションなど、重要な業務はたくさんあるはず。それなのに、チケットの消化だけが、特に優先して取り組むべきタスクとされているのは不自然だと感じました。

加えて、開発や設計のスキルがずば抜けて優れているエンジニアが、卓越した成果を上げていると次第にマネジメント職に就かざるを得なくなることにも、違和感がありました。開発とマネジメントは全く別の仕事です。慣れないマネジメントに労力を費やすことで、その人の開発・設計スキルを活かせなくなってしまうことが、会社にとってプラスだとはなかなか思えなかった。

やはりエンジニアとして突出した能力があるならば、エンジニアにしかできない仕事で事業貢献をするべきです。深い専門知識を持ち、それをアップデートし続け、常にさまざまな選択肢を持ち、将来の状況変化を考慮して副作用のない最適なコードを書く。そういう優れたエンジニアにしかできないことこそ、高く評価されなければならないと思います。

――しかし、ある程度大規模な組織で開発を進める場合は、どうしてもチケットの管理やマネージャーが必要になりそうです。

梅林：それはそうだと思います。特にBtoCのサービスは、サービスのスケールとともにトラフィック量が激増しますし、それを捌けるシステムをつくるには大規模な開発が必要になる場面もある。となると、チケットの納期やマネージャーも当然必要でしょう。

しかし当社に関して言えば、「不動産売買」という事業ドメインの特性上、売り上げとトラフィック量の相関は比較的緩やかです。こうした環境ならば、大規模な開発組織をつくるのではなく、「非常に優秀な少数のエンジニアがその専門技能を存分に生かすことが、事業貢献に直結する」という構造を成り立たせることができるだろう、と思うんです。

――となると、今はどんな風に開発を進めているのですか？

梅林：開発現場では、エンジニア個人にできる限り多くの裁量を持ってもらっています。

価値ある機能を、最適な仕様で開発していくためには「CSやセールスなど関係者とコミュニケーションをとる時間」と「エンジニアとして開発に没頭する時間」の両方が必要ですが、それぞれにいつどのくらいの時間を使うのかは、各エンジニアに一任しています。各々が自分のタイミングで時間の使い方を切り替えることによって、フロー状態でいられる状態を少しでも長く確保できるようにしているのです。

組織としては、拡大を目指してはいますが、やみくもに数を増やそうとは考えていません。今いる15人のエンジニアは、非常に優秀で自立しています。事業への責任感と興味を持ち、ピュアに誰かのために動き、思いやりをもってコミュニケーションがとれる、いわゆる「いいやつ」ばかりです。各々が自立しているからこそ、結果的に「マネジメント」は不要になっています。今後もこのカルチャーを守りながら、ゆるやかに拡大していくことを目指しています。

また、システムにおいては、toBのVerticalSaaSで、かつマルチプロダクトという特性から、「再利用性が高く、属人性やメンテナンスコストが低いエコシステムの構築」を最重視しています。

――「エンジニアにしかできない事業貢献を最大化」するために、普段どのように開発を進めていますか？

梅林：各エンジニアのフロー状態を最長にするために、タスクに納期は設定していません。期限が決まっていると、例えば納期の近いタスクのレビューを依頼されたときなどに、めちゃくちゃ集中して脳汁が出ているのに作業を中断しなければいけなくなることがあるんです。1回でもインタラプトが発生すれば、作業効率は著しく落ちてしまいます。

一方で納期がなければ、エンジニアは自分の裁量で各業務に取り組むタイミングを選べます。メンションへの返信やレビューなどの業務は、フロー状態に入ってタスクに没頭している最中ではなく、タスクとタスクの合間などに取り組んでもらえばよい。また、プルリクエストを投げた瞬間は、タスクがdoneになって頭がリフレッシュしているはず。そういうタイミングで新しいタスクを始めてもらったりするのもいいと思っています。

また、このように自分で時間の使い方を決めながら開発を進められるよう、同期的なコミュニケーションは極力少なくしています。ミーティングは週に3時間までと決め、必要なやり取りは全てテキストで行います。

タスクに納期を設けないことによって、短期的に見れば機能のリリースが遅れることはあるでしょう。しかし中長期的に見れば、各エンジニアが最も集中して作業している時間は、間違いなく伸びています。開発組織としてより高い価値を生み出すために、あえて短期的なゴールを重視しすぎないようにしています。

――納期のない状態でも、開発を着実に進めていくために、どのような工夫をしていますか？

梅林：僕が目指す究極のマネジメントは「マネジメントをしないこと」なので、各エンジニアの細かなタスク管理や、定期的な1on1などは一切行っていません。しかし、だからと言って何もしないわけではなく、普段のプルリクエストでのコメントやSlackでの発言はめちゃめちゃ見ています。それは各エンジニアの「波」を把握するためです。人のモチベーションやテンションの高低は、テキストにもよく現れますから。

普段からその人の「波」を見ていると、普段と違うときにすぐ気づけるんですよね。例えば少し雑談が減っていたり、文言の様子が変わっていたりといった変化がある場合は、何かがブロッカーになっているとか、困っていることがあるかも。そうした兆候を観察したときは、様子を聞くためにこちらから1on1を設定しています。こうして「波」を見て、異変があれば随時対処する、というやり方が、ある種のヘルスチェックになっているんですよね。

もう一つこだわりがあるとすれば、やはり採用です。今の組織における自立性や円滑なコミュニケーションを維持するためには、それができるメンバーが必要です。納期が設定されてなくてもベストを尽くしてくれる人しかいない、と自信を持って思えるからこそ、「納期がないとズルズル遅れてしまうのでは」といった不安はありません。

――システムにおいては「再利用性が高く、属人性やメンテナンスコストが低いエコシステムの構築」を重視しているとのことでした。具体的にはどんな工夫をしていますか？

梅林：当社はtoBのバーティカルSaaSを提供しているので、売上を非連続的に伸ばしていくためにマルチプロダクト戦略をとっています。その戦略に沿って、新プロダクトを立ち上げやすくなるように再利用性が高く、かつエンジニアがプロダクト間の移動がしやすくなるように属人性が低い、すなわち「シンプルなシステム」をつくる、という方針を取ってきました。

具体的な工夫としては、創業から一貫してRuby on Railsを使っていることが挙げられます。Ruby on Railsは規約が多いので、一定のスキルを持つエンジニアであれば、誰が書いても、似たようなシンプルなつくりになるんです。規約を存分に生かして開発できれば、再利用性が高くシンプルで、属人性が低いシステムをつくっていくことができる。となればメンバー配置を柔軟に変更できるし、メンテナンスコストも下がります。このメリットを高く評価し、僕もコアメンバーも、Rubyで開発するのは初めてでしたが、全プロダクトをRuby on Railsでつくると決めました。

また、他社ではプロダクトや機能の特性に応じて、GoやRustなど別の言語や、一部にRuby on Railsから外れるフレームワークを取り入れる例もありますが、当社では相当な理由がない限り選ばないかなと思っています。その分認知負荷や属人性が高まるし、メンテナンスコストも上がって、Ruby on Railsを使うメリットが減衰してしまいますから。

ただ、これは生成AI以前の意思決定なので、今もう一度創業期に戻ったら、また違う選択をするかもしれません。

――一気に陳腐化するのを防ぐために複数の技術を使う、という考え方もありますが、「1つの技術に絞ること」のメリットを最大化しているのですね。

梅林：そうですね。また、インフラの構成もできるだけシンプルになるよう開発しているので、大抵のエラーはシステムを再起動すれば直るようになっています。

一例として、ユーザーのセッションを保存する方法に、ファイルキャッシュを使っているんです。Redisのようなインメモリデータベースを使って高速化するのが定石ではありますが、Redisの管理って意外と大変なんです。マネージドなクラスターでダウンタイムゼロといっても、スケールイン、スケールアウトのタイミングでリシャーディングが行われると、一時的なレイテンシーの増加や、ネットワーク帯域やCPU、I/Oに負荷増が起きます。そのためRedisを管理するには、その振る舞いや内部構造をきちんと理解する必要があり、属人性が高くなってしまうと考えています。

ファイルキャッシュだとサーバー間ではデータが共有されません。その対策としては、キャッシュ対象には基本的にサーバー間で共有する必要がないものしか入れないようにしています。また、ファイルキャッシュのヒット率を最大化するために、Application Load Balancer（ALB）のスティッキーセッション機能を利用し、特定のユーザーからのリクエストは常に同じサーバーにルーティングされるようにもしています。

この方法では一般的に、サービスが拡大してサーバーが増えたらキャッシュヒット率が下がるんじゃないか、という懸念が生じると思います。ただ当社では中長期的に見ても、現段階では特に懸念はしていません。もし今後事業がものすごくグロースしたとしても、大量にサーバーを用意することはないはずだからです。Faciloのサービスは現状、DAU10万人以上にまで拡大していますが、インフラやアプリケーションをすべてシンプルに構成しているため、サーバーはほぼ1台で済んでいます。また、当社が現在事業を展開する「日本国内の不動産売買」という領域では、1プロダクトあたりのユーザーは最大でも約100万人程度と試算しています。この数であれば、大量のサーバーを用意しなくても捌ききれるはずです。

このようにインフラにおいても、再起動すれば直るような「シンプルなつくりであること」を徹底した結果、インシデントにかかる時間もかなり少なくなっています。SLAは今99.9%で、休日のオンコール作業も、創業以来1時間も発生していません。

この決断も、「再利用性が高く、属人性やメンテナンスコストが低いエコシステムの構築」という目的を達成するためです。いわゆるベストプラクティスとは少し違うやり方でも、当社の事業構造に合わせ、よりメンテナンスがしやすいようアレンジして採用しています。

梅林：ちなみに開発体制も「できるだけシンプルかつ効率的にしたい」と考えているので、SREやインフラエンジニアというポジションはありません。

確かにSREやインフラエンジニアがいれば、誰もがインフラを意識せずに開発できるような、抽象度の高いインフラを構築できるというメリットもあるでしょう。でも僕はそれよりも、全てのアプリケーションエンジニアが、インフラとアプリケーションがどうつながっているか、またCI/CDのパイプラインやデータのパイプラインの構築方法を理解して、自分たちのプロダクトにとって望ましい抽象度のインフラを構築できることこそ、理想的だと思います。

それができれば、インシデントの対応や、新しいプロダクトをつくるときのインフラの構築も、アプリケーションエンジニアだけで完結でき、コミュニケーションフローもシンプルに保てます。幸い、当社のエンジニアは全員インフラにも強いので、この方針をとることができています。

――現在の組織体制やシステムは、今後組織が拡大したとしても維持できるものなのでしょうか。

梅林：それは正直に言ってまだわかりません。

組織体制の面で、拡大したときの展望として今考えているのは、社内で自分と同じような動きや判断ができる人を育て、その人と担当領域を分けるやり方です。自分の下に階層をつくってマネジメントするやり方は、極力選ばないでいたいと思っています。

一番避けたいのは、規模拡大を急ぐあまり、カルチャーやスキルレベルが合わない人を採用してしまうこと。急激にエンジニアの数を増やしたら、もちろん瞬間的かつ局所的に、開発のアウトプットは増えるかもしれません。しかしそれは、今の開発組織のカルチャーが変わっていったり、開発者体験が今よりも下がったりして、今いるエンジニアのエンゲージメントが下がることとトレードオフですよね。

拡大するとしても、今活躍している優秀なエンジニアに、今と変わらずエンゲージメント高く活躍してもらえるようにし続けたい。組織に長く所属している人って、スポットでは測れない貢献があると思うんですよ。1チケット捌く上では、そう大差ない場合もあるかもしれない。でも、これまでどのように当社が成長してきたのかを知っていて、長い時間をかけて文脈を共有してきた人の方が、コミュニケーションが格段に円滑に進むときもあるんです。

そのため、組織拡大は目指すものの、カルチャーが変わってしまうような急激な拡大は望んでいません。ある程度滑らかに増やさないと、いろいろなところに不具合が発生していくんじゃないかな、と考えています。

技術的には、直近では「マルチアカウントをどうするか」がそれなりにチャレンジングな課題かなと思っています。ちょうど2つ目のプロダクトがリリースされて、3つ目もいつ誕生するかわからないという状態なので、よく現場でディスカッションしています。机上の空論ではあるものの、方針はだいぶ固まってきました。いくつかのプランが出そろった上で、それぞれにトレードオフがある中で全員が「これがFaciloっぽい」と言ってくれたものがあったんです。こうしてメンバーと意思疎通ができていれば、今後生じる技術的なチャレンジも、当社としての一貫性を持って乗り越えていけるだろうと思います。

――組織もシステムも、ベストプラクティスやトレンドに囚われない姿が印象的です。

梅林：たしかに、業界のデファクトスタンダードをなんとなく取り入れる、といったことはしないですね。ベストプラクティスを全く見ないわけではないし、むしろそういう情報を見るのは好きですよ。ただ、取り入れるうえでは「Faciloでやるならどうアレンジするか」は必ず精査しています。

多くのベストプラクティスを取り入れることは、やろうと思えばできるはずです。NetflixやGoogle、Facebookなどのビッグテックのやり方を、今の時代は誰もが真似できる状況にある。だからこそ、真似しなくていい部分をいかに見極めるかが、自社に最適化された開発組織やシステムをつくるために必要なんだと思っています。

取材：光松瞳・桐生直輝
執筆：一本麻衣
編集：光松瞳
撮影：赤松洋太