1人1人が小さなアーキテクトになる組織を目指す

こんにちは！ウォンテッドリーでバックエンド領域のエンジニアリングマネージャーをしている鴛海です。

この記事ではウォンテッドリーのバックエンド組織がどのような課題を解決してきて、現在どのような課題が存在しているのか、どのようなバックエンド組織を目指しているのかを紹介します。

ウォンテッドリーはプロダクトを大きく変化させる時期に入っています。チームとしても個人としても大きな挑戦ができる環境にあるので興味を持ってもらえると幸いです！

前提: ウォンテッドリーのプロダクト

これまでの取り組みと現在の課題を紹介する前に前提となるプロダクトについてご紹介します。

ウォンテッドリーでは「究極の適材適所により、シゴトでココロオドルひとをふやす」をミッションとして仕事に関するサービスを展開しています。ココロオドルシゴトを見つけてその環境で活躍するまでを “Recruitment Marketing”、 “Recruiting”、”Employee Engagement” というの 3つの領域に分割して考え、その中の “Recruitment Marketing” と ”Employee Engagement” でそれぞれ Wantedly Visit と Engagement Suite というサービスを展開しています。

(画像: Wantedly, Inc. 会社説明資料より)

Wantedly Visit は「自分に合った企業を見つける個人」と「自社に合った個人を見つけたい企業」が出会うことを最大の目的とした仕事のプラットフォームを提供しています。この個人と企業の 2つの側面を持つ市場 (2-sided market) はどちらかが弱くなると全体が上手く回らなくなるという特徴があります。

Engagement Suite は社内の定着、活躍を支援するサービス群で、福利構成サービスである Perk、社内コミュニケーションを活性化する社内報、チームマネジメントをサポートする Pulse という複数のサービスを包含しています。Engagement Suite は完全に企業に閉じ、ニーズが大きく変動しにくいことが特徴です。

これまでの取り組み: 特定のアプリの UI に依存しないシステムの構築

Wantedly は Rails で作られた単一コンポーネントから始まり、組織とプロダクトの拡大に沿ってアーキテクチャを更新してきました。大きな部分では特定のアプリの UI に結合したシステムから特定のアプリの UI に依存しないシステムに変えました。

特定のアプリの UI に依存しないシステムにした理由はいくつかありますが、大きな理由としてはアプリごとの機能展開の速度を向上させ、開発のトータルのコストを減らすためです。

ウォンテッドリーでは機能をリリースする際に価値検証を行い本当に必要とされているかを確かめる開発プロセスをとっています。このような開発プロセスではサイクルをはやく回し改善していく必要があるため、デリバリーまでのリードタイムの短さが重要になってきます。そのためデリバリーまでのリードタイムが短い Web アプリで機能の価値検証を行い、その後モバイルアプリに展開することがよくあります。しかし、Web アプリとモバイルアプリで別々の API を作る必要のあるアーキテクチャでは Web アプリで作った機能をモバイルアプリに展開するために Web アプリの開発とモバイルアプリの開発時の 2回バックエンドの開発をする必要がありました。

そこで最初にコストをかけてどのアプリでも使えるような汎用的な API に設計することで、それ以降の機能展開速度を向上させることができました。1つのアプリを想定するより 1回のシステムの開発コストは増えますが、2回に分けるとメンバーのアサインの手間もかかるためトータルではコストが低くなりました。

(画像: Wantedly Engineering Handbook 「GraphQL Gateway - アプリ向けにAPIを公開する」より)

このアーキテクチャを実現するために以下のようにアプリとシステムの間に GraphQL で Gateway サーバーを建て特定の UI に依存しない情報設計レベルの API を提供しています。これにより開発がスキーマファーストとなり、ドメイン知識が GraphQL に集約されます。これにより全体を考えて設計することを強制することができ、これにより組織のソフトウェア設計能力を上げていくことができると考えています。

(画像: Wantedly Engineering Handbook 「技術とアーキテクチャ」より)

課題: 次のアーキテクチャの進化の指針を決める

今まで話してきたようなアーキテクチャを考えてきましたが、アーキテクチャは組織、プロダクト、市場などさまざまなものに影響を受けるため変化し続ける必要があります。

現在ウォンテッドリーは去年末にリリースしたスキル診断を皮切りに機能拡大を進めています。いくつかの新規機能開発プロジェクトを進めていく中で、根本からの仕様変更が頻繁に起こる新規開発では現在のアーキテクチャが合っていないのではないかという仮説が出てきました。新規機能は本当に価値があるかを見極めるためにリリースしてフィードバックを得て修正してまたフィードバックを得て...というループを回す場合が多いです。このような開発では設計が大きく変わることもしばしばあります。しかし、現在のアーキテクチャでは全体を考えて設計して最初にコストを払うため、このフィードバックループの速度がでにくくなってしまいました。

このように今あるアーキテクチャが全て正しいとは言えないため、アーキテクチャは進化していく必要があります。ばらばらに進化してしまうと全体のアーキテクチャがカオスになってしまうため、次の進化の方向性を考える必要があります。