Engineer Entrance Book
Engineer Entrance Book

Engineer Entrance Book

icon
💡 最終更新：2023/07

お部屋探しポータル「Canary」が、累計ダウンロード300万件を突破しました！🎉

このEntrance Bookは、株式会社BluAgeに興味を持ってくださったエンジニアの方に向け、会社やエンジニア組織、働き方などについて知っていただくためのものとなっています。

ぜひ最後までご覧ください。

1. BluAgeについて

1.1. 会社概要

私たちBluAgeは、【もっといい「当たり前を」つくる】をミッションとして、デジタルの力で業界のDXを牽引するスタートアップです。

1.2. サービス概要

主力サービスのtoCお部屋探しポータル「Canary」は、2019年6月のリリースから、 累計ダウンロード300万件を突破。

App Storeの評価は★4.8でカテゴリ内トップ。優れたUI/UXを強みとしています。

2022年末に本格立ち上げとなったtoBの不動産仲介会社向けSaaS「Canary Cloud」も、大手仲介会社への導入事例などもあり急速成長中です。

また、2022年9月には、家電業界最大手の株式会社ヤマダホールディングスと資本業務提携を締結し、10億円の第三者割当増資を実施しました。

会社としての大きな通過点の1つである上場に向け、加速度的な成長を続けています。

1.3. 会社公式note・テックブログ

公式note（記事抜粋）

テックブログ

2. 開発組織について

2.1 大事にするもの

2.1.1 2つの視点

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

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

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

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

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

2.1.2 バリューについて

BluAgeでは、ミッション達成のために開発組織の全メンバーが拠り所とすべき行動指針としてバリューを4つ定めており、それぞれに対して「DO/DON’T」という具体的な行動例まで策定しています。

  1. 圧倒的なオーナーシップを持とう
    • DO
      • 自分自身が立ち上げた会社のつもりでベストと考える行動を取り続ける
      • 組織を自らが作っていく意識を持ち、採用・育成にも全力を尽くす
      • エンジニア、UX、UI、QA、営業といった役割に閉じず、ことに向かって貢献する
      • ラストマンシップを持っている
    • DON’T
      • 他責思考
      • 自分だけよければいいという考えのもとの判断や行動
      • 障害などの問題が発生しても、「誰かが対応してくれるはず」とスルーしてしまう

  2. プロフェッショナリズムを全うしよう
    • DO
      • クラフトマンシップを持ち、細部にも妥協しないものづくりをする
      • 自分のやったことが、どのようなアウトカムを生み出しているかを意識する
      • AND思考で動く
      • 仕組み化・ショートカットできるポイントを積極的に見つけつつ、最後に泥臭く向き合わなければならない点にはしっかり向き合う
      • 一人のビジネスパーソンとして、ベーシックなビジネススキルの研鑽・生産性向上に努める
    • DON’T
      • 小さな違和感を放置してしまう
      • アウトプットだけで満足している
      • 目の前のタスクに追われ、積み上げ思考になってしまっている
      • 制約を満たしていない解決策を出す
      • 実行を伴わない評論家になっている

  1. 挑戦を諦めない
    • DO
      • 未知の領域の壁でも学習と挑戦で乗り越えていけると信じる
      • 現状のプロダクト・ユーザ体験をもっとよくできるという確信を持ち、より良い解決策をゼロベースから常に模索する
      • ストレッチゾーンを主戦場にする
      • 全社戦略から逆算された高い目標に向けて行動している
    • DON’T
      • 自分自身の力が全てだと思い込み、まわりを巻き込むのを忘れてしまう
      • コンフォートゾーンにとどまる
      • 仮説を持たない状態で、向こう見ずなことを実行してしまう

  1. 誠実さを体現しよう
    • DO
      • 自社がユーザー・顧客にとってベストな選択肢になる努力をする
      • 自分と他人には情報の非対称性がある事を理解し、誠実にその差分を埋める努力をする
      • 誠実に冷静な目でプロダクトを見極め、自身のフィールドに関係なく改善する
      • 遠慮はしないが、配慮は常にする
      • 技術的負債の返済も長期的にはプロダクトの価値の源泉になると認識する
    • DON’T
      • チームよりも自分を優先する
      • うそをつく
      • 憶測や印象でメンバーにフィードバックする
      • ユーザ、顧客、他のチームから信頼を損ねるような行動をしている
      • 自分しか分からないコードと分かっていても、コメントなしでコミットしてしまう

2.2 開発組織

2.2.1 チームのトポロジー

Team Topologiesの考え方を取り込みつつチームを構築しています。具体的には、以下の様なチームを構成しています。

▼こちらの記事でも詳しくお話しています！

  • Stream Aligned Team
    • Canary ポータルチーム（toC: お部屋探しユーザー向け）
    • Canary Cloud チーム（toB: 仲介会社向け SaaS）
  • Enabling Team
  • Platform Team
image

※ 現状のBluAgeではComplicated Subsystem Teamは必要ないと考えるので作らない

BluAgeではこれから売買領域や賃貸管理領域などさらに多くのドメインにサービスを提供していく可能性があり、そうなった時にも適切な摂理面でチームを切りつつ、チームが自律性を持ちながら可能な限りフリクションなく価値を生み出していける状態を目指します。

2.2.2 メンバー構成

  • 正社員：15名
    • Webフロントエンド: 4名
    • モバイルアプリ: 3名
    • バックエンド: 8名
    • 各チームに厳密な区切りがあるわけではなく、必要に応じて他の領域における開発に工数を割くこともできます。（何にどの程度の工数を割くかは、チームの状況や個人の裁量に委ねられます。）
  • 副業・業務委託メンバー：稼働量の多寡はありますが、5~10名ほどが参画してくださっています
  • インターン生：社員側のキャパシティなどにもよりますが、インターン生は業務経験を問わず積極的に受け入れており、常時3~4名ほどが参画してくださっています

という体制で現在開発を行っています。プロダクトの成長に人員がまだまだ追いついていない状況です。

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

  • 裁量を持ったときに抽象度が高いタスクをアクションに落とし込み自走し、難しい状況を突破し、業務遂行し切ることができる力を持っているメンバーが集まっています。
  • 働き方も多様で、メンバーそれぞれが生産性や成果を最大化できるスタイルで働いています。
    • もちろんフルリモートでの勤務も可能です。（毎日出社しているメンバーもいれば、フルリモートで働いているメンバーや半々程度のメンバーもいます）
  • エンジニアは業務において裁量権を大きく持って働いています。
    • 開発だけをするわけではなく、要件定義のフローからビジネス側の議論に参加することが多いです。
    • 施策内容などに対する意見は職種問わずフラットに受け入れる文化があります。
  • 技術に対する姿勢に関しても、組織全体として理解する文化があります。
    • 短期的な視点ではなく、将来的な事業のスケールや採用面でのメリットなども総合的に考慮した上で技術選定を行っています。
    • 新しい技術に対する抵抗は少なく、選定基準をクリアしていれば積極的にモダンな技術を採用しています。
    • 技術検証や学習のためのサンドボックス環境（GCPプロジェクト等）を個々のメンバーで利用できます。
    • 技術力向上のために、経費で技術書など必要なものがあれば基本的に購入可能です。
    • 2023/5より、GitHub Copilot 導入支援開始を開始しました
      • 希望メンバーについては、BluAgeのOrgで取得したGitHub Copilotのライセンスを付与

2.3 開発スタイル

2.3.1 Web

  • BtoCプロダクト (Canary)
    • 技術スタック
      • image
    • TypeScript / ESLint / PrettierによるDX向上
    • Storybook駆動でのコンポーネント開発
    • Jest / ReactTestingLibraryによるUnitテスト
    • Next.jsによるSSR
    • google search consoleなどを用いて分析を行いつつSEO改善
    • ReduxによるFluxアーキテクチャ
    • API Routesを経由したバックエンドAPIとのgRPC通信
    • styled-componentsを用いたスタイリング
    • 取り組んでいる課題
      • SEO改善
      • styled-componentsからzero runtime cssへの移行検討
      • パフォーマンス改善のためのバンドルサイズ削減やWebVitalの見直し
        • リアルユーザーモニタリング / 合成モニタリング 環境整備
      • 脱Reduxを行いシンプルな構成への移行
      • ディレクトリ、コンポーネント設計の見直し
      • テスト戦略の議論 / テストカバレッジの向上
      • リグレッションテストの整備
  • BtoBプロダクト (Canary Cloud)
    • 技術スタック
        • image
      1. TypeScript / ESLint / PrettierによるDX向上
      2. Storybook駆動でのコンポーネント開発
      3. Jest / ReactTestingLibrary によるUnitテスト
      4. reg-suit / storycapによるVisual Regression Test
      5. Next.jsでのクライアントサイドレンダリング
      6. React Queryによる非同期処理の抽象化とキャッシュ戦略
      7. Sentryによるロギング
      8. ChakraUIをラップしたAtomコンポーネント共通化
    • 取り組んでいる課題
      • デザインシステムの強化
      • CSS Modules→デザインシステムへの移行
      • パフォーマンス改善のためのバンドルサイズ削減やWebVitalの見直し
        • リアルユーザーモニタリング / 合成モニタリング 環境整備
      • Sentryによるエラーモニタリングの効率化
      • テスト戦略の議論 / テストカバレッジの向上
        • E2Eテストの導入
      • リポジトリの分離、モノレポ化
      • React Queryを用いたキャッシュの運用と非同期処理層の分離
      • formik→react-hook-formへの置き換え
  • メンバーについて / チームの雰囲気
    • 年齢層は20代がもっとも多く、平均年齢は27歳程度です。
    • 自走力があり、チャレンジングな課題でも協力しつつ積極的に取り組むメンバーが集まっています。また各メンバーが思いやりを持ち、居心地のいい空気感を保つようにしています。
    • 毎日相談できる時間を設けたりこまめにペアプログラミングを行うなど積極的にコミュニケーションして開発に取り組んでいます。
    • フロントエンドの最新情報を流すチャンネルがあったり、雑談時に取り入れたい技術について皆で調べるなど、日々フロントエンド技術の進化を追うことを楽しんでいます。
    • ドキュメンテーションをこまめに行なっており、オンボーディング資料や技術選定から障害対応マニュアルや技術負債についてなどプロジェクトの様々なことがすぐに把握できる環境を目指しています。

2.3.2 アプリ

2.3.3 バックエンド

  • 技術スタック
    • Monorepo / Microservices
      • チームのスケールや迅速な変化への対応を目的として、2021年から Monorepo / Microservices による実装を行なっています。
      • 以前から存在するコードベースに関しても、徐々に Microservices へ移行していく予定です。

      image
    • Go / gRPC
      • 言語としては Go が多く、各 microservice の疎通には gRPC を採用しています。
      • 基本的に test code は書くようにしており、test coverage は常に90%以上となるようにしています。
      • Client との疎通に関しては、 grpc-gateway や、 grpc-web を利用しています。

      image
    • Buf / Ko
      • proto から gRPC / gRPC-gateway / OpenAPI（swagger.json） を生成する際には、Bufを利用しています。
      • docker image の build や push には、GCP と親和性の高いGoogle の ko を利用しています。

      image
    • CloudSpanner / Datastore / Elasticsearch
      • 各種データの保存に関しては、上記のサービスを利用しています。
      • Cloud Spanner と Datastore の使い分けに関しては、現状全て Cloud Spanner に移行していこうという流れになっており、一部移行できていない Datastore の実装が残っているという状態です。
      • Elasticsearch に関しては、Cloud Spanner の検索機能では対応しきれない物件の検索時等に使用しています。
      • また上記以外にも、各種インフラに関しては terraform で管理するようにしています。

      image
    • GKE（Multi Cluster） / Anthos Service Mesh
      • コンピューティング部分に関しては、上記のサービスを利用しています。
      • クラスタを冗長化するために Multi Cluster の運用をしており、各種 manifests は kustomizeで管理しています。
      • Service Mesh には、managed のメリットの大きさから Anthos Service Mesh を利用しています。

      image
    • GitHub Actions / PipeCD
      • CI には、GitHub Actions を利用しています。
      • CD には PipeCD を利用しており、Progressive Delivery によるデプロイを行なっています。

  • メンバー
    • 人数に関しては、上述の通りです。また年齢層は20代がもっとも多く、平均年齢は25歳前後となっています。
    • 技術力も大事な観点の一つであると認識していますが、よりマインド・人間性を重視するチームでありたいとメンバー各員が考えています。

3. 採用情報

BluAgeでは、様々な事業・職種でエンジニア採用を随時行っています！

一覧や各募集の詳細については、以下のページをご覧ください。

また、「もう少しBluAgeについて知りたい！」という方は、採用責任者の眞砂↓までお気軽にご連絡ください！（TwitterのDMを開放しています）

https://twitter.com/masagotty

BluAge 採用情報トップ

©BluAge Corp.