こんにちは、ウォンテッドリーの Visit Growth Squad というプロダクトグロースチームでソフトウェアエンジニアをしている川辺 (@sh1ntaro_dev) です。

このストーリーは、Wantedly Advent Calendar 2024 の6日目の記事です。前日は市古さんによる「最速で開発プロジェクトをリードするための6原則」という記事でした。

自身の話ですが、入社して一年半が経過しさまざまな業務、技術に触れてきました。Wantedly VisitのUI/UX改善をメインに、フロントエンドの組織横断の課題やデザインシステムの発展、最近ではプロジェクトマネジメントなども行っており、幅広く成長できた1年半だったなと思っています。

この記事では、そのような経験から改めて組織としてのウォンテッドリーと、プロダクトとしてのWantedlyをグロースさせるために、チームに与えられた役割や実際の行いを前提として、後半ではいちフロントエンドエンジニアに求められる役割と価値について深掘った内容を書いていきたいと思います。

ウォンテッドリーの開発に興味がある方、同じ規模感のサービスのグロース開発をしている方、UI/UX改善に関わるフロントエンドエンジニアやデザイナーの方などの参考になれば幸いです。

前提

グロース開発チーム Visit Growth Squad とは？

ウォンテッドリーでは、Squadと呼ばれる「ある目的を持ったチーム」が複数構成されています。その中で、私の所属しているVisit Growth Squadと呼ばれるチームには以下のような特徴があります。

• Wantedly Visit を成長させるためのチーム
• 職能混合型で、PdM, デザイナー, フロントエンドエンジニア, バックエンドエンジニアが在籍している
• 2024/12/02現在、toBチームとtoCチームに分かれ、それぞれ異なるOKRかつ異なるユーザーに向け、仮説検証を行っている
• 仮説検証の単位を「施策」と呼び、施策ごとにPRD（プロダクト要求定義書）を作成して全員が要求・要件定義に関わる
• スクラム開発を採用しており、UI/UX改善をメインとした仮説検証を1つの施策につき平均約2,3週間程度で回している

普段やっている仮説検証へのスタンスや、ABテストの検証、課題の発見方法 ...といった内容については プロダクトの課題発見及び解決 という記事に書かれています。

我々が達成したいこと

まず私たちの全社的なミッションは「究極の適材適所によりシゴトでココロオドルひとをふやす」こと。そしてこれを金銭的なものでなく「双方のビジョンの共感」によって実現したいと考えています。これらの実現のためにVisit Growth Squadでできることは、まさに「企業とユーザー双方の魅力的な出会いをふやすこと」となります。この活動が、社会全体でシゴトでココロオドルひとが増えていくことにつながる考えると、ミッションにダイレクトに直結する大事な役割であることがわかります。

2024/12/02現在、toBチームとtoCチームに分かれ

と言及した通り、「魅力的な候補者と出会いたい企業を幸せにするチーム」と「魅力的な会社と出会いたい候補者を幸せにするチーム」に分かれ、定性・定量 2つの側面からデータを分析して課題を発見し、素早く小さく仮説検証を実施しています。

現在それぞれののチームにおいて、toBチームは「新しいスカウト体験の実現」を、toCチームは「アクティブユーザーの促進」をObjectiveとしています。

Visit Growth Squadにはさまざまな職種の方が在籍していますが、それぞれどのような役割を与えられ、どのような働き方をしているかと言った話についても次の章でご説明します。

メンバーの職種とそれらの責務について

Visit Growth Squadでは各メンバーを次のような役割に分け、多くの場合施策ごとに一人ずつアサインをして進めています。

• Squad Leader: 全体の施策進行とチームのObjective達成に責任を持つ
• Product Manager (PdM): チームのKeyResult達成に責任を持ち、各施策の要求・要件定義を担う
• Product Designer: 要求仕様をデザインに落とし込み、以降のデザイン成果物のブラッシュアップを担う
• Frontend Engineer: 要件をフロントエンド実装に落とし込むことを担う
• Backend Engineer: 要件をバックエンド実装に落とし込むことを担う
• Project Manager (PjM): 施策のPJ進行の成功に責任を持ち、日々のタスク管理やファシリテーションを担う

特徴として、PjMは他のロールの誰かが兼任することがほとんどです。施策ごとに「施策オーナー」という役割を決めてその人が実質PjMとなるイメージです。また、エンジニアについては Frontend / Backend と分けて記述をしているものの、顧客に価値を届けることが最も重要であると捉え、施策によってはその垣根を超えて業務を進めることも多いです。

我々はその「垣根を越える」ということをエンジニアだけでなく全員で体現しています。「要求はPdMが考えるもの」「UI/UXはデザイナーだけに責任がある」といった思考はなく、状況に応じて権限を委譲し、役割を越境しながら仕事を進めています。

どうやっているか

以上の達成したいこと、各メンバーの役割を踏まえ、普段の施策は以下のような工程を基本として実施しています。

PRDというのは施策のベースとなるプロダクト要求定義書のことです。これを元に各メンバーが施策における要求・要件の認識を揃えることがスタート地点となります。（参考: PRD のススメ ~ メンバーや関係者とのスレ違いを減らそう）

ここまでがWantedly VisitをグロースさせるVisit Growth Squadの紹介でした。以降ではこのような環境におけるフロントエンドエンジニアとしての仕事、価値について言及していきます。

ソフトスキルの醸成

状況に応じて権限を委譲し、役割を越境しながら仕事を進めています。

先ほどこのような言及をしましたが、まさにこれがエンジニアとして「コードだけ書ければよい」ではないことを表しています。我々のチームは全員がUXデザイナーといった言い方をすることがありますが、エンジニアも各施策について不確実性の高い段階から要求やUXの部分の議論に参加します。その場でエンジニア視点でアイデアを出したり、クリティカルシンキングをもとにリスクを発見したりといったことは、ソフトスキルの醸成なくしては実現が難しい部分です。

エンジニアとしてはつい、コーディングスキルの上達、新しい言語・設計パターンの習得、対応可能な技術領域を増やす... といったに目を向けがちですが、特にグロース開発を担うエンジニアとしては、クリティカルシンキング・ロジカルシンキング・コミュニケーション・問題解決力 ...etc などの基礎スキルが重要と考えます。

なぜなら我々は「不確実な人とプロダクトを前に、課題を発見し、それを解消していく」といった非常に抽象的な仕事と向き合っているためです。これを問くために、「どうやるか」ではなく「なぜやるか」「なにをやるか」といった部分への思考がより基礎かつ重要になります。

プロジェクトマネジメント

特徴として、PjMは他のロールの誰かが兼任することがほとんどです。施策ごとに「施策オーナー」という役割を決めてその人が実質PjMとなるイメージです。

前提のこの部分にあるように、自分はフロントエンドエンジニアではありますが施策オーナーを兼任することもあります。最近自分がフロントエンド実装とともにやっていたマネジメント業務として以下のような仕事がありました。

• バックエンドタスクを含めた全体の実装工数の洗い出しと見積もり
• バックエンドエンジニアを交えた設計、実装方針の議論
• データサイエンティストとの推薦システムやログデータ周りの影響に関する議論
• PdM、デザイナーとの大きな仕様・デザインに関する議論
• プロジェクト内全体の情報整理

これらを担いつつ、フロントエンドエンジニアとしてのReactの設計・実装のタスクもあるといった状況でした。ここで重要だと感じたのが「権限を委譲すること」です。全てのタスクにボールを持ち1から最後まで手を動かすといったことをやっているとどうしてもリソースが枯渇します。他メンバーに任せられる部分については、積極的にタスクを委譲します。難易度が高かったり、メイン領域とは異なるタスクである場合、土台の部分だけ決めてあとは任せる、といったことを行います。このような行いが知識の属人化を防ぎ、全体最適につながると考えています。

また余談ですが プロジェクトマネジメントにおいてチームメンバーが貢献できること にある通り、プロジェクトのマネジメントは「全員が貢献するもの」と考えています。「プロジェクト内全体の情報整理」と書いた部分はプロジェクトマネージャー以外も日々意識することができます。例えば 違和感を言語化し、「これって大丈夫そう？」とラフに発言する・追いづらくなっているタスクアサイン状況を可視化して共有してみる などです。こういった行いをリーダー以外も積極的に実施していけるような自己組織化されたチームを目指しています。

デザインに対するフィードバック

施策の最初の段階のPrototypingという作業と、施策のKick off後のデザインのブラッシュアップ作業によって得られたデザイン成果物に対して、デザインレビューを行います。観点としては次の通りです。

• このデザインで要求を満たせるか
• UX低下につながる体験が生まれないか
• 実装上の懸念になる表現はないか
• Wantedlyらしいデザインに準拠しているか

3つ目は特にフロントエンドエンジニアとして注目している観点になります。バックエンドエンジニアとデザイナーとの間に立ち、デザインを見た時に以下のようなことを考えます。

• 達成困難、または負債になり得る実装を必要とする要件が含まれていないか
• • ユーザー操作によるデータフローの複雑化
  • フロントエンドの状態管理やパフォーマンスの品質低下
  • 複雑すぎるフロントエンド実装要件
• デザイン表現が無い部分についてデザイナーとの認識齟齬が生まれないか
• デザインシステムによって表現不可能なコンポーネント設計

やはり「バックエンドエンジニアとデザイナーとの間に立ち」という点が重要で、もっと言うと「ユーザーの体験とデータの変化を繋げる役割」がフロントエンドの仕事なので、

• ユーザー体験をつくるデザイナーがわからないデータのこと
• データの変化をつくるバックエンドエンジニアがわからないユーザー体験のこと

これら両方に理解があるフロントエンドエンジニアとしてこの段階でフィードバックできることは多岐に渡ります。

このような仕様のフィードバックや、デザイナーとのコミュニケーションに関して UIデザインとフロントエンド実装のレビュープラクティス集 や プロダクトデザイナーと上手に協働するための心得 なども参考にしてみてください。

ソフトウェアテスト

ここで用いるテストとは、主にウォーターフォール開発やV字モデルでも用いられる以下のような工程を指します。私たちはQAと呼ぶことが多いです。

• 単体テスト
• 統合テスト
• システムテスト
• 受け入れテスト

エンジニアとしてコードレベルでの単体テスト、統合テストに責任を持つのはもちろん、以降のシステムテストにおいても手を動かすことがあります。システムテストではテスト項目書を作成し「そのプロジェクトにおける要求」をベースに全ての要件が仕様通り満たされているかといった点を、実際にプロダクト成果物を動かしながらテストしています。

フロントエンドエンジニアとしては、実際にこのテスト項目書の作成に携わることもあれば、実施者としてシステムテストを実施することもあります。

モニタリング

我々の施策はもちろん作って終わりではなく、その施策に効果があったか？その結果どんな情報が得られたか？といった分析を必ず行なっています。

それらを判断する具体的な情報リソースとしては

• 日々収集している各ファネルごとの数値
• ユーザーのアクセスログやイベントログ
• ABテスト領域の振り分け結果のログ

があります。仮説検証にはABテストを用いることが多いのですが、この結果「既存機能だけを見せたA群に対し、新機能を見せたB群にどのような効果が現れたか」を見ることになります。

この過程ではBigQuery上でSQLを書いて「その施策に効果があったか？」に答えを出す作業が発生しますが、これも状況に応じてフロントエンドエンジニアがアサインされることもあります。そもそも効果検証に限らず、ウォンテッドリーにおける「データへの理解」はユーザーへの理解やプロダクトへの理解と同等レベルで重要なものです。そのため、フロントエンドエンジニアであってもSQLを書くということは日常茶飯事になっています。

また、失敗から学んで成長する という記事には、施策の実施→モニタリングを繰り返す過程でそれらをどのように分析し、次に繋げていくかといった内容が書かれています。

フロントエンドの内部品質への責任

施策の中にも「実装」という工程でのフロントエンド開発作業は含まれていますが、それを含めつつ組織全体の視点での「フロントエンドの内部品質への責任を持つ」というテーマでこちらの章に寄せました。

ウォンテッドリーではSquadというチームの他にChapterと呼ばれる「ある分野ごとに構成された技術横断チーム」があります。自分はFrontend Chapterというチームに属しています。Sqaudでは「フロントエンドエンジニアとしてユーザーに価値を届ける」のが仕事。Chapterでは「会社横断のフロントエンド課題の解消」が仕事です。Squad業務がメインとはいえ、雑にフロントエンドを作って早くユーザーに価値を届けられればいいというものではありません。

Squadの施策におけるフロントエンド実装がChapterによって考えてきたアーキテクチャから逸脱していないか、今回新たに実装した新しい概念はChapterメンバーにも共有・相談が必要なのではないか、といったように会社全体でのフロントエンド品質を考えながら施策の実装に取り組む姿勢も重要です。

UI/UXの品質への責任

施策における各工程には直接紐付きませんが、まだ実装においてフロントエンドエンジニアが特に気にしなければいけないものがあります。これがUI/UXの品質の担保です。「デザインに対するフィードバック」の章でも Wantedlyらしいデザインに準拠しているか といった点を見ていると言及しましたが、まさにWantedlyらしいデザインを正しく実装できること は非常に重要です。ただしこれを何のルールやツールもなしに毎回達成するのは困難を極めます。我々はこのようなWantedlyらしいデザインを誰でも簡単にアウトプットに繋げられるよう Wantedly Design System を運用しています。

つまりこのデザインシステムの成長に貢献することこそ、UI/UXの品質向上に加えデザイナーとのコミュニケーションの効率を上げることにつながります。

このデザインシステムを成長させる融資のチームとしてDesign System Guildという場所があり、そこに所属し日々Squadチームのプロダクト開発で発生するUI/UX実装の悩みをデザインシステムチームにフィードバックし、Wantedly Design SystemによってUI/UX実装についてより高いスピードと品質を実現できるように努めています。

参考

• Web アプリのデザインシステムライブラリ
• Wantedly Design System : プロダクト開発を加速させるための一貫性と効率性
• Design System Guild を立ち上げました

まとめ

Wantedlyのグロース開発における目的と実際にやっていることを元に、その中でフロントエンドエンジニアとして必要とされる役割についてご説明しました。

フロントエンドエンジニアというと、Next.jsやReactなどのエコシステムに詳しく、仕様やデザインの意図を正しく実装でき、品質の高いUI/UXをユーザーに提供できる人。というイメージがありますが、グロース開発チームの一員としてはより広い役割が求められます。

まとめとして、ウォンテッドリーにおける「フロントエンドエンジニアに求められるシゴト」には、次のようなものが挙げられます。

• 与えられた仕様とデザインを、自律してフロントエンドのコードに落とし込むこと
• 仕様とデザインを形にするだけでなく、自ら要求について考えアイデアを出すこと
• 広い意味でのプロジェクトマネジメント（情報の交通整理）ができること
• デザインのレビュー、およびデザイナーとのコミュニケーションを行い成果物の品質を上げること
• データ資産への理解をした上でそれらを活用して改善に繋げること
• フロントエンド開発に閉じずプロダクトの価値向上のため職務を越境すること
• プロフェッショナルとしてUI/UXのディティールまでこだわりを持つこと

自分自身、まさに「Next.jsやReactなどのエコシステムに詳しく、仕様やデザインの意図を正しく実装でき、品質の高いUI/UXをユーザーに提供できる人」というのができるフロントエンドエンジニアであると思っていましたが、実際にさまざまな経験を経て、チームとプロダクトが前進するためには、必要なことはそれだけではないことを実感することができました。