Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
BtoB SaaS プロダクトでの要件定義のリアル
Search
naotsukamoto
November 13, 2023
10
3.6k
BtoB SaaS プロダクトでの要件定義のリアル
2023/11/14に findy社主催の【要件定義 Lunch LT】に、「BtoB SaaS プロダクトでの要件定義のリアル」というタイトルで登壇しました。
naotsukamoto
November 13, 2023
Tweet
Share
More Decks by naotsukamoto
See All by naotsukamoto
3つの決めつけから見る失敗の要件定義
naotsukamoto
10
15k
211127_塚本_プロ筋conf登壇用資料.pdf
naotsukamoto
3
1.1k
Featured
See All Featured
Happy Clients
brianwarren
98
6.7k
Writing Fast Ruby
sferik
627
61k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Building Applications with DynamoDB
mza
90
6.1k
A Tale of Four Properties
chriscoyier
156
23k
Building Adaptive Systems
keathley
38
2.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Bash Introduction
62gerente
608
210k
Faster Mobile Websites
deanohume
305
30k
BBQ
matthewcrist
85
9.3k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Cult of Friendly URLs
andyhume
78
6k
Transcript
BtoB SaaSプロダクトでの要件定義のリアル 株式会社hacomono 塚本 尚 1
塚本 尚 / Nao Tsukamoto • 株式会社 hacomono プロダクトマネージャーグループ •
前職はBtoBtoCのプラットフォームの PdM • (余談)走る人です。先日福岡マラソンを走りウェルネス 度あげてきました 自己紹介 2
0 hacomonoについて 3
4
5
None
1 本日のメインメッセージ 7
BtoB SaaSプロダクトづくりをPdMとして関わる中で、要件定義において大事にしていること 本日伝えたいこと 8 1. お客様のその業務本当に必要ですか?よく知り、よく見極めて、自分たちの価値を出すとい う話 2. PdMとして仕様に言及することもあるが、丁寧に扱しましょうという話
2 顧客をよく知る 9
• お客様の業務の中身わかっていますよね? • お客様の現状の業務、そのまま機能つくろうとしていないか? こういうこと起きてないか? 10 お客様のその業務本当に必要ですか?よく知り、よく見極めて、自分たちの価値を出す 伝えたいこと
要件定義前の業務の把握 hacomonoでの大きめの新機能開発においては、要件定義の前段で以下を行う • パイロットとなるお客様が決まる ↓ • PdMも直接打ち合わせして、ヒアリング。 現場・現地に行く ↓ •
現状のシステムでできることをベースに、 hacomonoで実現させたいフローをつくっていく ↓ • 現状や課題を整理して、要件を洗い出していく ↓ • ︙ 11
大事にしていること 要件定義前に、必要な業務に削ぎ落とした上で、お客様の要望への解と hacomonoらしさを加える • 決して既存業務にあわせない。既存業務は既存システムの上に構築された業務・運用の可能性が高い ◦ 既存業務は、既存システムありきの業務なのか?本当に必要な業務はなにか? 12
大事にしていること 要件定義前に、必要な業務に削ぎ落とした上で、お客様の要望への解と hacomonoらしさを加える • 登場人物を各フローごとに捉える。誰がその業務を行うのか?機能を使うのか?アウトプットは誰が見 るのか? ◦ 特にhacomonoが対峙するフィットネス市場だと、以下の登場人物を捉える必要があります i. アルバイト・パート
ii. 店舗スタッフ iii. マネージャー、店長 iv. エリアマネージャー・本部統括 v. エンドユーザー vi. 保護者・家族 vii. hacomono社員 viii. アプリケーション ◦ 多い。。。 • 業務フローをストーリーで描くことで、より具体化できる 13
私がある機能の開発時に作ったお客様の実際の業務フロー図。 hacomonoでやるやらないを記載する。やる 場合は、何をどうやるか。やらない場合どういう運用にしていくのか?を整理したもの。 具体例としては 14
3 仕様はチームで丁寧に扱う 15
• 開発者に、仕様ガチガチに要件として出しちゃっていませんか? or 無思考で丸投げしていませんか? • 仕様まで決定事項のように要求だしていませんか?そう伝わっていませんか? こういうこと起きてないか? 16 必要なときには仕様に言及することもあってよい。しかし、丁寧に扱いましょう 伝えたいこと
• 一般的には、なぜやるのか、なにをつくるかに責任をもつのが PdMと言われている • hacomonoでは要件定義段階で PdMが仕様まで割りとカバーすることがある ◦ 顧客の業務上、仕様まで踏み込まないと価値と整合性が取れないことがある ◦ 仕様まで言及しないと、それだけでは価値を満たせない、正しくは価値を毀損してしまうこともある
PdMが仕様に言及する? 17
PdMからの仕様の言及は、決定事項ではない。要求である。なので、開発チーム では議論余地が多分にあるものとして扱うこと。 • それは、PdMが仕様を決めすぎてそのまま進むと、アンチパターンに陥ってしまう ◦ プロダクトの整合性が崩れ一貫性がなくなってしまったり、仕様が複雑になってしまう。 ◦ PdMはどこまでいっても仕様や実装がどうなっているかに責任を持つのは難しい • その中で、開発側とときには意見が合わなくなることもある
◦ でもそれは当たり前 ◦ 意見はあわなくてもいい、目指す方向は同じでも責任領域は違うのでお互いの立場から意見 を出す行為自体が大事 大事にしていること 18
4 まとめ 19
本日伝えたいこと 20 1. いい要件は、相手をよく知ること。よく知り、よく見極めて、自分たちの価値を出す。 そして、 業務フローは書いても書かれるな、ということ 2. PdMが仕様に言及することもあるが、丁寧に扱おう、ということ
おまけ おまけ 21
We are hiring! hacomonoはプロダクトマネージャー絶賛募集中です • 本気で顧客の解像度あげてプロダクトづくりしたい方 • 仕様もお手の物、私エンジニアでしたよ、という方 22 hacomono
entrance book
イベントもやります。ぜひ 23 hacomono イベント情報はこちら
24