サムネイル画像
インタビュー

「打席数×打率」を最大化せよ。少数精鋭で巨大サービスを進化させたフロントエンド哲学

企業ロゴ
株式会社Red Frasco

問い合わせ数6年で1,760%、応答速度10〜30ミリ秒、キャッシュ非ヒット時でも平均100ミリ秒前後──。「いい部屋ネット」のリニューアルプロジェクトが実現した圧倒的な数字の裏側には、泥臭さと開発効率を両立させたフロントエンドの哲学がありました。

日本の賃貸市場という巨大なインフラを支えながら、技術負債に苦しむ現状を打破するため、ログイン機能の廃止による全ページCDNキャッシュ、開発基盤整備による4年で2,000回リリース、そしてGraphQLによるWeb/アプリ共通化など、大胆かつ泥臭い施策を重ねながら、実現したサイトの大幅リニューアルはどのように進められたのでしょうか。創業期から一貫して「事業のために技術を尽くす」考え方を大切にしてきたRed Frascoの哲学を体現し、主にフロントエンドの改善を牽引した石山雄大さんに、リニューアル成功までの全貌を伺いました。

プロフィール

石山 雄大(いしやま・たけひろ) さん

VP of Engineering

大学院卒業後、2017年に株式会社リクルートホールディングスへ新卒入社。アプリケーションエンジニアとして新規事業のプロダクト開発を担当。フリーランスエンジニアとしての活動を経て、2020年12月、Red Frascoに参画。当時は5人未満だった少数精鋭体制において、フロントエンド開発を主導し「いい部屋ネット」の大規模リニューアルプロジェクトを牽引。

「打席数×打率」の最大化で生まれた、驚異的な成果

画像2

──石山さんがRed Frascoに参画されたのは、どのようなタイミングだったのでしょうか

石山:2020年12月、ちょうど会社が2期目に入るタイミングでした。当時のチームは全体で5人未満という少数精鋭体制。現在はエンジニアが15名程度、デザイナーやQAも含めると20人を超えるチームに拡大しました。が、当時の人数で「いい部屋ネット」という、すでに稼働している巨大なサービスを止めずに成長させていく、非常に挑戦的なミッションが課されていました。

CTOの吉田が話していたように、Red Frascoでは「事業のために技術がある」という考え方を大切にしています。しかし、当時のサイトは事業を伸ばすための施策を行う以前に、開発効率が極めて低い状態でした。

オンプレミス環境の巨大なモノリシックなシステムを抱え、自動リリースの仕組みがなく属人化も深刻、障害によるダウンタイムが頻発しカスタマー体験が損なわれている――。そんな状況で、改善すべきポイントは山積みでした。技術的な負債が重くのしかかり、いくら良い改善案を思いついても、それを実装してユーザーに届けるためのスピードが圧倒的に不足していました。成果を生むために必要な「打席に立つ回数」そのものを増やせない状態だったんです。

そんな状態でありながら、事業の成長にもコミットし続けなければならないという、非常にチャレンジングな状況でもありました。

──山積みだった課題に対して、最初どのようなアプローチを取られたのでしょうか?

石山:「問い合わせ数」をKPIに設定し、まずはプロダクト改善が本当に事業成長に結びつくのか、小さな検証からスタートしました。具体的には、「問い合わせ」に直結する3画面に対象を絞り、デバイスもスマホに限定してUIを刷新しました。検証の結果、取り組み開始からわずか3カ月で問い合わせ数が200%を達成しました。プロダクト改善がダイレクトにビジネス成果へ繋がることを、強い確信をもって実感できた瞬間でした。

画像3
スモールスタート後、技術負債と向き合いながらサービスを止めずにStep by Stepで進めてきた改善プロセス(素材提供:株式会社Red Frasco)

しかし同時に、さらなる非連続な事業成長を実現するためには、当時の開発基盤やアーキテクチャでは限界があることも浮き彫りになりました。こうした背景が重なり、「長期的に事業を伸ばし続けるためのリニューアルプロジェクト」が本格的に立ち上がりました。

──基盤整備と、事業貢献を目指した高速改善の取り組みによって、リ二ューアルプロジェクトで具体的にどのような成果が得られましたか

石山:お問い合わせ数1,760%という圧倒的な成果を出すことができました。

振り返えってみると、リニューアルすることを目的とせずに目の前の課題を1つずつ泥臭く解消し続けたこと、ビジネスを止めない移行プロセスを構築できたことが大きかったと感じています。

画像4
主要KPIの1つである「いい部屋ネット」のお問い合わせ数の推移(素材提供:株式会社Red Frasco)

とくにプロジェクトの早い段階で、「打席数×打率」を最大化できる開発基盤を整えられたことが、技術負債を返済しながら、問い合わせ数を1,760%に直結した要因だと確信しています。

4年でリリース2,000回。「打席数×打率」の最大化はどうやって生まれたか

画像5

──「打席数×打率」の最大化という戦略において、具体的には何に取り組まれたのでしょうか

石山:まずは、「打席数×打率」のうち、打席数を最大化することを徹底しました。打率を上げるには、チームとしての試行回数を増やし、仮説検証から学びを得るサイクルを高速で回す必要があります。1発のホームランを狙うより、とにかく何度も打席に立てる状態をつくること小さく始めることが重要だと考えました。

画像6
1発のホームランを狙うのではなく、細かく高速に検証していくスタイルの概念図(素材提供:株式会社Red Frasco)

そのために最初に着手したのが、「最強の開発基盤づくり」 です。プロジェクトの成否はここで決まると感じていたので、この部分だけは絶対に妥協しませんでした。具体的には、次のような取り組みを集中的に行いました。

  • CircleCI を用いた Blue/Green デプロイを洗練し、常に安全かつ迅速にリリースできる仕組みを構築
  • 案件チケットごとに feature ブランチを切り、push するだけで feature 環境が自動生成されるワークフローを整備
  • 出来上がったものは即ステージングに反映し、テスト → QA → リリースまで滞留させないプロセスを徹底
  • ステージング環境を6つ用意し、本番と全く同じデータを毎日同期することで「完全再現性」のある検証環境を維持
  • 割れた窓を放置しない文化づくりのため、厳格なモニタリング基盤を早期に構築

そして、この中でもとくにこだわったのが、最後の「割れた窓を放置しない文化づくり」です。技術的な仕組みだけでなく、チーム全体の姿勢や判断基準そのものを変える取り組みであり、最も大切にしたい部分でもありました。

CTOの吉田が口うるさく言う「ヒヤリハットの法則」がこの文化の土台になっています。バグのないシステムなんて存在しませんし、リリース回数が増えれば増えるほど、こちらから「壊しにいっている」ようなものなので、どこかで不具合が出るのは当然です。ただ、その「当然」を理由に些細な違和感や軽微なエラーを見過ごしてしまうと、いずれは重大な事故につながってしまう。そして重大な事故が増えれば増えるほど、障害対応に時間を取られ、本来注ぐべき価値創造の時間がどんどん削られてしまう。それが本当に嫌なんです。

画像7
160件以上のメトリクスをDatadogで監視し、小さな変化を見逃さないモニタリング(素材提供:株式会社Red Frasco)

フロントエンドはSentry、ログやインフラ監視はDatadog(※)に集約しています。気づけば監視するメトリクスの数は160を超え、各モニターの閾値もかなり厳しめに設定しています。アラートが鳴れば、誰かが「あとで見ればいいか」ではなく、必ずその場で状況を確認し、小さな違和感でも放置しない。そんな “当たり前” がチーム全体に根づきました。結果として、障害の芽を早期に摘み、価値創造に集中するための時間を守るという、本来やりたかった開発のリズムが回り始めています。

こうした開発基盤の整備によって、「つくったらすぐ検証して、すぐリリースする」 という理想的な打席数の最大化が実現できました。結果として、学習と改善のスピードが劇的に向上し、チーム全体が「高速で改善し続けられる組織」に進化したと感じています。

※Datadog Syntheticsの活用事例は こちら

──「最強の開発基盤づくり」と合わせて、開発効率にもこだわられたと伺いました

画像8

石山:そうですね。アーキテクチャ設計、技術選定においては開発効率を上げるという目的をもって取り組みました。たとえばGraphQLの導入は開発効率を上げる打ち手として最大の恩恵を得られた技術選定だったと思います。

不動産領域は、とにかく取り扱う項目数が圧倒的に多いです。物件情報ひとつ取っても数百項目レベルで属性が存在し、画面やパーツごとに必要な情報が全く違います。そんな大量の項目を組み合わせて構築されるUI/UXを改善するには、開発効率を高め、メンテナンスのスピードをいかに速くできるかが重要になります。

画像9
GraphQLはRESTと比べて不動産ドメインと相性がよく最大の恩恵を受けられた(素材提供:株式会社Red Frasco)

GraphQLは、大量の項目を扱う不動産ドメインとの相性が抜群で、以下のようなメリットが一気に得られました。

  • 画面ごとに必要なデータだけを取得
  • フロント側の改修に合わせてAPIを都度つくり直さなくてよい
  • バックエンドチームの工数を使わず高速でUI改善できる
  • 型安全でバグの混入が減る
  • スキーマ駆動で、チーム全体(Webとネイティブアプリ)がデータ構造を正しく共有できる

とくに「打席数×打率」を最大化したい私たちにとって、GraphQL は 「打席数そのものを底上げする存在」だったんです。

そしてなにより、WebとアプリでAPIを完全に共通化できたことで、一度実装すれば双方に反映されるため、開発スピードがめちゃくちゃ向上しました。具体的には、この効率化により、iOSアプリは1年、Androidアプリは6カ月という異例のスピードでリニューアルすることができました。以前の開発環境では、考えられなかったですね。

ワンチーム体制が意思決定のスピードを生む高速改善サイクル

画像10
目的に対してチームでコミットするというRed Frascoでの考え方(素材提供:株式会社Red Frasco)

──基盤が整い、打席数は増やせても、ヒットを打てなければ打率は下がります。そこにはどんな秘策がありましたか

石山:打席に立つ回数が増えた後、「打率の高い改善」にするために有効だったのが、Red Frasco独自のコンパクトな「ワンチーム体制」です。

私たちは、マーケティング、プロダクト、データチームが完全に連携し、縦割りのない非常にコンパクトな構成になっています。大きい企業になるほどセクショナリズムが強くなってしまいがちですが、Red Frascoは横のつながりがすごく強いんです。

とくに影響が大きいのは、データチームが中心にいて、集客からコンバージョンまでのあらゆるデータが、全部一箇所にまとまっていることです。

画像11
集客から反響まであらゆるデータが一箇所に集約され、すべてのデータはtableauを通じて全チームが同じ数字にアクセスできる環境が整っている(素材提供:株式会社Red Frasco)

──ワンチーム体制は、具体的な改善サイクルにどのように活かされていますか

石山:この体制と、整えられた技術基盤があるからこそ、私たちは他社には真似できない高速な改善サイクルを回すことができていると自負しています。

コンパクトなチームは、意思決定の階層を極限まで減らします。データがフラットにあることの優位性は、組織的なボトルネックを解消することに直結します。

Red Frascoではエンジニア自身がデータを見て課題を発見し、プロダクトマネージャーやマーケティング担当と直接議論できます。このフラットな構造が意思決定の速度を上げ、「4年間で2,000回以上のリリース」というアジリティを実現できている最大の要因です。

一般的な大規模サービスでは考えられないこの高速なサイクルこそが、「打席の数」と「打率」を最大化するRed Frascoの哲学を体現しています。

たとえば、「このエリアの物件一覧ページのCVRが低下している」というデータチームからの知見を、マーケティングとプロダクトがすぐに共有し、フロントエンドは即座に仮説に基づいたA/Bテストを実装し、リリースできます。

一般的なWebサービスでは、A/Bテストの実施自体が重いプロセスになりがちですが、私たちは技術的なコストを気にせずビジネス上の課題解決に集中できます。まさに「技術が事業貢献のために機能している」ことを日々実感できる環境です。

――さまざまな取り組みを振り返って、最も効果があったとお考えの施策を一つ教えてください

画像12

石山:最も成果に直結し、かつ大胆だった施策の一つが、「ログイン機能の廃止と全ページキャッシュ」でした。

ログイン機能をなくす判断には慎重な議論もありましたが、LocalStorageでお気に入り情報を保持できるようにすることで、UXを損なわずに高速化を実現できました。

こういう意思決定をすぐにできたのは、データ基盤が整っていてデータチームが「いい部屋ネット」に訪れるユーザがどんなユーザなのかデータで可視化してくれていたからです。

一般的なポータルサイトでは、閲覧履歴やお気に入り機能のためにログインが必要ですが、これがあるとセキュリティ観点で全ページを一律にキャッシュすることが難しくなります。

しかし、既存データの分析に基づき、「いい部屋ネット」のユーザーの多くがサイトに来訪してからすぐお問い合わせすることがわかっていたので「ログイン機能」を廃止し、「お気に入り」などの機能はブラウザのLocalStorageに依存させるという大胆な意思決定ができました。

これにより、全ページをCDNにキャッシュできるようになり、応答速度は10〜30ミリ秒、キャッシュがヒットしなかった場合でも平均100ミリ秒前後という、Webサービスとしては驚異的なスピードを実現できました。

画像13
CloudFrontには余計な設定をいれずに「土管化」してアプリケーション側でキャッシュを制御(素材提供:株式会社Red Frasco)

CloudFrontへの移行は、CDNに複雑な設定を積み重ねる方向ではなく、Next.jsアプリケーション側でキャッシュポリシーを統一的に管理できる土台を整えることに重きを置きました。このアプローチによって、ページごとの更新性に応じて最適なTTLをNext.jsから直接指示でき、キャッシュ運用の柔軟性とメンテナンス性が飛躍的に向上しました。

マイナスから未知の領域へ、事業の未来を切り拓く醍醐味

画像14

──これまでの5年間を振り返って、どのように感じていますか。また、次のチャレンジについて教えてください

石山:これまでは「マイナスをゼロにする戦い」だったと思います。すでに市場にある標準的な機能がわかっていたので、そこに最短で追いつくために、足りないものをつくっていくフェーズでした。技術的な負債もあり、基盤を整える必要もありました。

そして今、私たちはようやくその段階を終え、打席に立つ回数を最大化できる状態になりました。これからは「ゼロから未知の領域へ」、つまり真の差別化と事業成長を追求する新しい段階に入ります。

実は標準的な機能実装が最優先だったため、これまでユーザーインサイトを深く掴むための定性・定量調査や、新しい価値創出のための思考の深化が後回しになっていました。でも、これからは違います。競合の模倣ではなく、ユーザーへのデプスインタビューや高度な調査を積極的に行い、深くインサイトを掴むことで、真に必要とされる新しい機能をつくり出していきます。

そして、「技術をどう使うか」という問いが、より重要になってきます。AIが台頭し、単純なコーディング作業が代替されつつある今、エンジニアの真価が問われるのは、まさにこの「仮説構築」と「価値創出」の領域です。CTOの吉田が語るように、一見地味で泥臭く見える「トイル」であっても、それが事業を伸ばすために必要な作業であれば、最も価値ある仕事です。

──最後に、Red Frascoならではの面白さ、そしてどのような仲間と働きたいか教えてください

石山:意思決定のスピード感と自由度を両立しながら、巨大な事業に挑めることが最大の面白さです。

「いい部屋ネット」のような社会インフラに近い巨大なサービスを、自分たちの技術戦略に基づいて改革し、問い合わせ数1,760%という圧倒的な成果をチームで出せる。「技術の力で事業を動かす」という、エンジニアにとって最もエキサイティングな経験ができる場所だと思います。

プロダクトとしては新しい価値を生み出す挑戦ができるフェーズにやっと立つことができました。技術そのものが好きであることはもちろん、「なぜこの技術が必要なのか」「誰に、どんな価値を届けるのか」まで考え、事業を伸ばすことにコミットできる仲間と、この未知の領域を切り拓いていきたいと思っています。

……と、ここまで少しお行儀よく話してしまいましたが、正直なお話をすると、最終的には「手を動かしてナンボの世界」なんですよね。実装して、動かして、壊して、直して、より良くしていく。スクラップアンドビルドのサイクルを自分の手で回せることこそが、一番の楽しさであり、やりがいだと思っています。

そんな、エンジニアリングの矜持を求めている人と、世の中の当たり前を疑い、最適化よりも最良化を目指せるようなプロダクトづくりをともにやっていきたいです。