お部屋探しポータル「Canary」の累計ダウンロードが400万件を突破しました🎉
また、内容を大幅にアップデートしました！
この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.2.5 カナリーでエンジニアとして働く魅力
- 2.3 開発環境について
- 2.3.1 技術スタックと課題
- 2.3.2 開発の進め方・流れ
- 2.4 開発組織全体の課題感
- 2.4.1 採用の強化
- 2.4.2 マネージャー層の強化
- 2.5 採用広報の取り組み
- 2.5.1 テックブログ（‣）
- 2.5.2 LTイベントへの登壇
- 2.5.3 各種イベントなどへのスポンサー
- 2.6 福利厚生など
- 2.7 オフィスなどの雰囲気
- 3. 採用情報
- 3.1 選考フロー
- 3.2 募集中のポジション
- 3.3 さいごに
1. 株式会社カナリーについて
1.1. 会社概要
私たちカナリーは、【もっといい「当たり前を」つくる】をミッションとして、デジタルの力で業界のDXを牽引するスタートアップです。
Company Deck（会社紹介資料）
1.2. 事業・サービス概要
主力サービスのtoCお部屋探しポータル「Canary」は、2019年6月のリリースから、 累計ダウンロード400万件を突破。
App Storeの評価は★4.8でカテゴリ内トップ。優れたUI/UXを強みとしています。
2022年末に本格立ち上げとなったtoBの不動産仲介会社向けSaaS「Canary Cloud」も、大手仲介会社への導入事例などもあり急速成長中です。
また、2024年3月には、株式会社クレディセゾンと10億円の資本業務提携を締結しました。
新たな事業の柱として、DXソリューションズ事業も展開。
家具家電業界最大手のヤマダホールディングスなどのDX推進を行っており、
今後さらなる拡大・事業成長を目指し組織を強化中です。
1.3. 会社公式note・テックブログ
公式note（記事抜粋）
- カナリーの開発組織について：Team Topologiesの話や、組織の雰囲気の話
- 「個々のメンバーがやりたいことと事業の方向性をアラインさせる」VPoEが語る、カナリーの開発組織への想い
- 「より良いプロダクトを目指していくための『作り方を作る』役割」 CTOがカナリーで目指すこと
テックブログ
2. 開発組織について
2.1 大事にするもの
2.1.1 2つの視点
カナリーのエンジニアは2つの視点を大事にしていきたいと考えています。
- 課題解決に挑戦するソフトウェアエンジニア
- プロフェッショナルとしてアウトプットに誇りを持つ
カナリーは【もっといい「当たり前」をつくる】というミッションを実現するため、既存の「当たり前」を超えてよりよいユーザー体験を追求していく必要があります。そのためには、「バックエンド」や「フロントエンド」といった職能・役割に閉じずに、ユーザーの新しい体験全体を作り上げるという意識が必要だと考えています。その様な意味を込めて「課題解決に挑戦するソフトウェアエンジニア」を目指したいと考えています。
一方で「課題解決が目的でありエンジニアリングは手段」という見方が強くなってしまうと、エンジニアリングを軽視しているのかの様に見えてしまうかもしれません。決してそうではなく、複雑な課題を解決し、それを継続的に強化していくためのコードベースを維持するためには高い技術と強い意思が必要ですし、リスペクトすべきものだと考えています。そういった姿勢がなくては、いつしかコードが腐敗しメンテナンス不可能になってしまうでしょう。目的志向と技術志向はお互いに欠かすことのできない両輪であり、課題解決を行うソフトウェアを高い品質でデリバーする事を目指し、そのアウトプットに誇りを持ちたいと考えています。
また、課題解決に精一杯取り組むが故に（時間的に）新しいスキルの習得が難しくなるといった現実的な課題があることも認識しており、後述する新たに構築するチーム（Enabling Team）などを通じて、エンジニアリングスキルの向上にも挑戦していきます。
2.1.2 バリューについて
2.2 組織紹介
2.2.1 チーム編成・体制
▼こちらの記事でも詳しくお話しています！
2024年9月時点でのチーム編成は下記のようになっています。
図中の各チームと PLE/TLE/SWE の役割について以下説明します。
- チームについて
- Stream Aligned Team
- 顧客に直接インパクトをもたらすプロダクト毎の開発ループを回すチーム
- 現在のチーム
- Canary ポータルチーム（toC: お部屋探しユーザー向け）
- Canary Cloud チーム（toB: 仲介会社向け SaaS）
- （新規プロダクトチーム）
- 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.2.2 一部メンバー紹介
🎤 各ページ内にインタビュー記事なども掲載しているので、是非ご覧ください！
2.2.3 エンジニアの特徴・働き方
- 抽象度が高い課題をアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っているメンバーが集まっています。
- 働き方も多様で、メンバーそれぞれが生産性や成果を最大化できるスタイルで働いています。
- リモート勤務について
- 北海道や関西といった各地方に在住のメンバーも多く、完全なフルリモートが可能です。
- フルリモート以外だと、「週の半分くらい出社」「ほぼ毎日出社」といった形で各自に合った出社頻度を選択しています。
- その他
- 勤怠管理はSlackコマンド1つで入退室の記録が可能であるなど、できる限り本質的な業務に使える時間を最大化するための運用を作っています。
- リモートが多い中でもメンバー同士がチーム感を持って気軽にコミュニケーションできる環境作りの一環として、Gather（バーチャルオフィスツール）を開発本部全体で導入しました。
- エンジニアは業務において裁量権を大きく持って働いています。
- （プロダクトやフェーズにもよりますが）開発だけでなく、要件定義のフローからビジネス側の議論に参加するケースもあります。
- 施策内容などに対する意見は職種問わずフラットに受け入れる文化があります。
- 技術に対する姿勢に関しても、組織全体として理解する文化があります。
- 短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行っています。
- 新しい技術に対する抵抗は少なく、選定基準をクリアしていれば積極的にモダンな技術を採用しています。
2.2.4 エンジニアのキャリアパス・グレード・給与レンジ
カナリーでは、全社共通の6段階のグレードを定義しており、エンジニアなどの職種が属する開発本部では、グレードごとの給与レンジを定義しています。
- 専門職に関しては、組織を構築・牽引することのみに限らずその専門性によって事業に突き抜けた貢献をすることもできるという考えのもと、スペシャリストという形でグレードに対する期待を併記しています。
- ただし、専門職であっても組織的な貢献をする方が得意な人もいるので、実際にはどちらか一方を選ぶというようなシンプルなキャリアパスにはならない可能性があると考えています。
- 開発本部のグレードごとの給与レンジ（年額給与。単位：万円）
- 開発本部のグレードの定義
- 現在、個々のメンバーのキャリアパスについてはマネージャー（主に各チームのPLE）との1on1などを通して方向性をすり合わせ、その道へ進むのに必要な要素を目標設定に落とし込んだり、最適なアサインのための判断材料として活用するといった形で支援を行なっています。
- 今後、組織が拡大する中で各メンバーの志向性もさらに多様化してくるため、上述のグレードに加え、それらを適切に吸収・評価できる制度や枠組み（キャリアラダーなど）の設計にも取り組んでいます。
グレード | 不確実性の
範囲のイメージ | 期待 |
G6 | 会社 | 業界のトレンドや潮目を見極め、その中での会社の中長期的なあり方を定められる。また、それを実現するための方針や戦略、組織を立案し実現することができ、会社およびその将来に対して多大なインパクトをもたらすことができる。
スペシャリストは世界的に高いレベルの専門性を有し、自身の専門性を活用して会社およびその将来を革新する多大なインパクトをもたらすことができる。 |
G5 | 事業 | 経営方針や戦略を理解し、（複数のプロダクトからなる）事業の中長期的なあり方を定められる。また、それを実現するための方針や戦略、組織を立案し実現することができる。
スペシャリストは社外でも高いレベルの専門性を有し、複数のプロダクトに影響のある高度に複雑な仕事でも完遂のための方針・戦略を立案し実現することができる。 |
G4 | プロダクト | 経営方針や戦略を理解し、プロダクト、開発のあり方を定める事ができる。また、それを実現するための方針や戦略、チームを不確実性が高い状態でも立案し実現することができる。
スペシャリストは社内でも高いレベルの専門性を有し、プロダクト、チーム内での難易度の高い課題も解決する事ができる。また、自身の領域において他メンバーが仕事を進める際の適切な方針を定めることができる。 |
G3 | ユースケース | 経営方針や戦略、チームの方針や戦略を理解し、プロダクトに必要な一連のユーザー体験を不確実性がある状態でも上位の方針や状況に照らし合わせて最適な手段を取り、自走して設計、実現することができる。複数人での取り組みではリーダーシップを発揮して仕事を推進することができる。 |
G2 | 機能 | 経営方針や戦略、チームの方針や戦略を理解し、プロダクトに必要なユーザー体験を実現する一部の領域を一定の不確実性の中では自走しながら完遂する事ができる。 |
G1 | キャッチアップ | 経営方針や戦略、チームの方針や戦略、必要なスキルを自主的にキャッチアップでき、不足する部分は周囲のサポートを受けつつも不確実性の限られた仕事は最後まで完遂することができる。 |
2.2.5 カナリーでエンジニアとして働く魅力
| 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 技術スタックと課題
Canary ポータルチーム
- アプリ
- 技術スタック
- 取り組んでいる主な課題
- 開発環境改善
- エンジニアメンバーの開発環境の整備
- モバイルアプリの開発は各エンジニアメンバーの環境差異に影響を受けやすく、環境構築がスムーズにいかないなどの問題が発生しやすいため、それらの差異を吸収できるような仕組みを整備したい。
- ディレクトリ構造のリファクタ
- 初期リリースから4-5年が経過する中で、構造が複雑になってしまっている箇所が多々あるため、理想的なディレクトリの形へと修正していきたい。
- 運用改善
- モニタリング方法の改善による運用工数の削減（Datadogの導入）
- UI/UX改善施策の推進
- カナリーの強みの1つであるUI/UXをさらに改善するための施策実装を推進していきたい。
- Webフロント
- 技術スタック
- 取り組んでいる主な課題
- テスト関連
- テスト戦略の議論 / テストカバレッジの向上
- リグレッションテスト/e2eテストの整備
- 開発環境改善
- バンドルサイズ削減やWebVitalの見直し
- リアルユーザーモニタリング / 合成モニタリング 環境整備
- テスタブルなディレクトリ構造へのリアーキテクチャ、コンポーネント設計の見直し
- SEO改善
- より多くのユーザにサイトを訪れてもらうための改善施策
- バックエンド
- 技術スタック
- 取り組んでいる主な課題
- システムモニタリングの自動化・改善サイクル構築
- アプリケーションのエラーやリソース逼迫等によるアラートの整備はある程度できているが、それだけではカバーし切れない項目については日次モニタリング（当番制）でカバーしている状況。
- これらモニタリングの自動化を進めるだけでなく、発見された課題を改善するまでのサイクルを構築していきたい。
- 物件掲載に伴うトイルの削減
- 掲載中の物件情報や店舗情報の変更などの作業（トイル）について、一定の仕組み化は進んでいるものの、まだまだエンジニアの手を要する部分が残っている状況。
- それらのトイルを削減することで、メンバーがエンジニアリングに向き合う時間を最大化したい。
- データの整備と仕組み化
- 物件同士の「名寄せ」の仕組み改善
- Canaryは、ポータルサイトとして多数の不動産仲介会社から物件データを受け取っているため、ある実在の部屋（「○○マンションのy号室」）に対して取扱会社が異なる複数の部屋レコードを保持することがある。
- それらをユーザに対して表示する際、情報をまとめるために「部屋Aと部屋Bが同じかどうか」を建物名/階数/賃料などから判別する必要があり、これを「名寄せ」と呼んでいる。
- 現在も一定の「名寄せ」ロジックがあるが、本来同一と見なすべき物件同士を別物として判定してしまうなどの事態がより起こりづらいロジックに改善していくことを目指している。
- 沿線・エリア等のマスタ系データ整備
- 名称変更や統合などが発生する沿線・エリア等のマスタ系データについて、それらを最新の状態に保つための仕組みを作りたい。
- Canary Cloudチーム
- Webフロント
- 技術スタック
- 取り組んでいる主な課題
- featuresアーキテクチャへの移行(現在進行中)
- hooksやviewが肥大化していて機能改修時のコードリーディングコストが高い状態。
- 機能ごとに切り出して疎結合にすることで見通しを良くしたり、車輪の再発明を防ぐような実装にしていきたい。
- Sentryによるエラーモニタリングの効率化
- 現在はSentryを用いてエラーモニタリングをしているが、運用をまだ定めきれていなかったりトリアージフローを仕組み化できていない状態。
- 現状溜まってしまっているアラートを精査し、クリティカルなアラートに気付きやすくするための仕組み作りをしていきたい。
- feature flagの導入
- マルチテナント構成において、現在はハードコーディングで各テナントにおけるイレギュラー対応をしている状態。
- また、カナリアリリースができておらず障害時の影響範囲が大きくなっている状態。
- 開発体験の向上、障害影響の最小化に向けて導入していきたい。
- story bookの本格運用
- 現在はデザイナーへのレビューが機能完成時点となっており、手戻り発生時の影響が大きい状態。
- 完成時点でのレビューは、デザイナー視点でも「修正の指摘がしづらい」「自分がデザインしてから日が経っているのでレビューがしにくい」といったデメリットがある。
- story bookは導入しているものの有効活用できていないため、運用を軌道に乗せてデザイナーと質の高いレビューができるようにしたい。
- バックエンド
- 技術スタック
- 取り組んでいる主な課題
- 日々発生するトイル（定常業務）を削減するための仕組み化・自動化 (現在進行中)
- マルチテナント構成により、データの複製やデータの新規作成業務が頻発する中、それらを開発側でカバーしている状態。
- これらを削減するためのオペレーション改善をしていきたい。
- ディレクトリ構成の見直し (現在進行中)
- ディレクトリ階層が少ない影響で、トランザクション境界が広すぎたり各階層における責務が不透明な状態になってしまっている。
- メンバー間で議論しながら新たに階層を増やしたり移行作業を進めていきたい。
- キャッシュ機構の導入
- 現在はほぼ全てのRead系APIで Spanner を直接参照しており、キャッシュを活用できていない状態。
- CRMのさらなるグロースに向けて、キャッシュサーバやブラウザキャッシュを用いてユーザ体験の向上及びコスト削減をしていきたい。
2.3.2 開発の進め方・流れ
- 各チーム、基本的にはプロジェクト形式で開発を進めています。
- = プロダクトとしてやりたい事（もしくは解決したい課題など）に対して都度エンジニアがアサインされ、そのプロジェクトを推進していく形。
- 「プロジェクト」の例（Canary ポータルチーム）
- 物件レコメンド機能のロジック改修
- 物件詳細ページ タイトル部分のUIスタイル改修
- 不要となったxx機能のコード削除
- …
- 厳密にスプリント（例えば2週間）の中で開発項目やvelocityを管理している訳ではないため、いわゆる”スクラム開発"ではありませんが、週1回など定期的に各プロジェクトの進捗をチームメンバー全員で確認する機会があるなど、スクラム的な要素も含まれています。
- 開発の大まかな流れ
- 中長期的な開発ロードマップは、PdMやプロダクトのリードエンジニアを中心に作成しています。
- ロードマップから開発チケット（背景や要件、デザインなどを記載）へ落とし込み、それぞれのチケットに対してアサインされたエンジニアがプロジェクト形式で開発を進めていきます。
- 1つのチケットを担当するエンジニアは、規模にもよりますが1-3名です。
- 設計・実装・テスト・リリースが完了したら、新たに別チケットの開発へと移ります。
- 各開発チケット（プロジェクト）の進め方
- 設計
- 一定規模以上の機能開発などについては、DB設計・APIインターフェース・シーケンス図などを含む設計を用意し、各領域のTLE（テックリード）らからレビューを受けます。
- 実装
- [Canary ポータルチーム]
- ある程度の粒度でPRを区切り、各PRが approve された時点で main ブランチにマージします（トランクベースの開発に近いです）。
- [Canary Cloudチーム]
- 機能単位のブランチを切り、そこに対してある程度の粒度で区切ったPRをマージしていくことが多いです。
- [共通]
- 実装中の不明点は、Slack の huddle などで他メンバーへ随時相談するなどして解消しています。
- テスト
- コードベースについては、関数・メソッド単位での単体テストを中心に品質を担保しています。
- リリース
- [Canary ポータルチーム]
- 基本的には main ブランチへのPRマージの度にリリースをします（1日平均3-5回）。
- リリース対象は、変更のあった microservice のみです。
- [Canary Cloudチーム]
- できる限りこまめなリリースを行なっています。
- 緊急性を要するもの以外は、ユーザーである仲介会社様の利用頻度が低い午後のリリースを心がけています。
- [共通]
- 大きな機能追加などを伴う場合、（実装者・レビュワーの動作確認とは別に）デバッグ会をチームで実施することもあります。
2.4 開発組織全体の課題感
2.4.1 採用の強化
- 特に2024年に入って以降、前例にないハイペースでエンジニア採用が進みましたが、目標としている事業・プロダクトの成長を達成するためには、まだまだ多くのエンジニアの力が必要と考えています。
- 更なる採用の成功のために、カナリーのエンジニア組織や技術的な取り組みに対する「認知」を広げ、より多くの候補者の方と接点を作ることが重要であると捉え、後述のようにテックブログやイベント登壇/協賛など、採用広報にも力を入れています。
2.4.2 マネージャー層の強化
- 採用を通して組織が拡大する中で、「チームの短期的成果を最大化するだけでなく、各メンバーが100%の力を発揮し、中長期的に成長し続けられる状態を作る」といった役割を担えるマネージャー層がより多く必要となっています。
- 補足）弊社では現在EM（マネジメント専門でプレイヤーとしての動きはしない）のような役割を定義していません。ここでの「マネージャー層」は主に各チームの PLE（プロダクトリードエンジニア）を指しています。REF
- 上記課題への取り組みとして、「ベンチャー企業におけるマネジメント力強化」に特化した外部のトレーニングサービスを現在のマネージャー層で受講するなど、組織拡大による歪みや弊害を最小化できるような準備を進めています。
2.5 採用広報の取り組み
2.5.1 テックブログ（
Zenn Canary Tech Blog）
2.5.2 LTイベントへの登壇
![[カナリーVPoE 高山氏]お部屋探しアプリでデータ負債に挑む #データ負債解消2](https://images.spr.so/cdn-cgi/imagedelivery/j42No7y-dcokJuNgXeA0ig/f35d772c-b120-4107-b108-9a4a523ab717/report_DATELT2_takayama/w=640,quality=90,fit=scale-down)
2.5.3 各種イベントなどへのスポンサー
- Go Conference 2024
- 全サービスで Go を採用している企業として、スポンサーをさせて頂きました。
- React Native Matsuri
- React Nativeに関する国内最大のイベントであるReact Native Matsuriに2年連続スポンサー協賛しています。下記はゴールドスポンサーとして参加したReact Native 2022のスポンサーセッションの詳細です。
- 今後も、各種イベントには登壇・スポンサーといった形で積極的に参加していきます。
2.6 福利厚生など
- 休暇
- （有給休暇とは別に）入社時に付与される特別休暇があり、急な用事などで有給付与前に休まざるを得なくなった際などに利用できます。
- PC貸与
- 入社時、メンバーが希望するスペックのMacbookProを貸与しています。
- 技術力・生産性向上のための施策
- 技術検証や学習のためのサンドボックス環境（GCPプロジェクト等）を個々のメンバーで利用できます。
- 技術書など必要なものがあれば、基本的に経費で購入可能です。
- GitHub Copilot を会社のOrganizationにて（= 無料で）利用可能です。
- その他
- 会社近くに居住するメンバーに対する家賃補助制度があります。
2.7 オフィスなどの雰囲気
- もちろんフルリモート可ですが、出社時にも最高のパフォーマンスを出せるような環境作りには力を入れています。
- 各種社内アクティビティには、エンジニアも積極的に参加して他部署メンバーとの交流を図っています。
3. 採用情報
3.1 選考フロー
カナリーでは、お互いに納得が行くまでマッチ度を確認できるよう選考フローを設計しています。
- カジュアル面談
- 書類選考
- コーディングテスト
- 面接(複数回)
- 内定
- オファー面談
3.5. お試し副業 / 1day JOB etc.(場合によって、お互いに必要があると判断したら実施)
3.2 募集中のポジション
カナリーでは、様々な事業・職種でエンジニア採用を随時行っています！
一覧や各募集の詳細については、以下のページをご覧ください。
3.3 さいごに
「もう少しカナリーについて知りたい！」という方は、採用責任者の眞砂↓までお気軽にご連絡ください！（XのDMを開放しています）