カナリーが取り組む技術課題（Ver.2025）

はじめに

カナリーでは、もっと良い「当たり前」をつくる というミッション、そして「不動産テック領域におけるプラットフォーマーになる」という中長期の事業戦略を前に進めるため、日々プロダクト開発に取り組んでいます。

現在リリース済みの「CANARY（BtoC/不動産情報マーケットプレイス）」、「CANARY Cloud（BtoB/不動産業務特化型SaaS）」は立ち上げ以来順調に成長している一方、上記の事業戦略の達成に向けて解決しなければならない技術課題がまだまだたくさんある状況です。

本記事では、私たちが2025年現在取り組んでいる技術的な課題をプロダクト毎にご紹介します。

カナリーの開発チームに興味のある方に、等身大の姿が伝われば幸いです。

1. CANARY

「CANARY」は、toCユーザー向けの不動産情報マーケットプレイスです。
2019年にモバイルアプリをリリースしたのち、Web版も後追いでリリースされました。

アプリは現在500万DLを突破しており、アクティブユーザー数も日々増加し続けています。

そんな「CANARY」で取り組んでいる技術課題をご紹介します。

モバイルアプリ

• UI/UX改善

  • 検索体験の改善
    • ユーザーが理想の部屋にスムーズに出会えるよう、検索体験の向上に向けたアプリ改善を進めている。
  • 機能拡充
    • カナリーの強みであるUI/UXをさらに磨くとともに、競合サービスにはない独自機能の開発・実装を進めていきたい。

• 生産性改善

  • 開発体制の改善
    • モバイルアプリの開発は各エンジニアメンバーの環境差異に影響を受けやすく、環境構築がスムーズにいかないなどの問題が発生しやすいため、それらの差異を吸収できるような仕組みを整備したい。
    • Expo の Bare Workflow から Managed Workflow へ移行予定
  • ディレクトリ構造のリファクタリング
    • 初期リリースから5-6年が経過する中で、構造が複雑になってしまっている箇所が多々あるため、理想的なディレクトリの形へと修正していきたい。
  • QAプロセスの標準化
    • テストやデバッグチェックリストを整備し、誰が対応しても一定の品質が担保できるようなQA体制の標準化を目指している。
  • オブザーバビリティの改善
    • ユーザー影響のある問題を迅速に検知・対応できるような仕組みの整備を進めている。Datadog を活用し、リアルタイムでの監視と分析の体制を強化したい。

Webフロント

• リアーキテクチャ・リファクタリング

  • 独自のディレクトリ構造になっており、どこに何を配置するかの判断基準などが形骸化しているので、bullet proof react ベースに則ったアーキテクチャに移行中。
  • 「CANARY」はリリースから6年目を迎えており、複雑なソースコードも増加しているため、負債を溜めない仕組みを整えつつ、定期的な解消にも取り組んでいる。

• テスト関連

  • Testing Trophy に従い、インテグレーションテストを追加する
    • テスト戦略を定義し、テストが不十分な箇所に対して Vitest を使用したインテグレーションテストを拡充。
    • さらなる品質向上のため、VRT や E2Eテストの導入も検討中。

• オブザーバビリティ周り

  • アラートの対応が形骸化しているので、運用方法も含めて改善中。

• styled-components のリプレイス

  • 2025年3月にメンテナンスモードに移行したと発表されたため、代替のライブラリなどを模索中。

• コーディング規約

  • Style Guide の見直しを図り、cursor project に段階的に移行して開発生産性の向上に取り組んでいる。

• SEO改善

  • Google等の検索結果で上位表示されることによるオーガニック流入増加のため、SEO設定の見直しを中心とした改善施策に取り組んでいる。

バックエンド

• 物件連動周り（連動 = 物件データを取り込んだり、更新したりする処理を指す）

  • リアーキテクチャ
    • 不動産マーケットプレイスとして多数の不動産仲介会社から物件データを受け取っている。物件データを変換する処理がいくつかのパターンに分かれており、新規の実装時に似たようなコードを書く必要がある。
    • これらの処理をある程度統一的に扱えるようにリファクタすることで、新規の実装時の開発スピードを向上させたり、属人化を防いでいきたい。
  • 物件鮮度の向上
    • 物件データを受け取り、検索結果として表示するまでに時間がかかってしまうケースがある。これらの時間を短縮することで、物件の鮮度を向上し、人気物件を取りこぼすことなくアプリ上に表示させるようにしたい。
  • エラーの整備とそれらを定量的に評価した上で改善に繋げる仕組みづくり（エラーバジェットや SLI/SLO の策定）
    • 物件連動におけるエラーは BigQuery などに出力しているが、生じたエラーが CANARY起因のものなのか、不動産仲介会社から提供される物件データ起因なのかが判別できない状態になっている。
    • 上記のような状態を改善し、CANARY起因のエラーがどれくらい存在するのかを定量的に可視化したい。そうすることで、物件連動におけるエラー率を減少させ、掲載される物件数の向上に努めたい。

• APIのレスポンス速度改善

  • 検索やお問い合わせのAPIが遅い傾向にある。
  • そもそものAPIの構造を変えたり、DBのパフォーマンスチューニングなどを行うことでAPIのレスポンス速度を向上させ、より良いユーザー体験を提供したい。

• トイル削減

  • 掲載中の物件情報に対する変更や他プロダクトとの連携について、一定の仕組み化は進んでいるものの、まだまだエンジニアの手を要する部分が残っている状況。
  • それらのトイルを削減することで、メンバーがエンジニアリングに向き合う時間を最大化したい。

2. CANARY Cloud

「CANARY Cloud」は、不動産業務に特化したSaaSプロダクトです。

CRM（顧客管理）をはじめとした充実した機能を揃えながら、誰もが直感的に操作できるような分かりやすいデザインにこだわり設計されている点が特徴です。

"不動産会社におけるオペレーション効率化"を最大の提供価値としており、直近では累計利用者が200万人を突破するなど、導入スピードも加速しています。

そんな「CANARY Cloud」で取り組んでいる技術課題をご紹介します。

Webフロント

• QA作業の負担軽減

  • 機能の増加に伴いそれらを使うパターンも増えたことで、QAの負担が大きくなってきていることを背景に、よく使う画面に絞ってE2Eテストを導入し始めた。
  • Playwright を使い、最低限守るべき動作を自動で確認できるように整備中。
  • → E2Eテストケースがまだ少なく、これから充足させていく予定です。

• コンポーネント設計の見直し

  • 既存の Container/Presentational パターンではコード量が増えがちだったため、現在はその廃止を進めている。
  • また、API呼び出しはコンポーネント単位で行うようにし、責務が肥大化しない構成に変更。
  • これにより、APIの挙動も含むインテグレーションテストの導入が容易になり、テスト範囲の拡大が期待できます。
  • 開発プロセスとしては、実装前に「どこで分けるか」「責務はどこまでか」を軽く共有することで、チーム全体での認識を揃えながら開発を進められるようにしている。
  • → コンポーネント設計が新旧の両パターンあるため、今後すべてを旧から新へ変更予定です。

• Lintルール・コーディング規約の明確化

  • warnとして見過ごされていたLintルールをerrorに変更し、ignoreされていたルールも見直すことで、CIでの厳密なチェックを整備。
  • またコーディング規約を文書化し、AIを活用した自動コードレビューを取り入れることで、コードの一貫性維持とレビュー効率の向上を図っています。

バックエンド

• DBトランザクションロックの最適化

  • 処理範囲が広くDBのトランザクションロックが長時間/広範囲になっているものがあるため、処理内容を精査し改善していきたい。

• APIレスポンスの最適化

  • APIエンドポイントによっては使用されていないレスポンスのデータが含まれてしまっているため、不必要なものは削除しペイロードの最適化を行いたい。

• データ整合性・非同期処理の改善

  • トランザクションが細切れになっていると、結果整合性を完全に担保できない状況になってしまっている。
  • ReadTransaction / ReadWriteTransaction が適切なスコープで分割されている状態にしていきたい。
  • また、各種リソースに対する処理のatomic性が担保されている状態にしたい。

• リファクタリング

  • ビジネスロジックとアプリケーションロジックが密結合しているコードが広くあるため、可読性やメンテナンス性に改善の余地がある。
  • これらロジックを適切に分離しコードの保守性・再利用性を高めたい。

• SMS送信における到達率の改善

  • SMS送信の機能を実現しているが、海外ベンダーを利用している関係から到達率に改善の余地がある。
  • そのため、国内ベンダーに切り替えてSMSの到達率の向上を計りたい。
  • また、送信のみ実現しているが今後は双方向によるやりとりとしてSMSの送受信を実現したい。

• gRPCにおけるペイロードが破損する問題

  • 一部のリクエストペイロードが破損する（途中からデータが繰り返す）事象が発生しており、調査・改善を進めている。

• キャパシティプランニングの仕組み導入

  • サービス利用者が急速に拡大したことによって、キャパシティプランニングを適切に行える体制が必要になった。
  • 特に季節要因やマーケティング施策で負荷上昇などが見込まれる際に、適切なキャパシティを用意できるようにしたい。
  • 日常的に十分なキャパシティを確保できている状態にしたい。

• トイル削減の仕組み・自動化

  • マルチテナント構成によりデータの複製や新規作成業務が発生する中、これらを開発側のscriptやSQLでカバーしている状態。
  • これらを削減するためにオペレーション改善をしていきたい。

3. プロダクト横断

プロダクト横断的な視点での課題についてもこちらでご紹介します。

「不動産テック領域におけるプラットフォーマーになる」という事業戦略を推し進めるために、toC/toB含めた複数プロダクトを開発している点は弊社の大きな特徴です。

その際、「プロダクト間で有機的にデータを連携させることで、模倣が難しい構造的な優位性を築く」という点は非常に重要なポイントであり、今後も新規プロダクトの開発が進むほどその重要性が増していくと考えています。

よって、プロダクト横断という視点では、「物件」や「会社・店舗」といったプロダクト間で共通のデータの整理・連携を特に大事な技術課題と位置付けています。

※ 弊社では、このようなチームを超えたアプリケーション課題への取り組みを「アプリケーションプラットフォーム」と呼んでおり、主に Platform Team がここに取り組んでいます。

現状ではそのような共通データが中長期的な視点で十分に整理されているとは言えないため、難易度の高い課題ではありつつ、解決できた時のインパクトは非常に大きいです。

最後に

2025年現在、カナリーが取り組む（今後取り組んでいく）技術課題を紹介させて頂きました。

私たちが向き合っている技術課題は、どれも「お部屋探し、ひいては不動産業界の未来を変える」ために必要なピースです。

今回ご紹介したような課題を解決し、「プロダクトや事業、業界に大きなインパクトを与えたい！」と興味を持ってくださった方がいれば、ぜひカジュアルにお話しましょう！

※ Entrance Book には、今回ご紹介した課題に加え、技術スタックの詳細についても記載されています。ご興味あればぜひご覧ください。

記事は以上となります。最後まで読んでくださりありがとうございました！