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
   

   View Slide

2. いきなり問いを・・・・
   要件定義って、何を定義すること・・・？？
   2
   

   View Slide

3. 私のこたえ
   whyとwhatをしっかり定義すること である
   意味するところ
   why：実現させたい理由・背景
   what：実現させたいこと・条件
   how：その条件を満たすための方法
   3
   

   View Slide

4. 決めつけによる失敗の話をします
   howの決めつけ - その1：エンジニア側への決めつけ
   howの決めつけ - その2：ビジネス側への決めつけ
   howの決めつけ - その3：既存のシステム・仕様への決めつけ
   4
   

   View Slide

5. 3つの決めつけから見た失敗
   5
   

   View Slide

6. 前提：サービスのフロー概要
   6
   

   View Slide

7. 失敗その1
   howの決めつけ - その1：エンジニア側への決めつけ
   7
   

   View Slide

8. やっちゃったこと
   whatが抜けたhowの連携をして失敗した
   私は、「記事・広告からLPに遷移するときにパラメータをつけるので、会員登録完了時
   にそのパラメータをDBに格納するようにしたい」という連携をした
   エンジニアに実装してもらった
   しかし、私が提案した方法だとDBに格納されないことがわかった
   8
   

   View Slide

9. なぜ失敗か
   whatを連携してチームでhowの検討をすべきだったのにもかかわらず、howを決めつけ
   て実装を連携してしまった
   教訓
   （あるあるな話ではあるが、）プロダクトマネージャーは、howではなく、whyとwhat
   に強く向き合うべき
   それは、私たちがエンジニアレベルで仕様を細かく把握しているわけではないため
   9
   

   View Slide

10. 失敗その2
    howの決めつけ - その2：ビジネス側への決めつけ
    10
    

    View Slide

11. やっちゃったこと
    whatを十分理解せずhowを決めつけてしまったので失敗した
    私は、「記事から流入して会員登録されたときを想定して、パラメータをデータベースに
    格納できるように」という連携をエンジニアにした
    しかし、広告から流入して会員登録されたときは、パラメータが引き継ぎできていなかっ
    た
    11
    

    View Slide

12. なぜ失敗か
    広告からの流入の場合を考慮できてなかった
    教訓
    ビジネス側と私で、今考えているwhatが必要十分かどうかをすり合わせるべきだった
    プロダクトマネージャーは、自分の考えているwhatが十分なものかに注力すべき
    それは、開発チームでwhatに強く責任を持てるのは、プロダクトマネージャーだから
    12
    

    View Slide

13. 失敗その3
    howの決めつけ - その3：既存のシステム・仕様への決めつけ
    13
    

    View Slide

14. やっちゃったこと
    既存の仕様を活用できるはずだ！と決めつけて失敗した
    私は、「企業の契約ステータスを管理する仕組みを用いて、企業の情報掲載ページの公
    開・非公開を制御してほしい」という連携をした
    結果的に、情報掲載ページが意図した通りに制御されなかった
    14
    

    View Slide

15. なぜ失敗か
    既存の仕様が、過去定義した通りに利用されているはずだと思いこんでいた
    教訓
    既存の仕様が現在どうのように利用されているか、をちゃんと把握すべき
    オペレーションが変わることや想定外の用途で利用されていることはよくある
    現状の仕様への決めつけが、チームでhowを検討する余地をなくす
    15
    

    View Slide

16. そもそも
    私は要件と仕様を、以下のように捉えている
    要件：実現したいことを成すために必要な条件
    仕様：条件を実現する方法
    howの決めつけは、仕様の決めつけである
    仕様をエンジニアレベルで細かく把握していないので、現状のhowを活用できるかどうかを自
    身だけで判断すべきではない
    16
    

    View Slide

17. まとめ
    howの決めつけによるプロダクトの失敗確率は相当高い
    プロダクトマネージャーが、howを決めつけてしまっては失敗すると言える
    よって、whyとwhatの定義をしっかりすべきであり、 howはチームに属すると肝に命じ
    よう
    17
    

    View Slide

18. さいごにちょっと宣伝1
    Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
    もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開し
    ているので、お気軽にご連絡ください
    18
    

    View Slide

19. さいごにちょっと宣伝2
    我々は、今はまだその恩恵を受けづらい領域に対する価値提供によって、エンドユーザーから
    事業者まで誰もがデジタル化の恩恵を受けられる、「DXの民主化」が実現された世の中を目
    指していく、という思いを込めて「DX Democracy」を策定しました。
    19
    

    View Slide