Slide 1

Slide 1 text

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


Slide 2

Slide 2 text

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


Slide 3

Slide 3 text

0 hacomonoについて 3


Slide 4

Slide 4 text

4


Slide 5

Slide 5 text

5


Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

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


Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

2 顧客をよく知る 9


Slide 10

Slide 10 text

● お客様の業務の中身わかっていますよね? ● お客様の現状の業務、そのまま機能つくろうとしていないか? こういうこと起きてないか? 10
 お客様のその業務本当に必要ですか?よく知り、よく見極めて、自分たちの価値を出す 伝えたいこと

Slide 11

Slide 11 text

要件定義前の業務の把握 hacomonoでの大きめの新機能開発においては、要件定義の前段で以下を行う ● パイロットとなるお客様が決まる ↓ ● PdMも直接打ち合わせして、ヒアリング。 現場・現地に行く ↓ ● 現状のシステムでできることをベースに、 hacomonoで実現させたいフローをつくっていく ↓ ● 現状や課題を整理して、要件を洗い出していく ↓ ● ︙ 11


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

● 開発者に、仕様ガチガチに要件として出しちゃっていませんか? or 無思考で丸投げしていませんか? ● 仕様まで決定事項のように要求だしていませんか?そう伝わっていませんか? こういうこと起きてないか? 16
 必要なときには仕様に言及することもあってよい。しかし、丁寧に扱いましょう 伝えたいこと

Slide 17

Slide 17 text

● 一般的には、なぜやるのか、なにをつくるかに責任をもつのが PdMと言われている ● hacomonoでは要件定義段階で PdMが仕様まで割りとカバーすることがある ○ 顧客の業務上、仕様まで踏み込まないと価値と整合性が取れないことがある ○ 仕様まで言及しないと、それだけでは価値を満たせない、正しくは価値を毀損してしまうこともある PdMが仕様に言及する? 17


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

4 まとめ 19


Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

おまけ おまけ 21


Slide 22

Slide 22 text

We are hiring! hacomonoはプロダクトマネージャー絶賛募集中です ● 本気で顧客の解像度あげてプロダクトづくりしたい方 ● 仕様もお手の物、私エンジニアでしたよ、という方 22
 hacomono entrance book

Slide 23

Slide 23 text

イベントもやります。ぜひ 23
 hacomono イベント情報はこちら

Slide 24

Slide 24 text

24