Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Role of frontend engineer at product growth team

Avatar for shintaro shintaro
March 19, 2025
470

Role of frontend engineer at product growth team

Avatar for shintaro

shintaro

March 19, 2025
Tweet

Transcript

  1. © 2025 Wantedly, Inc. 自己紹介 Shintaro Kawabe shintaro_dev s-kawabe 所属

    ウォンテッドリー株式会社 ・Visit Client Growth Squad ・Frontend Chapter React / TypeScript / Figma / Design System 好きな 技術 ポーカー / カラオケ / クラフ トビール 趣味 s_kawabe ✨#wantedly_tn
  2. © 2025 Wantedly, Inc. 今⽇伝えたい話 / 対象 伝えたい話 対象 直近の施策から考える、

    グロースチームにおけるフロントエン ドエンジニアの役割 職能横断的なチームにおいて⽇々どん なコミュニケーションをしながら仕事 を進めているか グロース時期の開発スタイルについて 知りたい⽅ 他職種と連携して仕事を進めている フロントエンドエンジニア
  3. © 2025 Wantedly, Inc. 1. 前提 1. グロースチーム Visit Client

    Growth とは 2. 開発の流れとエンジニアの主な仕事 3. 技術スタック 目次 2. フロントエンドエンジニアに求められる役割 @toB管理画面プロジェクト 1. Must-do actions | やること 2. Should-do actions | やったほうがいいこと 3. Optional actions | やらなくてよいこと 4. Don’t-do actions | やるべきでないこと
  4. © 2025 Wantedly, Inc. 1-1. グロースチーム Visit Client Growth とは

    • Wantedly VisitにおけるtoB領域(契約してくれている企業の⽅)に向けた UI/UX改善や機能開発を軸として活動するチーム • 職能横断的なチームで、現在6名で活動中 ◦ リーダー ◦ プロダクトマネージャー ◦ UIデザイナー ◦ バックエンドエンジニア* 2 ◦ フロントエンドエンジニア • 現在はスカウト機能のUI/UX改善や新機能開発に⼒を⼊れている
  5. © 2025 Wantedly, Inc. 1-2. 開発の流れとエンジニアの主な仕事 フロントエンドエンジニア, バックエンドエンジニアがやること • 企画に対しての実現可能性や⼯数提案

    • プロダクトマネージャー、デザイナーとの外部仕様‧内部仕様の相談 • ⼯数⾒積もり、実装とレビュー • QA項⽬書のレビュー、QA環境の準備 • リリースと効果検証
  6. © 2025 Wantedly, Inc. 1-2. 開発の流れとエンジニアの主な仕事 チームの動き • この部分が⼀番⻑く、チームのコミュニケーションが最も活性 化する

    • 1Sprint = 1週間として⽉曜⽇にSprint Planning、 ⾦曜⽇に Sprint Review&KPTを実施 • タスクは時間でなくポイントで⾒積もる ◦ チームのパフォーマンスを可視化
  7. © 2025 Wantedly, Inc. 2. フロントエンドエンジニアに求められる役割 @toB管理画⾯プロジェクト 例: スカウト送信予約 様々な要因で業務時間に

    スカウトを送れないことがある 早朝や遅い時間外にスカウトが来ると 「時間外労働の多い会社なのかな?」という印象に 採⽤担当者 求職者
  8. © 2025 Wantedly, Inc. 2-1. Must-do actions | やること 進捗として動くソフトウェアを出し続ける

    • 「今週はここまで進みました」だけでなく動くモノを毎週アップデートし続 け、共有し続けるマインドが重要 • フィードバックサイクルを⼩さく、リーンに開発する ◦ ドッグフーディングや社内ユーザビリティテストにも活きる • その前提でのタスク設計と管理が⼤事 ◦ ビッグバンなアップデート 󰢁 • ウォンテッドリーでは内製 Feature Flags が使える • (意外と⼤事)頼まれていなくても進捗を共有する
  9. © 2025 Wantedly, Inc. 2-1. Must-do actions | やること スキーマ設計を最速でFixする

    • ウォンテッドリーではスキーマ駆動開発を採⽤している (protocol buffers) ◦ スキーマを元にRubyのサービスクラスとGraphQL schemaを⽣成する • これが開発のスタート地点になるためバックエンドエンジニアが出したPull Requestを最速でレビューしFixさせる ◦ 時にはペアプログラミングを⾏う、設計に参加する • Fixしたスキーマを元に、フロントエンドはバックエンド開発を待たずにUI 開発を進められる ◦ Storybook駆動開発、テスト駆動開発を活⽤
  10. © 2025 Wantedly, Inc. 2-1. Must-do actions | やること 状態設計

    • UI Stack ◦ デザイナーと会話し、各状態の表現を細部まで考える • エラーの種類 ◦ どういうエラーがどういう時に起こるのか?それが起きたらUIはどう 変わるのか? • フロントエンドのキャッシュ、グローバルな状態管理 ◦ ローカルステート、クエリパラメータ、Apollo ClientのCache ◦ ここが⼀番他のメンバーから⾒えにくい
  11. © 2025 Wantedly, Inc. 2-2. Should-do actions | やったほうがいいこと 状態設計

    - エラーの種類 • PdMの考えたエラーケース • デザイナーの考えたエラーテキスト • バックエンドの考えたエラーコード →これらを間に⽴つフロントエンドエンジニアが 情報整理して綺麗にする
  12. © 2025 Wantedly, Inc. 2-2. Should-do actions | やったほうがいいこと みんなの仲介役、橋渡し役を積極的にやる

    • フロントエンドエンジニアは、デザインとバックエンドとプロダクト仕様を 全部知ってる⼈(個⼈的にはそう思っている) • 各職能領域の情報をしっかりとプロジェクト前進に活かすこと ◦ 例: 「このエラー表現のデザインは現状のAPI設計だと難しいんじゃな いか?」「今のバックエンドエンジニアの想定だとこの仕様を満たす ためにはフロントエンド実装コストが爆増するんじゃないか?」 • リスクの早期発⾒やメンバー間の認識齟齬に気づいて発信してあげよう • 時にはプロジェクトマネジメントに近いこともやる
  13. © 2025 Wantedly, Inc. 2-3. Optional actions | やらなくてよいこと バックエンド設計、実装への過度な⼲渉

    • ウォンテッドリーではフロントエンド/バックエンドで職務を分けている チームが多い ◦ (RailsとTypeScriptという横断しにくい技術選定でもある) • フロントエンドエンジニアとして、バックエンドの細かい設計にまで時間を 使っていると間に合わない • しっかり役割分担し、⾃分のやるべきことに集中する • その代わり毎⽇コミュニケーションを取る、常に相談がしやすい距離、関係 性を保つ
  14. © 2025 Wantedly, Inc. 2-3. Don’t-do actions | やるべきでないこと 確認作業、QA作業を怠る

    • 動くものを作ったから終わりではなく、きちんとQA作業にも関わるようにする • QAチームやPdMと⼀緒にQA項⽬を作る ◦ エンジニア観点でしか気づけない重要なエッジケースなどをFBしてあげる ◦ 逆に過剰なテストケースを削るという⾏いも重要 • UI観点でもデザイナーに必ずチェックを依頼する ◦ これは意外と漏れがち、黙ってやり過ごすこともやろうと思えば可能... • きちんとリリースするまでがフロントエンドの実装作業