【フルリモート/Go】×[400万DLのBtoC部屋探しポータル]や[不動産仲介会社向けBtoB SaaS]の開発！バックエンドエンジニア

■会社・事業について
株式会社カナリーは、【もっといい「当たり前」をつくる】をミッションに掲げ、
不動産DX領域で事業展開するスタートアップ企業です。

2021年の約12億円の資金調達（シリーズB）

[モバイルアプリ]
- Expo Bare WorkflowによるReact Native開発
- EASの環境を整備（EAS build, EAS Submit）
- TypeScript / ESLint / PrettierによるDX向上
- 状態管理はRedux Toolkitを使用
- E2Eテストを整備（MagicPod）
- Firebase の Remote Config を用いたABテスト
- GitHub ActionsによるCI整備
- Sentry / Datadog によるモニタリング・エラー検知

[Webフロントエンド]
- Next.jsによるSSR
- TypeScript / ESLint / PrettierによるDX向上
- ReduxによるFluxアーキテクチャ
- styled-componentsを用いたスタイリング
- Jest / ReactTestingLibraryによるUnitテスト
- Storybook駆動でのコンポーネント開発
- Statsig を用いたABテスト
- API Routesを経由したバックエンドAPIとのgRPC通信
- Datadogによるモニタリング・エラー検知

[バックエンド/インフラ]
- Microservices
    - チームのスケールや迅速な変化への対応を目的として、Microservices を採用
    - 以前から存在するコードベース（Monorepo）から徐々に Microservices へ移行する作業を行なっており、2024年現在ではほぼ全てのコードが Microservices の上で動作中
- Go / gRPC
    - アプリケーションは Go で書かれており、各 microservice の疎通には gRPC を採用
    - 基本的に test code は書くようにしており、test coverage は常に90%以上を維持
    - Client との疎通に関しては、 **grpc-gateway** を利用
- Buf / Ko
    - proto から gRPC / gRPC-gateway / OpenAPI（swagger.json） を生成する際には B**uf** を利用
    - docker image の build や push には、GCP と親和性の高いGoogle の **ko** を利用
- Cloud Spanner / Elasticsearch
    - 各種データの保存に関しては、上記のサービスを利用
    - Elasticsearch は、Cloud Spanner の検索機能では対応しきれない物件の検索等に活用
    - また上記以外にも、各種インフラを  **Terraform** にて管理
- GKE（Multi Cluster） / Anthos Service Mesh
    - コンピューティング部分に関しては、上記サービスを利用
    - クラスタを冗長化するために **Multi Cluster** の運用をしており、各種 manifests は **kustomize**で管理
    - Service Mesh には、managed のメリットの大きさから Anthos Service Mesh を採用
- Pub/Sub、Cloud Tasks
    - 基本的に、非同期処理を行いたい場合は Cloud Pub/Sub を使用
    - 非同期処理のうち rate limitを設定したい場合など、特定の理由がある場合は Cloud Tasks を使用（ex: バッチ処理など）
- Datadog
    - Microservice でのエラー検知やリソース状況のモニタリング等に活用
- GitHub Actions / PipeCD
    - CI には GitHub Actions を利用中
    - CD には PipeCD を利用しており、**Progressive Delivery** によるデプロイを実施

必須スキル/経験

・コンピュータの基礎的な知識

・設計の基礎的な知識

・ネットワークの基礎的な知識（HTTP, DNSなどのプロトコル含む）

・データベースの基礎的な知識

・セキュリティの基礎的な知識

・バックエンドの開発経験

・バージョン管理システム（Git等）を用いた開発経験

歓迎スキル/経験

・Go言語を利用したシステムの開発経験

・分散システムの開発・運用経験

・大規模データを使った開発・運用の経験

・AWS、またはGCPを用いたシステム構築・運用の経験

・クローラー、検索エンジンの開発経験

・パフォーマンスの最適化の経験

求める人物像

※不動産領域に対する強い熱量やご経験は入社時には必ずしも必要ではありません。

・【もっといい「当たり前」をつくる】というミッションに共感していただける方
・以下の4つのバリューにマッチする方
　①圧倒的なオーナーシップを持とう - 高い視座から物事を眺め、全体最適を達成しよう。会社や組織を自らが作っていくという意識を持とう。
　②プロフェッショナリズムを全うしよう - 深く思考し、速く行動し、相手の期待を超え続けよう。謙虚さを忘れず素直でありながら、昨日の自分を超えて成長しよう。
　③挑戦を諦めない - 常に目的志向で仮説を持ち、失敗や変化を恐れずチャレンジしよう。逆境に見える状況でも粘り強く、愚直に挑み続けよう。
　④誠実さを体現しよう - いつ何時も、全てのステークホルダーに真摯に向き合おう。迷ったときは、短期的なプロフィットよりも中長期的なベネフィットを選ぼう。

・抽象度が高いタスクをアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っている方
・短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行うことができる方
・新しいものに対する抵抗が少なく、（選定基準をクリアしていれば）積極的にモダンな技術を採用する姿勢を持っている方
・ビジネス職のメンバーと議論しつつ要件定義を行うことができる方
・ゆくゆくはフロントエンド領域にも踏み出し、フィーチャーの開発・運用全体を見通しUXに責任を持っていただける方

カナリーのエンジニアは2つの視点を大事にしていきたいと考えています。

1. 課題解決に挑戦するソフトウェアエンジニア
2. プロフェッショナルとしてアウトプットに誇りを持つ

カナリーは【もっといい「当たり前」をつくる】というミッションを実現するため、既存の「当たり前」を超えてよりよいユーザー体験を追求していく必要があります。そのためには、「バックエンド」や「フロントエンド」といった職能・役割に閉じずに、ユーザーの新しい体験全体を作り上げるという意識が必要だと考えています。その様な意味を込めて「課題解決に挑戦するソフトウェアエンジニア」を目指したいと考えています。

一方で「課題解決が目的でありエンジニアリングは手段」という見方が強くなってしまうと、エンジニアリングを軽視しているのかの様に見えてしまうかもしれません。決してそうではなく、複雑な課題を解決し、それを継続的に強化していくためのコードベースを維持するためには高い技術と強い意思が必要ですし、リスペクトすべきものだと考えています。そういった姿勢がなくては、いつしかコードが腐敗しメンテナンス不可能になってしまうでしょう。目的志向と技術志向はお互いに欠かすことのできない両輪であり、課題解決を行うソフトウェアを高い品質でデリバーする事を目指し、そのアウトプットに誇りを持ちたいと考えています。

また、課題解決に精一杯取り組むが故に（時間的に）新しいスキルの習得が難しくなるといった現実的な課題があることも認識しており、後述する新たに構築するチーム（Enabling Team）などを通じて、エンジニアリングスキルの向上にも挑戦していきます。

紹介資料

仕事の魅力

### エンジニアの特徴・働き方

- 抽象度が高い課題をアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っているメンバーが集まっています。
- 働き方も多様で、メンバーそれぞれが生産性や成果を最大化できるスタイルで働いています。
    - リモート勤務について
        - 北海道や関西といった各地方に在住のメンバーも多く、**完全なフルリモートが可能**です。
        - フルリモート以外だと、「週の半分くらい出社」「ほぼ毎日出社」といった形で各自に合った出社頻度を選択しています。
    - その他
        - 勤怠管理はSlackコマンド1つで入退室の記録が可能であるなど、できる限り本質的な業務に使える時間を最大化するための運用を作っています。
        - リモートが多い中でもメンバー同士がチーム感を持って気軽にコミュニケーションできる環境作りの一環として、Gather（バーチャルオフィスツール）を開発本部全体で導入しました。
- エンジニアは業務において裁量権を大きく持って働いています。
    - （プロダクトやフェーズにもよりますが）開発だけでなく、要件定義のフローからビジネス側の議論に参加するケースもあります。
    - 施策内容などに対する意見は職種問わずフラットに受け入れる文化があります。
- 技術に対する姿勢に関しても、組織全体として理解する文化があります。
    - 短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行っています。
    - 新しい技術に対する抵抗は少なく、選定基準をクリアしていれば積極的にモダンな技術を採用しています。

### エンジニアのキャリアパス・グレード・給与レンジ

カナリーでは、全社共通の6段階のグレードを定義しており、エンジニアなどの職種が属する開発本部では、グレードごとの給与レンジを定義しています。（後述のEntrance Book内にて全て公開しております。）

- 専門職に関しては、組織を構築・牽引することのみに限らずその専門性によって事業に突き抜けた貢献をすることもできるという考えのもと、スペシャリストという形でグレードに対する期待を併記しています。
- ただし、専門職であっても組織的な貢献をする方が得意な人もいるので、実際にはどちらか一方を選ぶというようなシンプルなキャリアパスにはならない可能性があると考えています。

- 現在、個々のメンバーのキャリアパスについてはマネージャー（主に各チームのPLE）との1on1などを通して方向性をすり合わせ、その道へ進むのに必要な要素を目標設定に落とし込んだり、最適なアサインのための判断材料として活用するといった形で支援を行なっています。
- 今後、組織が拡大する中で各メンバーの志向性もさらに多様化してくるため、上述のグレードに加え、それらを適切に吸収・評価できる制度や枠組み（キャリアラダーなど）の設計にも取り組んでいます。

メンバー