- シリーズCで約40億円の資金調達を発表しました！🎉
- CTOの中山が、アーキテクチャConferenceにて登壇いたしました！🎉
- 同じくCTOの中山が、Startup CTO of the Year 2025 ファイナリストに選出されました！🎉
このEntrance Bookは、株式会社カナリーに興味を持ってくださったエンジニアの方に向け、会社やエンジニア組織、働き方などについて知っていただくためのものとなっています。
/w=1920,quality=90,fit=scale-down)
目次（クリックで該当箇所へ移動します）
※ かなりボリューミーな内容となっております。ぜひ目次から、気になるパートを参照ください！
1. 会社・事業・サービスについて
1.1. Company Deck（会社紹介資料）
1.2 会社公式note・テックブログ
抜粋記事（ぜひお読みください！）
急拡大するプロダクト組織のフルリモートワークを支える技術
CTOがエンジニアリング組織の役割と責務を再設計した結果と学び
｢個々のメンバーがやりたいことと事業の方向性をアラインさせる｣VPoEが語る、カナリーの開発組織への想い
｢より良いプロダクトを目指していくための『作り方を作る』役割」CTOがカナリーで目指すこと
2. 開発組織・チームについて
2.1 開発組織として大事にするもの
カナリーのエンジニアは2つの視点を大事にしていきたいと考えています。
- 課題解決に挑戦するソフトウェアエンジニア
- プロフェッショナルとしてアウトプットに誇りを持つ
カナリーは【もっといい「当たり前」をつくる】というミッションを実現するため、既存の「当たり前」を超えてよりよいユーザー体験を追求していく必要があります。そのためには、「バックエンド」や「フロントエンド」といった職能・役割に閉じずに、ユーザーの新しい体験全体を作り上げるという意識が必要だと考えています。その様な意味を込めて「課題解決に挑戦するソフトウェアエンジニア」を目指したいと考えています。
一方で「課題解決が目的でありエンジニアリングは手段」という見方が強くなってしまうと、エンジニアリングを軽視しているのかの様に見えてしまうかもしれません。決してそうではなく、複雑な課題を解決し、それを継続的に強化していくためのコードベースを維持するためには高い技術と強い意思が必要ですし、リスペクトすべきものだと考えています。そういった姿勢がなくては、いつしかコードが腐敗しメンテナンス不可能になってしまうでしょう。目的志向と技術志向はお互いに欠かすことのできない両輪であり、課題解決を行うソフトウェアを高い品質でデリバーする事を目指し、そのアウトプットに誇りを持ちたいと考えています。
また、課題解決に精一杯取り組むが故に（時間的に）新しいスキルの習得が難しくなるといった現実的な課題があることも認識しており、後述する新たに構築するチーム（Enabling Team）などを通じて、エンジニアリングスキルの向上にも挑戦していきます。
2.2 チーム構成
▼こちらの記事でも詳しくお話しています！
2025年8月時点でのチーム編成は下記のようになっています。
図中の各チームと PLE / TLE / SWE の役割について以下説明します。
- チームについて
- Stream Aligned Team
- 顧客に直接インパクトをもたらすプロダクト毎の開発ループを回すチーム
- 現在のチーム
- CANARY マーケットプレイスチーム（toC: お部屋探しユーザー向け）
- CANARY Cloud CRMチーム（toB: 仲介会社向け SaaS）
- （新規プロダクトAチーム）
- （新規プロダクトBチーム）
- Platform Team
- Stream Aligned Team の認知負荷を下げられる様な横断的関心ごとを扱うソフトウェアやその他の考え方・ツール・ドキュメントなどを提供し、Stream Aligned Team の認知負荷・作業負荷を軽減する。それによって Stream Aligned Team の出力を最大化する。
- Enabling Team
- Stream Aligned Team に足りないスキルをセンシングし埋めていく事で Stream Aligned Team の自律性・自走力を高める。それによって Stream Aligned Team の出力を最大化する。
- エンジニアの役割（PLE/TLE/SWE）について
- 各 Stream Aligned Team では以下3つの役割を定義し、それぞれに対する責務を定め、日々の業務だけでなく評価や育成にも活かしています。
- PLE（Product Lead Engineer）
- プロダクト全体としてのエンジニアリングに対して責務を持つ
- 基本的にプロダクトに対して一人だが、拡大過程にある場合は co-PLE という形で補佐を置く事がある
- 基本的な考え方としては「人材/技術/組織/コミュニケーションなど全てのマネジメントに最終的な責任を持つが、一人で全部を担うのは難しいので部分的に委譲している」と捉える
- 技術マネジメント→ TLE（後述）など
- 残った部分が、PLE の直接的な責務
- 人材マネジメント
- 組織マネジメント
- コミュニケーションマネジメント
- プロダクトマネジメント
- 上記の責務を全うするため、以下の権限を持つ
- アサイン
- 技術領域を横断した方針（設計・実装・運用等）の決定
- TLE（Technical Lead Engineer ）
- バックエンド、フロントエンド、モバイルアプリなど各技術領域のエンジニアリング・技術マネジメントに対して責務を持つ
- 上記の責務を全うするため、以下の権限を持つ
- 技術領域内の方針（設計・実装・運用等）の決定
- SWE（Software Engineer）
- プロジェクトを推進する主体となる
- 各役割のイメージ
▼上記体制に関する背景などの詳細はこちらの記事で紹介しています！
- 今後のチーム編成について
- カナリーではこれから売買領域や賃貸管理領域などさらに多くのドメインにサービスを提供していく可能性があり、そうなった時にも適切な節理面でチームを切りつつ、チームが自律性を持ちながら可能な限りフリクションなく価値を生み出していける状態を目指します。
- 補足
- Team Topologies の考え方を取り入れていますが、フロントエンド/バックエンド両方について同じくらいのスキルを求めるものではなく、各メンバーの実際の比重についてはグラデーションがあります。
- フロントエンド : バックエンド が 9 : 1 のような人もいれば、5 : 5 という人も。
- 他領域にチャレンジしたことでそちらの開発が楽しくなり、むしろ比重が高まったというケースもありました。
- 「フロントエンドは絶対にやりたくない」のような温度感でなければ問題ありません。
- 個々人の志向性や進みたいキャリアに鑑み、Will/Can/Mustのバランスを見てアサインしています。
- 副業・業務委託メンバーについて
- 稼働量の多寡はありますが、5~10名ほどが参画してくださっています。
- インターン生について
- 社員側のキャパシティなどにもよりますが、インターン生は業務経験を問わず積極的に受け入れており、常時2~3名ほどが参画してくださっています。
2.3 一部メンバー紹介
面接や面談でお話させていただくメンバーのうち、一部を紹介しています。
🎤 各ページ内にインタビュー記事なども掲載しているので、是非ご覧ください！
/w=1920,quality=90,fit=scale-down)
/w=1920,quality=90,fit=scale-down)
/w=1920,quality=90,fit=scale-down)
/w=1920,quality=90,fit=scale-down)
2.4 開発組織全体の課題感
採用の強化
- 特に2024年以降、前例にないハイペースでエンジニア採用が進みましたが、目標としている事業・プロダクトの成長を達成するためには、まだまだ多くのエンジニアの力が必要と考えています。
- 更なる採用の成功のために、カナリーのエンジニア組織や技術的な取り組みに対する「認知」を広げ、より多くの候補者の方と接点を作ることが重要であると捉え、後述のようにテックブログやイベント登壇/協賛など、採用広報にも力を入れています。
マネージャー層の強化
- 採用を通して組織が拡大する中で、「チームの短期的成果を最大化するだけでなく、各メンバーが100%の力を発揮し、中長期的に成長し続けられる状態を作る」といった役割を担えるマネージャー層がより多く必要となっています。
- 補足）弊社では現在EM（マネジメント専門でプレイヤーとしての動きはしない）のような役割を定義していません。ここでの「マネージャー層」は主に各チームの PLE（プロダクトリードエンジニア）を指しています。
- 上記課題への取り組みとして、「ベンチャー企業におけるマネジメント力強化」に特化した外部のトレーニングサービスを現在のマネージャー層で受講するなど、組織拡大による歪みや弊害を最小化できるような準備を進めています。
2.5 採用広報の取り組み
テックブログ（）
LTイベントへの登壇
![[カナリーVPoE 高山氏]お部屋探しアプリでデータ負債に挑む #データ負債解消2](https://images.spr.so/cdn-cgi/imagedelivery/j42No7y-dcokJuNgXeA0ig/f35d772c-b120-4107-b108-9a4a523ab717/report_DATELT2_takayama/w=1920,quality=90,fit=scale-down)
各種イベントなどへのスポンサー
- Go Conference 2025
- 全サービスで Go を採用している企業として、昨年に続き協賛させて頂きました。
- React Native Matsuri
- React Nativeに関する国内最大のイベントであるReact Native Matsuriに2年連続スポンサー協賛しています。下記はゴールドスポンサーとして参加したReact Native 2022のスポンサーセッションの詳細です。
また遠方におけるカンファレンスやイベント登壇などについて、交通費/宿泊費の一部を会社から補助しています！
（メンバーより「北海道開催のイベントに登壇したい」という相談があり、その日のうちにCEO承認を取った上で支援を決めた、という経緯がありました）
今後も、各種イベントには登壇・スポンサーといった形で積極的に参加していきます！
社内+α向けのLTイベント
- チームを跨いだ交流や情報交換を目的として、エンジニアだけでなくデザイナー・プロダクトマネージャーも参加するLT会（Beer Bash）を定期的に開催しています
3. 利用技術・開発環境について
3.1 各チームの利用技術と課題
- 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のレスポンス速度を向上させ、より良いユーザー体験を提供したい。
- トイル削減
- 掲載中の物件情報に対する変更や他プロダクトとの連携について、一定の仕組み化は進んでいるものの、まだまだエンジニアの手を要する部分が残っている状況。
- それらのトイルを削減することで、メンバーがエンジニアリングに向き合う時間を最大化したい。
- CANARY Cloud CRMチーム
- 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.2 AI関連ツールの活用
- GitHub Copilot
- コーディングの効率性を高めるべく、希望者にはライセンスを付与しています。
- Cursor
- Github Copilot よりも Cursor を使いたいエンジニア向けに、会社でBusinessプランを契約し、費用を補助しています。
- Devin
- 各チームの開発フロー等に組み込むことで生産性を向上させる目的で、全エンジニアが Devin を活用できるようにしています。
- Gemini（for Google Workspace）
- チャットUIの Gemini に加え、Meet、Gmail、Googleスライド、スプレッドシートなど様々なGoogleサービスで無制限に利用可能です。
- エンジニアに限らず全社員に推奨しています。
- Dify
- プロダクトへの生成AI組み込みや業務フロー改善のためのアプリ構築などを目的として、DifyのTEAMプランを契約し、（エンジニアに限らず）全社員が利用可能にしています。
※ 上記のようなAI関連ツールを正しく・効果的に活用するための「生成AIガイドライン」を社内で策定・展開しています。
3.3 開発の進め方・流れ
- 各チーム、基本的にはプロジェクト形式で開発を進めています。
- = プロダクトとしてやりたい事（もしくは解決したい課題など）に対して都度エンジニアがアサインされ、そのプロジェクトを推進していく形。
- 「プロジェクト」の例（CANARY マーケットプレイスチーム）
- 物件レコメンド機能のロジック改修
- 物件詳細ページ タイトル部分のUIスタイル改修
- 不要となったxx機能のコード削除
- …
- 厳密にスプリント（例えば2週間）の中で開発項目やvelocityを管理している訳ではないため、いわゆる”スクラム開発"ではありませんが、週1回など定期的に各プロジェクトの進捗をチームメンバー全員で確認する機会があるなど、スクラム的な要素も含まれています。
- 開発の大まかな流れ
- 中長期的な開発ロードマップは、PdMやプロダクトのリードエンジニアを中心に作成しています。
- ロードマップから開発チケット（背景や要件、デザインなどを記載）へ落とし込み、それぞれのチケットに対してアサインされたエンジニアがプロジェクト形式で開発を進めていきます。
- 1つのチケットを担当するエンジニアは、規模にもよりますが1-3名です。
- 設計・実装・テスト・リリースが完了したら、新たに別チケットの開発へと移ります。
- 各開発チケット（プロジェクト）の進め方
- 設計
- 一定規模以上の機能開発などについては、DB設計・APIインターフェース・シーケンス図などを含む設計を用意し、各領域のTLE（テックリード）らからレビューを受けます。
- 実装
- [CANARY マーケットプレイスチーム]
- ある程度の粒度でPRを区切り、各PRが approve された時点で main ブランチにマージします（トランクベースの開発に近いです）。
- [CANARY Cloud CRMチーム]
- 機能単位のブランチを切り、そこに対してある程度の粒度で区切ったPRをマージしていくことが多いです。
- [共通]
- 実装中の不明点は、Slack の huddle などで他メンバーへ随時相談するなどして解消しています。
- テスト
- コードベースについては、関数・メソッド単位での単体テストを中心に品質を担保しています。
- リリース
- [CANARY マーケットプレイスチーム]
- ストア申請が必要なモバイル以外（Web/サーバー）は、main/master ブランチへのPRマージの度にリリースをします（1日2-5回ほど）。
- サーバーのリリース対象は、変更のあった microservice のみです。
- [CANARY Cloud CRMチーム]
- できる限りこまめなリリースを行なっています。
- 緊急性を要するもの以外は、ユーザーである仲介会社様の利用頻度が低い午後のリリースを心がけています。
- [共通]
- 大きな機能追加などを伴う場合、（実装者・レビュワーの動作確認とは別に）デバッグ会をチームで実施することもあります。
4. 働く環境・カルチャーについて
4.1 エンジニアの特徴・働き方
- 抽象度が高い課題をアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っているメンバーが集まっています。
- 働き方も多様で、メンバーそれぞれが生産性や成果を最大化できるスタイルで働いています。
- リモート勤務について
- 北海道や関西といった各地方に在住のメンバーも多く、完全なフルリモートが可能です。
- フルリモート以外だと、「週の半分くらい出社」「ほぼ毎日出社」といった形で各自に合った出社頻度を選択しています。
- コアタイムあり(11:00-15:00)のフレックス制度
- 各自の状況（お子さんの送り迎え、通院など）に合わせて勤務時間を調整することができます。
- コアタイム中でも、どうしても離席する必要がある場合は、チーム内で適宜対話・調整の上で柔軟に対応しています。
- エンジニアは業務において裁量権を大きく持って働いています。
- （プロダクトやフェーズにもよりますが）開発だけでなく、要件定義のフローからビジネス側の議論に参加するケースもあります。
- 施策内容などに対する意見は職種問わずフラットに受け入れる文化があります。
- 技術に対する姿勢に関しても、組織全体として理解する文化があります。
- 短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行っています。
- 新しい技術に対する抵抗は少なく、選定基準をクリアしていれば積極的にモダンな技術を採用しています。
- その他
- 勤怠管理はSlackコマンド1つで入退室の記録が可能であるなど、できる限り本質的な業務に使える時間を最大化するための運用を作っています。
- リモートが多い中でもメンバー同士がチーム感を持って気軽にコミュニケーションできる環境作りの一環として、Gather（バーチャルオフィスツール）を開発本部全体で導入しました。
- （有給休暇とは別に）入社時に付与される特別休暇があり、急な用事などで有給付与前に休まざるを得なくなった際などに利用できます。
- 会社近くに居住するメンバーに対する家賃補助制度があります。
4.2 エンジニアとして働く魅力
Category | 項目 | 詳細 |
|---|---|---|
Philosophy(企業理念) | ミッション | • 【もっといい「当たり前」をつくる】をミッションに、不動産というレガシー産業のアップデートに挑んでいる • 衣食住のうち「住」の領域で、日々の暮らしとも密接に関わるため、自分自身や周りの人にとっても直接的なメリットがある |
Philosophy(企業理念) | ビジョン | • 【新しい価値を創造し続ける社会インフラになる】をビジョンに、100年続く企業を目指している • 「カナリー出身者って皆優秀だよね」と世間から思ってもらえる会社になれるよう、一人一人が成長しつつ働いている |
Philosophy(企業理念) | 創業背景 | • CEO自身がそれまで引越しを多く経験してきた中で、不便や非効率を強く感じたことが創業の背景 • 強い原体験が元となっているため、事業に向き合う熱量が高い |
People(人･文化) | 人の良さ | • とにかく「いい人」しかいない • 社内メンバーの関係性の質が高く、オープンなコミュニケーションが可能 • 人間関係によるストレスが少なく、集中して仕事ができる • 誰に対しても、どんな話題でも気軽に話せる環境 |
People(人･文化) | メンバーの優秀さ | • メンバーのレベルが高く、学びが多い • 技術的、働き方的な多様な刺激が得られる • 新しい技術やアイデアに対する取り組みが活発 |
People(人･文化) | カルチャー | • 日系大手、外資系、メガベンチャーの「良いとこ取り」なカルチャー • 働きやすさと成果を両立させる環境を自分たちで作り上げていくという意識 • 各メンバーの実年齢に関わらず全体として若々しく、エネルギッシュな雰囲気 |
People(人･文化) | 部署間の垣根の低さ | • 各部署の垣根が低く、常に互いへのリスペクトを持ちながら協力的に働いている • 部署間のコミュニケーションが円滑で、チームワークが良好 |
People(人･文化) | コミュニケーション | • リモートと対面での情報の差が小さく、コミュニケーションが円滑 • 会議の雰囲気が良く、スムーズで忌憚ない議論が行われている • Slackなどの反応が早いため、迅速な意思決定が行われやすい環境 |
People(人･文化) | 互助精神 | • 実装や問題解決において周りから迅速にサポートが得られる • 思いやりの精神が根付いており、互いに教え合う（Enableする）雰囲気 • 技術的な成長とチームワークが促進される環境 |
People(人･文化) | 業務外含めた交流 | • バーベキューや歓迎会など、業務外の交流も定期的に行われる • 社員同士の仲が良く、プライベートでも楽しめる • これらを全員強制ではなく、各自の志向性に合わせ享受できる |
People(人･文化) | 権限移譲、チャレンジ | • 新卒や若手も含め、積極的に業務に参加し、裁量を持って働ける • プロジェクト進行における裁量権が大きい • 新しいアイデアやチャレンジが歓迎される |
People(人･文化) | 組織改善 | • モダンな開発環境が整っており、最新の技術を用いた開発が可能 • 改善案が積極的に提案され、組織の発展に寄与している • 社内の議論が活発で、新たな取り組みが常に模索されている |
Profession(事業･業務内容) | 技術領域 | • 「ソフトウェアエンジニア」としてフルスタックに開発に取り組め、広範な技術知識を習得できる • toCサービスはWebとアプリの両方の開発に携わることができ、Reactを起点とした多角的なスキルアップが可能 • 閉じられた技術領域に限定されず、新しい技術への挑戦が奨励されている |
Profession(事業･業務内容) | 事業領域 | • 2030年に2.4兆円規模になるとされている不動産テック市場に挑戦している • 市場の大きさ・成長可能性と会社の成長は強くリンクしているので、会社としても大きな伸び代が見込まれる |
Profession(事業･業務内容) | 事業戦略 | • マルチプロダクト / コンパウンド戦略を取り、不動産テック領域のプラットフォームになることでの構造的な優位性の確立を目指している • プラットフォーム化は安定した収益につながることに加え、エンドユーザーと事業者の双方に一貫した価値をもたらすことができる |
Profession(事業･業務内容) | toB/toC両軸での事業展開 | • 10→100フェーズのtoCサービスおよび1→10フェーズのtoB SaaS両方の事業に携われる • 加えて複数の新規プロダクトの開発も行っており、0→1フェーズにも関わることができる • このように多様なフェーズやビジネスモデルを経験でき、幅広いスキルを身につけられる |
Profession(事業･業務内容) | 新規事業 | • 年間売上1兆円超のヤマダホールディングス等に対するDXコンサルティングといった新規事業にも取り組んでいる • 大手企業との資本業務提携などにより、新たなビジネスチャンスを追求している |
Profession(事業･業務内容) | 未来の事業領域 | • 現在の不動産テック領域は巨大かつレガシーなため、10年スパンでのチャレンジとなる • 一方さらにその先では、不動産テック領域での経験を活かし他の業界などにも事業を広げていく可能性もある |
Privilege(働き方･待遇) | 働き方 | • コアタイムありのフレックス制度で、ライフスタイルに合わせて効率的に働ける • フルリモートワークも可能で、場所を選ばずに働ける(地方在住者の実例も多数) • 一方で対面のコミュニケーションも大切にしており、たまにオフラインで集まることにも価値があると皆が共有している |
Privilege(働き方･待遇) | キャリア・成長支援 | • 勉強会や書籍購入補助など、学びのサポートが充実 • 自身のキャリアパスに合わせた目標設定やその先を見据えた成長支援が行われている • 自身の役割を積極的に広げ様々なプロジェクトに参加することが可能 |
Privilege(働き方･待遇) | オフィス環境 | • フルリモート前提でありながら、物理的なオフィス環境も良好(アクセスの良さ、街の雰囲気、新築で入居したオフィスetc. ) • 開発メンバーはブースで区切られているデスクも使用可能で、集中しやすい |
4.3 オフィスなどの雰囲気
- フルリモート可ですが、出社時にも最高のパフォーマンスを出せるような環境作りには力を入れています。
- 各種社内アクティビティには、エンジニアも積極的に参加して他部署メンバーとの交流を図っています。
5. 評価制度・キャリアについて
5.1 グレード・給与レンジ
カナリーでは、全社共通の6段階のグレードを定義しており、エンジニアなどの職種が属する開発本部では、グレードごとの給与レンジを定義しています。
- 専門職に関しては、組織を構築・牽引することのみに限らずその専門性によって事業に突き抜けた貢献をすることもできるという考えのもと、スペシャリストという形でグレードに対する期待を併記しています。
- ただし、専門職であっても組織的な貢献をする方が得意な人もいるので、実際にはどちらか一方を選ぶというようなシンプルなキャリアパスにはならない可能性があると考えています。
- 開発本部のグレードごとの給与レンジ（年額給与。単位：万円）
- 開発本部のグレードの定義
グレード | 不確実性の
範囲のイメージ | 期待 |
G6 | 会社 | 業界のトレンドや潮目を見極め、その中での会社の中長期的なあり方を定められる。また、それを実現するための方針や戦略、組織を立案し実現することができ、会社およびその将来に対して多大なインパクトをもたらすことができる。
スペシャリストは世界的に高いレベルの専門性を有し、自身の専門性を活用して会社およびその将来を革新する多大なインパクトをもたらすことができる。 |
G5 | 事業 | 経営方針や戦略を理解し、（複数のプロダクトからなる）事業の中長期的なあり方を定められる。また、それを実現するための方針や戦略、組織を立案し実現することができる。
スペシャリストは社外でも高いレベルの専門性を有し、複数のプロダクトに影響のある高度に複雑な仕事でも完遂のための方針・戦略を立案し実現することができる。 |
G4 | プロダクト | 経営方針や戦略を理解し、プロダクト、開発のあり方を定める事ができる。また、それを実現するための方針や戦略、チームを不確実性が高い状態でも立案し実現することができる。
スペシャリストは社内でも高いレベルの専門性を有し、プロダクト、チーム内での難易度の高い課題も解決する事ができる。また、自身の領域において他メンバーが仕事を進める際の適切な方針を定めることができる。 |
G3 | ユースケース | 経営方針や戦略、チームの方針や戦略を理解し、プロダクトに必要な一連のユーザー体験を不確実性がある状態でも上位の方針や状況に照らし合わせて最適な手段を取り、自走して設計、実現することができる。複数人での取り組みではリーダーシップを発揮して仕事を推進することができる。 |
G2 | 機能 | 経営方針や戦略、チームの方針や戦略を理解し、プロダクトに必要なユーザー体験を実現する一部の領域を一定の不確実性の中では自走しながら完遂する事ができる。 |
G1 | キャッチアップ | 経営方針や戦略、チームの方針や戦略、必要なスキルを自主的にキャッチアップでき、不足する部分は周囲のサポートを受けつつも不確実性の限られた仕事は最後まで完遂することができる。 |
5.2 キャリアパス
- 現在、個々のメンバーのキャリアパスについてはマネージャー（主に各チームのPLE）との1on1などを通して方向性をすり合わせ、その道へ進むのに必要な要素を目標設定に落とし込んだり、最適なアサインのための判断材料として活用するといった形で支援を行なっています。
- 今後、組織が拡大する中で各メンバーの志向性もさらに多様化してくるため、上述のグレードに加え、それらを適切に吸収・評価できる制度や枠組み（キャリアラダーなど）の設計にも取り組んでいます。
5.3 成長支援
- 技術力・生産性向上のための支援を様々な形で行っています。
- 技術検証や学習のためのサンドボックス環境（GoogleCloudのプロジェクト等）を個々のメンバーで利用できます。
- 技術書など必要なものがあれば、基本的に経費で購入可能です。
- GitHub Copilot または Cursor が利用可能です
- 入社時、ハイスペックの MacbookPro を貸与しています。
6. 採用情報
6.1 選考フロー
カナリーでは、お互いに納得が行くまでマッチ度を確認できるよう選考フローを設計しています。
- カジュアル面談
- 書類選考
- スキルテスト
- 面接(複数回)
- 内定
- オファー面談
HireRooというサービスを用い、ブラウザベースでコーディングテストや記述問題を解いていただきます
3.5. お試し副業 / 1day JOB etc.(場合によって、お互いに必要があると判断したら実施)
6.2 募集中のポジション
カナリーでは、様々な事業・職種でエンジニア採用を随時行っています！
一覧や各募集の詳細については、以下のページをご覧ください。
6.3 さいごに
「もう少しカナリーについて知りたい！」という方は、Xにて公式アカウントまでお気軽にご連絡ください！（DMを開放しています）
