新規機能の開発における_早く価値を届ける開発の取り組み.pdf

新規機能の開発における  早く価値を届ける開発の取り組み 

フロントエンドエンジニア / プロダクトエンジニア   2023年4月入社クリエイティブサーベイ株式会社   ストリームアラインドチーム  ねこ /
ガジェット   自己紹介  2 横越菜穂子  @takepo0928 

アジェンダ  1. サービスと機能  2. 開発チーム  3. どう取り組んだか  4. もっとこうできたらよかったな  5.
いま改善している取り組み  6. まとめ  3

🖥 サービスと機能  4

CREATIVE SURVEY  5

開発した機能  • カスタマイズ版のWebhook  ◦ フォーム回答時に外部サービスに回答内容をWebhookとして送信できる機能  ◦ もともとWebhookの機能はあったが、決まった形式でしか回答結果を送れず、柔軟性が足りていなかった  • 対象箇所は
Rails / Next.js でつくられている  6

開発スケジュール  • チームはこの機能開発に集中できるわけではなく、他の施策とも並行して進めないといけない状況だった  • 仕様決めから機能リリースまでおよそ2ヶ月  • 無事期間内にリリースをしてプレスリリースも出せた  • 実際に開発した機能起因で解約阻止や受注にもつながった 
7

󰟲 開発チーム  8

開発チーム  • スクラム開発  • ストリームアラインドチーム  • リモートワーク  • 1つの機能開発に集中ではなく、複数の機能開発をクオーターで受け持つ  9

チーム編成  • ストリームアラインドチーム  ◦ BE: 3人  ◦ FE: 3人  
• チーム横断  ◦ QA: 1人  ◦ デザイナー: 1人  10

💡どう取り組んだか  11

仕様決めからエンジニアが参加  • プロダクトバックログアイテムはあるが、仕様がまだきっちりときまっていなかった   • FigmaベースでPdMと仕様のすり合わせして確定させた  • 連携予定サービスとの連携の実現可能性調査もおこなった   •
QAにも仕様共有の段階で入ってもらい、実装と平行してテストケース設計に入れるようにした    12

設計書を作ってレビュー  • 仕様をもとにBE/FEでペアプロの形で設計書をざっと作る  • 設計レビューはチームメンバー + CTO + コードレビュワー  •
エンジニア内で認識合わせをして、実装時やコードレビュー時の手戻りを減らす  • とはいえ変更は入るものなので詳細度は求めすぎず、柔軟に対応するようにした  13

スキーマ駆動開発  • 設計・タスクだしが済んだらまずAPI設計をして機能実装に入る  • OpenAPIで記述する形にしている  • BE/FEでペアプロで決めて残りメンバーはレビューする形で進めた  • Git管理しているので変更が発生してもプルリクベースで共有をした  •
BE/FEの認識ズレを防ぐ目的  14

APIつなぎこみ確認用issueをちゃんと切る  • APIのスキーマが決まったらBE / FEは分かれて実装している  • 細かい機能やAPI単位でAPIのつなぎ込み動作確認用のissueを切って対応  • 実装期間が短いのであらかじめ必要なポイントをとっておいて見える化しておく  15

はやめに機能が試せる環境をつくる  • dev環境でリリース前にPdM,PMMにも触ってもらえるようにした  • 機能リリースすればOKというわけではない  • プレスリリース準備やヘルプ作成でも動作確認環境が必要  • リリース後すぐにプレスリリースを出すような動きだった  •
リリース前にはやめに動作確認・気になるポイントを洗い出せるように  16

サービス連携確認  • 基本機能がそろって終わりではない  • 連携で使用されうる主要なサービスのユースケースに沿った動作確認をした   ◦ Sansan  ◦ HubSpot 
◦ kintone  ◦ Slack  ◦ Microsoft Teams  ◦ Marketo など  17

💭 もっとこうできたらよかったな  18

既存機能との組み合わせの思考が足りていなかった  • 新規機能なので既存と影響しない形で作ることベースで考えていた  • 既存の機能との組み合わせることで、工数削減しつつ、既存にも影響を与えすぎず、使い方や概念の複雑性をもたせず進められた  • 既存を活かしてやりたいことが実現できないかを改めて考えてみるべき  19

既存機能の仕様理解の認識合わせ  • 結局既存機能の組み合わせでつくることになった  • その既存機能の理解度がメンバー内でバラバラなまますすめてしまい、認識の齟齬が起きてしまった  • どこまで共通認識を持てているかちゃんと確認しよう  20

実装・デザインの期間が短くなった  • 他の施策もやりつつ進めていたり、当初からの仕様変更があったり  • 設計やタスクの洗い出しも遅くなったので期間内にできるか見えない期間があった  • リリースは間に合ったが、バタバタな動きになった  • やらないといけないことの絞り込み・優先度付け  21

🚀 いま改善している取り組み  22

いま改善している取り組み  • スプリントごとの振り返りに加えて、月イチでチーム振り返りを実施  • 設計が分割できるものは分割して実装と設計を並行して進める  • いつどんな施策をすすめるかQで見える化して月ごとに見直す  • 段階的リリースとスコープを明確にし、優先度づけをするようにした  23

📝 まとめ  24

まとめ  • 最初から完璧なチームなんてないので日々改善してよりよくいこう  • 大事なこと  ◦ 仕様・設計の変更に対しての柔軟性をもつこと  ◦ 領域にとらわれすぎないこと  ◦
メンバー内での共通認識を持つこと  ◦ 早く気付ける・試せるようにすること  25

🏁 END  26

新規機能の開発における_早く価値を届ける開発の取り組み.pdf

新規機能の開発における_早く価値を届ける開発の取り組み.pdf

CREATIVE SURVEY Inc.

More Decks by CREATIVE SURVEY Inc.

Other Decks in Business

Featured

Transcript