💡 最終更新：2024/03
株式会社クレディセゾンと10億円の資本業務提携を締結しました！🎉
このEntrance Bookは、株式会社カナリーに興味を持ってくださったエンジニアの方に向け、会社やエンジニア組織、働き方などについて知っていただくためのものとなっています。
ぜひ最後までご覧ください。
▼株式会社カナリー 採用情報トップはこちら
/w=640,quality=90,fit=scale-down)
- 1. 株式会社カナリーについて
- 1.1. 会社概要
- Company Deck（会社紹介資料）
- 1.2. サービス概要
- 1.3. 会社公式note・テックブログ
- 公式note（記事抜粋）
- テックブログ
- 2. 開発組織について
- 2.1 大事にするもの
- 2.1.1 2つの視点
- 2.1.2 バリューについて
- 2.2 開発組織
- 2.2.1 チーム編成（トポロジー）
- 2.2.2 メンバー構成
- 2.2.3 エンジニアの特徴・働き方
- 2.2.4 カナリーでエンジニアとして働く魅力
- 2.3 開発環境
- 2.3.1 Web
- 2.3.2 アプリ
- 2.3.3 バックエンド
- 2.3.4 その他 開発組織としての取り組み
- 2.3.5 オフィスなどの雰囲気
- 3. 採用情報
1. 株式会社カナリーについて
1.1. 会社概要
私たちカナリーは、【もっといい「当たり前を」つくる】をミッションとして、デジタルの力で業界のDXを牽引するスタートアップです。
Company Deck（会社紹介資料）
1.2. サービス概要
主力サービスのtoCお部屋探しポータル「Canary」は、2019年6月のリリースから、 累計ダウンロード350万件を突破。
App Storeの評価は★4.8でカテゴリ内トップ。優れたUI/UXを強みとしています。
2022年末に本格立ち上げとなったtoBの不動産仲介会社向けSaaS「Canary Cloud」も、大手仲介会社への導入事例などもあり急速成長中です。
また、2024年2月には、株式会社クレディセゾンと10億円の資本業務提携を締結しました。
会社としての大きな通過点の1つである上場に向け、加速度的な成長を続けています。
1.3. 会社公式note・テックブログ
公式note（記事抜粋）
- カナリーの開発組織について：Team Topologiesの話や、組織の雰囲気の話
- 「個々のメンバーがやりたいことと事業の方向性をアラインさせる」VPoEが語る、カナリーの開発組織への想い
- 「より良いプロダクトを目指していくための『作り方を作る』役割」 CTOがカナリーで目指すこと
テックブログ
2. 開発組織について
2.1 大事にするもの
2.1.1 2つの視点
カナリーのエンジニアは2つの視点を大事にしていきたいと考えています。
- 課題解決に挑戦するソフトウェアエンジニア
- プロフェッショナルとしてアウトプットに誇りを持つ
カナリーは【もっといい「当たり前」をつくる】というミッションを実現するため、既存の「当たり前」を超えてよりよいユーザー体験を追求していく必要があります。そのためには、「バックエンド」や「フロントエンド」といった職能・役割に閉じずに、ユーザーの新しい体験全体を作り上げるという意識が必要だと考えています。その様な意味を込めて「課題解決に挑戦するソフトウェアエンジニア」を目指したいと考えています。
一方で「課題解決が目的でありエンジニアリングは手段」という見方が強くなってしまうと、エンジニアリングを軽視しているのかの様に見えてしまうかもしれません。決してそうではなく、複雑な課題を解決し、それを継続的に強化していくためのコードベースを維持するためには高い技術と強い意思が必要ですし、リスペクトすべきものだと考えています。そういった姿勢がなくては、いつしかコードが腐敗しメンテナンス不可能になってしまうでしょう。目的志向と技術志向はお互いに欠かすことのできない両輪であり、課題解決を行うソフトウェアを高い品質でデリバーする事を目指し、そのアウトプットに誇りを持ちたいと考えています。
また、課題解決に精一杯取り組むが故に（時間的に）新しいスキルの習得が難しくなるといった現実的な課題があることも認識しており、後述する新たに構築するチーム（Enabling Team）などを通じて、エンジニアリングスキルの向上にも挑戦していきます。
2.1.2 バリューについて
💡カナリーでは、ミッション達成のために全メンバーが拠り所とすべき行動指針としてバリューを4つ定めており、それぞれに対して「Do/Don’t」という具体的な行動例まで策定しています。
2.2 開発組織
2.2.1 チーム編成（トポロジー）
Team Topologies の考え方を取り込みつつチームを構築しています。
▼こちらの記事でも詳しくお話しています！
具体的には、以下の様なチームを構成しています。
- Stream Aligned Team
- Canary ポータルチーム（toC: お部屋探しユーザー向け）
- Canary Cloud チーム（toB: 仲介会社向け SaaS）
- Enabling Team
- Platform Team
※ 現状のカナリーではComplicated Subsystem Teamは必要ないと考えるので作らない
カナリーではこれから売買領域や賃貸管理領域などさらに多くのドメインにサービスを提供していく可能性があり、そうなった時にも適切な節理面でチームを切りつつ、チームが自律性を持ちながら可能な限りフリクションなく価値を生み出していける状態を目指します。
2.2.2 メンバー構成
- チーム別（フルタイム）
- Canary ポータル チーム：8名
- Canary Cloud チーム：7名
- Platform チーム：1名
- 副業・業務委託メンバー：稼働量の多寡はありますが、5~10名ほどが参画してくださっています
- インターン生：社員側のキャパシティなどにもよりますが、インターン生は業務経験を問わず積極的に受け入れており、常時2~3名ほどが参画してくださっています
上記のような体制で開発を行っていますが、プロダクトの成長に人員がまだまだ追いついていない状況です。
2.2.3 エンジニアの特徴・働き方
- 抽象度が高いタスクをアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っているメンバーが集まっています。
- 働き方も多様で、メンバーそれぞれが生産性や成果を最大化できるスタイルで働いています。
- もちろんフルリモートでの勤務も可能です。（毎日出社しているメンバーもいれば、フルリモートで働いているメンバーや半々程度のメンバーもいます）
- エンジニアは業務において裁量権を大きく持って働いています。
- 開発だけをするわけではなく、要件定義のフローからビジネス側の議論に参加することが多いです。
- 施策内容などに対する意見は職種問わずフラットに受け入れる文化があります。
- 技術に対する姿勢に関しても、組織全体として理解する文化があります。
- 短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行っています。
- 新しい技術に対する抵抗は少なく、選定基準をクリアしていれば積極的にモダンな技術を採用しています。
2.2.4 カナリーでエンジニアとして働く魅力
🙌 下記は、実際に社内のエンジニアメンバーが出し合ってまとめたものとなります！
| Category | 項目 | 詳細 |
|---|---|---|
Philosophy(企業理念) | ミッション | • 【もっといい「当たり前」をつくる】をミッションに、不動産というレガシー産業のアップデートに挑んでいる
• 衣食住のうち「住」の領域で、日々の暮らしとも密接に関わるため、自分自身や周りの人にとっても直接的なメリットがある |
Philosophy(企業理念) | ビジョン | • 【新しい価値を創造し続ける社会インフラになる】をビジョンに、100年続く企業を目指している
• 「カナリー出身者って皆優秀だよね」と世間から思ってもらえる会社になれるよう、一人一人が成長しつつ働いている |
Philosophy(企業理念) | 創業背景 | • CEO自身がそれまで引越しを多く経験してきた中で、不便や非効率を強く感じたことが創業の背景
• 強い原体験が元となっているため、事業に向き合う熱量が高い |
People(人･文化) | 人の良さ | • とにかく「いい人」しかいない
• 社内メンバーの関係性の質が高く、オープンなコミュニケーションが可能
• 人間関係によるストレスが少なく、集中して仕事ができる
• 誰に対しても、どんな話題でも気軽に話せる環境 |
People(人･文化) | メンバーの優秀さ | • メンバーのレベルが高く、学びが多い
• 技術的、働き方的な多様な刺激が得られる
• 新しい技術やアイデアに対する取り組みが活発 |
People(人･文化) | カルチャー | • 日系大手、外資系、メガベンチャーの「良いとこ取り」なカルチャー
• 働きやすさと成果を両立させる環境を自分たちで作り上げていくという意識
• 各メンバーの実年齢に関わらず全体として若々しく、エネルギッシュな雰囲気 |
People(人･文化) | 部署間の垣根の低さ | • 各部署の垣根が低く、常に互いへのリスペクトを持ちながら協力的に働いている
• 部署間のコミュニケーションが円滑で、チームワークが良好 |
People(人･文化) | コミュニケーション | • リモートと対面での情報の差が小さく、コミュニケーションが円滑
• 会議の雰囲気が良く、スムーズで忌憚ない議論が行われている
• Slackなどの反応が早いため、迅速な意思決定が行われやすい環境 |
People(人･文化) | 互助精神 | • 実装や問題解決において周りから迅速にサポートが得られる
• 思いやりの精神が根付いており、互いに教え合う（Enableする）雰囲気
• 技術的な成長とチームワークが促進される環境 |
People(人･文化) | 業務外含めた交流 | • バーベキューや歓迎会など、業務外の交流も定期的に行われる
• 社員同士の仲が良く、プライベートでも楽しめる
• これらを全員強制ではなく、各自の志向性に合わせ享受できる |
People(人･文化) | 権限移譲、チャレンジ | • 新卒や若手も含め、積極的に業務に参加し、裁量を持って働ける
• プロジェクト進行における裁量権が大きい
• 新しいアイデアやチャレンジが歓迎される |
People(人･文化) | 組織改善 | • モダンな開発環境が整っており、最新の技術を用いた開発が可能
• 改善案が積極的に提案され、組織の発展に寄与している
• 社内の議論が活発で、新たな取り組みが常に模索されている |
Profession(事業･業務内容) | 技術領域 | • 「ソフトウェアエンジニア」としてフルスタックに開発に取り組め、広範な技術知識を習得できる
• toCサービスはWebとアプリの両方の開発に携わることができ、Reactを起点とした多角的なスキルアップが可能
• 閉じられた技術領域に限定されず、新しい技術への挑戦が奨励されている |
Profession(事業･業務内容) | 事業領域 | • 2025年に1.2兆円規模になるとされている不動産テック市場に挑戦している
• 市場の大きさ・成長可能性と会社の成長は強くリンクしているので、会社としても大きな伸び代が見込まれる |
Profession(事業･業務内容) | 事業戦略 | • マルチプロダクト / コンパウンド戦略を取り、不動産テック領域のプラットフォームになることでの構造的な優位性の確立を目指している
• プラットフォーム化は安定した収益につながることに加え、エンドユーザーと事業者の双方に一貫した価値をもたらすことができる |
Profession(事業･業務内容) | toB/toC両軸での事業展開 | • 10→100フェーズのtoCサービスおよび1→10フェーズのtoB SaaS両方の事業に携われる
• 今後新規プロダクトの開発も予定しており、0→1フェーズにも関わることができる
• このように多様なフェーズやビジネスモデルを経験でき、幅広いスキルを身につけられる |
Profession(事業･業務内容) | 新規事業 | • 年間売上1兆円超のヤマダホールディングス等に対するDXコンサルティングといった新規事業にも取り組んでいる
• 大手企業との資本業務提携などにより、新たなビジネスチャンスを追求している |
Profession(事業･業務内容) | 未来の事業領域 | • 現在の不動産テック領域は巨大かつレガシーなため、10年スパンでのチャレンジとなる
• 一方さらにその先では、不動産テック領域での経験を活かし他の業界などにも事業を広げていく可能性もある |
Privilege(働き方･待遇) | 働き方 | • コアタイムありのフレックス制度で、ライフスタイルに合わせて効率的に働ける
• フルリモートワークも可能で、場所を選ばずに働ける(地方在住者の実例も多数)
• 一方で対面のコミュニケーションも大切にしており、たまにオフラインで集まることにも価値があると皆が共有している |
Privilege(働き方･待遇) | キャリア・成長支援 | • 勉強会や書籍購入補助など、学びのサポートが充実
• 自身のキャリアパスに合わせた目標設定やその先を見据えた成長支援が行われている
• 自身の役割を積極的に広げ様々なプロジェクトに参加することが可能 |
Privilege(働き方･待遇) | オフィス環境 | • フルリモート前提でありながら、物理的なオフィス環境も良好(アクセスの良さ、街の雰囲気、新築で入居したオフィスetc. )
• 開発メンバーはブースで区切られているデスクも使用可能で、集中しやすい |
2.3 開発環境
2.3.1 Web
- BtoCプロダクト (Canary)
- 技術スタック
- TypeScript / ESLint / PrettierによるDX向上
- Storybook駆動でのコンポーネント開発
- Jest / ReactTestingLibraryによるUnitテスト
- Next.jsによるSSR
- google search consoleなどを用いて分析を行いつつSEO改善
- ReduxによるFluxアーキテクチャ
- API Routesを経由したバックエンドAPIとのgRPC通信
- styled-componentsを用いたスタイリング
- 取り組んでいる主な課題
- SEO改善
- パフォーマンス改善のためのバンドルサイズ削減やWebVitalの見直し
- リアルユーザーモニタリング / 合成モニタリング 環境整備
- ディレクトリ、コンポーネント設計の見直し
- テスト戦略の議論 / テストカバレッジの向上
- リグレッションテストの整備
‣
- BtoBプロダクト (Canary Cloud)
- 技術スタック
- TypeScript / ESLint / PrettierによるDX向上
- Storybook駆動でのコンポーネント開発
- Jest / ReactTestingLibrary によるUnitテスト
- reg-suit / storycapによるVisual Regression Test
- Next.jsでのクライアントサイドレンダリング
- React Queryによる非同期処理の抽象化とキャッシュ戦略
- Sentryによるロギング
- ChakraUIをラップしたAtomコンポーネント共通化
- 取り組んでいる主な課題
- デザインシステムの強化
- CSS Modules→デザインシステムへの移行
- パフォーマンス改善のためのバンドルサイズ削減やWebVitalの見直し
- リアルユーザーモニタリング / 合成モニタリング 環境整備
- Sentryによるエラーモニタリングの効率化
- テスト戦略の議論 / テストカバレッジの向上
- E2Eテストの導入
- リポジトリの分離、モノレポ化
- React Queryを用いたキャッシュの運用と非同期処理層の分離
- formik→react-hook-formへの置き換え
‣
2.3.2 アプリ
- 技術スタック
- Expo Bare WorkflowによるReact Native開発
- EASの環境を整備（EAS build, EAS Submit）
- TypeScript / ESLint / PrettierによるDX向上
- 状態管理はRedux Toolkitを使用
- E2Eテストを整備（MagicPod）
- Sentryによるロギング
- GitHub ActionsによるCIを整備
- FirebaseのRemote Configを用いたABテスト
- 技術に対する姿勢
- 移り変わりの速いライブラリなどの潮流を追いつつ、長期的な保守性やパフォーマンスなどのKPIを高いレベルで達成できるような技術選定をしています。
- Reduxで実装していたstate管理をRedux Toolkitに移行し、stateとview側の別々での管理をより容易にしています。
‣
2.3.3 バックエンド
- 技術スタック
- Monorepo / Microservices
- チームのスケールや迅速な変化への対応を目的として、2021年から Monorepo / Microservices による実装を行なっています。
- 以前から存在するコードベースに関しても、徐々に Microservices へ移行していく予定です。
- Go / gRPC
- 言語としては Go が多く、各 microservice の疎通には gRPC を採用しています。
- 基本的に test code は書くようにしており、test coverage は常に90%以上となるようにしています。
- Client との疎通に関しては、 grpc-gateway や、 grpc-web を利用しています。
- Buf / Ko
- proto から gRPC / gRPC-gateway / OpenAPI（swagger.json） を生成する際には、Bufを利用しています。
- docker image の build や push には、GCP と親和性の高いGoogle の ko を利用しています。
- CloudSpanner / Datastore / Elasticsearch
- 各種データの保存に関しては、上記のサービスを利用しています。
- Cloud Spanner と Datastore の使い分けに関しては、現状全て Cloud Spanner に移行していこうという流れになっており、一部移行できていない Datastore の実装が残っているという状態です。
- Elasticsearch に関しては、Cloud Spanner の検索機能では対応しきれない物件の検索時等に使用しています。
- また上記以外にも、各種インフラに関しては terraform で管理するようにしています。
- GKE（Multi Cluster） / Anthos Service Mesh
- コンピューティング部分に関しては、上記のサービスを利用しています。
- クラスタを冗長化するために Multi Cluster の運用をしており、各種 manifests は kustomizeで管理しています。
- Service Mesh には、managed のメリットの大きさから Anthos Service Mesh を利用しています。
- GitHub Actions / PipeCD
- CI には、GitHub Actions を利用しています。
- CD には PipeCD を利用しており、Progressive Delivery によるデプロイを行なっています。
- 取り組んでいる主な課題
- 各種メトリクス・アラートに対するモニタリング強化
- 日々発生するトイル（定常業務）を削減するための仕組み化・自動化
- 複数リポジトリ（コードベース）の統一化による開発生産性向上
‣
2.3.4 その他 開発組織としての取り組み
- エンジニアチームの技術力・生産性向上のための施策
- 技術検証や学習のためのサンドボックス環境（GCPプロジェクト等）を個々のメンバーで利用できます。
- 経費で技術書など必要なものがあれば基本的に購入可能です。
- 希望メンバーについては GitHub Copilot や ChatGPT Team を利用可能です。
- React Native界隈を盛り上げるための貢献
- React Nativeに関する国内最大のイベントであるReact Native Matsuriに2年連続スポンサー協賛しています。下記はゴールドスポンサーとして参加したReact Native 2022のスポンサーセッションの詳細です。
- ※ その他技術イベントについても、今後積極的に参加していく予定です。
2.3.5 オフィスなどの雰囲気
- もちろんフルリモート可ですが、出社時にも最高のパフォーマンスを出せるような環境作りには力を入れています。
- 各種社内アクティビティには、エンジニアも積極的に参加して他部署メンバーとの交流を図っています。
3. 採用情報
カナリーでは、様々な事業・職種でエンジニア採用を随時行っています！
一覧や各募集の詳細については、以下のページをご覧ください。
また、「もう少しカナリーについて知りたい！」という方は、採用責任者の眞砂↓までお気軽にご連絡ください！（XのDMを開放しています）