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

プロダクトの持続的成長を実現するための開発体制作り

 プロダクトの持続的成長を実現するための開発体制作り

2024/09/20(金) 「Product Engineer Meetup 価値あるリリースのための開発プロセス最適化」にて弊社エンジニア村田が発表した際の資料です。

イベントタイトル:
Product Engineer Meetup 価値あるリリースのための開発プロセス最適化
https://smartcamp.connpass.com/event/322993/

CREATIVE SURVEY Inc.

October 03, 2024
Tweet

More Decks by CREATIVE SURVEY Inc.

Other Decks in Business

Transcript

  1. Confidential © CREATIVE SURVEY 自己紹介 名前 村⽥ 千紘 略歴 2018/8

    Sansan株式会社⼊社 2024/3 クリエイティブサーベイ株式会社へ出向 所属チーム ‧開発部/SAチーム/プロダクトエンジニア 趣味 ‧ビール/旅⾏/マンガアプリ
  2. Confidential © CREATIVE SURVEY 概要 主要株主 許認可 会社概要 5 会社名:クリエイティブサーベイ株式会社

    設 ⽴:2014年7⽉ 代表取締役:⽯野 真吾 Sansan株式会社 、株式会社フォーデジット プライバシーマーク(Pマーク)取得 国際規格ISO27001(ISMS)取得 Salesforce 正規パートナー Confidential © CREATIVE SURVEY 5
  3. Confidential © CREATIVE SURVEY ミッション 6 顧客の声を 機会に変える あらゆることが急速にデジタルに移⾏する中、少し前まで⽬の前にいた顧 客と画⾯越しに会話することも増えてきました。

    CRMやMAの普及と共に属性データや⾏動データを元に顧客に アプローチすることが当たり前になった現在においても、 顧客不在で事業が成⻑し続けることは困難です。 いつの時代も、顧客の声は事業に成⻑のきっかけをもたらしてきました。 私たちは顧客の声を事業の成⻑の機会に変えていきます。 Confidential © CREATIVE SURVEY
  4. Confidential © CREATIVE SURVEY プロダクト開発の課題 • 価値あるリリースとは? ◦ ユーザーニーズに合致し、使⽤率が⾼く、ビジネス成果に貢献する機能を提 供すること

    • 過去の問題点 ◦ 開発チームがユーザのユースケースを正しく理解できていなかったことで ユーザにとって価値のある機能を提供することができず、リリースしたもの のユーザが使うことができなかった ◦ サクセスチームとの連携に対するアクションが不⼗分だったため、開発チー ムがユーザ影響を正確に認識できておらず、ユーザ通知期間を踏まえてのリ リース計画が⽴てられていなかった
  5. Confidential © CREATIVE SURVEY 解決策:新しい開発フロー フィーチャー リクエストの 収集 PBIの作成 仕様の決定

    設計 タスク化と リリース プランの作成 開発 QA リリース 完了 フィーチャー リクエストの 収集 PBIの作成 仕様の決定 設計 タスク化と リリース プランの作成 開発 QA リリース 完了 課題抽象化 フィード バックの 収集 課題が 解決さ れたか Before After Yes No
  6. Confidential © CREATIVE SURVEY 課題の抽象化 フィーチャー リクエストの 収集 PBIの作成 仕様の決定

    設計 タスク化と リリース プランの作成 開発 QA リリース 完了 フィーチャー リクエストの 収集 PBIの作成 仕様の決定 設計 タスク化と リリース プランの作成 開発 QA リリース 完了 課題抽象化 フィード バックの 収集 課題が 解決さ れたか Before After Yes No
  7. Confidential © CREATIVE SURVEY 課題の抽象化 - なぜ必要か • ⽬的: ◦

    不要な機能開発の回避 ◦ 効率的なPBI(Product Backlog Item)の作成 • メリット: ◦ 複数の課題を1つの機能開発/改修で解決 ◦ リソースの最適化 ◦ プロダクトの⼀貫性維持
  8. Confidential © CREATIVE SURVEY 課題の抽象化 - どのように行うか • フィーチャーリクエストの収集 ◦

    全社員がリクエスト可能 ◦ 多様な視点を取り⼊れる • グルーピング ◦ 類似リクエストをまとめる ◦ パターンや傾向を識別 • 課題の抽出と抽象化 ◦ グループから本質的な課題を特定 ◦ 具体的な実装から離れた抽象的な表現に
  9. Confidential © CREATIVE SURVEY 仕様検討フェーズ フィーチャー リクエストの 収集 PBIの作成 仕様の決定

    設計 タスク化と リリース プランの作成 開発 QA リリース 完了 フィーチャー リクエストの 収集 PBIの作成 仕様の決定 設計 タスク化と リリース プランの作成 開発 QA リリース 完了 課題抽象化 フィード バックの 収集 課題が 解決さ れたか Before After Yes No
  10. Confidential © CREATIVE SURVEY 仕様検討フェーズ - なぜ重要か • 仕様フェーズの主な⽬的: ◦

    ユーザーの課題解決の確実性 ◦ 適切な機能範囲の決定 ◦ 既存機能との整合性確認 ◦ 実装可能性の検証 ◦ 顧客通知の有無の確認 • メリット: ◦ サクセス、プロダクト視点による仕様決定により、各視点でブラッシュアッ プできる ◦ QA視点で既存機能への考慮漏れを防げる
  11. Confidential © CREATIVE SURVEY 仕様検討フェーズ - どのように進めるか • 初期仕様書作成 ◦

    担当: 開発チーム ◦ 内容: 実現可能性調査を含む基本仕様 • 仕様のブラッシュアップ ◦ 参加者: CTO、PdM、サクセスマネージャー、開発チーム、QAチーム、デザ インチーム担当者 • 最終仕様の決定 ◦ 全参加者の合意形成 ◦ ユーザー課題解決の再確認
  12. Confidential © CREATIVE SURVEY 仕様検討フェーズ - 何を考慮すべきか • ユーザー課題との整合性 ◦

    機能要件、⾮機能要件の策定 ◦ 機能範囲の適切性 ▪ 含めるべき機能と除外する機能の明確化 • 既存機能との相互作⽤ ◦ 影響範囲の特定と対応策 ◦ 事前に既存顧客への通知の有無の確認 • 技術的な実現可能性 ◦ リソース、時間、技術的制約の考慮
  13. Confidential © CREATIVE SURVEY リリースフェーズ、リリース後ヒアリング フィーチャー リクエストの 収集 PBIの作成 仕様の決定

    設計 タスク化と リリース プランの作成 開発 QA リリース 完了 フィーチャー リクエストの 収集 PBIの作成 仕様の決定 設計 タスク化と リリース プランの作成 開発 QA リリース 完了 課題抽象化 フィード バックの 収集 課題が 解決さ れたか Before After Yes No
  14. Confidential © CREATIVE SURVEY リリースフェーズ、リリース後ヒアリング • リリース前: ◦ エンジニアが直接サクセスチームにリリース内容を共有する時間を設ける ◦

    顧客影響の認識合わせやリリース後のサポート体制の強化が⽬的 • リリース後ユーザーフィードバック収集: ◦ 課題を持っていたユーザに直接ヒアリングする
  15. Confidential © CREATIVE SURVEY 成果と課題 • 成果 ◦ スケジュール通り価値ベースで機能リリースすることができた ▪

    開発フェーズに⼊ったあとに⼿戻りがなかった ▪ リリース後の再修正がなかった • 今後の課題 ◦ 課題詳細化〜設計フェーズの最適化 ▪ 実装フェーズに⼊るまでの時間⻑いので改善していく必要がある ▪ 現状固定メンバーで⾏ってきたため属⼈化してしまっている • 課題に対する取り組み ◦ 現在の体制にあったフレームワークを⼀部導⼊する ▪ 仕様フェーズ USDM の導⼊ ▪ 設計フェーズ Theory of Models の導⼊
  16. Confidential © CREATIVE SURVEY 魅力、面白さ • 顧客の課題を理解するところから⼊れることで、何をどう作っていけば価 値につながるかを意識して開発を⾏うことができる • 初期フェーズからリリース後まで⼀貫して携われることで、エンジニアと

    してのスキルアップにもつながる ◦ 顧客の課題を技術的に解決できる⾯⽩みも実感できる • 実際に使われる機能をリリースすることでモチベーションがあがる
  17. Confidential © CREATIVE SURVEY まとめ • プロダクト開発は、ビジネスサイドと⼀体になって取り組むことが⼤事 • 顧客要望をそのまま開発するのではなく、根本の課題はなんなのか、どう なると使い続けたいと思ってもらえるのかを考える

    • どうやったら課題を解決できるか、より使いやすくなるのかといった検討 に時間をかけることで、最終的なリリースサイクルは早くなる • 結局使ってもらえる機能を開発できるのが⼀番楽しい