BtoB SaaS プロダクトでの要件定義のリアル

塚本 尚(@nao_tsukamoto)
株式会社hacomono
プロダクトマネージャー
大学院を卒業後、2017年に株式会社speeeへ新卒入社。不動産マッチングメディア事業の開発及びマーケティング担当を経て開発ディレクター及びプロダクトマネージャーへ。2022年12月にhacomonoへ入社。現在はPOS / EC 2つの領域でプロダクトを牽引している。

https://findy.connpass.com/event/300908/
要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT

Transcript

1. BtoB SaaSプロダクトでの要件定義のリアル 株式会社hacomono 塚本 尚 1

2. 塚本 尚 / Nao Tsukamoto • 株式会社 hacomono プロダクトマネージャーグループ • 前職はBtoBtoCのプラットフォームの PdM • （余談）走る人です。先日福岡マラソンを走りウェルネス 度あげてきました 自己紹介 2

3. 0 hacomonoについて 3

7. 1 本日のメインメッセージ 7

8. BtoB SaaSプロダクトづくりをPdMとして関わる中で、要件定義において大事にしていること 本日伝えたいこと 8
 1. お客様のその業務本当に必要ですか？よく知り、よく見極めて、自分たちの価値を出すとい う話 2. PdMとして仕様に言及することもあるが、丁寧に扱しましょうという話
9. 2 顧客をよく知る 9

10. • お客様の業務の中身わかっていますよね？ • お客様の現状の業務、そのまま機能つくろうとしていないか？ こういうこと起きてないか？ 10
 お客様のその業務本当に必要ですか？よく知り、よく見極めて、自分たちの価値を出す 伝えたいこと
11. 要件定義前の業務の把握 hacomonoでの大きめの新機能開発においては、要件定義の前段で以下を行う • パイロットとなるお客様が決まる ↓ • PdMも直接打ち合わせして、ヒアリング。 現場・現地に行く ↓ • 現状のシステムでできることをベースに、 hacomonoで実現させたいフローをつくっていく ↓ • 現状や課題を整理して、要件を洗い出していく ↓ • ︙ 11

12. 大事にしていること 要件定義前に、必要な業務に削ぎ落とした上で、お客様の要望への解と hacomonoらしさを加える • 決して既存業務にあわせない。既存業務は既存システムの上に構築された業務・運用の可能性が高い ◦ 既存業務は、既存システムありきの業務なのか？本当に必要な業務はなにか？ 12

13. 大事にしていること 要件定義前に、必要な業務に削ぎ落とした上で、お客様の要望への解と hacomonoらしさを加える • 登場人物を各フローごとに捉える。誰がその業務を行うのか？機能を使うのか？アウトプットは誰が見 るのか？ ◦ 特にhacomonoが対峙するフィットネス市場だと、以下の登場人物を捉える必要があります i. アルバイト・パート ii. 店舗スタッフ iii. マネージャー、店長 iv. エリアマネージャー・本部統括 v. エンドユーザー vi. 保護者・家族 vii. hacomono社員 viii. アプリケーション ◦ 多い。。。 • 業務フローをストーリーで描くことで、より具体化できる 13

14. 私がある機能の開発時に作ったお客様の実際の業務フロー図。 hacomonoでやるやらないを記載する。やる 場合は、何をどうやるか。やらない場合どういう運用にしていくのか？を整理したもの。 具体例としては 14

15. 3 仕様はチームで丁寧に扱う 15

16. • 開発者に、仕様ガチガチに要件として出しちゃっていませんか？ or 無思考で丸投げしていませんか？ • 仕様まで決定事項のように要求だしていませんか？そう伝わっていませんか？ こういうこと起きてないか？ 16
 必要なときには仕様に言及することもあってよい。しかし、丁寧に扱いましょう 伝えたいこと
17. • 一般的には、なぜやるのか、なにをつくるかに責任をもつのが PdMと言われている • hacomonoでは要件定義段階で PdMが仕様まで割りとカバーすることがある ◦ 顧客の業務上、仕様まで踏み込まないと価値と整合性が取れないことがある ◦ 仕様まで言及しないと、それだけでは価値を満たせない、正しくは価値を毀損してしまうこともある PdMが仕様に言及する？ 17

18. PdMからの仕様の言及は、決定事項ではない。要求である。なので、開発チーム では議論余地が多分にあるものとして扱うこと。 • それは、PdMが仕様を決めすぎてそのまま進むと、アンチパターンに陥ってしまう ◦ プロダクトの整合性が崩れ一貫性がなくなってしまったり、仕様が複雑になってしまう。 ◦ PdMはどこまでいっても仕様や実装がどうなっているかに責任を持つのは難しい • その中で、開発側とときには意見が合わなくなることもある ◦ でもそれは当たり前 ◦ 意見はあわなくてもいい、目指す方向は同じでも責任領域は違うのでお互いの立場から意見 を出す行為自体が大事 大事にしていること 18

19. 4 まとめ 19

20. 本日伝えたいこと 20
 1. いい要件は、相手をよく知ること。よく知り、よく見極めて、自分たちの価値を出す。 そして、 業務フローは書いても書かれるな、ということ 2. PdMが仕様に言及することもあるが、丁寧に扱おう、ということ
21. おまけ おまけ 21

22. We are hiring! hacomonoはプロダクトマネージャー絶賛募集中です • 本気で顧客の解像度あげてプロダクトづくりしたい方 • 仕様もお手の物、私エンジニアでしたよ、という方 22
 hacomono entrance book
23. イベントもやります。ぜひ 23
 hacomono イベント情報はこちら