3つの決めつけから見る失敗の要件定義

## 今回発表したイベントについて

PeerQuest Inc. （ https://peer-quest.jp/ ）様主催の、#開発PM勉強会（ https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query ）の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。

株式会社Speee プロダクトマネージャー 塚本尚

https://peer-quest.connpass.com/event/229463/

## 発表した内容について

結局行き着いたのは、（あるある話だとは思いますが）**whyとwhatの定義をしっかりす定義すること** でした。
その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表しました。

## サマリ

- howへの決めつけによるプロダクトの失敗確率は相当高い
- howの決めつけ - その1：エンジニア側への決めつけ
- howの決めつけ - その2：ビジネス側への決めつけ
- howの決めつけ - その3：既存のシステム・仕様への決めつけ
- プロダクトマネージャーがhowを決めつけてしまっては、プロダクト開発は失敗すると言える
- よって、whyとwhatの定義をしっかりすべきであり、 howはチームに属すると肝に命じよう

Transcript

1. 3つの決めつけから見る失敗の要件定義 株式会社Speee デジタルトランスフォーメーション事業本部 イエウール事業部 塚本 尚（プロダクトマネージャー） twitter：@nao_tsukamoto 1
2. いきなり問いを・・・・ 要件定義って、何を定義すること・・・？？ 2
3. 私のこたえ whyとwhatをしっかり定義すること である 意味するところ why：実現させたい理由・背景 what：実現させたいこと・条件 how：その条件を満たすための方法 3
4. 決めつけによる失敗の話をします howの決めつけ - その1：エンジニア側への決めつけ howの決めつけ - その2：ビジネス側への決めつけ howの決めつけ - その3：既存のシステム・仕様への決めつけ 4
5. 3つの決めつけから見た失敗 5
6. 前提：サービスのフロー概要 6
7. 失敗その1 howの決めつけ - その1：エンジニア側への決めつけ 7
8. やっちゃったこと whatが抜けたhowの連携をして失敗した 私は、「記事・広告からLPに遷移するときにパラメータをつけるので、会員登録完了時 にそのパラメータをDBに格納するようにしたい」という連携をした エンジニアに実装してもらった しかし、私が提案した方法だとDBに格納されないことがわかった 8
9. なぜ失敗か whatを連携してチームでhowの検討をすべきだったのにもかかわらず、howを決めつけ て実装を連携してしまった 教訓 （あるあるな話ではあるが、）プロダクトマネージャーは、howではなく、whyとwhat に強く向き合うべき それは、私たちがエンジニアレベルで仕様を細かく把握しているわけではないため 9
10. 失敗その2 howの決めつけ - その2：ビジネス側への決めつけ 10
11. やっちゃったこと whatを十分理解せずhowを決めつけてしまったので失敗した 私は、「記事から流入して会員登録されたときを想定して、パラメータをデータベースに 格納できるように」という連携をエンジニアにした しかし、広告から流入して会員登録されたときは、パラメータが引き継ぎできていなかっ た 11
12. なぜ失敗か 広告からの流入の場合を考慮できてなかった 教訓 ビジネス側と私で、今考えているwhatが必要十分かどうかをすり合わせるべきだった プロダクトマネージャーは、自分の考えているwhatが十分なものかに注力すべき それは、開発チームでwhatに強く責任を持てるのは、プロダクトマネージャーだから 12
13. 失敗その3 howの決めつけ - その3：既存のシステム・仕様への決めつけ 13
14. やっちゃったこと 既存の仕様を活用できるはずだ！と決めつけて失敗した 私は、「企業の契約ステータスを管理する仕組みを用いて、企業の情報掲載ページの公 開・非公開を制御してほしい」という連携をした 結果的に、情報掲載ページが意図した通りに制御されなかった 14
15. なぜ失敗か 既存の仕様が、過去定義した通りに利用されているはずだと思いこんでいた 教訓 既存の仕様が現在どうのように利用されているか、をちゃんと把握すべき オペレーションが変わることや想定外の用途で利用されていることはよくある 現状の仕様への決めつけが、チームでhowを検討する余地をなくす 15
16. そもそも 私は要件と仕様を、以下のように捉えている 要件：実現したいことを成すために必要な条件 仕様：条件を実現する方法 howの決めつけは、仕様の決めつけである 仕様をエンジニアレベルで細かく把握していないので、現状のhowを活用できるかどうかを自 身だけで判断すべきではない 16
17. まとめ howの決めつけによるプロダクトの失敗確率は相当高い プロダクトマネージャーが、howを決めつけてしまっては失敗すると言える よって、whyとwhatの定義をしっかりすべきであり、 howはチームに属すると肝に命じ よう 17
18. さいごにちょっと宣伝1 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開し ているので、お気軽にご連絡ください 18
19. さいごにちょっと宣伝2 我々は、今はまだその恩恵を受けづらい領域に対する価値提供によって、エンドユーザーから 事業者まで誰もがデジタル化の恩恵を受けられる、「DXの民主化」が実現された世の中を目 指していく、という思いを込めて「DX Democracy」を策定しました。 19