カナリーの開発組織について：Team Topologiesの話や、組織の雰囲気の話
※元々の公開日：2023/4/20
はじめまして。株式会社カナリー VPoE の高山です。
カナリーは、【もっといい「当たり前」をつくる】をミッションとしているスタートアップです。
日々の暮らしには、不便・非効率がありながらも、過去の延長で「当たり前」と受け入れてしまっていることが溢れていますが、我々は、デジタルの力でこの「当たり前」をアップデートし、もっといい未来をつくっていくことを目指しています。
今回は、そんなミッションを達成するために日々プロダクトに向き合っている開発本部についてご紹介します。
開発本部のミッション
カナリーの開発本部では、全社のものとは別に【レバレッジを最大化させ、事業成長のドライバーになる】というミッションを掲げています。
まだまだ小さなカナリーがもっといい「当たり前」をつくるには、メンバー1人あたりが事業に対して与えられるインパクトを極限まで大きくすることが必要不可欠です。
それを実現するため、テクノロジーに精通した”課題発見・解決のプロ”として、高品質のソリューションを最高速度で提供し続けることを目指しています。
開発チームの雰囲気や特徴
エンジニアの人数としては、正社員が15名ほど、副業/業務委託として稼働いただいているメンバーが（稼働量のグラデーションはありますが）5-10名ほどいます。正社員メンバーの年齢層は20代がもっとも多く、平均年齢は27歳程度です。
常時出社しているのは4-5名で、それ以外のメンバーは日によって出社/リモートを使い分けているケースが多いです。
もちろんフルリモートも可能なので、中には北海道や福岡に住みながら勤務しているメンバーもいます。
自走力があり、チャレンジングな課題でも協力しつつ積極的に取り組むメンバーが集まっています。また各メンバーが思いやりを持ち、居心地のいい空気感を保つようにしています。
雰囲気としては、上述のように「関係性の質」が高い一方、良い意味でキラキラしていないというか、地に足付けて物事を進めるタイプが多いです。
日々のコミュニケーション
社内のチャットツールとしてSlackを利用しています。
基本的に、個人情報などのセンシティブな情報のやり取りがなければチャンネルは全てパブリックとしているため、過去の経緯や背景等のキャッチアップがしやすいです。
エンジニア同士で技術に閉じた話をする際は [#xxx_developers] のような開発者が集まるチャンネルでやり取りしていますが、例えば施策内容のすり合わせや問い合わせ対応等を行う場合は、プロダクト軸（「カナリー」（toC 部屋探しポータル） / 「カナリークラウド」（toB SaaS））のチャンネルでプロダクトマネージャーや営業メンバーとも密にコミュニケーションをとっています。
また、例えば技術的な質問をする際に、テキストではなく口頭でパッと話す方が早そうなケースでは、積極的にSlack Huddle を利用するなどしてチーム全体の業務効率を上げるよう意識しています。
その他の特徴として、メンバーのほぼ全員が自身の分報チャンネル（times）を持っている点が挙げられます。
現在取り組んでいる開発に関する気付き・作業ログなどのまじめなものから完全プライベートのことまで、色々な投稿が飛び交っている（カオスな）チャンネルたちで、メンバー同士のゆるい交流やちょっとした息抜きの場になっていたり？します。
MTG・1on1
開発メンバーがほぼ毎日参加しているのが、チーム毎の「朝会」または「開発定例」です。
自分が取り組んでいる案件の進捗共有や、設計や実装などで困っていることを相談する場として活用しています。
また、隔週などの頻度でチーム単位の KPT を行なっています。
その期間で見つけた開発フロー等に関する Problem（「デバッグ用のダミーデータが欲しい」「PRのレビュー依頼は Slack メンションではなく GitHub 上の Reviewers 指定で良いのでは」etc…）を各自出してもらい、それぞれに対してネクストアクションを決めて改善していくという取り組みです。
💡 今まで結構な回数KPTを実施しているのですが、それでも毎回5-10個くらいの Problem が集まるので、まだまだ開発体験やフローを改善できる余地があるのだなと日々感じています。
1on1についても積極的に実施しており、例えばメンターがついているメンティーの場合は、そのメンターと週1ペースで話す場を設け、仕事を進める上でブロッカーとなっている点の整理や技術的な疑問の解消などを日々行なっています。
その他イベントなど
普段からチームとして頻繁にオフラインで集まる会を開催しているわけではありませんが、年末年始の節目や新メンバー入社などのタイミングで、開発メンバーで集まってご飯に行ったりイベントで盛り上がったりしています。
▼昨年2022年秋には山梨県の山奥で開発合宿も行い、非常に好評でした。今年もやりたい。
▼こちらは、新卒歓迎会の告知の様子です。
制度面
特にエンジニアに関わりの深いものとして、「経費での技術書購入」「技術検証や学習のためのサンドボックス環境（GCPプロジェクト等）提供」があります。
技術書に関しては、実際にメンバーから依頼を受けて購入したものをオフィスに保管（またはPDFとして保存）し、誰でも読めるような形にしています。
また、GCPの個人用プロジェクトを立ち上げて、（一定課金が発生する）GKEクラスタの構築や Kubernetes リソースの作成・操作などを学習目的で行なってもらったケースもあります。
このように、技術力向上に必要と思われることに関しては、制度面でのサポートも今後拡充していきたいと考えています。
※ 現在は、GitHub Copilot や ChatGPT Plus の利用支援も検討中です。
2023/05/02追記：5月より、GitHub Copilot 導入支援（希望メンバーについてはカナリーのOrgで取得したGitHub Copilotのライセンスを付与）を開始しました！
他部署との関わり方
他部署（主に営業本部）ともSlackや直接のMTGなどで関わる機会が一定あり、そういったコミュニケーションが重要だとも考えています。
例えば、
プロダクトに対するお客様からのフィードバック・要望を営業メンバーから開発メンバーへ伝えてもらい、早期改善を行ったり今後の開発ロードマップ策定に生かす
逆に、開発上の理由（例えば工数の兼ね合い）ですぐに実現が難しい機能などがあれば営業メンバーを通じてお客様へ丁寧に説明してもらう
など、お互いが密に連携することでプロダクト改善やお客様の満足度向上に寄与できる場面が多々あるためです。
また仕事以外の場面でも、「社内アクティビティ」の一環として野球やフットサルなどのスポーツを本部の垣根を跨いで一緒に行なったり、半年に1度ほどのペースで開催されるオフラインの全社懇親会でお互いの交流をはかったりしています。
各本部の意思疎通や情報共有が分断されたセクショナリズムの状態に陥らないよう、（同じプロダクトに向き合うメンバーとして）引き続き良い関係性を築いていければと思っています。
若手の活躍
弊社はスタートアップですが、メガベンチャー出身のメンバーが多いこともあり、若いメンバーの育成を重視しています。
実際に、開発本部には去年・今年でインターンから新卒が2名ずつ入社し、すでに各チームで活躍中です。
具体的には、
「カナリー」や「カナリークラウド」における新機能を、設計〜実装まで自走しながら完遂
社内利用の新規プロダクトの要件定義（営業メンバーなどへのヒアリング）、開発スケジューリングや設計〜実装を主導し、他メンバーと協力しつつプロジェクトを進行
「カナリー」の、外部提携会社との新たな取り組みを開発面でリード
など、新卒1,2年目からある程度大きなチャンクでの仕事を積極的に任せ、実際に結果を出してくれています。
開発チームの体制
今年（2023年）から、Team Topologies の考え方を取り込みつつチームを構築しています。具体的な構成などについては EntranceBook をご覧ください。
また、このトピックについては、今後開設予定のテックブログでもご紹介いたします。
今の体制になって一番大きく変わったのが、「チーム内で密にコミュニケーションをとり、フィードバックループを高速に回すことを目指しているため、フロントエンド/バックエンドといった職能による切り分けを基本的には行わない = “ソフトウェアエンジニア” としてシステムに関わる」という点です。
これにより、「今まではフロントエンドorバックエンドのどちらかのみを実装していたエンジニアが、もう一方の開発にチャレンジする」ということがよく見られるようになりました。
実例として、普段はアプリ開発をしながらバックエンドにも挑戦しはじめたメンバー（Nさん）がいます。
本人にそのチャレンジについて聞くと、
今はアプリの検索性を上げるための新規機能開発に取り組んでいる。
去年まではアプリメインで担当だったが、今回バックエンド含めて担当している。以前はバックエンドの方とコミュニケーションを取りつつ API を実装していただいてアプリを実装するという形だったが、今回はまるっと自分一人で対応。
実際にやってみた結果、ポータルという事業・プロダクトに対する理解度が上がったと思う。コードを通してドメインへの理解も深まったし、今までは担当領域の「アプリ」という目線で見ていた Slack チャンネルのやり取りも見え方が変わった。
とは言え、キャッチアップは大変だった。バックエンド自体が初めてだった事に加えて Go、Spanner、Elasticsearch など、必要な情報をインプットする必要があったため。
といった話をしてくれました。
新たな領域へのチャレンジであるので大変な面もありつつ、事業やプロダクトに対する理解が深まったことで、今までとは異なる視点で業務に取り組めているという側面もありそうです。
チーム全体としても、フロントエンド/バックエンドの隔たりが少なくなり、よりスムーズにAPIインターフェースの議論が進んだり、「フロント or バックエンドの人しかできない/知らない」といった属人的な知見・情報が少なくなるなど、まだ取り組みを始めたばかりですが開発生産性やスピードの向上を実感しだしています。
今後に向けての課題
メンバーの採用
不動産業界という巨大な市場において、まだまだ事業としてやりたいことがたくさんある中、エンジニア組織が順調に拡大していかないと我々自身がボトルネックになってしまうという危機感を持っています。
ではどんな方を採用したいのか？という点については、まず（前述したように組織として育成を重視していることもあり）「若くて伸びしろのあるメンバー」の方は大歓迎です。
一方で、人数が増えるほど当然マネジメントのコストも上がっていくので、一定規模の開発チームで組織的な知見を持っていたり、マネジメント経験がある方も増やしていきたいと思っています。
移り変わる状況の中で最適なチームの形を保てるか
事業・プロダクト・メンバーの状況などによって、より良い開発を実現するための最適な形も常に変化していきます。そのように状況が移り変わる中でも適切な範囲でチームを切りつつ、各チームが自律性を持ちながら可能な限りフリクションなく価値を生み出していける状態を保てるかという点も大きな課題の1つです。
例えば、現在我々は「不動産賃貸・仲介」の領域をメインにプロダクト展開を行っていますが、今後それ以外の領域（「不動産売買」「管理」等）に対してもサービスを提供していく可能性があります。その際に「チームをどのように切るのか（あるいは切らないのか）」といった選択を正しく行った上で、日々チームのパフォーマンスをウォッチし、最適な形を保っていくことが必要だと考えています。
さいごに
今回は、カナリー開発本部についてご紹介しました。
私たちは、不動産業界という巨大な領域で、【もっといい「当たり前」をつくる】ために日々プロダクトと向き合っています。
チームの雰囲気や体制などに少しでも興味を持っていただけたら、是非カジュアルにお話できれば嬉しいです。
▼カナリー 採用情報ページ
https://recruit.canary-app.jp/
▼エンジニア向け Entrance Book